|
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]).
Figura
1: Risultati finali del Final Approval Ballot della
JSR #208
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!
Figura 2: I componenti JBI plugin
L'Architettura
JBI
L'architettura
JBI è costituita principalmente dai seguenti
elementi:
- i
Componente JBI-plugin
- Binding
Components (BC)
- 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.
Figura 3: L'architettura JBI ad alto livello
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.
Figura 4: Operazione di normalizzazione e denormalizzazione
dei BC
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.
Figura 5: Esempi di componenti plugin JBI SE
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).
Figura 6: La comunicazione tra i componeti JBI
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, ..).
Figura 7: Il pattern Message Exchange 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.
Figura 8: BC,SE, Delivery Channel & 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(<<serviceName>>,
<<operationName>>).
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(<<javax.xml.transform.Source>>);
inOnly.setMessage(message);
channel.send(inOnly);
.....
Figura 9: Class diagram: il Delivery Channel
ed i vari tipi di Message exchange
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.
Figura 10:
Ciclo di vita di un Componente JBI
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.
Figura 11: esempio di scenario d'integrazione
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:\tmp\timecard_ftp).
Il
file d'esempio <JBI_HOME>/examples/Demo/Sample/XTTPayroll.xml
viene copiato all'avvio della Demo nella directory c:\tmp\timecard_ftp.
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 <<SunAppServer>>/domains/domain1/applications/j2ee-modules/SunJBIDemo/myout/
out_<timestamp>.xml. 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)).
Figura 12: esempio di scenario d'integrazione
risolto con JBI
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.
Bibliografia
e riferimenti
[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
[WSDL 2.0 Extensions]
[MOKA_INT6] S.Rossini: Integrazione di applicazioni
Enterprise (VI) Mokabyte N.83-Marzo 2004
[MOKA_EAI_IM] S.Rossini-G.Morello: Integrazione di applicazioni
Enterprise (parte VII): l'Integration Middleware -Mokabyte
N.88 - Settembre 2004
[MOKA_ESB] S. Rossini: Enterprise Service Bus (Seminario
Sonic Sftware) - Mokabyte N.96 - Maggio 2005
|
