Nei precedenti articoli abbiamo parlato di SOA sia dal punto di vista architetturale che delle metodologie di analisi e di design. In questo articolo introdurremo uno dei componenti architetturali fondamentali nelle achitetture a servizi: il Service Bus.

Introduzione

Nei precedenti articoli abbiamo parlato di SOA sia dal punto di vista architetturale (vedere [1]) che delle metodologie di analisi e di design (vedere [2]) .

Un‘azienda che decide di evolvere il proprio sistema informativo verso una architettura SOA deve fare diverse scelte e fronteggiare numerose sfide.

In [3] e [4] abbiamo visto come sia indispensabile capire il livello di maturità  dell‘organizzazione e definire in base a questa una roadmap che definisca i passi aziendali (organizzativi, tecnici, metodologici e culturali) per definire un processo evolutivo ed incrementale con l‘obiettivo di una architettura SOA matura.

In [5] abbiamo parlato di Service Oriented Integration (SOI): i principi Service Oriented applicati alle problematiche d‘integrazione.

In questo articolo introdurremo uno dei componenti architetturali fondamentali nelle achitetture a servizi: il Service Bus.

SOA & il Service Bus

I servizi SOA devono essere in grado di comunicare tra di loro attraverso un canale di comunicazione: il SOA bus.
Da un punto di vista architetturale il SOA bus è un layer che deve mettere a disposizione uno strato di comunicazione tra i servizi.
Scopo dell‘Enterprise Service Bus (ESB) è fornire un‘infrastruttura che centralizzi funzionalità  quali supporto alla comunicazione sincrona ed asincrona basata su messaggi, intelligent routing, supporto alla trasformazione dei dati, supporto alla connettività  verso EIS eterogenei, …

Ad oggi non esistono specifiche relative al SOA Bus: cos‘è, quale funzionalità  deve fornire, come è composto, ecc …

Di fatto, oggi, sono percorribili due strade: “costruirlo” in modo applicativo sfruttando le tecnologie esistenti (CORBA, J2EE, Web Services), rivolgersi al mercato acquistando un prodotto ESB (alcuni player importanti sono IBM, Bea, Sonic, Iona, Cape Clear, SeeBeyond, ecc…) o utilizzare un prodotto open source.

Ma perché si parla di ESB e non di Integration Broker, i tradizionali Middleware d‘integrazione presenti da anni sul mercato e che hanno (almeno in parte) i requisiti per soddisfare a tele esigenza?

EAI: gli Integration Broker

I tradizionali Middleware di integrazione sono basati su un modello di tipo hub-and-Spoke (“a stella”). In tali architetture, le operazione di data mapping, data transformation e message routing sono centralizzate nell‘Hub (il “fulcro della raggiera”) e svolte dall‘Integation Broker, il componente centrale dell‘Integration Middleware.

Da un punto di vista architetturale, l‘Integration Broker rappresenta l‘interfaccia unica attraverso cui transita ogni richiesta di comunicazione tra sistemi applicativi disomogenei che devono in qualche misura interoperare.

In questo modo, tutte le problematiche/operazioni di integrazione (messaging, intelligent routing, data trasformation, data mapping, …) risultano essere centralizzate, riusabili e facilmente amministrabili.

I trade-off di un simile approccio sono dati dal fatto che l‘Hub rappresenta un potenziale “collo di bottiglia” (bottleneck), un potenziale “single point of failure” e presenta difficoltà  di scalabilità .
Inoltre, gran parte delle suite di integrazione ad oggi sul mercato, sono state sviluppate in tempi in cui o non esistevano “standard” o questi non erano sufficientemente maturi e stabili. I fornitori Software, hanno così sviluppato soluzione proprietarie per risolvere le problematiche tipiche d‘integrazione.
In questo modo, le suite EAI spesso forniscono tecnologie (API, script, motori di regole di trasformazione, composizione di processi, connettori proprietari, …) proprietarie per l‘implementazione della logica di integrazione, non consentendo il riuso e l‘interoperabilità  tra differenti piattaforme.
Le competenze necessarie per lo sviluppo e la gestione di tali soluzioni EAI, sono quindi garantite quasi unicamente dal fornitore del Prodotto (producendo una situazione di vendor lock-in) con conseguente svantaggio tecnico ed economico (licenze, manutenzione e consulenze del prodotto).

La situazione è tale per cui, ad oggi, nella maggior parte dei casi, l‘adozione di tali suite ha comportato problemi in termini di costi, manutenzione e interoperabilità .

Enterprise Service Bus

Un Enterprise Service Bus (ESB) è invece un prodotto per l‘integrazione basato su standard di mercato e su un‘architettura orientata ai servizi che fornisce le funzionalità  tipiche dei tradizionali EAI Broker, con due fondamentali differenze.

La prima è tecnologica: gli ESB espongono tramite “standard” funzionalità  che i tradizionali Integration Broker fornivano tramite tecnologie proprietarie. Esempi di standard ampiamente utilizzati sono:JDBC, JCA, JMS, JMX , WSDL, UDDI, SOAP, JAX-RPC, JAXM, JAXR, SSAJ, XQuery, XPath, JBI, BP4WLS,…

