Le soluzioni di Enterprise Application Integration (EAI) sono da sempre caratterizzate da proposte basate su tecnologie non standard. In questo articolo parleremo di Java Business Integration (JBI), lo standard d‘integrazione proposto da SUN.
Introduzione
Le soluzioni di Enterprise Application Integration (EAI) sono da sempre caratterizzate da soluzioni basate su tecnologie non standard.
L‘adozione di soluzioni proprietarie crea una forte dipendenza dal fornitore del Prodotto (vendor lock-in) con conseguente svantaggio tecnico (mancanza di standard, difficoltà di scalabilità e di interoperabilità ) ed economico (licenze, manutenzione e consulenze sul prodotto).
Java Business Integration (JBI) è lo standard proposto dalla Java Community Process (JCP) attraverso la specifica JSR-208 (vedere [JSR208_SPEC]) che definisce un‘architettura per affrontare le problematiche d‘integrazione in modo standard e portabile.
La JSR208 ha recentemente passato la JCP public review con l‘approvazione di tutti i partecipanti a parte BEA e IBM (vedere [FMSS]).
Cos‘è JBI
JBI è l‘acronimo di Java Business Integration. Definisce un‘architettura standard per uniformare l‘integrazione di componenti EIS eterogenei all‘interno di applicazioni JBI-compliant.
Le specifiche JBI definiscono un ambiente Java per l‘integrazione basato sui principali standard open e di mercato.
JBI definisce uno standard mirato ai container che permette lo sviluppo di container di servizi secondo un modello a plugin. Lo scenario che si prospetta è la definizione di un contenitore (l‘environment JBI) in grado di ospitare container di servizi agendo da “container of containers” (vedere [IWRTH]) in grado di interagire mediante un sistema di messaging basato sul Web Services Description Language 2.0 (vedere [WSDL2.0]).
L‘idea di base è di potere definire dei contenitori di servizi che consentano la System Integration e permettere quindi a sistemi inizialmente non progettati per lavorare insieme di cooperare tra loro come se fossero un‘unica applicazione (Composite Application).
In questo modo lo sviluppatore sarà in grado di sviluppare un‘applicazione “assemblando” le funzionalità necessarie utilizzando gli opportuni Componenti plugin JBI. Ad esempio una soluzione d‘integrazione potrebbe essere un‘applicazione composta da un engine BPEL che interopera con un EJB Continer e un data trasformation all‘interno di un JBI environment.
Il modello plugin di JBI
JBI prevede il deploy di componenti d‘integrazione all‘interno dell‘environment JBI secondo un modello a plugin.
I Componenti plugin JBI forniscono la logica di integrazione per connettere applicazioni Java con applicazioni non-Java, risorse legacy e pacchetti applicativi.
JBI si pone quindi un obiettivo molto ambizioso: ottenere servizi d‘integrazione riusabili e portabili su qualsiasi prodotto JBI-compliant ottenendo l‘effetto Java “Write Once, run everywhere” nell‘ambito dell‘integrazione!
L‘Architettura JBI
L‘architettura JBI è costituita principalmente dai seguenti elementi:
- il Componente JBI-plugin: Binding Components (BC) e Service Engine (SE)
- il Normalized Message Router (NMR)
- gli MBean di Management
Esterne al JBI environment ci sono le entità da integrare (tali entità possono essere sia dei service consumer che dei service provider). Per interfacciarsi con l‘ambiente JBI i servizi esterni possono utilizzare una disparata varietà di tecnologie e di protocolli di comunicazione.
La figura che segue riporta l‘architettura ad alto livello di JBI.
I componenti JBI
All‘interno di un environment JBI-compliant è possibile “pluggare” due tipologie di componenti: i Binding Component (BC) ed i Service Engine (SE).
I Binding Component
I Binding Components (BC) hanno lo scopo di fornire la logica di connettività da/verso i servizi esterni all‘installazione JBI.
Il compito principale dei BC è quindi di integrare applicazioni/Enterprise Information Systems (EIS) non Java-based.
Il compito principale dei BC è quindi quello di normalizzare e/o denormalizzare i messaggi da/verso i servizi esterni adattando i protocolli/formati deli servizi remoti esterni all‘ambiente JBI (es: HTTP, SOAP, JMS, JCA, FTP, TCP/IP, AS1/AS2-EDI,…).
In questo modo è possibile per i servizi Service Engine (SE) interni all‘environment JBI sia consumare i servizi remoti esterni a JBI (comunicazione inbound) che esportare le proprie funzionalità ai servizi remoti (comunicazioni outbound).
Ricapitolando: i BC devono occuparsi di “adattare” i messaggi in entrambi le direzioni:
- nelle comunicazioni inbound devono normalizzare i messaggi trasformando il formato specifico del protocollo di comunicazione e dei dati in messaggi in forma canonica.
- nelle comunicazione outbound devono invece denormalizzare il messaggio trasformando il messaggio normalizzato nel formato specifico dei dati del client esterno all‘ambiente JBI.
I Service Engine
I Service Engine (SE) sono componenti JBI che forniscono logica di integrazione e di trasformazione verso altri componenti così come a loro volta possono utilizzare i servizi degli altri SE. I SE sono in grado principalmente di integrare applicazioni/risorse Java-Based.
I SE possono essere a loro volta dei “container”.
In particolare, determinati SE possono agire da container per ospitare service providers a service consumers all‘interno dell‘environment JBI esponendo un modello di programmazione uniforme agli utenti.
In questa ottica possiamo pensare a JBI come ad un contenitore di contenitori di servizi (container of containers) dove ogni container espone verso lo sviluppatore un‘interfaccia uniforme di API.
Esempi di SE:
- Un SE di trasformazione XML/XSLT che può permettere diversi tipi di trasformazione dei dati. In questo caso l‘interfaccia di programmazione è il linguaggio XSLT.
- Un engine di esecuzione di processi WS-BPEL2.0 . In questo caso l‘interfaccia di prograammazione è il WS-BPEL stesso.
- Un EJB Container! In questo caso le API a disposizione sono quelle proprie degli EJB.
In quest‘ottica JBI permetterà la composizione di applicazioni d‘integrazione con le funzionalità necessarie per raggiungere l‘obiettivo dando la possibilità di scegliere il miglior JBI compent plugin adatto per lo specifico caso d‘integrazione (best of breed).
Il modello di Messaggi di JBI
I componenti plugin-JBI all‘interno dell‘environment JBI non comunicano direttamente tra di loro. L‘environment JBI agisce da intermediario per lo scambio dei messaggi da un componente all‘altro.
Nello specifico il componente infrastrutturale JBI che gestisce il routing dei messaggi è il Normalized Message Router (NMR).
Il NMR effettua il routing dei messaggi dai BC verso i SE nelle comunicazioni inbound e dei SE verso i BC nelle comunicazioni outbound.
Il NMR permette di disaccoppiare il Service Consumer dal Service Provider garantendo un basso accoppiamento tra i componeti JBI (loose coupling).
All‘interno dell‘environment JBI i messaggi sono definiti in un formato indipendente e neutrale da qualsiasi specifica applicazione, tecnologia o protocollo di comunicazione. Questo modello “technology-neutral” è un formato canonico e comune e viene usato e condiviso da tutti i componenti all‘interno dell‘ambiente JBI. In questo modo il sistema di messaging può trattare in un modo omogeneo e univoco i diversi messaggi che gli arrivano da applicazioni eterogenee.
JBI adotta le specifiche WSDL 2.0 Predefined Extensions che definiscono il Message Exchange Pattern (MEP) che identifica la sequenza e le cardinalità dei messaggi permessi durante l‘esecuzione di una operazione. Questo permette di definire un preciso protocollo per lo scambio di messaggi tra il consumer e provider. Il pattern MEP è il fondamento dell‘interoperabilità dei componenti JBI.
Il pattern è definito in termini di tipo di messaggio (message type) che può essere di tipo normal o fault e dalla direzione del messaggio.
Per ogni tipologia di invocazione (One Way, Request-Response, …) è asscociato un ben preciso MessageExchange Pattern (In-Only, In-Out, …).
Lo scambio dei messaggi avviene mediante il Delivery Channel. Il DeliveryChannel rappresenta un canale di comunicazione bidirezionale usato dai BC e dei SE per comunicare con il NMR. Di fatto il Delivery Chennel rappresenta il contratto tra il servizio JBI (consumer/provider) e il NMR.
L‘interfaccia DeliveryChannel permette sia di creare una factory di MessageExchange factory (mediante il metodo DeliveryChannel.createMessageExchangeFactory()) sia di inviare messaggi attraverso i metodi:
send(exchange): invia il messaggio in modalità asincorna
sendSync(exchange): invia il messaggio in modalità sincrona
Il Message Exchange Factory permette di creare un MessageExchange mediante il metodo MessageExchangeFactory.createExchange(<
Il MessageExchange è l‘interfaccia base che fornisce i metodi comuni per le API che implementano uno specifico message exchange pattern.
Dal MessageExchange ottenuto (che può essere di classe InOnly, InOut, InOptionalOut, RobustInOnly, cioè i 4 tipi di MEP possibili da JBI) mediante il metodo factory createMessage(), è possibile ottenere un oggetto Message.
Il messaggio, una volta pronto per essere spedito, può essere “imbustato” mediante il metodo NormalizedMessage.setContent(), associato all‘opportuno MessageExchange con il metodo setMessage() ed infine inviato con il metodo DeliveryChannel.send().
Di seguito si riporta un esempio di codice che riassume quanto spiegato fino ad ora.
...DeliveryChannel channel = context.getDeliveryChannel();
MessageExchangeFactory factory = channel.createExchangeFactory();
InOnly inOnly = factory.createInOnlyExchange();
NormalizedMessage message = inOnly.createMessage();
message.setContent(<>);
inOnly.setMessage(message);channel.send(inOnly);...
Management
Oltre al sistema di messaging, JBI definisce una infrastruttura di Management basata su Java Management eXtensions (JMX).
JBI fornisce meccanismi standard per effettuare:
- installazione dei componenti plugin JBI
- gestione del ciclo di vita del componente(stop, start, ecc …)
- deploy dei componenti
L‘implementazione JBI dovrà fornire gli MBean infrastrutturali per rendere disponibili le funzionalità di management attraverso gli opportuni tool di amministrazione.
Ad esempio il tool di amministrazione JBI potrà essere in grado installare/disinstallare i componenti JBI interagendo con l‘MBean InstallationServiceMBean, di effettuare il deploy/undeploy dei componenti JBI con l‘MBean DeploymentServiceMBean oppure avviare (start) o arrestare (stop) i componenti comunicando con il ComponentLifeCycleMBean.
Il ciclo di vita di un Componente JBI
Ogni componente JBI ha un ben preciso ciclo di vita.
Il ciclo di vita di un componente è riportato nella figura che segue.
L‘InstallerMBean è responsabile della gestione dell‘installazione/deinstallazione del componente. Il ciclo di vita convenzionale start/stop è invece gestito deal ComponentLifeCycleMBean.
Il ciclo di vità “base” può essere eventualmente “esteso” in modo applicativo aggiungendo altri stati.
Il JBI Software Development Kit 1.0
SUN ha rilasciato recentemente il JBI Software Develpoment Kit versione 1.0 (vedere [JBI_SDK1.0]), la prima implementazione di quanto definito nelle specifiche JSR 208.
Il JBI Software Developer Kit (SDK) 1.0 è composto dalle API JBI, un set di tool (di sviluppo e di amministrazione) e da un ambiente di runtime.
Lo scopo di questo rilascio è di rendere disponibile il primo runtime JBI con dei samples a corredo per pemettere agli sviluppatori di prendere dimestichezza con JBI.
Nel JBI SDK sono disponibili i seguenti esempi di Componenti JBI:
- SunFileBinding: un BC che permette ai servizi di comunicare con il file system locale
- SunSOAPBinding: un BC che permette la comunicazione (inbound e outbound) via web services
- SunSequencingEngine: un SE in grado di invocare sequenzialmente una serie di servizi opportunamente configurati
- SunTransformationEngine: un SE che permette le trasformazioni XSLT di un documento XML ricevuto in ingresso
Il SDK fornisce anche un‘applicazione di demo.
Lo scopo della Demo è di permettere la verifica della corretta installazione del JBI SDK ed il funzionamento basilare dell‘environment JBI mediante i quattro componenti sample sopra descritti.
Uno scenario d‘esempio
Concludiamo l‘articolo con un esempio di scenario d‘integrazione per ricapitolare quanto spiegato fino ad ora.
Come scenario d‘esempio, semplice ma didattico, utilizzeremo lo scenario della Demo fornita con la versione del JBI Software Development Kit 1.0.1della SUN (vedere [[JBI_SDK1.0_DOC]]).
Lo scenario della Demo prevede di risolvere un semplice problema di integrazione.
Le entità da integrare sono rappresentate da due aziende: l‘azienda A e l‘azienda B.
L‘azienda A e responsabile della gestione degli stipendi dei dipendenti per conto dell‘azienda manifatturiera B
L‘Azienda A necessita di inviare i dati delle buste paghe all‘azienda B. La rappresentazione dei dati (lo schema) è però diverso tra le due aziende.
Bisogna quindi provvedere a trasformare il formato dei dati dell‘azienda A nel formato dei dati dell‘azienda B prima di inviarli.
Questo viene ottenuto nel seguente modo.
I dati dei pagamenti (payroll data) sono contenuti in un file XML che viene inviato via FTP (Figura 12(1)) in una directory su cui è in “ascolto” il File Binding Component (SunFileBinding) (Figura 12(2)).
Il BC è in ascolto su una specifica directory definita in fase di deploy dell‘endpoint (di default è: c: mp imecard_ftp).
Il file d‘esempio
Il componente JBI SunFileBinding “preleva” il file e inserisce il suo contenuto come payload in un messaggio in forma “normale” e lo invia al Service Engine (SunSequencingEngine) (Figura 12(3)).
Il Service Engine invoca il Transformation Service passandogli il messaggio ricevuto dal BC (Figura 12(4)).
Il SunTransformationEngine applica una trasformazione XSLT ai dati di payroll ricevuti.
Il documento viene trasformato dal formato (schema) dell‘azienda A nel formato dell‘azienda B. Il file XML ottenuto viene messo dal SE nella directory <
Una volta ottenuto il formato del payroll nel formato comprensibile dall‘azienda B, il SunSequencingEngine invia il documento trasformato al BC SunSOAPBinding (Figura 12(5)).
Il BC SunSOAPBinding denormalizza il messaggio, e provvede ad inviare il documento mediante il protocollo SOAP all‘azienda B (Figura 12(6)).
Conclusioni
JBI è uno standard estremamente interessante e promettente. Sotto un certo punto di vista può essere considerato come uno standard J2EE-like applicato ad hoc per il mondo dell‘integrazione.
Lo scopo è sicuramente ambizioso … “bissare” il sucesso J2EE ottenuto in ambito Enterpise nel complesso panorama dell‘Enterprise Application Integration.
Il peso che JBI assumerà negli anni a venire sarà , come per ogni proposta di standard, soprattutto dettato dal supporto e dalla fiducia che i principali player del mercato decideranno di accordare alla specifica SUN.
Nonostante quindi il promettente potenziale tecnico, l‘impatto di JBI sul mercato potrebbe essere limitato; basti considerare che ad oggi IBM e BEA hanno prese le distanze preferendo puntare sulle loro soluzioni.
Un mercato di Componenti JBI standard preconfezionati, pluggabili nell‘infrastruttura JBI potrebbe consentire la riduzione dei tempi e dei costi di sviluppo dell‘integrazione indirizzando soluzioni standard, scalabili e … portabili!
JBI infatti porebbe consentire il deploy e l‘aggregazione di componenti sviluppati da diversi vendor all‘interno di ambienti JBI-compliant. Questo permettere di scegliere il miglior componente per la specifica situazione (best of breed) d‘integrazione all‘interno di una infrastruttura JBI-compliant.
Questo aiuterebbe significativamente ad aumentare l‘interoperabilità tra i sistemi d‘integrazione, la flessibilità ed il riuso per diminuire conseguentemente la complessità (ed i costi!) tipici delle attuali soluzioni d‘integrazione.
JBI potrebbe essere quindi un passo significativo per la riduzione del vendor lock-in che “attanaglia” da sempre le suite d‘integrazione.
Sicuramente JBI rappresenta la prima vera possibilità per i prodotti Enterprise Service Bus di dirigersi (in modo concreto!) verso la definizioni di prodotti d‘integrazione open.
Sebbene JBI possa essere considerato un passo importante per il mondo Java e per il mercato EAI in genere, la versione attuale dello standard è giovane e presenta punti che dovranno essere migliorati.
Ad esempio ad oggi non si un work manager infrastrutturale per la gestione dei thread dei componenti (ad oggi tale gestione è demandato all‘applicativo), la gestione della persistenza dei Message Exchange, la gestione di messaggi Long-lived (ad oggi i messaggi sono considerati short-lived), gestione infrastrutturale della sicurezza e della Policy, …
Nel prossimo articolo concluderemo la panoramica su JBI descrivendo le principali API del Framework JBI.
Riferimenti bibliografici
[JSR208_SPEC]
R. Ten-Hove, P. Walker: Java Business Integration (JBI) 1.0 Final ReleaseMay 24, 2005
http://www.jcp.org/en/jsr/detail?id=208
[JBI_HOME]
http://java.sun.com/integration/
[WP_DEVSE]
Sun White Paper: Developing a Service Engine Component-
http://java.sun.com/integration/reference/techart/
[IWRTH]
Standardizing business integration with JBI: Inteview with Ron Ten-Hove
http://searchwebservices.techtarget.com/qna/0,289202,sid26_gci1061937,00.html
[FMSS]
F. Marinescu: JSR 208: JBI Passes Public Review, IBM & BEA Abstain
http://www.theserverside.com/news/thread.tss?thread_id=33433
[FSJBI]
F. Sommers: Service-Oriented Java Business Integration Put your Integration on Auto-Pilot with JSR 208 –
http://www.artima.com/lejava/articles/jbi.html
[SOAJBI]
Shin, Sang-Chul: Service Oriented Architecture with Java Business Integration(JBI) ?
http://www.javapassion.com/webservices/SOAandJBI4.pdf
[JBI_SDK1.0]
http://java.sun.com/integration/download/
[JBI_SDK1.0_DOC]
http://java.sun.com/integration/1.0/docs/sdk/
[JBI_JAVADOC]
http://java.sun.com/integration/1.0/docs/sdk/api/index.html
[WSDL 2.0]
R.Chinnici, M.Gudgin, J. J Moreau, J. Schlimmer, S. Weerawarana: Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language. Working Draft, W3C,August 2004.
http://www.w3.org/TR/2004/WD-wsdl20-20040803
[WSDL 2.0 Bindings]
H. Haas, P. Le Hà©garet, J-J. Moreau, D. Orchard, J. Schlimmer, Editors. Web Services Description Language (WSDL) Version 2.0 Part 3: Bindings. Working Draft, W3C, August 2004.
http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803
[MOKA_INT6]
S.Rossini, “Integrazione di applicazioni Enterprise (VI)” Mokabyte 83,-Marzo 2004
[MOKA_EAI_IM]
S.Rossini-G.Morello, “Integrazione di applicazioni Enterprise (parte VII): l‘Integration Middleware”, Mokabyte 88, Settembre 2004
[MOKA_ESB]
S. Rossini, “Enterprise Service Bus (Seminario Sonic Sftware)”, Mokabyte 96, Maggio 2005