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
Marco Piraccini è nato a Cesena il 09/10/1975. E‘ laureato in Ingegneria Informatica presso la facoltà di Bologna con una tesi sull‘assessment della maturità del processo di testing e
in Fisica Computazionale presso la facoltà di Udine con una tesi sull‘uso di GRID per le simulazioni Monte Carlo (nell‘ambito di un esperimento di astrofisica).
Attualmente lavora come Software Architect per una società di consulenza. Il suo Blog è disponibile al seguente indirizzo: http://darkav.blogspot.com/
Vittoria Caranna è nata a Rimini nel 1982. Lauretasi in Ingegneria Informatica presso l‘Università degli studi di Bologna nel dicembre del 2007, da gennaio 2008 lavora per il Gruppo Imola.
Svolge attività di consulenza, in particolare per quanto riguarda le tematiche architetturali e di processo.
Stefano Rossini è nato a Giussano (MI) il 29/10/1970 e ha conseguito il diploma universitario in Ingegneria Informatica presso il Politecnico di Torino. Ha maturato più di venti anni di esperienza in diversi progetti Enterprise mission-critical ricoprendo i ruoli di IT Program Manager, Project Manager & Software Architect presso importanti gruppi bancari, pubblica sanità, pubblica amministrazione e software house.
Attualmente ricopre il ruolo di Sofware Factory Manager, Lean Change Agent ed Enterprise Architect presso Capgemini.
Esperto in ambito di sanità pubblica come Project/Program Manager per la governance dei progetti IT strategici di Cartella Clinica Elettronica (CCE) e Fascicolo Sanitario Elettronico (FSE).
Esperto in ambito bancario dove ha ricoperto per una decina d'anni il ruolo di Project Manager e Leader Software Architect (BPM, IWBank e BPS) occupandosi della pianificazione e gestione del progetto, del coordinamento del gruppo di sviluppo software sia InHouse che Nearshore/Offshore. Esperto nella conduzione di progetti secondo metodologia di Project Management PMBok e metodologia agile Scrum.
Si occupa di Java dal 1999 arrivando da precedenti esperienze in C e C++ in ambito Telco (Alcatel & Siemens). Ha pubblicato più di un centinaio di articoli su argomenti di IT Governance, Project Management, architetture enterprise e problematiche di Integrazione e SOA. È coautore dei libri "Manuale pratico di Java" (2001) e "La programmazione della piattaforma J2EE" (2005) editi da Hops/Tecniche Nuove. Certificazioni IT Governance: COBIT V.4.1 Foundation Certificate; certificazioni IT Service Management: ITIL V.3 Foundation Examination; certificazioni Project Management: CSM - Scrum Master, CSPO - Scrum Product Owner, PMI: 35 contact hours.
Profilo linkedin: http://www.linkedin.com/pub/stefano-rossini/30/977/242