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 Jbi4Cics, realizzato dal GruppoImola

Introduzione

Grazie alla diffusa adozione della SOA (Service Oriented Architecture), la specifica JBI sta prendendo piede nelle moderne tecnologie di integrazione. Secondo i dettami di JBI, è possibile sviluppare nuovi componenti di integrazione che possono essere installati in ESB (Enterprise Service Bus) che aderiscono alle specifiche, e che funzionino come ponti tra il bus e le tecnologie di comunicazione ormai datate.

Il Gruppo Imola contribuisce al progetto open-jbi-components ed è partner strategico di NetBeans; in questo contesto, finora Imola Informatica ha sviluppato due Binding Component JBI open source: Jbi4Corba and Jbi4Cics.

Il componente Jbi4Cics è un Binding Component JBI utilizzabile per connettere un un ESB con un sistema CICS. Jbi4Cics è sviluppato e testato sulla piattaforma OpenESB ed è integrato in NetBeans Enterprise.

In questo articolo presentiamo il componente Jbi4Cics con un caso di esempio di integrazione sviluppato utilizzando NetBeans Enterprise di Sun Microsystem.

 

Integrazione, ESB e JBI

Ogni sistema complesso si evolve negli anni, utilizzando tecnologie, standard e architetture differenti: tutto ciò comporta dei costi di integrazione. Java Business Integration (JBI) cerca di affrontare questo problema creando, per le soluzioni di integrazione, una architettura basata su standard.

Ogni problema di integrazione è unico; una adeguata miscela di componenti compatibili con le specifiche JBI fornirà  una soluzione commisurata nel modo migliore al problema specifico da risolvere. Un ESB JBI-compliant permette di integrare, in un modo standard, le vecchie tecnologie ereditate dal passato con quelle nuove; i componenti JBI rappresentano il ponte che collega il mondo “esterno” e il bus.

Per esempio, con Jbi4Corba, è possibile esporre un servant CORBA all‘interno del bus, oppure esporre un servizio interno sotto forma di servant CORBA: il componente si incarica della comunicazione (trasformare le request CORBA in messaggi XML) e della pubblicazione del servizio sul bus (come definizione WSDL standard).

Con Jbi4Cics, è possibile esporre un servizio CICS all‘interno del bus: il componente si incarica della comunicazione (trasformare la request ECI in messaggi XML) e della pubblicazione del servizio sul bus (come definizione WSDL standard).

Le specifiche JBI definiscono due diversi tipi di componenti adatti al deploy in un Enterprise Service Bus: i Binding Component (BC) e i Service Engine (SE). Mentre i Service Engine sono adatti a contenere logica pura di integrazione, i Binding Component, come suggerito dal nome (“componenti di connessione”) rappresentano il collegamento tra il bus e le applicazioni esterne.

Naturalmente, mentre all‘interno del bus viene utilizzata una comune “lingua franca” (sostanzialmente messaggi SOAP), all‘esterno del bus siamo in presenza di una “babele” di differenti tecnologie di comunicazione. Per questa ragione le specifiche JBI prevedono il concetto di Binding Component.

Quando viene ricevuto un messaggio da un servizio esterno, il compito del BC sta nel normalizzarlo e inviarlo al receiver endpoint (il “punto terminale” ricevente, che può essere sia un SE che un altro BI) utilizzando il Normalized Message Router (NMR). Viceversa, quando il messaggio deve essere restituito al servizio esterno, esso deve essere tradotto dal formato NMR al formato esterno; pertanto il NMR effettua lo smistamento di messaggi tra servizi e componenti di collegamento.

 

Figura 1 – BC, SE & NMR

 

 

Seguendo le indicazioni di JBI, il deploy di soluzioni di integrazione deve avvenire in Service Assemblies (SA), composti utilizzando BC e SE configurati correttamente per creare un flusso di messaggi coerente all‘interno del bus. Un‘applicazione sviluppata sulla base di tali concetti viene definita Composite Application.

 

