Con questo articolo si conclude la serie dedicata a JBI e SCA, in cui analizziamo le principali caratteristiche dei due standard. Sono due standard di integrazione che spesso vengono presentati in contrapposizione, ma che in realtà potrebbero essere utilizzati insieme.
Nei precedenti articoli [MOKA-JBI-SCA_I], [MOKA-JBI-SCA_II] si sono introdotti i due standard più promettenti nell’ambito degli Enterprise Service Bus (ESB): JBI e SCA. Sono due standard che spesso vengono presentati in contrapposizione, ma la realtà non è proprio così.
ESB JBI e SCA
JBI si basa su un modello architetturale a bus (ESB), si occupa in maniera più specifica di integrazione. JBI descrive due tipologie di componenti (Binding Component e Service Engine) che possono essere installabili su qualunque ESB JBI-compliant. Questo significa che se si hanno esigenze di integrazione di qualunque tipologia, possono essere risolte procurandosi i componenti JBI adatti alle proprie esigenze.
JBI ha riscontrato un importante consenso nei prodotti open source e non solo; ad esempio, TIBCO ActiveMatrix Service Grid e Iona Artix già lo supportano. Oracle dichiara che adotterà JBI in Oracle Fusion Middleware mentre SUN lo aggiungerà nella suite Seebeyond JCAPS.
Figura 1 – I principali ESB Java Open Source JBI-compliant
L’obiettivo dell’attuale specifica di SCA invece è la definizione di un modello architetturale coerente con SOA e la specifica delle relative API. I componenti di SCA devono contenere logica di business (che può essere scritta utilizzando diversi linguaggi come Java, C++ e BPEL) e possono a loro volta essere composti per produrre ulteriore logica, collegati tramite binding standard. Si tratta quindi un modello estendibile per la costruzione e l’evoluzione dei sistemi informativi.
L’obiettivo SCA è quindi quello della portabilità del codice: ciò che è sviluppato con un certo linguaggio in un certo Dominio può essere eseguito in un altro Dominio ottenendo gli stessi effetti: SCA è, in poche parole, un’interfaccia standard implementata dai diversi produttori in modo proprietario.
Attualmente sono disponibile due implementazioni opensource: Apache Tuscany e Fabric3.
Figura 2 – I principali SCA runtime Open Source
SCA è supportato dai principali vendor e presente negli ESB di mercato come ad esempio Oracle Corporation (Oracle Fusion), BEA Systems (Aqualogic Service Bus), IONA Technologies (Artix ESB) e IBM (WebSphere Enterprise Service Bus).
JBI e SCA a confronto
JBI si focalizza sulla possibilità di integrazione mediante i suoi componenti.
SCA si focalizza invece sullo sviluppo di applicazioni che vengono “installate” (deploy) nelle piattaforme Java EE, e sulla definizione dei servizi sulla base dei componenti.
Diamo adesso un’occhiata a cosa JBI e SCA hanno in comune:
- Si orientano entrambi su SOA ma affrontano il problema da lati opposti. JBI si concentra sull’integrazione a tempo di esecuzione e sul deploy, mentre SCA si focalizza sul modello dei componenti per lo sviluppo.
- Promuovono il concetto di separazione della logica di business dalla logica d’infrastruttura. La logica di business non dovrebbe interessarsi di cosa necessita alle implementazioni per realizzare la persistenza o la transazionalità, dato che questi aspetti fanno parte della logica di infrastruttura.
- Promuovono il concetto di costruzione dei componenti. Tali componenti sono legati in-sieme usando i metadati, presenti in ciascun container.
- Forniscono un linguaggio XML per i metadati dei componenti.
- Permettono le invocazioni sincrone e asincrone dei servizi.
Vediamo adesso alcune caratteristiche che sono invece specifiche di ciascuno dei due standard:
- SCA fornisce un modello di programmazione del client per localizzare ed accedere ai componenti dei servizi. Questo modello supporta anche le invocazioni dinamiche e presen-ta un modello di risposta più ricco di JBI.
- JBI fornisce API per i fornitori, indipendentemente dalla interoperabilità dei componenti all’interno del container.
- Il modello architetturale JBI sottinteso è quello a bus; la logica dei servizi è contenuta in Service Engine (SE), mentre l’esposizione e il consumo dei servizi avviene tramite Binding Components (BC) e la compatibilità dei BC e dei SE con la specifica ne garantisce la portabilità.
- Nelle applicazioni SCA, i servizi sono esposti da Composite che contengono componenti; ogni componente espone e consuma dei servizi.
- JBI prevede la portabilità dei BC e dei SE, permettendo di scegliere in un mercato più vasto e aperto.
- SCA prevede un insieme di implementazioni obbligatorie per lo standard (p.e.: Java e BPEL, JMS).
In sintesi si tratta di specifiche sostanzialmente diverse (anche se entrambe basate su concetti di Service Oriented Architecture): JBI è orientato all’integrazione (modello condiviso di messaging) ed è meno vincolante di SCA che, dall’altra parte, si pone obiettivi più ambiziosi.
Ai “morsetti” non fa molta differenza se un servizio SOA è esposto con SCA o con JBI.
JBI è più utile in una roadmap SOA per evolvere il software a servizi. La portabilità dei componenti riduce il lock-in sui middleware scelti e permette di scegliere il “best of breed” tra i SE e i BC. SCA rappresenta una scelta più naturale per un disegno “da zero”.
Entrambi gli standard possono essere usati separatamente: JBI solo su piattaforma Java, SCA su ambienti Java e nativi (C++, C#, …).
Molti autori non vedono i due standard in antitesi ma considerano inevitabile una loro futura convergenza. Ad esempio, la presentazione “The Best of Both Worlds with Java Business Inte-gration and Service Component Architecture” [TBOBW], tenuta al JavaOne 2008 da Jos Dir-ksen e Tijs Rademakers, suggerisce come queste due tecnologie possano convivere cooperan-do: un container SCA che “gira” come Service Engine all’interno di un container JBI.
Si può quindi tranquillamente ipotizzare in futuro di utilizzare sia SCA che JBI allo stesso tempo, ottenendo quindi i vantaggi di entrambi. Integrando servizi SCA su un bus attraverso un opportuno Service Engine JBI, potremmo avere i vantaggi del modello SOA di SCA uniti alla capacità di integrazione di JBI. Unendo le potenzialità di SCA a quelle JBI potremmo ottenere il “best-of-breed” di entrambi: la portabilità applicativa di SCA unita alla portabilità ESB di JBI!
A nostro avviso questo è auspicabile perche’ dovrebbe portare vantaggi ad entrambi gli standard.
Figura 3 – JBI & SCA
È da notare che JBI fa parte di una standardizzazione JSR/JCP, mentre SCA è uno standard Oasis. La differente standardizzazione è un ostacolo alla convergenza di entrambi su un livello unico di specifiche. C’è comunque la speranza che i fornitori siano innovativi nello sviluppare l’integrazione con la coesistenza di JBI e SCA.
Conclusioni
Con questo articolo si conclude questa serie di articoli dedicati a JBI e SCA. In essa abbiamo potuto vedere le principali caratteristiche dei due standard e ci siamo soffermati sulle principali analogie e differenze che sussistono tra loro. Sono due standard che spesso vengono presentati in contrapposizione, ma che in realtà potrebbero essere utilizzati insieme ottenendo quindi i vantaggi di entrambi.
Riferimenti
[MOKA-JBI-SCA_I] M. Piraccini – S. Rossini – V.Caranna, “Java Business Integration e Service Component Architecture. I parte: Introduzione”, MokaByte 131, Luglio/Agosto 2008
[MOKA_JBI-SCA_II] M. Piraccini – S. Rossini – V.Caranna, “Java Business Integration e Service Component Architecture. II parte: Esempio pratico”, MokaByte 133, Ottobre 2008
[MOKA_SOA]
- [MOKA_SOA_I] M. Piraccini – S. Rossini, “SOA: Introduzione”, MokaByte 100, Ottobre 2005
- [MOKA_SOA_II] M. Piraccini – S. Rossini, “SOA: Metodologia”, MokaByte 101, Novembre 2005
- [MOKA_SOA_III] M. Piraccini – S. Rossini, “SOA (III): Il Maturity Model”, MokaByte 102, Dicembre 2005
- [MOKA_SOA_IV] M. Piraccini – S. Rossini, “SOA (IV) Roadmap”, MokaByte 103, Gennaio 2006
- [MOKA_SOA_V] M. Piraccini – S. Rossini, “SOA (V) SOI”, MokaByte 104, Febbraio 2006
- [MOKA_SOA_VI] M. Piraccini – S. Rossini, “SOA (VI) ESB (I)”, MokaByte 105, Marzo 2006
- [MOKA_SOA_VII] M. Piraccini – S. Rossini, “SOA (VII) ESB (II)”, MokaByte 106, Aprile 2006
- [MOKA_SOA_VIII]M. Piraccini – S. Rossini, “SOA (VIII)”, MokaByte 107, Maggio 2006
- [MOKA_SOA_IX] M. Piraccini – S. Rossini, “SOA (IX) Esempio (I)”, MokaByte 108, Giugno 2006
- [MOKA_SOA_X] M. Piraccini – S. Rossini, “SOA (X) Esempio (II)”, MokaByte 108, Luglio/Agosto 2006
- [MOKA_SOA_XI] M. Piraccini – S. Rossini, “SOA (XI): Riuso e granularità dei servizi SOA”, MokaByte 108, Luglio/Agosto 2006
[MOKA_JBI]
- [MOKA_JBI_I] S. Rossini, “Java Business Integration (I)”, MokaByte 100, Ottobre 2005
- [MOKA_JBI_II] S. Rossini, “Java Business Integration (II)”, MokaByte 101, Novembre 2005
- [MOKA_JBI_II] S. Rossini, “Java Business Integration (III)”, MokaByte 102, Dicembre 2005
[MOKA_EAISOA_CAP5] “Architetture di integrazione: Dall’Enterprise Integration a SOA”, Capitolo 5 “Java Business Integration”
https://www.mokabyte.it/cms/article.run?articleId=6TB-7TJ-J6N-2C5_7f000001_21141690_7578477f
[WP_COBIS] Comparison of business integration software
http://en.wikipedia.org/wiki/Comparison_of_business_integration_software
[JBI4CICS] S. Rossini – A. Cannone
- IT: “JBI4CICS: Integrare CICS con il Binding Component Jbi4Cics”, MokaByte 118, Maggio 2007
- EN: “Integrating CICS with Jbi4Cics Component”
http://www.theserverside.com/tt/articles/article.tss?l=IntegratingCICSwithJBI
[JBI4CORBA] M. Piraccini – M. Casoni, “Jbi4Corba: Integrare CORBA con il Binding Component Jbi4Corba”, MokaByte 117, Aprile 2007
[MOKA_ESB] S. Rossini, “Enterprise Service Bus”, MokaByte 96, Maggio 2005
[DCISCA] D. Chappel, “Introducing SCA”
http://www.davidchappell.com/articles/Introducing_SCA.pdf
[DEV]
http://www.developer.com/net/net/article.php/3636501
[ESB_WP]
http://it.wikipedia.org/wiki/Enterprise_Service_Bus
[GARTNER] Magic Quadrant for the Integrated Service Environment Market
http://www.i-10.dk/Document/00000003.pdf
[ITL]
http://itlab.wordpress.com/2008/06/16/sca-e-jbi/
[JBI]
http://jcp.org/en/jsr/detail?id=208
[JBIMF]
http://wiki.open-esb.java.net/Wiki.jsp?page=JBIMockFramework
[JBI_WP]
http://en.wikipedia.org/wiki/Java_Business_Integration
[ORAC]
http://www.oracle.com/technology/pub/articles/debu_testability_of_ejb.html
[OSOA]
http://www.osoa.org/display/Main/SCA+and+Spring+Framework
[ROADJBISS] Ross Mason, “The Road to JBI: Paved with Good Intentions”
http://www.theserverside.com/tt/articles/article.tss?l=TheRoadtoJBI
[RSAJ] M. Edwards, “Relationship of SCA and JBI”
http://www.osoa.org/display/Main/Relationship+of+SCA+and+JBI
Jean-Jacques Dubray, “Comparing SCA, Java EE and JBI”
https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/2824
[SCA]
http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications
[SCA_WP]
http://en.wikipedia.org/wiki/Service_component_architecture
[SETINJ]
http://www.martinfowler.com/articles/injection.html#SetterInjectionWithSpring
[TBOBW] J. Dirksen – T. Rademakers, “The Best of Both Worlds with Java Business Integration and Service Component Architecture (TS-5870)”
http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-5870&yr=2008&track=soa