Seguendo le specifiche JBI, è possibile sviluppare nuovi componenti di integrazione che possono poi essere installati in Enterprise Service Bus compatibili affinché funzionino come “ponti” tra il bus e le vecchie tecnologie di comunicazione. esaminiamo il componente Jbi4Corba, realizzato dal GruppoImola.
Grazie alla diffusa adozione dell‘architettura orientata ai servizi (Service Oriented Architecture), la specifica JBI sta prendendo sempre più piede nelle moderne tecnologie di intergrazione.
Seguendo le specifiche JBI, è possibile sviluppare nuovi componenti di integrazione che possono poi essere installati in Enterprise Service Bus compatibili affinchà© funzionino come “ponti” tra il BUS e le vecchie tecnologie di comunicazione.
Il GruppoImola ha sviluppato il componente Jbi4Corba, un Binding Component JBI open source che può essere utilizzato per connettere un ESB con un sistema CORBA.
GruppoImola contribuisce con questo componente al progetto open-jbi-components e diviene partner strategico di NetBeans. Per tali ragioni, il componente Jbi4Corba viene sviluppato e testato sulla piattaforma OpenESB ed è integrato in NetBeans Enterprise.
In questo articolo viene presentato il componente di collegamento Jbi4Corba, accompagnando tale presentazione con un caso d‘uso di integrazione realizzato con il nuovo NetBeans Enterprise di Sun Microsystem.
Integrazione ed Enterprise Service Bus
Ogni sistema complesso si evolve negli anni utilizzando tecnologie, standard e architetture differenti: tutto ciò ha dei costi in termini di integrazione. Gli scenari degli ultimi dieci anni nel mondo della Information Technology mostrano quanto tali costi possano essere elevati. SOA viene presentata come soluzione di questo problema: se si sviluppa un sistema prevendendo fin dall‘inizio l‘evoluzione e l‘integrazione, questa mentalità ridurrà al minimo i costi di integrazione e si garantirà maggiore reattività ai cambiamenti del modello di business.
Il middleware Enterprise Service Bus può essere adottato in SOA per integrare le tecnologie vecchie “ereditate” (legacy), con quelle nuove. perché l‘integrazione che usa un ESB è una buona idea?
Ogni volta che si adotta una nuova tecnologia, devono essere prese molte decisioni. Una di queste decisioni è “ha senso mantenere il vecchio software o è meglio sostituirlo con quello nuovo?”. Il software nuovo è probabilmente migliore, da un certo punto di vista (servizi migliori e costi più vantaggiosi) e può essere aperto a nuovi canali di comunicazione. D‘altro canto, il vecchio software ha un grosso vantaggio: funziona e rappresenta un bene economico comunque valido per l‘azienza e che l‘azienda ha già pagato.
Per risolvere questo problema, una delle opzioni è “inglobare” (wrapping) il vecchio software, accedendo ad esso tramite uno strato di integrazione. Se questo layer di integrazione utilizza per la comunicazione degli standard open (come previsto da SOA), i costi di integrazione vengono ridotti. Inoltre, se questo strato è centralizzato (con un middleware di integrazione), non sono più necessarie delle connessioni punto a punto tra i processi che devono essere integrati: il risultato è un sistema meglio gestibile.
Questa impostazione architetturale può essere realizzata utilizzando gli ESB, ed è inoltre possibile farlo in maniera standardizzata grazie alla nuova specifica JBI (Java Business Integration).
Gli obiettivi principali dell‘Enterprise Service Bus sono:
- disaccoppiamento e messaggistica utilizzando il BUS
- condivisione, vendita e acquisto di componenti
- la filosofia “configurare invece di scrivere codice” (Configure, don‘t code)
Vediamo questi aspetti in maggiore dettaglio.
Disaccoppiamento e messaggi usando il BUS
I componenti JBI non comunicano direttamente uno con l‘altro, ma è il BUS che ha il compito di consegnare i messaggi da un punto a un altro. Connettendo tutti i servizi con il BUS, questa architettura consente di evitare l‘integrazione punto a punto, che può condurre a sistemi complessi con alti costi di manutenzione.
I servizi possono essere implementati utilizzando tecnologie diverse, pertanto diventa possibile connettere il BUS alle nostre “vecchie” soluzioni, che si sono dimostrate valide e affidabilie nel corso degli anni.
Il ponte tra il mondo “esterno” e il BUS è rappresentato dai componenti JBI.
Per esempio, con Jbi4Corba è possibile esporre un servant CORBA all‘interno del bus, o esporre un servizio interno sotto forma di servant CORBA: il componente si incarica della comunicazione (trasformare la request CORBA in messaggi XML) e della pubblicazione del servizio sul BUS (ome definizione standard WSDL).
Condivisione, vendita e acquisto di componenti
L‘architettura ESB è basata su un modello “pluggable”, in cui cui le varie parti da aggiungere devono essere costruite seguendo le specifiche JBI. Questo significa che se si scrive un componente JBI, è possibile condividerlo, e tutti possono installarlo e usarlo in un ESB che aderisca alle specifiche JBI.
Ovviamente questa filosofia favorisce un mercato in cui è possibile trovare componenti di integrazione che facciano al caso nostro. Va anche detto che, dal momento che JBI è uno standard aperto, c‘è molto spazio per soluzioni open source.
Jbi4Corba è un progetto open source pertanto è possibile usarlo ed estenderlo senza particolari limitazioni.
La filosofia “configurare invece di scrivere codice”
ESB favorisce una filosofia della “configurazione piuttosto che la programmazione”, secondo la quale non dovrebbe essere necessaria la conoscenza di un linguaggio di programmazione per usare un componente, ma dobrebbero essere gestiti solamente i dati di configurazione. Il punto interessante è che i dati di configurazione possono essere facilmente gestiti per mezzo di appositi tool.
Per esempio, si può utilizzare il plugin per NetBeasn sviluppato dal GruppoImola per creare soluzioni di integrazione, usando il componente Jbi4Corba, senza alcuna conoscenza di programmazione.
Java Business Integration
Le specifiche JBI definiscono due tipi diversi di componenti adatti al deployment in un ESB: i Binding Components (BC) e i Service Engines (SE).
Mentre i Service Engine sono utili per contenere logica di integrazione pura, i Binding Components rappresentano la “connessione” tra il BUS e le applicazioni esterne.
Ovviamente, mentre dentro il bus viene usata una “lingua franca” (sostanzialmente, messaggi SOAP), fuori dal bus è presente una babele di differenti tecnologie di comunicazione. Questa è la ragione per cui la specifica JBI fornisce il concetto di Binding Component.
Fondamentalmente, un BC può avere due funzioni:
- Provider: dalla prospettiva del bus, si tratta di un componente che può essere usato da altri componenti per invocare un servizio.
- Consumer: dalla prospettiva del bus, si tratta di un componente che può essere usato da un‘applicazione esterna, per invocare un servizio.
Quando viene ricevuto un messaggio proveniente da un servizio esterno, il compito del Binding Component sta nel normalizzarlo e inviarlo al receiver endpoint, ossia al destinatario (che può essere un Service Engine o un altro Binding Component), usando il Normalized Message Router (NMR).
Viceversa, quando il messaggio deve essere inviato al servizio esterno, esso deve essere “tradotto” dal formato NRM al formato esterno.
Secondo quanto previsto da JBI, il deploy delle soluzioni di integrazione deve avvenire in Service Assemblies (SA), composti usanto BC e SE configurati correttamente per creare un flusso di messaggi coerente all‘interno del BUS.
Le applicazioni sviluppate usando tali concetti sono dette composite (Composite Application).
Il componente Jbi4Corba
Con il supporto di Sun Microsystems, il GruppoImola ha sviluppato Jbi4Corba, un Binding Component open source.
Con questo componente è possibile integrare agevolmente i sistemi CORBA con qualsiasi altra applicazione, perché esso è in grado di gestire la comunicazione tra il bus e un servant o client CORBA esterni.
In effetti, abbiamo sviluppato un plugin per NetBeans che consente una integrazione completa del componente con OpenESB, ossia l‘Enterprise Service Bus open source sviluppato da Sun Microsystems.
Diamo un‘occhiata all‘interno del componente, per comprendere le sue caratteristiche principali e il modo in cui funziona.
Le caratteristiche principali del componente Jbi4Corba sono:
- rilasciato sotto licenza LGPL v2.1
- supporto per tipi CORBA primitivi e complessi
- supporto per entrambe le modalità consumer e provider
- supporto per gli IDL contenenti definizioni di più interfacce
- supporto per più implementazioni di ORB
- supporto per comunicazioni sincrone (In-Out MEP)
Il componente può fungere da provider (esporre un servant CORBA sul BUS) o da consumer (esporre un service sul BUS come servant CORBA):
Modalità Provider
Nel primo caso in esame, il componente viene configurato come provider.
Si possono individuare 5 elementi:
- un Servant CORBA
- il nome del servizio CORBA
- l‘ESB
- il BC Jbi4Corba
- un endpoint che effettua l‘invocazione del servizio
In questa confgurazione, l‘endpoint che invoca il servizio può inviare un messaggio normalizzato al BC: tale messaggio sarà trasformato in una request CORBA. Il BC conosce lo specifico servant CORBA (look-up effettuata tramite il name server), pertanto può effettuare chiamate verso di esso. Il risultato della chiamata è normalizzato e inviato all‘endpoint che effettua l‘invocazione.
Durante questo “scambio”, il BC usa 3 informazioni definite quando il provider è stato configurato. Il nome del servant CORBA, lo host e la porta in cui si trova il nome del servizio.
A questo punto una buona domanda potrebbe essere: “Dobbiamo scrivere un BC specifico per ogni servant CORBAA per “pubblicarlo” sul bus?”. Ovviamente la risposta è no.
Infatti, Jbi4Corba è scritto per un uso generale e per adattarlo a qualsiasi servant CORBA.
Secondo la filosofia “configure, don‘t code”, l‘unico compito a carico dell‘utente è di configurare il modo in cui il BC può individuare il servant, e di specificare il file IDL che rappresenta l‘interfaccia esposta
Modalità Consumer
Jbi4Corba può anche fungere da consumer, esponendo un endpoint interno sotto forma di servant CORBA.
Gli elementi sono sostanzialmente gli stessi della modalità provider, ma alcuni di essi cambiano ruolo. Infatti, in questa situazione, il BC di Jbi4Corba deve creare un servant CORBA che possa essere invocato da parte di un Client CORBA esterno.
A runtime, un client CORBA invoca un metodo sul servant CORBA creato tramite il componente Jbi4Corba. La richiesta viene trasformata in un messaggio normalizzato, che è collocato sul bus e poi inviato all‘endpoint che lo deve ricevere.
In questa situazione, l‘utente deve conoscere solamente alcune informazioni di configurazione per poter effettuare correttamente il deploy di questo componente. Le informazioni, in questo caso, sono rappresentate dall‘interfaccia dell‘endpoint (espressa con WSDL). Questa interfaccia è convertita in interfaccia IDL che è poi registrata sul name server CORBA.
Scenario di integrazione
Per mostrare il modo in cui può essere usato il componente Jbi4Corba, possiamo immaginare un semplice scenario di integrazione. In questo esempio, dobbiamo integrare un semplice servant CORBA (che espone un servizio di saldo di conto corrente) in un processo BPEL. Pertanto dobbiamo configurare il Jbi4Corba in modalità provider.
L‘interfaccia del servizio è definita usando un file IDL, dove si dichiara un metodo –getBalance()â?Â. Questo metodo accetta una stringa in input, che rappresenta il nome dell‘utente, e restituisce un numero double (compreso tra 0.00 e 100.00). Ecco di seguito il file IDL usato nell‘esempio:
module it {
module imolinfo{
module demo {
interface BalanceService {
double getBalance(in string user);
};
};
};
};
Requisiti software
Ci servono alcuni strumenti open source:
NetBeans Enterprise Pack 5.5.1
Innanzitutto si installa l‘IDE NetBeans e il corrispondente Enterprise Pack. Poi si scompatta il plugin di NetBeans per Jbi4Corba appena scaricato dentro una directory temporanea: dovrebbero essere spacchettati alcuni file .nbm.
A questo punto si avvia NetBeans e si effettuano i seguenti passaggi:
- dal menu Tools -> Update Center -> Install Manually Downloaded Modules (.nbm files) -> next
- si selezionano i file .nbm spacchettati precedentemente -> next -> next
- si accetta l‘accordo di licenza
- si selezionano tutti i moduli e poi si clicca su finish
Creare il WSDL del servizio
Il primo passo sta nel creare un nuovo WSDL a partire dall‘interfaccia IDL di CORBA. Con tale WSDL, sarà possibile aggiungere il servant come partner-link nel processo BPEL. Questa operazione è il compito principale svolto dal plugin Jbi4Corba di NetBeans.
In NetBeans, selezionare:
- New Project -> Service Oriented Architecture -> BpelModule
NetBeans creerà una cartella dove sarà possibile aggiungere il file IDL.
Adesso, fare click con il tasto destro del mouse sul file IDL e selezionare –Create WSDLâ?Â.
Dovrebbe apparire il wizard jbi4corba chiedendo di specificare alcuni dati di configurazione. Oltre alle informazioni necessarie per individuare il servant CORBA (le prorietà ORB e il nome CORBA da ricercare), occorre specificare:
- il nome dell‘endpoint (che sarà usato per registrare il servizio all‘interno del BUS)
- il namespace del servizio
Realizzare il processo BPEL con NetBeans
Adesso si può realizzare un processo usando il nuovo editor BPEL di NetBeans. Il primo passo sta nel definire il WSDL per l‘intero processo. Poi, secondo quanto previsto da BPEL, deve essere creato il partner link per ciascun servizio coinvolto.
Il processo realizzato è molto semplice: viene ricevuto un messaggio che poi è usato per effettuare una chiamata al servant CORBA. Va notato che con NetBeans è possibile disegnare in maniera visuale tutto il processo, senza alcuna conoscenza dei linguaggi di programmazione.
Fig. 11 – Il processo BPEL
Creare una nuova Composite Application che include il modulo BPEL
Quando il progetto BPEL è protno, si deve creare il progetto CA (Composite Application). L‘applicazione composita includerà un Binding Component SOAP (che viene aggiunto automaticamente da NetBeans), il processo BPEL appena creato e il Binding Component CORBA.
Una volta creato tale progetto, occorre seguire i seguenti passi:
- click con il tasto destro sul nodo del progetto CA e scegliere “Add JBI module” (selezionando il modulo BPEL che abbiamo creato in precedenza)
- click con il tasto destro sul nodo del progetto CA e scegliere “Build Project”
- click con il tasto destro sul nodo del progetto CA project node e scegliere “Edit Project”
A questo punto, dovrebbe apparire l‘editor CASA (Composite Application Service Assembly).
Avviare il Sun Java System Application Server ed effettuare il deploy della Composite Application
Adesso siamo pronti per effettuare il deploy della SA.
Innanzitutto occorre avviare il Sun Java System Application Server, nella maniera che segue:
- aprire la finestra di runtime
- aggiungere il “Sun Java System Application Server 9â?Â, se non è già presente
- fare click con il tasto destro sul server e avviarlo
Installare il componente jbi4corba
Per effettuare il depoloy della Composite Application, il componente Jbi4Corba deve essere installato su OpenESB. Occorre seguire i seguenti passaggi:
- se il server non è già in funzione, avviarlo
- aprire la sottodirectory “JBI” del server, fare click con il tasto destro su “Binding Components” e selezionare “Install New Binding Component”
- selezionare l‘installer di Jbi4Corba scaricato precedentemente (jbi4corba-0.2-installer.zip)
- adesso apparirà il componente Jbi4corba. Fare click con il tasto destro su di esso e selezionare “Start”.
Avviare il name server e il servant CORBA
Prima che si possa effettuare il deploy della Service Assembly, deve essere avviato un name server CORBA. Per esempio, si può avviare il Java runtime ORB, utilizzando:
orbd -ORBInitialPort 1049 -ORBInitialHost localhost
Fatto questo, il servant CORBA si può avviare e registrare sul name server.
Effettuare il deploy della Composite Application
Finalmente si è pronti per il deploy! A questo punto basta fare click con il tasto destro sul progetto Composite Application e scegliere “Deploy Project”. Per vedere sul sever la SA di cui si è appena fatto il deploy, fare click con il tasto destro sulla sottocartella “Service Assemblies” e selezionare “refresh”.
Test del servizio
È possibile usare la funzionalità di test di NetBeans per effettuare un test diretto della Composite Application con messaggi SOAP.
Roadmap
Jbi4Corba è già un buon Binding Component, ma lo sviluppo continua.
GruppoImola e Sun Microsystems hanno definito un‘interessante roadmap per le prossime release:
release 0.5
- più meccanismi di individuazione (corbaloc/corbaname, IOR)
- comunicazione asincrone (InOnly MEP)
- supporto per parametri InOut
- supporto per più tipi di IDL
- supporto per più tipi di WSDL
release 1.0
- supporto per caratteristiche di sicurezza avanzate
- supporto per la gestione delle transazioni
- support per caratteristiche di gestione avanzate
Conclusioni
L‘avvento di SOA e dei Web Service sta spingendo le aziende a riorganizzare il loro portfolio di software sotto forma di servizi riutilizzabili. In questa riorganizzazione, il software viene di solito “inglobato” con il wrapping per salvaguardare gli asset dell‘azienda, e poi viene esposto sotto forma di servizio usando un Enterprise Service Bus.
Ci sono alcune aree business (per esempio nelle infrastrutture delle aziende telefoniche) in cui tali asset sono rappresentati in gran parte da sistemi CORBA: in tali scenari il componente Jbi4Corba component può risultare utile.
Infatti, tramite il componente Jbi4Corba, è possibile consentire l‘integrazione di CORBA in un ambiente ESB in due maniere:
- Pubblicare un servant CORBA sul bus, dove può esere invocato da qualunque altro software connesso.
- Esporre, sotto forma di servant CORBA, tutto il software connesso al bus.
Riferimenti
Gruppo Imola
http://www.imolinfo.it/index_en.php
http://gruppoimola.wordpress.com/
Jbi4Corba
http://www.glassfishwiki.org/jbiwiki/Wiki.jsp?page=CORBABC
NetBeans
http://www.netbeans.org/
OpenESB
https://open-esb.dev.java.net/
JBI
http://jcp.org/en/jsr/detail?id=208