Il componente Jbi4Cics

Il Gruppo Imola ha sviluppato il Binding Componet open source Jbi4Cics. Grazie a tale componente è possibile integrare senza problemi i sistemi CICS con qualsiasi altra applicazione, poiché Jbi4Cics permette di mappare un servizio CICS ECI come endpoint JBI. E avere a disposizione un endpoint JBI interno apre una ampia gamma di possibilità , perché questo punto terminale può prendere parte ai flussi di messaggi e all‘orchestrazione che hanno luogo all‘interno dell‘ESB.

È stato sviluppato un plugin per NetBeans  che consente un‘integrazione piena del componente con OpenESB (che è la piattaforma Enterprise Service Bus open source sviluppata da Sun Microsystem).

Analizziamo adesso il componente in maniera più approfondita per comprenderne le caratteristiche principali e il funzionamento.

Le principali caratteristiche del componente Jbi4Cics (attuale release: 0.2) sono:

• Rilasciato sotto licenza LGPL v2.1
• Supporto per OpenESB e ServiceMix
• Plugin compatibile con la suite NetBeans Enterprise
• Supporto per chiamate sincrone CICS-ECI (cioè InOut MEP)
• Supporto per i tipi di dati COBOL String, Binary, Packed Decimal, Zoned Decimal
• Supporto per le strutture nidificate e fixed length occurs

Fondamentalmente, il componente CICS funge da provider (dalla prospettiva del bus, si tratta di un componente utilizzabile da altri componenti per invocare un servizio) esponendo un servizio CICS ECI sul bus.

 

 

 

Figura 2 – Il componente Jbi4Cics ed ESB

 

Come è possibile vedere, ci sono 4 elementi:

• ESB
• un endpoint che effettua l‘invocazione
• il Binding Component Jbi4Cics
• il CICS Transaction Gateway (CTG)

In questa configurazione, l‘endopoint che effettua l‘invocazione può inviare un messaggio normalizzato al BC: tale messaggio sarà  trasformato in una request CTG. Il BC conosce lo specifico CTG e il programma COBOL, pertanto può effettuare la chiamata ad esso. Il risultato della chiamata viene normalizzato e inviato al punto terminale che effettua l‘invocazione.

Durante questo “scambio”, il BC utilizza tre informazioni definite quando il provider è stato configurato: host e porta in cui è collocato CTG (tramite JCA Connection Factory), il nome del programma COBOL, il nome del server CICS.

 

 

Figura 3 -  Scambi che interessano il componente Jbi4Cics a runtime

A questo punto, secondo la filosofia del “configura, non scrivere codice”, per usare Jbi4Cics non serve conoscere un linguaggio di programmazione ma basta saper maneggiare i dati di configurazione. Pertanto, l‘unico compito per l‘utente è di configurare il mondo in cui il BC può individuare il CTG (tramite JCA Connection Factory) e di specificare il file COMMAREA che rappresenta l‘interfaccia esposta dal servizio COBOL.

 

Scenario di integrazione

Per mostrare il modo in cui è possibile usare il componente Jbi4Cics, possiamo immaginare un semplice scenario di integrazione. In questo esempio dobbiamo integrare un semplice programma COBOL (che espone un servizio di lunghezza di stringa) dentro un processo BPEL.

L‘interfaccia del programma COBOL viene definita usando un semplice file di testo dove dichiariamo la sua COMMAREA. Questo metodo accetta un input e restituisce la sua lunghezza. Ecco la COMMAREA utilizzata in questo esempio

02 inputString PIC X(30) DISPLAY.
02 strlen PIC 9(10) DISPLAY.

 

 

Figura 4 – Configurazione Jbi4Cics

 

Requisiti software

È necessaria la preinstallazione di alcuni strumenti open source