La seconda differenza è architetturale: un ESB non si basa su un‘architettura “monolitica” di tipo Hub-and-spoke, ma su di una architettura distribuita a bus condiviso SOA (Service Oriented Architecture) oriented. In altre parole, in un‘infrastruttura ESB, tutte le applicazioni sono integrate ed operano come “servizi”.

Le logica d‘integrazione non è più centralizzata in un hub centrale, ma è distribuita lungo gli endpoint connessi al bus. Decentralizzando la logica di integrazione lungo il bus si migliora la scalabilità  teorica ed è possibile effettuare il deploy delle funzionalità  d‘integrazione strettamente necessarie (selective-deployment).

L‘utilizzo degli standard permette di ridurre le soluzioni proprietarie chiuse e costose tipiche dei tradizionali prodotti EAI riducendo il vendor lock-in ed i costi legati alle consulenze specialistiche ed alle licenze.

Risulta evidente che l‘aumento di interoperabilità  dato dall‘uso di protocolli e tecnologie standard, riduce i rischi aziendali complessivi indotti dall‘adozione di un middleware (in teoria lo rende “sostituibile”).
Utilizzando i Web Services, è possibile disaccoppiare l‘interfaccia del servizio (WSDL) dall‘implementazione del servizio stesso. Oltre a tale disaccoppiamento l‘ESB permette di separare la logica del servizio dalla logica di processo. In questo modo le interdipendenze tra i servizi non sono più implementate/cablate nei servizi stessi. Ottenuti questi endpoint astratti e omogenei, è possibile “orchestrare” i servizi per ottenere veri “processi di business”. Tutte le regole e le logiche di routing e trasformazione sono così gestite mediante configurazioni seguendo il mantra ESB: “configure, don‘t code”.
Un ESB permette, in linea con le best practices SOA, un‘integrazione “incrementale”: è possibile infatti di integrare in momenti differenti le varie parti di un sistema attraverso un approccio cosiddetto Leave-and-layer: si lascia inalterato l‘esistente portfolio dei servizi Legacy e di applicazioni esistenti riconciliando le loro differenze (logica e dati) in un nuovo layer (l‘ESB !).

Un ESB quindi, rispetto ai prodotti tradizionali di integrazione, dovrebbe ridurre il vendor lock-in, i costi di licenze e manutenzione e permettere una maggiore garanzia di portabilità  del codice e di interoperabilità .

Ad oggi, praticamente quasi tutti i principali produttori di Software hanno realizzato o intendono realizzare un proprio prodotto ESB da proporre sul mercato.

Da un lato società  che proponevano broker di integrazione tradizionali (es: IBM e SeeBeyond) hanno affiancato alla loro suite d‘integrazione anche dei prodotti ESB, dall‘altro le società  di dimensioni più limitate (come Sonic o Fiorano) che proponevano sistemi di comunicazioni a messaggi hanno migliorato il loro prodotto aggiungendo nuove features. Altri venditori hanno riadattato le loro integration suite effettuando di fatto un rebrand del loro prodotto al fine di ridurre i costi (licenze e manutenzione), altri ancora hanno provveduto a “sfruttare” il trend fornendo una versione “light” del prodotto Integration Broker in veste di ESB.

Dentro un‘ESB

• Iniziamo ad entrare un po‘ di più nei dettagli elencando alcune delle caratterisitche fondamentali che un ESB deve implementare:
• Trasformazione (sintattica e semantica) e mapping dei messaggi da un formato all‘altro. Questa trasformazione può comprendere anche l‘arricchimento dei messaggi con informazioni necessarie (es: metadati)
• Delivery dei messaggi con autenticazione, autorizzazione, non ripudio; in generale deve essere garantito il supporto middleware alla comunicazione asincrona.
• Gestione avanzata del routing dei messaggi, ad esempio sulla base del contenuto del messaggio stesso (questo permette a un servizio di mandare un messaggio senza conoscerne la destinazione).
• Funzionalità  di amministrazione per la gestione e configurazione del BUS
• Esposizione di servizi middleware di supporto alla logica di business: gestione delle transazioni, logging, audit,
• Utilizzo di più protocolli di comunicazione (tramite appositi Adapter) per facilitare l‘integrazione

Parte queste funzionalità  possono essere fornite da un middleware che supporti la comunicazione asincrona a messaggi (MOM): rispetto a questo un ESB è l‘evoluzione da un puro supporto alla comunicazione ad un sistema integrato di composizione di servizi. Si può affermare che gli ESB realizzano la parte di middleware richiesta da architetture SOA utilizzando sistemi a scambio di messaggi.

ESB Container

In analogia ai container J2EE (che erano contenitori di componenti Java Enterprise), possiamo dire che gli ESB sono contenitori di servizi: parliamo quindi di ESB container.
I Container forniscono le facilities nella gestione dei servizi (es: ciclo di vita), nelle modalità  di comunicazione (es: gestione degli endpoint dei messaggi e modalità  di inoltro) e di gestione delle risorse (es: resource pool); inoltre forniscono tipiche funzionalità  infrastrutturali di middleware come monitoring, logging, audit.

