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 e così via.

Nei precedenti articoli abbiamo parlato di SOA sia dal punto di vista architetturale ([1]) che delle metodologie di analisi e di design ( [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.

Nel precedente [6] si sono introdotte le caratteristiche salienti di un Enterprise service BUS (ESB). 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, …

In questo articolo tratteremo una veloce panoramica degli ESB open source ad oggi disponibili.

Open Source & Integrazione

Nell‘ambito dell‘integrazione, i prodotti open source non hanno ancora ottenuto i livelli di credibilità  raggiunti nell‘area dei Platform Middleware; ad esempio a oggi ancora non esiste nulla che abbia la credibilità  commerciale di Tomcat o JBoss.

L‘unica formula ad oggi cost effective è la formula “Royalty Free Source Code” dove il sorgenti software (ad esempio di resource adapter) sono rilasciati come “open source” al cliente nel momento in cui viene effettuato un contratto di manutenzione e supporto (Royalty Free Source Code).

In tale direzione sicuramente è degno di nota l‘accordo di collaborazione tra JBoss e Librados finalizzato a fornire una soluzione d‘integrazione “a basso costo” combinando un prodotto open source (JBoss) e un prodotto “cost-effective” (Librados). La partnership tra l‘open source JBoss e l‘opzione royalty-free source code di Librados rappresenta una potenziale soluzione “low cost” di integrazione concorrenziale rispetto ad esempio ai costosi Integration Broker.

Per quel che riguarda più specificatamente gli ESB, il panorama dell‘open source sta evolvendo in modo interessante.

Ad esempio Iona sta sviluppando Celtix (vedere [8]), la versione open source dell‘ESB commerciale Artix (vedere [9]).

LogicBlaze fornisce ServiceMix, un prodotto molto interessante e completamente JBI-compliant.

SUN dal canto suo fornirà  un ESB open source basato su JBI attraverso il progetto GlassFish.

Apache sta “incubando” Synapse (cioè ospitando per un periodo, valutando se poi comprenderlo tra i suoi progetti): Synapse è un progetto di ESB open source, principalmente basato su codice di WSO2, Infravio e Sonic Software (vedere [11]).

E‘ interessante il fatto che in questo ambito stanno nascendo collaborazioni tra i vari player open source come ad esempio tra Iona (Celtix) e LogicBlaze (ServiceMix) a cui si sta aggiungendo anche Synapse al fine di unificare gli sforzi per “assemblare” un ESB concorrenziale rispetto ai prodotti commerciali come Bea, IBM, SeeBeyond, Fiorano, Sonic.

L‘obiettivo è arrivare velocemente ad avere un prodotto che venga largamente accettato dal mercato. Tali collaborazioni potrebbero in futuro produrre un ecosistema collaborativo per creare ESB open source.

Le cose tuttavia sono agli inizi. Iona ha creato il progetto Celtix in giugno e attualmente sono state rilasciate solo delle Milestone build. Il più stabile ESB rilasciato attualmente sembra ServiceMix che è attualmente alla versione 2.0.2.
Una cosa interessante che si può osservare è che lo standard JBI (inizialmente “boicottato” da Bea e IBM), sta prendendo piede negli ESB OpenSource che si stanno sviluppando, tanto che la compatibilità  con questo standard è uno dei metri che si possono utilizzare nell‘analisi di questi sistemi.
Un altro parametro che abbiamo considerato è l‘integrazione o il supporto di Orchestration Service, cioè a componenti architetturali che permettono l‘orchestrazione dei servizi in Business Process (definiti ad esempio tramite lo standard BPEL.

Celtix

Celtix è un ESB Java sponsorizzato da IONA ed ospitato nella comunità  ObjectWeb (consorzio francese simile negli obiettivi e nei servizi a SourceForge).
Il codice si basa in parte su Artix (di cui di fatto Celtix è una versione “light”), anch‘esso un ESB che funge da switch / runtime-adapter tra le diverse applicazioni da integrare collegate al bus.

Essendo Celtix la versione open source di Artix, avrà  necessariamente un mercato diverso; l‘offerta open source di Celtix renderà  Iona in grado di affrontare progetti che richiedono esplicitamente l‘uso di software libero (come ad es. alcuni progetti governativi che richiedono espressamente open source).
Con questa strategia Iona può differenziare la sua offerta: per organizzazioni che necessitano funzionalità  avanzate e senza vincoli di utilizzo di prodotti opens source e con un budget non limitato, Artix continuerà  ad essere la scelta principale.

Iona assicura che le due piattaforme saranno comunque interoperabili.

In aggiunta, Iona sta anche sponsorizzando il progetto open-source SOA Tools Platform nel consorzio Eclipse. Questa iniziativa unisce gli sforzi delle comunità  Celtix e Eclipse con lo scopo comune di creare uno strumento IDE per la realizzazione di progetti SOA.

Celtix offre un meccanismo di sviluppo di WebServices prettamente Java-Oriented (WSDL-to-Java, Java-to-WSDL, …) che semplifica lo sviluppo offrendo di fatto un subset delle funzionalità  di Artix.

Da notare che il Java-to-WSDL si basa sulle nuove specifiche JSR181per i metadata per i Webservices.

Partendo da un WSDL è possibile ottenere la generazioni delle classi Java infrastrutturali del Web Service:

%CELTIX_DIST% inwsdl2java -d buildclasses -s buildsrc .wsdlhello_world.wsdl

A questo punto è possibile sviluppare l‘implementazione del servizio estendendo la classe stub generata dal tool WSDL-to-Java:

public class GreeterImpl implements Greeter {/* (non-Javadoc) * @see org.objectweb.hello_world_soap_http.Greeter#greetMe(java.lang.String) */public String greetMe(String me) {return "Hello " + me + "!";}  }

e la relativa classe Server che si occupa di pubblicarlo come endpoint:

Object implementor = new GreeterImpl();String address = "http://localhost:9000/SoapContext/SoapPort";Endpoint.publish(address, implementor);

A questo punto è possibile invocare in modo semplice il Web Service:

public class Client {private static final QName SERVICE_NAME  = new QName("http://objectweb.org/hello_world_soap_http", "SOAPService");public static void main(String args[]) throws Exception {. . .SOAPService ss = new SOAPService(wsdlURL, SERVICE_NAME);Greeter port = ss.getSoapPort();String resp = port.greetMe("ESB World");System.out.println(resp);. . . }}

Per quel che riguarda il supporto a JBI, Celtix dovrebbe fornire la possibilità  di installare un container JBI compliant (es: ServiceMix) in cui eseguire i servizi JBI.

Analogamente il supporto a WS-BPEL può essere dato tramite orchestration engines “esterni”, come ActiveBPEL (vedere [13]).

ActiveBPEL è un orchestration engine che può essere installato a partire dalla versione 5 di Tomcat. Il funzionamento è semplice: si produce un archivio “bpr” che contiene i wsdl dei servizi orchestrati con la descrizione dei messaggi di input/output e il processo definito in BPEL. Questo archivio viene copiato sulla directory bpr di tomcat (creata all‘installazione di ActiveBPEL) che ne permette l‘installazione.
La correttezza del deploy può quindi essere verificata con una apposita console web.
Sempre tramite la console è possibile monitorare graficamente il processo e le esecuzioni (vengono evidenziati i rami percorsi del workflow e i valori delle variabili BPEL associate per ogni esecuzione).

In questo modo è possibile orchestrare servizi esposti da Celtix; occorre notare però che l‘orchestrazione è “esterna”, cioè occorre lanciare un processo apposito esternamente a Celtix (ActiveBPEL) che conosca i riferimenti ai Web Services (definiti su wsdl) utilizzati nell‘orchestrazione .

E‘ disponibile inoltre ActiveBPEL Designer, un tool (ora free) di disegno dei processi BPEL basato su Eclipse.

ServiceMix

ServiceMix è stato il primo ESB JBI-compliant a fare la comparsa nel mondo degli ESB open-source; viene rilasciato da LogicBlaze con licenza Apache.

ServiceMix mette a disposizione un‘implementazione del JBI container conforme alle specifiche e fornisce sia Binding Component che interessanti Service Engine “pre-confezionati”.
Alcuni esempi sono:

• Routing basato su regole (tramite Drools [22]).
• Supporto a WS-BPEL tramite PXE/Intalio|BPEL (vedere [21])
• Trasformazione XSLT
• Quartz per la schedulazione di eventi

Inoltre sono presenti dei Binding Componennts per la gestione dei principali protocolli (come HTTP, FTP, SMTP, JMS, RSS).

ServiceMix può essere utilizzato in tre configurazioni differenti: stand-alone, “embedded” in un‘applicazione oppure o all‘interno di un file war pronto per essere installato in un server J2EE.

Vediamo un semplice esempio di componente.
Riprendendo il componente JBI sviluppato in [7], osserviamo che il suo deploy è quantomeno immediato: l‘installazione dei componenti JBI avviene semplicemente copiando il jar del componente (nel nostro esempio era il MokaComponent.jar) nella directory install di ServiceMix. Deve essere inoltre copiato il Service Assembly MokaServiceAssembly.zip nella directory deploy di ServiceMix (es: C:installedservicemix-2.0.2deploy).

Oltre all‘installazione di componenti JBI, ServiceMix permette lo sviluppo di servizi in altri due modi:

• Mediante l‘utilizzo delle proprie API
• Mediante lo sviluppo di componenti POJO, che implementano l‘interfaccia javax.jbi.component.ComponentLifeCycle.

Nel primo caso il componente estende la classe ServiceMix di supporto org.servicemix.components.util.ComponentSupport, implementa l‘interfaccia MessageExchangeListener e utlizza gli oggetti JBI per la comunicazione (DeliveryChannel, NormalizedMessage, MessageExchange, …).

Costruiamo un servizio (nella modalità  in cui utilizzamo le API ServiceMix) che permetta la visualizzazione del messaggio ricevuto.

public class ReceiverTraceComponent extends ComponentSupport implements MessageExchangeListener {private SourceTransformer sourceTransformer = new SourceTransformer();public ReceiverTraceComponent(){}public SourceTransformer getSourceTransformer() {return this.sourceTransformer;}public void setSourceTransformer(SourceTransformer sourceTransformer) {this.sourceTransformer = sourceTransformer;}public void onMessageExchange(MessageExchange exchange) throws MessagingException {NormalizedMessage message = exchange.getMessage("in");if (message == null) {System.err.println(this.getClass().getName() + ".onMessageExchange: #ERROR# message is null!");}else {try {Source source=message.getContent(); Transformer transformer = TransformerFactory.newInstance().newTransformer();transformer.transform(source, new StreamResult(System.out));}catch (TransformerException e) {e.printStackTrace();}}done(exchange);}}

Una volta ricevuto il messaggio:

NormalizedMessage message = exchange.getMessage("in");

viene prelevato il suo contenuto

Source source=message.getContent();

e stampato su standard output:

transformer.transform(source, new StreamResult(System.out));

Bisogna provvedere all‘opportuna configurazione del componente nel file servicemix.xml indicando il nome logico del servizio (my:trace) e la classe concreta del component (RecevierTraceComponent):

Nella seconda modalità  di sviluppo è possibile creare i servizi in modalità  POJO. L‘intento è quello di “spogliare” ulteriormente gli oggetti sviluppati da logica che non sia di business.

Il supporto a BPEL viene dato tramite il ServiceEngine di PXE/Intalio|BPEL, fornito da FiveSight (vedere PXE]), recentemente acquistata da Intalio. E‘ stato inoltre disponibile come plugin del Sun Java Studio Enterprise (vedere [23]).

Mule

Mule è un ESB open source sviluppato dalla SymphonySoft ed ospitato da CodeHaus (un altro repository di progetti OpenSource). Mule, pur non basandosi su JBI, fornise la possibilità  di interazione tra i componenti Mule con container JBI-compliant.

Mule basa la sua architettura su un Container di tipo SEDA (Staged Event-Driven Architecture) in grado di gestire dei servizi (denominati UMOs, Universal Message Objects).
SEDA prevede la decomposizione di un sisitema complesso in una serie di “stadi” (stage) connessi tra loro tramite code (vedere [19]).
Gli UMOs sono oggetti (che non sono altro che classi Java POJO) in grado di ricevere e inviare eventi: sono questi oggetti che in questa architettura contengono la logica di Business. Inoltre ogni UMO può fornire uno o più endpoint di comunicazione, che supportano svariati tipi di protocollo come TCP, http, SMTP, JDBC, JMS, etc.

Entrando in dettaglio nel container, Mule è un light-weight container di UMO, basato sul principio dell‘ IoC (inversion of control).

La classe del servizio è costituita da un classe Java rigorosamente “piatta” (appunto POJO) il cui compito è fornire la logica di business:

public class EchoComponent extends LogComponent implements EchoService{public Object onCall(UMOEventContext context) throws Exception{super.onCall(context);return context.getTransformedMessage();}public String echo(String echo){return "Hello " + echo;}}

Il servizio deve essere opportunamente configurato nel file descriptor XML bisogna indicare la classe POJO del servizio, gli endpoint e la modalità  d‘invocazione

Nell‘esempio proposto l‘oggetto Java diventa invocabile via Axis invocando l‘URL:

http://localhost:8081/services/EchoUMO?method=echo&param=Stefano

Apache Synapse

Il progetto di Apache Synapse riguarda la costruzione di un “Web Services broker” utile per la traduzione di documenti in differenti formati XML (XSLT transformation) ed il routing intelligente basato sul contenuto dei messaggi (Content Based Routing).
Lo scopo del progetto è fornire un framework leggero e estendibile per la consegna e la mediazione di messaggi tra i Web Services (piuttosto che un ESB completo in senso stretto).

Il codice iniziale di questo progetto è stato donato da Sonic Software,WSO2 e Infravio.

Il progetto è ancora allo stadio iniziale: la cosa interessante è che Synapse collaborerà  con i progetti ObjectWeb Celtix, ServiceMix per concorrere alla creazione di un‘estesa comunità  open source dedicata all‘infrastruttura SOA.

Conclusioni

I prodotti che abbiamo presentato offrono tutti un bassa maturità . E‘ tuttavia molto incoraggiante l‘adozione di standard promettenti come JBI e BPEL.
Sicuramente interessante è l‘alleanza tra progetti OpenSource per il supporto del numero maggiore possibile di features: la collaborazione tra i progetti Celtix, ServiceMix e Synapse rappresenta un importante passo avanti verso la creazione di un‘estesa comunità  open source dedicata all‘infrastruttura SOA; da tali collaborazioni potrebbero in futuro sfociare in un ecosistema collaborativo che realizzi un ESB open source di qualità  enterprise.

Bibliografia

[1] M. Piraccini, S. Rossini “SOA: Introduzione” MokaByte 100 Ottobre 2005
https://www.mokabyte.it/2005/10/soa-1.htm

[2] M. Piraccini, S. Rossini “SOA: Metodologia” MokaByte 101 Novembre 2005
https://www.mokabyte.it/2005/11/soa-2.htm

[3] M. Piraccini, S. Rossini “SOA (III): Il Maturity Model” MokaByte 102 Dicembre 2005
https://www.mokabyte.it/2005/12/soa-3.htm

[4] M. Piraccini, S. Rossini “SOA (IV) Roadmap” MokaByte 103 – Gennaio 2006
https://www.mokabyte.it/2006/01/soa-4.htm

[5] M. Piraccini, S. Rossini “SOA (V) SOI” MokaByte 104 – Febbraio 2006
https://www.mokabyte.it/2006/02/soa-5.htm

[6] M. Piraccini, S. Rossini “SOA (VI) ESB (I)” MokaByte 105 – Marzo 2006
https://www.mokabyte.it/2006/03/soa-6.htm

[7] S. Rossini “Java Business Integration(I), (II), (III)” MokaByte 100, 101, 102

[8] http://celtix.objectweb.org

[9] http://www.iona.com/products/artix

[10] http://servicemix.org

[11] http://incubator.apache.org/synapse

[12] http://www-128.ibm.com/developerworks/library/specification/ws-bpel/

[13] http://www.activebpel.org

[14] Coordinating Celtix Applications with ActiveBPEL
http://celtix.objectweb.org/demos/bepl/celtix_activeBPEL_integration.pdf

[15] J. Jeffrey Hanson “ServiceMix as an enterprise service bus: Use ServiceMix 2.0 as a service-oriented message routing framework”
http://www.javaworld.com/javaworld/jw-12-2005/jw-1212-esb.html?lsrc=jwrss

[16] Sing Li “Plug into JBI with ServiceMix”
http://www.itarchitect.co.uk/articles/display.asp?id=222

[17] ServiceMix home page
http://swik.net/ServiceMix/

[18] http://mule.codehaus.org/

[19] M.Welsh “Harvard University: SEDA: An Architecture for Highly Concurrent Server Applications”
http://www.eecs.harvard.edu/~mdw/proj/seda/

[20] http://servicemix.org/Examples

[21] http://pxe.intalio.org/public

[22] http://drools.codehaus.org

[23] Using the Orchestration Designer Feature
http://developers.sun.com/prodtech/javatools/jsenterprise/tpr/reference/docs/bpel_gsg.html

[24]Roy W. Schulte “Predicts 2003: Enterprise Service Buses Emerge”
http://www.gartner.com/

[25] Open source ESB projects Synapse and Celtix contributed
http://www.theserverside.com/news/thread.tss?thread_id=36120

[26] M. Fowler “Inversion of Control Containers and the Dependency Injection pattern”
http://www.martinfowler.com/articles/injection.html