• l‘IDE NetBeans 5.5.1ÂÂ
• NetBeans Enterprise Pack 5.5.1
• plugin Jbi4Cics per NetBeansÂÂ
• il Binding Component Jbi4Cics

Per primi, vanno installati l‘ambiente di sviluppo integrato NetBeans e il relati-vo Enterprise Pack. Poi occorre scaricare e scompattare il plugin per NetBeans Jbi4Cics in una directory temporanea (verranno estratti alcuni file con esten-sione .nbm).

A questo punto si avvia l‘IDE NetBeans e si seleziona:

• Tools -> Update Center -> Install Manually Downloaded Modules (.nbm files) -> next
• Poi si selezionano i file .nbm scompattati e -> next -> next
• Si accetta l‘accordo della licenza
• Si seleziona l‘opzione che prevede di includere tutti i moduli, e poi fine.

 

 

Figura 5 – L‘installazione dei moduli Jbi4Cics per NetBeans

 

Avviare il Sun Java System Application Server

Innanzitutto, avviare l‘Application Server Sun Java System, seguendo i seguenti passi:

• Aprire la finestra di runtime
• Fare click con il tasto destro sul server e avviarlo

 

 

Figura 6 – Avviare il Sun Java System Application Server

 

Installare il componente Jbi4Cics

Aprire la sottodirectory “JBI” del server, fare click con il tasto destro su “Binding Components” e scegliere “Install New Binding Component”

 

 

Figura 7 – Installazione del componente Jbi4Cics

A questo punto, selezionare l‘installer Jbi4Cics precedentemente scaricato (jbi4cics-0.2-installer.zip): apparirà  il componente Jbi4Cics. Adesso basta fare click con il tasto destro del mouse e selezionare “Start”.

 

Creare il WSDL del servizio

Il passo successivo consiste nel creare un nuovo WSDL a partire dall‘interfaccia del programma COBOL. Con questo WSDL, diventa possibile aggiungere il servizio CICS come partner link in un processo BPEL. È questa l‘operazione principale effettuata dal plugin per Jbi4Cics in NetBeans: esso riconosce le estensioni CPY e cpy per il file Copy Cobol.

Dall‘IDE NetBeans, selezionare

New Project -> Service Oriented Architecture -> BpelModule

NetBeans creerà  una cartella in cui sarà  possibile collocare il file CPY.

 

 

Figura 8 – Ecco come aggiungere il file CPY nel modulo BPEL

 

A questo punto, si fa click con il tasto destro sul file CPY e si seleziona “Create WSDL”.

 

 

Figura 9 – La creazione del WSDL a partire dall‘interfaccia Cobol

 

Ecco che dovrebbe apparire il wizard di Jbi4Cics che ci chiederà  di specificare alcuni dati di configurazione.

 

 

Figura 10 – Il wizard del plugin Jbi4Cics

Progettare il processo BPEL con NetBeans

Adesso diventa possibile progettare un processo utilizzando il nuovo editor BPEL di NetBeans. Il primo punto consiste nel definire il WSDL per l‘intero processo; poi, nell‘ottica BPEL, deve essere creato un partner link per ciascun servizio interessato.

Nell‘articolo su Jbi4Corba, abbiamo parlato di un processo BPEL semplice da progettare: un messaggio viene ricevuto e poi viene utilizzati per invocare il servant CORBA. L‘interfaccia del servizio CORBA viene definita usando un file IDL, in cui dichiariamo 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).

Ma in questo caso, dobbiamo fare qualcosa un po‘ più complesso. Dobbiamo conoscere il saldo di conto corrente solo se il conto corrente è valido. Dobbiamo invocare un programma Cobol che accetta una stringa in input (il nome utente) e restituisce un numero integer (compreso tra 0 e 5, dove 0 significa stato di conto corrente valido)