Avendo il supporto delle API esposte dal Middleware, lo sviluppatore può concentrarsi sullo sviluppo della logica di business (in questo caso del servizio) rispettando il service contract (cioè i messaggi di richiesta/risposta).

Per fissare le idee, possiamo tracciare un parallelismo (a fini didattici) tra gli EJB e i servizi su ESB: in entrambi i casi viene fornito un Container in cui questi oggetti vengono caricati e di cui vengono utilizzate le funzionalità  middleware. Infatti così come un EJB può accedere ai servizi dell‘Application Server (il Transaction Manager, Resource Pool, Sicurezza, …) un servizio può accedere ai servizi connessi al Message Bus.
Inoltre, così come l‘EJB Container gestisce il ciclo di vita dell‘EJB, un Service Container gestisce il ciclo di vita del servizio: ad esempio gli oggetti di contesto dell‘environment JBI (standard SUN emergente nell‘ambito dell‘integrazione) come il ComponentContext sono creati e gestiti in modo infrastrutturale analogamente a quanto accade con gli EJB per gli oggetti (familiari agili sviluppatori Java Enterprise) SessionContext, EntityContext, ecc.

Con gli EJB, mediante gli oggetti di contesto è possibile interagire con l‘environment per accedere alle informazioni di deploy (es: il nome del componente, le classi che lo costutiscono, …) e alle risorse del sistema.

public class SampleBean implements SessionBean {private SessionContext sessionContext;public void setSessionContext(SessionContext sessionContext){this.sessionContext = sessionContext;}public void doFoo(){UserTransaction ut = this.sessionContext.getUserTransaction();. . . if(this.sessionContext.isCallerInRole("Admin")){. . . InitialContext ctx = new InitialContext();String msg = ctx.lookup("java:comp/env/message");DataSourcedataSource = (DataSource) ctx.lookup("java:comp/env/jdbc/MokaDB");. . . } . . .}

Un servizio, analogamente, può comunicare con l‘infrastruttura dell‘ESB mediante opportune API vendor dependent o JBI-compliant.
Di seguito si riportano due esempi di implementazione di un servizio ESB.
Il primo esempio (vendor-dependent) riguarda un servizio utilizza le API del Framework ESB di Sonic Software:

public class SampleService implements com.sonicsw.xq.XQService{. . . public void service(com.sonicsw.xq.XQServiceContext ctx) throws XQServiceException{. . . com.sonicsw.xq.XQEnvelope env = null;env = ctx.getNextIncoming(); com.sonicsw.xq.XQMessage msg = env.getMessage();. . . ctx.addOutgoing(env);}}

Il secondo esempio riporta un servizio sviluppato con le API del Framework standard JBI proposta di SUN (vedere [6], [7] e [8]):

public class SampleConcreteComponent implements javax.jbi.component.Component,                     javax.jbi.component.ComponentLifeCycle {. . . public void init(ComponentContext jbiContext)throws JBIException{this.mContext = jbiContext;}public void doFoo(){. . . DeliveryChannel channel = this.mContext.getDeliveryChannel();. . . System.out.println(this.mContext.getComponentName() ); . . . ServiceEndpoint ref = this.mContext.activateEndpoint(qn, "MokaEndpoint");. . .} . . .}

La gestione (management) ed il monitoring dei service container sono spesso esposti tramite modalità  standard (e non in maniera proprietaria come avveniva in passato). Ad esempio è comune utilizzare degli Mbean JMX (Java Management extensions).

Conclusioni

In questo articolo abbiamo aggiunto un elemento architetturale importante in SOA: L‘Enterprise Service Bus.
E‘ opportuno concludere dicendo che a oggi, nonostante ci siano evoluzioni interessanti, gli ESB open source non hanno ancora raggiunto una forte maturità ; E‘ nostra opinione comunque che in tempi brevi acquisteranno un rulo importante nel mercato.
Nel prossimo articolo presenteremo una carellata dei principali ESB open source.

1M. Piraccini, S. RossiniSOA (I): Introduzione – MokaByte 100 – Ottobre 2005https://www.mokabyte.it/2005/10/soa-1.htm2M. Piraccini, S. RossiniSOA (II): Metodologia – MokaByte 101 – Novembre 2005https://www.mokabyte.it/2005/11/soa-2.htm3M. Piraccini, S. RossiniSOA (III): Maturity Model – MokaByte 102 – Dicembre 2005https://www.mokabyte.it/2005/12/soa-3.htm4M. Piraccini, S. RossiniSOA (IV): Roadmap – MokaByte 103 – Gennaio 2006https://www.mokabyte.it/2006/01/soa-4.htm5M. Piraccini, S. RossiniSOA (V): SOI – MokaByte 104 – Febbraio 2006https://www.mokabyte.it/2006/02/soa-5.htm6S. RossiniJava Business Integration(I) – MokaByte 100 – Ottobre 20057S. RossiniJava Business Integration(II) – MokaByte 101 – Novembre 20058S. RossiniJava Business Integration(III) – MokaByte 102 – Dicembre 20059D. Chappel”Enterprise Service Bus”, O‘Reilly, Giugno 2004