MokaByte 105 - Marzo 2006
 
MokaByte 105 - Marzo 2006 Prima pagina Cerca Home Page

 

 

 

Service Oriented Architecture
IV parte: dalla teoria alla pratica. Enterprise Service Bus

Nei precedenti articoli abbiamo parlato di SOA sia dal punto di vista architetturale (vedere [MOKA_SOA_I]) che delle metodologie di analisi e di design (vedere [MOKA_SOA_II]) . Un’azienda che decide di evolvere il proprio sistema informativo verso una architettura SOA deve fare diverse scelte e fronteggiare numerose sfide. In [MOKA_SOA_III] e [MOKA_SOA_IV] 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 [MOKA_SOA_V] 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.

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.


Figura 1 - Integration Middleware: architettura Hub-and-Spoke


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


Figura 2 - Integration broker: centralizzazione delle funzionalità d’integrazione


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,...


Figura 3: Architettura ESB


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”.


Figura 4: ESB: scenario d’integrazione


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.




Figura 5
: Service Container: visione d’insieme


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");
      DataSource dataSource = (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 [MOKA_JBI_I], [MOKA_JBI_II] e [MOKA_JBI_III]):

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).

Figura 6: Service Container: visione d’insieme


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.

 

Bibliografia
[MOKA_SOA_I] M. Piraccini, S. Rossini: SOA: Introduzione - MokaByte 100 - Ottobre 2005
http://www.mokabyte.it/2005/10/soa-1.htm
[MOKA_SOA_II] M. Piraccini,S. Rossini: SOA: Metodologia - MokaByte 101 - Novembre 2005
http://www.mokabyte.it/2005/11/soa-2.htm
[MOKA_SOA_III] M. Piraccini,S. Rossini: SOA (III): Il Maturity Model - MokaByte 102 - Dicembre 2005
http://www.mokabyte.it/2005/12/soa-3.htm
[MOKA_SOA_IV] M. Piraccini,S. Rossini: SOA (IV) Roadmap - MokaByte N.103 - Gennaio 2006
http://www.mokabyte.it/2006/01/soa-4.htm
[MOKA_SOA_V] M. Piraccini,S. Rossini: SOA (V) SOI - MokaByte N.104 - Febbraio 2006
http://www.mokabyte.it/2006/02/soa-5.htm
[MOKA_JBI_I] S. Rossini: Java Business Integration(I), Mokabyte N. 100 – Ottobre 2005
[MOKA_JBI_II] S. Rossini: Java Business Integration(II), Mokabyte N. 101 – Novembre 2005
[MOKA_JBI_II] S. Rossini: Java Business Integration(III), Mokabyte N. 102 – Dicembre 2005
[DC_ESB] David Chappel: Enterprise Service Bus - O’Reilly Giugno 2004