In questo articolo parleremo degli standard Java Business Integration (JBI) e Service Component Architecture (SCA), due standard riconducibili a SOA. Questi standard, a volte visti erroneamente come “contrastanti”, cercano di proporre un loro modello architetturale che possa aiutare alla realizzazione di una SOA.

 

Introduzione

In articoli precedenti (da [MOKA_SOA_I] a [MOKA_SOA_XII]) abbiamo cercato di affrontare l’argomento SOA da molti punti di vista (architetturale, metodologico, organizzativo, tecnologico, pratico) in modo da offrire una visione il più possibile completa di questo tema complesso ma che è oggi è sempre più strategico nel mondo IT. In [MOKA_SOA_VI] abbiamo introdotto 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.

È importante ricordare che non esistono specifiche relative al SOA Bus: cos’è, quale funzionalità deve fornire, come è composto, etc… Da un punto di vista tecnologico questo concetto trova riscontro nei prodotti ESB. In questo articolo parleremo degli standard Java Business Integration (JBI) e Service Component Architecture (SCA), due standard riconducibile a SOA. Questi standard cercano di proporre un loro modello architetturale che possa aiutare alla realizzazione di una SOA; spesso sono visti in antitesi nel loro proposito di facilitare l’integrazione ma in realtà propongono delle “sfide” un po’ diverse come vedremo nel corso di questi tre articoli.

Java Business Integration (JBI)

JBI è l’acronimo di Java Business Integration e definisce un’architettura standard per uniformare l’integrazione di componenti EIS eterogenei all’interno di applicazioni JBI-compliant. (vedere [MOKA_JBI]). Le specifiche JBI definiscono un ambiente Java per l’integrazione basato sui principali standard open e di mercato. JBI (JSR 208) definisce uno standard per 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 (WSDL) 2.0.

L’idea di base è di consentire la System Integration sfruttando l’idea dei container di servizi 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 rappresentata da un’applicazione composta da un engine BPEL, che interopera con un EJB Container, e da un data transformation all’interno di un JBI environment.

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 d’integrazione per connettere applicazioni Java con applicazioni non-Java, risorse legacy e pacchetti applicativi.

L’architettura JBI è costituita dai seguenti elementi:

• i Componenti JBI
  •   Binding Components (BC)
  •   Service Engine (SE)

• il Normalized Message Router (NMR)
• i componenti MBean di gestione
• le entità esterne da integrare (external service consumer e provider).

La figura 1 riporta l’architettura ad alto livello di JBI.

 

 Figura 1 – L’architettura JBI ad alto livello

 

Un Service Engine (SE), componente che fornisce o consuma servizi localmente (all’interno dell’ambiente JBI), si occupa della logica di business/integrazione, della trasformazione e del routing. Ad esempio, un SE BPEL è in grado di orchestrare i servizi dei processi business con la possibilità di esporre un nuovo servizio dato dall’aggregazione di questi ultimi.

I Binding Component (BC) sono dei componenti che espongono i servizi dell’ambiente JBI e sono specializzati per degli specifici protocolli esterni, come HTTP, JMS, JDBC, FTP, File, e altri. Questo permette a qualunque componente JBI di comunicare, su un protocollo disponibile, dal Binding Component installato (deploy) all’ambiente di esecuzione JBI. I BC consentono un disaccoppiamento dell’implementazione del servizio dal meccanismo di accesso.

I BC comunicano con il Normalized Message Router (NMR) per l’invio e la ricezione dei messaggi agli altri componenti dell’ambiente e sono loro che si occupano di effettuare la normalizzazione dei messaggi, che consiste nel trasformare tali messaggi nel formato compatibile all’ambiente JBI che è l’XML.

JBI consente il deploy e l’aggregazione di componenti sviluppati da diversi produttori all’interno di ambienti JBI-compliant. Questo permette di scegliere il miglior componente per la specifica situazione (il cosiddetto: “best of breed”) d’integrazione all’interno di una infrastruttura JBI-compliant.

 

 Figura 2 – JBI: Binding Component, Service Engine e Normalized Message Router

 

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 per cercare di ripetere il successo J2EE ottenuto in ambito Enterprise nel complesso panorama dell’Enterprise Application Integration.

Su MokaByte, ad oggi, è stato scritto molto riguardo JBI. Per approfondire l’argomento fare riferimento agli articoli [MOKA_JBI_I], [MOKA_JBI_II], [MOKA_JBI_III], [MOKA_EAISOA_CAP5], [JBI4CICS] e [JBI4CORBA]. In [MOKA_SOA_X] è stata presentata una demo di Composite Application utilizzando l’ESB JBI Service Mix.

 

 

 

 

 

Service Component Architecture (SCA)

Nel 2005, il consorzio Osoa (Open Soa) formato da BEA System, IBM, IONA, Oracle, SAP AG, Siebel e Sybase ha rilasciato le specifiche per SCA (Service Component Architecture), un modello per costruire applicazioni e sistemi usando una Service Oriented Architecture. Nel frattempo ha realizzato anche la specifica SDO (Service Data Object) per acquisire in modo omogeneo i dati provenienti da fonti diverse.

