You are currently browsing the tag archive for the ‘service producers’ tag.
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
L’obiettivo di SOA è allineare le capacità dell’IT agli obiettivi di business: secondo le statistiche, il principale motivo per cui molte aziende hanno adottato, o stanno adottando, questa strategia è l’agilità che essa consente al sistema informativo.
La metafora dei mattoncini del LEGO rende bene l’idea: diversi assemblaggi degli stessi componenti possono produrre rapidamente costruzioni diverse, soddisfacendo i requisiti di business in un tempo ridotto, ma con una qualità superiore, rispetto all’approccio IT tradizionale.
Oltre alle dichiarazioni di principio e alla corretta gestione delle informazioni all’interno dell’azienda, è necessario però che esista un quadro di riferimento architetturale in cui i servizi che vengono sviluppati trovino una adeguata collocazione. Oltre al modello da fornire ai progettisti, servono una infrastruttura tecnologica e un piano di investimenti per la sua realizzazione.
La figura seguente mostra uno schema sintetico di architettura di riferimento, in cui vengono evidenziati i Service Consumers e i Service Providers insieme a tutti i servizi condivisi che comprendono quelli applicativi e quelli infrastrutturali.
Come usare la SOA Reference Architecture
Il primo passo per l’adozione della SOA Reference Architecture di BEA è la sostituzione dei generici tipi di componente descritti dal modello con i componenti specifici del cliente: per esempio, “Portali” può essere specificato come “Portale Risorse Umane” e “Portale Customer Service”. “Packaged Applications” può diventare “SAP” e “Oracle Financials”. “Atomic Business Activities” può comprendere “Emissione dell’ordine” e “Pagamento”.
L’azienda può anche identificare come i nuovi progetti si adattano allo scenario complessivo, per esempio mettendo a disposizione un processo di business condiviso “Aggiunta Nuovo Prodotto” o fornendo un data service “Cliente”.
Il risultato è una istanza concreta della SOA Reference Architecture – un modello specifico per quell’azienda che diventa la definizione formale della architettura SOA. Fornisce lo schema per classificare l’infrastruttura e i servizi condivisi; definisce le relazioni tra la SOA desiderata e l’architettura esistente. Specifica la visione architetturale e determina il percorso da seguire per la sua costruzione. Infine, serve come cruciale strumento di comunicazione e di verifica della conformità.
Oltre a focalizzare le risorse dello sviluppo nella creazione delle soluzioni, le aziende devono gestire i progetti che ne risultano. La SOA Reference Architecture può servire da modello per un singolo progetto così come per l’intera SOA.
Un architetto e il responsabile del progetto possono usarla per scomporre le funzionalità di business in un insieme di servizi, assegnare la responsabilità per ciascun blocco al gruppo di sviluppo più adatto, monitorare l’implementazione.
In questo modo si possono ottenere il parallelismo nello sviluppo dei componenti, l’eliminazione delle duplicazioni, una efficace attribuzione dei costi a diverse voci di bilancio.
Il white paper
La SOA Reference Architecture di BEA fornisce benefici di lungo termine alle aziende fornendo un modello per costruire una SOA di livello enterprise in modo scalabile.
La potenza di SOA è la sua flessibilità. Ogni azienda può adattare i suoi particolari asset IT al suo business specifico.
Tuttavia questa potenza è inutile senza controllo: è necessario un modello che indirizzi il lavoro e permetta di verificarne i risultati.
Usando una SOA Reference Architecture, le aziende possono stabilire quali servizi dovrebbero costruire e quando farlo.
Possono aumentare il parallelismo e ridurre le duplicazioni nel portafoglio dei progetti di sviluppo. Possono imporre una governance efficace basata su policy che applicano correttamente i principi generali a circostanze specifiche.
La chiave per ottenere questi benefici è la conoscenza del posto che ciascun progetto e ciascun servizio occupano nello schema più ampio della SOA a livello enterprise. Usando la SOA Reference Architecture, sia le persone di business che quelle dell’IT possono indicare con precisione il ruolo di ogni servizio esistente o proposto.
Le dipendenze, le mancanze e le duplicazioni appaiono evidenti. La pianificazione, la cooperazione e l’approvvigionamento diventano più semplici. Le aziende possono finalmente trasformare l’agilità in un processo gestibile. BEA ha tracciato la strada con una SOA Reference Architecture basata su anni di esperienza nel mondo reale.
Un white paper che espone in dettaglio il valore della costruzione di una SOA Reference Architecture può essere scaricato dal sito BEA, nella sezione SOA.
La struttura di consulenza di BEA offre diversi servizi – che saranno discussi in altri post su questo blog – mirati alla definizione di un’architettura di riferimento specifica per il cliente e alla sua realizzazione.
Caffè con BEA 