You are currently browsing the category archive for the ‘Prodotti’ category.
SCA fornisce un modello di programmazione per la costruzione di applicazioni e di soluzioni basate su una Service Oriented Architecture. Il modello si basa sull’idea che le funzionalità di business possono essere composte a partire da una serie di servizi, che vengono assemblati insieme per creare soluzioni che servono un particolare requisito di business. Queste soluzioni sono definite Composite Applications, e sono rappresentate graficamente da Assembly Models. Le composite application possono contenere sia nuovi servizi creati specificamente per la applicazione che servizi esistenti offerti da sistemi e applicazioni esistenti, riusati come parti della composizione. La figura seguente mostra un esempio di assembly model per una composite application.
SCA Assembly Model (cliccare sulla figura per ingrandire)
Il modello di programmazione SCA è uno standard in via di formalizzazione a cura della iniziativa Open Composite Services Architecture (OpenCSA) di OASIS. SCA standardizza le informazioni scambiate tra differenti tools, assicurando che i servizi e i componenti che costituiscono un’applicazione vengano modellati, rappresentati e descritti in modo coerente. La coerenza significa che i servizi costruiti in strumenti differenti, usando differenti paradigmi di programmazione possono facilmente essere riusati e portati velocemente in produzione, aiutando le organizzazioni a realizzare l’efficacia promessa da SOA.
BEA usa SCA come standard per facilitare lo scambio di informazioni tra i prodotti BEA, come ALSB, ALDSP, ALBPM, WLS, WLP, WLI e Tuxedo-SALT. BEA ha intenzione di utilizzare SCA anche per facilitare scambio di informazioni con prodotti di terze parti.
Ciò significa che servizi fornite da piattaforme per data services, da service bus, da strumenti per business process modeling, etc. possono essere catturati e rappresentati in un formato comune, e poi riusati facilmente per comporre altre applicazioni di business.
Il Service Assembly Modeler
Il Service Assembly Modeler (SAM) di BEA supporta la composizione e la visualizzazione di applicazioni composite. La composizione avviene in un ambiente di sviluppo basato su Eclipse. In questo ambiente il gruppo di sviluppo può assemblare rapidamente applicazioni composite riusando servizi che esistono già, o creando nuovi servizi. SAM consente agli sviluppatori di vedere il modello di assemblaggio delle applicazioni composite, così come la definizione in linguaggio XML della composizione.
AquaLogic Enterprise Repository (ALER) consente alle organizzazioni di gestire le applicazioni composite e i servizi riusabili. I gruppi di sviluppo possono sottomettere le loro applicazioni composite in ALER direttamente da SAM. ALER fornisce visibilità alle applicazioni e ai servizi esistenti, tracciabilità tra le applicazioni composite e le loro dipendenze, dati analitici che misurano il riuso e facilitano la analisi di impatto.
Il Service Assembly Modeler (SAM) è un plug-in per Eclipse che fornisce strumenti per lavorare con i modelli di assemblaggio SCA per i servizi compositi. SAM viene distribuito con AquaLogic Enterprise Repository (ALER) e altri prodotti della famiglia BEA AquaLogic.
Si può usare SAM per:
- Rendere compatibili con SCA le applicazioni AquaLogic esistenti e poi creare service assembly model basati su queste applicazioni.
- Visualizzare composizioni SCA e altri artefatti di tipo service assembly model.
- Sottomettere modelli in AquaLogic Enterprise Repository (ALER).
Links
Introduzione a SCA:
http://en.wikipedia.org/wiki/Service_component_architecture
http://weblogs.java.net/blog/meeraj/archive/2008/01/introducing_ser.html
Prodotti BEA:
http://e-docs.bea.com/aler/docs30/pdf/SAMhelp.pdf
http://www.bea.com/framework.jsp?CNT=pr01891.htm&FP=/content/news_events/press_releases/2007
http://ecommerce.bea.com/showproduct.jsp?family=WLS&major=10.3SCA&minor=-1
Specifiche:
L’attuale insieme delle specifiche SCA sul sito OSOA comprende:
SCA Assembly Model
SCA Policy Framework
SCA Java Client & Implementation
SCA BPEL Client & Implementation
SCA Spring Client & Implementation
SCA C++ Client & Implementation
SCA Web Services Binding
SCA JMS Binding
La gestione degli aspetti di Authentication, Authorization ed Accounting (AAA) riveste un’importanza fondamentale per la sicurezza sia delle applicazioni usate all’interno dell’azienda stessa che di quelle utilizzate per proporre servizi alla propria clientela.
Questo a maggiore ragione in questi ultimi anni in cui la legge sulla privacy ha introdotto ulteriori requisiti e spostato la sicurezza da un solo concetto di difesa per chi eroga un servizio ad un meccanismo di difesa di chi usa quel servizio e come tale è costretto a fornire dati sensibili.
Le attuali soluzioni di Identity Management che implementano le funzioni di AAA hanno risolto egregiamente gli aspetti di Autenticazione che, tramite il Single Sign-On, permettono inoltre di unificare e centralizzare il controllo e la profilazione degli utenti.
Questo non è vero per quanto riguarda l’Autorizzazione soprattutto se questa è intesa come gestione dell’entitlement (cosa un utente è abilitato a fare) di tipo totalmente centralizzata, fortemente granulare e con alto gradi di dinamicità.
Ad oggi molto spesso la gestione dell’entitlement è implementata all’interno della singola applicazione rendendo difficile, se non impossibile la gestione dell’Autorizzazione in una architettura orientata ai servizi, dove l’applicazione non conosce a priori il contesto nel quale il servizio che offre viene “consumato”.
Ma cosa si intende esattamente per Entitlement?
La parola entitlement, specialmente se tradotta dal dizionario, può significare cose diverse a persone diverse. In questo contesto, per entitlement si intende un insieme di privilegi che governano quello che l’utente di una applicazione è abilitato a fare.
Un entitlement è la relazione tra una risorse dell’applicazione (o in forma più astratta un oggetto di business) e l’insieme di utente/gruppo/ruolo, rappresentata secondo una struttura gerarchica.
Gli entitlement:
- sono soggetti ad una massima proliferazione;
- necessitano di considerare diverse informazioni di contesto prima di effettuare una decisione;
- devono essere consistenti all’interno dell’infrasttuttura e all’insieme delle applicazioni;
- devono essere allineati con i sistemi di Identity Management;
- devono evolvere indipendentemente dalle applicazioni e dai servizi;
Tuttavia….
ad oggi la maniera più comune di implementare gli entitlements è cablarli nel codice dell’applicazione!!!
Per rispondere a questa esigenza BEA ha sviluppato la soluzione BEA AquaLogic Enterprise Security che permette di esternalizzare, unificare e semplificare la gestione delle politiche di autorizzazione ovvero degli entitlement.
La figura seguente mostra un esempio di applicazione di trading. Questa applicazione può essere usata da differenti tipologie di utenti, ma solo gli utenti che sono traders possono fare operazioni di acquisto/vendita. Inoltre, i traders posso operare solo per gli specifici conti per i quali sono autorizzati e solo fino ad uno specifico importo per ogni definito per ogni conto.
Come si può vedere nel secondo caso, la decisione è rimossa dall’applicazione e valuta a runtime dal motore di BEA AquaLogic Enteprise Security.
Utilizzando BEA AquaLogic Enterprise Security all’interno della propria infrastruttura si possono quindi definire le linee guida con cui devono essere sviluppate le applicazioni per quanto riguarda la funzionalità di gestione dell’Autorizzazione, ovvero:
- nessuna policy cablata nel codice
- nessuna policy dipendente da un file di configurazione
- scrittura del codice uniforme verso un unico layer per la gestione della sicurezza
Come funziona AquaLogic Enteprise Security in dettaglio?
Al prossimo post…
Nella versione di Guardian rilasciata agli inizi di Febbraio 2008 ci sono novità significative.
Durante lo scorso anno abbiamo avuto indicazioni da molti Grandi Clienti che ritenevano che l’auto installazione (auto-deploy) dell’Agente di Guardian fosse in contrasto con le policy di sicurezza e di auditing in essere.
Per queste ragioni abbiamo rimosso, a partire da Guardian 1.0.7, la funzione di auto-deploy, e di conseguenza l’Agente dovrà essere installato manualmente, ad esempio tramite la BEA WebLogic Console.
Nel prossimo futuro, a partire dalla release WLS 10.3, l’Agente Guardian sarà incluso direttamente in WLS Server e non sarà più necessario installarlo.
Per maggiori informazioni e per scaricare gratuitamente BEA Guardian cliccare QUI
Una caratteristica utile di Weblogic Server, dalla versione 9 in poi, è il cosiddetto production redeployment: una strategia di deployment delle applicazioni web che consente la coesistenza di due versioni dell’applicazione, garantendo il rilascio di una nuova release senza interrompere il servizio offerto agli utenti. E’ utile per la correzione di bug o per l’aggiunta di nuove funzionalità, senza dover chiudere l’applicazione nè aggiungere server ridondanti per redirigere il traffico durante la sostituzione.
Quando la nuova versione viene attivata, la vecchia viene mantenuta in funzione dal server finchè le sessioni utente già attive vengono completate oppure vanno in time out: nel frattempo la nuova versione comincia a servire tutte le nuove richieste. La figura seguente mostra come le richieste http vengono gestite da WLS:
Gli utenti che stavano navigando non subiscono alcun effetto dell’attivazione della nuova versione, quindi non è necessario pianificare finestre temporali di rilascio, magari di notte o nel week end come a volte si è costretti a fare. Versioni successive delle applicazioni possono essere storicizzate sui server, per cui è sempre possibile tornare indietro ad una versione precedente con la stessa modalità trasparente agli utenti. Inoltre, se una nuova versione viene attivata in Administration Mode, questa diviene visibile solo sul canale di amministrazione di WLS: ciò consente di eseguire test di corretto funzionamento prima dell’apertura al normale traffico utente.
Le operazioni di deployment e di attivazione delle versioni possono, come tutte le operazioni di amministrazione, essere eseguite attraverso la console web di WLS, attraverso script ANT o WLST, programmi java o strumenti esterni di configuration management. Alcuni tipi di applicazione non possono essere gestiti con questa modalità di rilascio, che è limitata a web applications e enterprise applications: vedere la documentazione online di WLS per i dettagli.
Un altro prodotto BEA finisce nel quadrante Leader di Gartner: è il BPM (Business Process Management). Il report Magic Quadrant Report for Business Process Management Suites (BPM)” descrive in dettaglio quali tipi di processo possono essere migliorati con un BPM, i punti di forza e di debolezza di 22 fornitori di soluzioni, ed i 10 fattori più importanti che un’azienda deve considerare nell’acquisto di un prodotto di BPM. Il report completo è scaricabile a questo indirizzo. Buona lettura.
“Non è un blog, è una brochure!” Questo è stato il commento di un amico che ha letto Caffè con BEA e sigh, io sarei tra i colpevoli. In effetti nel mio post precedente ho parlato e dato un giudizio positivo di un prodotto BEA, WebLogic Integration. Chiedo venia, purtroppo posso parlare di ciò che conosco. Per tentare di farmi perdonare, vi propongo un’altra riflessione, certo basata su WLI (vedi sopra) ma applicabile a tutti i prodotti dello stesso tipo.Spesso mi sono imbattuto in clienti che mi chiedevano: perchè dovrei usare un motore di processi ? Ecco, secondo me, le ragioni per utilizzarlo e quelle per farne a meno:I motivi del SI
- si sviluppa più in fretta (perchè i wizard mi nascondono le complessità delle interfacce da usare)
- si fà l’integration test più in fretta (perchè il debug di front-end e back-end è integrato)
- la gestione dello stato dei processi è già pronta e non richiede ulteriore sviluppo
- il monitor dei processi in produzione è già pronto e non richiede ulteriore sviluppo
- è più semplice modificare l’applicazione quando è già in produzione
I motivi del NO
- non ho controllo del codice perchè uso molti wizard e componenti già pronti
- non posso realizzare certi trucchi, perchè lo strumento me lo impedisce
- vorrei poter controllare alcuni dettagli dei processi in esecuzione, mentre lo strumento me ne visualizza altri
Le due liste non sono esaustive, anzi vi esorto a completarle o a modificarle secondo la vostra esperienza. Per quanto mi riguarda, e qui rischio l’ennesima stroncatura, i sostenitori della seconda lista finiscono spesso per riscriversi un process engine quasi per intero e dunque, io che sono di natura un pigro, mi chiedo: non era meglio prenderlo già pronto? 😉
Tempo fa partecipai ad un avvincente progetto di integrazione: inserimmo un “bus” per lo scambio di messaggi fra le diverse applicazioni di una SIM (Società di Intermediazione Immobiliare) e grazie a questo “strano oggetto” i traders ed i loro capi potevano vedere informazioni tra loro correlate ma che risiedevano in sistemi differenti ed isolati. Le modifiche avvenivano in tempo reale ed i dati erano dunque sempre aggiornati.
Ma non fu questa la parte che più piacque al cliente. L’iniziativa ebbe successo grazie alla rapidità con la quale l’IT riusciva a realizzare le richieste dell’utente finale. Oltre naturalmente, all’affidabilità del sistema, che non perdeva un messaggio.
Se, dopo quasi dieci anni, cito ancora quell’esperienza è perchè il confronto con la realtà di oggi appare ancora istruttivo: le interfaccie di comunicazione fra il bus e le applicazioni da integrare venivano sviluppate a mano di volta in volta, partendo da un set di librerie proprietarie. Non esisteva il concetto di processo o di orchestrazione. Il mapping dei dati era realizzato con uno strumento visuale che alimentava un motore esterno al bus. Forse ciò che è cambiato meno da allora ad oggi è la trasformazione dei messaggi. Eravamo già ad uno stadio evoluto, anche se non utilizzammo standards come XML.
In un progetto più recente che ho potuto osservare da vicino, il system integrator ha semplificato la componente di integrazione ed introdotto l’uso di un motore di processi utilizzando WebLogic Server e WebLogic Integration. Il bus comunica con le applicazioni via SOAP, RMI o JDBC, ed ha integrato la componente di processo consentendo la creazione di nuove funzionalità basate su quelle offerte dei sistemi esterni.
WebLogic Integration ha fatto la parte del leone. Ha consentito l’integrazione delle applicazioni e lo sviluppo dei processi in pochissimo tempo. L’infrastruttura di test inclusa nel prodotto ha ridotto i tempi di collaudo e le funzionalità del motore hanno sollevato il system integrator dall’onere di dover sviluppare da sé la logica di stato e persistenza di messaggi e di processi.
Naturalmente non solo BEA Systems offre strumenti di questo tipo. Ma ciò che voglio evidenziare, al di là dei prodotti utilizzati, è il progresso avvenuto in questo campo. Si programmano sempre meno le interfaccie di comunicazione (che son sempre state una materia ostica, nello sviluppo e nel collaudo) e si riduce sempre di più il tempo di realizzazione di nuove funzionalità, grazie all’uso dei process engine come WebLogic Integration.
Oggi affronto un progetto d’integrazione con grande serenità, convinto che l’adozione di WebLogic Integration sollevi il team da molto lavoro inutile, elimini le cause di tanti errori e consenta di raggiungere l’obiettivo con tempi certi e, cosa più importante, con la soddisfazione del cliente.
La collaborazione tra BEA ed Italtel continua con una intervista a Marco Casucci, Head of Services and Services Enabler Unit. Italtel, basandosi sulla WebLogic Communication Platform, è riuscita in breve tempo, e prima in Europa, ad implementare e lanciare sul mercato una soluzione innovativa e dirompente per il mercato delle Telecomunicazioni: la parola d’ordine è Convergenza, di reti, risorse, servizi, …
Per una lettura più approfondita clicca qui.