Il modello di programmazione fornito da SOA per realizzare le applicazioni si focalizza sulla modalità di definizione dei servizi. L’artefatto base di SCA è il componente, che consiste in un’istanza d’implementazione vista come logica business. Come mostra la figura 4, il componente racchiude la realizzazione di funzionalità note come servizi. Dal momento che un componente può far uso di servizi ulteriori, riesce a invocarli mediante i riferimenti. Le properties sono invece impostabili e vanno a influenzare le operazioni delle funzionalità business.

L’implementazione dei componenti è possibile mediante una varietà di tecnologie di implementazione messe a disposizione da SCA, che vanno dai linguaggi tradizionali (Java, C++) a linguaggi di più alto livello come BPEL. I componenti possono essere realizzati anche con applicazioni o componenti di tipo non SCA.

 

 Figura 4 – Un componente SCA

 

L’insieme dei componenti va a definire la Composite Application, rappresentante l’applicazione sviluppata. SCA fornisce quindi un modello di programmazione, l’Assembly Model, per la costruzione di applicazioni e di soluzioni basate sul concetto SOA di Composite Application.

Per cui il modello (Assembly Model) descrive come sviluppare componenti, come configurarli e come comporli. Secondo tale modello, le funzionalità business possono essere composte a partire da una serie di servizi, e assemblati insieme per creare soluzioni che servono un particolare requisito di business (Composite Application).

 

 Figura 5 – SCA: Assembly Model di una Composite Application

 

A sua volta, le Composite Application possono contenere sia nuovi servizi creati specificamente per l’applicazione che servizi esistenti offerti da sistemi e applicazioni esistenti, riusati come parti della composizione. Le composizioni ottenibili dall’aggregazione di componenti e da altre composizioni sono descritte tramite un file XML che segue il formato SCDL (Service Component Definition Language). Mediante questo file è possibile indicare i componenti e le composizioni da aggregare, la loro implementazione, le proprietà che richiedono (inversione di controllo), i punti di accesso che espongono (binding), le policy che esigono (sicurezza, affidabilità, …) e le dipendenze (altri componenti o composizioni cui fanno riferimento); anche per il risultato della composizione (il service) è possibile esporre uno o più punti di accesso (binding) e richiedere che un certo numero di policy vengano soddisfatte.

 

 

I Service Data Object (SDO) sono una specifica approvata dalla community Java attraverso la JSR 235 e rappresenta il risultato di uno sforzo compiuto dal-la IBM e da BEA System, chiamato CommonJ. SCA è una specifica pensata per lavorare a stretto contatto con gli SDO, implementati però già dalle tecno-logie SCA e che fanno di tale specifica un punto di forza per la realizzazione dell’integrazione.

Come mostra la figura 7, gli SDO definiscono un modo per accedere e manipolare i dati provenienti da sorgenti eterogenee, includendo i database relazionali, le sorgenti XML, i Web Services, i sistemi di informazione enterprise (EIS). Questi sono basati sul concetto di DataGraph che è una collezione di oggetti strutturati ad albero, e potrebbero essere disconnessi dalla sorgente dati. In SOA, l’applicazione non è connessa direttamente alla sorgente dati. Vi accede mediante un intermediario chiamato servizio di accesso ai dati (DAS) e riceve un grafo come risposta. Per approfondire l’argomento fare riferimento a [SDO].

 

 Figura 7 – Ruolo di un DMS

 

Conclusioni

La strada verso SOA ha portato i principali fornitori ad adottare dei modelli di riferimento che potessero rispondere alle esigenze del loro mercato. Nel corso di questi articoli analizzeremo gli standard JBI e SCA introdotti per la realizzazione delle applicazioni SOA.

In questo primo articolo abbiamo iniziato a descrivere sia lo standard SUN JBI che lo standard Oasis SCA. Nel prossimo articolo svilupperemo un esempio che verrà realizzato sia con JBI, utilizzando Open ESB (l’ESB OpensSource di SUN JBI-compliant) che con SCA utilizzando Oracle SOA suite (la suite Oracle per SOA basata su SCA).

 

Riferimenti

[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 109, Luglio/Agosto 2006

[MOKA_SOA_XI] M. Piraccini – S. Rossini, “SOA (XI): Riuso e granularità dei servizi SOA”, MokaByte 116, Marzo 2007

[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] M. Piraccini – S. Rossini, “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

[JBI4CICS] S. Rossini – A. Cannone, “JBI4CICS: Integrare CICS con il Binding Component Jbi4Cics”, MokaByte 118, Maggio 2007

 

[SSJBI4CICS]. Rossini – A. Cannone, “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

[ESB_WP]

http://it.wikipedia.org/wiki/Enterprise_Service_Bus

[WP_COBIS] Comparison of business integration software

http://en.wikipedia.org/wiki/Comparison_of_business_integration_software

[JBI_WP]

http://en.wikipedia.org/wiki/Java_Business_Integration

[JBI]

http://jcp.org/en/jsr/detail?id=208

[OASIS] OASIS Standard

http://www.oasis-open.org/specs/index.php#wssv1.0

[SCA]

http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications

[SCA_WP]

http://en.wikipedia.org/wiki/Service_component_architecture

[DCISCA] D. Chappel, “Introducing SCA”

http://www.davidchappell.com/articles/Introducing_SCA.pdf

[SDO]

http://www.ibm.com/developerworks/library/specification/ws-sdo/