Il processo BPEL dovrebbe restituire il saldo solo per un utente validato, mentre dovrebbe restituire 0 per l‘utente non valido. Il nostro processo deve seguire questo modello: viene ricevuto un messaggio che poi viene utilizzato prima per effettuare la chiamata al servant CORBA e poi per chiamare il programma Cobol.

 

 

Figura 11 – Il processo di esempio

 

Abbiamo due partner link: uno è un servant CORBA da integrare tramite Jbi4Corba, l‘altro è un programma Cobol da integrare tramite Jbi4Cics. Va notato come con NetBeans sia possibile progettare il processo grazie a strumenti visuali, senza alcuna conoscenza di linguaggi di programmazione.

 

 

Figura 12 – Il processo BPEL

 

Creare una nuova applicazione composita che includa il modulo BPEL
Una volta che il progetto BPEL è pronto, occorre creare il progetto della CA (Composite Application). La CA includerà  un Binding Component SOAP (aggiunto automaticamente da NetBeans), il processo BPEL e il nostro Binding Component per CICS.

Dopo aver creato il progetto, eseguire i seguenti passaggi:

• click con il tasto destro sul nodo del progetto CA e scegliere “Add JBI module” (selezionando il modulo BPEL creato precedentemente);
• click con il tasto destro sul nodo del progetto CA e scegliere “Build Project”;
• click con il tasto destro sul nodo del progetto CA e scegliere “Edit Project”.

A questo punto apparirà  l‘editor CASA (Composite Application Service Assembly).

 

 

Figura 13 – L‘editor CASA (Composite Application Service Assembly) di Ne-tBeans

 

Deploy della Composite Application

Finalmente è arrivato il momento di effettuare il deploy: basta fare click con il tasto destro sul progetto della Composite Application e scegliere “Deploy Project”. Per vedere sul server il SA di cui si è effettuato il deploy, fare click con il tasto destro sulla sottodirectory “Service Assemblies” e scegliere “refresh”.

 

 

Figura 14 – La Composite Application avviata correttamente

 

Test del servizio

È ora possibile utilizzare le funzionalità  di test di NetBeans per verificare direttamente il funzionamento della Composite Application con messaggi SOAP.

 

 

Figura 15 – Il test della Composite Application

Roadmap

Il componente Jbi4Cics è attualmente alla versione 0.2, ma lo sviluppo continua. Il Gruppo Imola e Sun Microsystem hanno definito il seguente piano di sviluppo per le prossime versioni:

Release 0.5 (III Qt 2007):

• maggior numero di tipi di dati Cobol (floating point, long floating point, date…)
• variable length occurs
• supporto per la clausola “redefines”
• chiamate asincrone (InOnly MEP).

Release 1.0 (I Qt 2008):

• maggior numero di funzionalità  di sicurezza
• maggior numero di funzionalità  transazionali
• maggior numero di funzionalità  per la gestione

 

Conclusioni

L‘avvento di SOA e dei web service sta spingendo le aziende a riorganizzare il software presente sotto forma di una serie di servizi riutilizzabili. In questa riorganizzazione, il sofware “legacy”, ereditato dal passato, viene normalmente inglobato in un processo di “wrapping”, per salvaguardare gli investimenti dell‘azienda, e poi viene esposto come servizio utilizzando un ESB. In tutte le aree di business in cui ci si trovi in presenza principalmente di sistemi host, il componente Jbi4Cics può risultare molto utile poiché, grazie ad esso, si può consentire a un vecchio CICS legacy di essere integrato in un moderno ambiente Enterprise Service Bus.

 

Riferimenti

Gruppo Imola
http://www.imolinfo.it
http://gruppoimola.wordpress.com/

 

Jbi4Cics
http://www.glassfishwiki.org/jbiwiki/Wiki.jsp?page=CICSBC

 

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

 

MokaByte (https://www.mokabyte.it)
M.Piraccini – M. Casoni, “Jbi4Corba”, MokaByte 117
S. Rossini, Java Business Integration, MokaByte 100, 101 e 102