Nel precedente articolo sono state esaminate alcune possibili modalità d'integrazione punto-punto tra applicazioni Enterprise (vedere [MOKA_INT6]).
Si sono implementate delle connessioni punto a punto tra le Applicazioni prese in esame ponendo l'accento sul singolo problema di comunicazione.
La figura 1 riassume gli scenari d'integrazione punto-punto affrontati in [MOKA_INT6].

Figura 1: Scenari d'integrazione punto-punto

Cos'è un Integration Middleware?
Il termine Middleware genera spesso confusione, letteralmente è lo strato software posto nel mezzo. In linea con questa definizione, sono identificabili come Middleware un numero vastissimo di software completamente differenti fra loro (es. Application Server, MOM, JDBC, Screen Scraper).

Comunemente i Middleware sono suddivisi in tre macro-aree: Basic Middleware, Platform Middleware e Integration Middleware.
I Basic Middleware forniscono architetture consistenti per l'integrazione tra dati ed applicazioni. Esempi di questa tipologia sono ad esempio i MOM (Webshpere MQ, Sonic MQ, TIBCO/Rendezvous, FioranoMQ, Bea MessageQ, …) ed i Middleware di Data Management come ODBC e JDBC.
I Platform Middleware rappresentano la tipologia più complessa di Middleware come ad esempio gli Application Server (IBM WebSphere, BEA WebLogic, JBoss, …), i TP Monitor (BEA Tuxedo, IBM CICS, IMS), gli ORB (Borland VisiBroker, IONA ORBIX) ed i vari Portal Server. Spesso gli Application Server forniscono, integrandole direttamente, le funzionalità tipiche di TP e ORB.
Gli Integration Middleware sono pensati invece per connettere database ed applicazioni sviluppati su architetture differenti. Esempi di questa tipologia sono gli Integration Broker (IBM MQSeries Integrator; Tibco ActiveEnterprise, Microsoft BizTalk Server; Sonic ESB, Fiorano ESB …), i Business Process Managers (IBM MQSeries Workflow, Tibco InConcert2000, Vitria Technology BusinessWare Automator, Fiorano BIS, Bea WLI), i Gateways (MOM, Database e Platform) e gli Adapter.
In ambito open source, le proposte (per riferimenti vedere [OSISJ]) non hanno ancora raggiunto i livelli di credibilità raggiunti dai Platform Middleware (JBoss su tutti).
Le più comuni funzionalità fornite da una Integration Suite sono:

• Resource Adapter (RA): risolvono i problemi di comunicazione. Quasi tutti i fornitori EAI forniscono Adapter proprietari (sincroni ed asincroni) per la comunicazione con specifici EIS.
• Messaging brokers: tipicamente opera come messaging layer (MOM) ed può operare sia in modalità point-to-point che publish/subscribe.
• Integration Broker: si occupa del data mapping dei dati e dell'intelligent routing (content-based e/o publish-and-subscribe). Di solito il data mapping è l'operazione più costosa nell'integrazione visto che tipicamente i dati acquisiti da un RA in un formato proprietario devono essere trasformati (sintatticamente e/o semanticamente) secondo le esigenze del business object richiedente.
• Workflow: in questo contesto si intende il coordinamento di business object e messaggi nell'esecuzione di processi di business. I tool specializzati nella gestione del workflow di processi di business sono denominati Business Process Manager (BPM).
• Monitor delle attività di Business (analisi della storia degli eventi di business per tracciare l'accuratezza, la qualità e la sicurezza delle attività di business istanziate)

Queste funzionalità vengono tipicamente fornite (tutte o in parte) dagli Integration Middleware.

Figura 2: Macro struttura di un Integration Middleware

L'adozione di tecnologie più sofisticate quali sistemi di Messaging, Gateway e Middleware di comunicazione consentono di semplificare le problematiche di comunicazione supportando meccanismi sincroni, asincroni e real-time.

E' comunque doveroso annotare che, in assenza di una struttura centralizzata permanente e di una visione consistente delle problematiche di integrazione, la semplice adozione di queste tecnologie non riesce ad abbattere i costi e le complessità della "Spaghetti Integration".
Per affrontare quindi con successo un'attività d'integrazione bisogna tenere conto sia di un aspetto prettamente tecnologico che di un aspetto organizzativo e metodologico. Inoltre è opportuno valutare la reali necessità architetturali e/o aziendali che giustifichino l'adozione di un Integration Middleware.
In questo articolo ci si concentrerà prettamente sull'aspetto tecnologico.

Il ruolo architetturale dell'Integration Middleware
Da un punto di vista architetturale, l'Integration Middleware deve essere l'interfaccia unica attraverso cui transita ogni richiesta di comunicazione tra sistemi applicativi disomogenei permettendo una gestione centralizzata delle problematiche d'integrazione. Di fatto l'Integration Middleware agisce come unica interfaccia verso il client, diventando il punto di normalizzazione tra i vari sistemi integrati.

Figura 3: Utilizzo di un Integration Middleware

Tool & wizard d'integrazione
Dal punto di vista dello sviluppo, l'adozione di una Integration Suite permette di semplificare lo sviluppo utilizzando tool, wizard ed utility che permettono un "rapido" sviluppo per risolvere i tipici comuni problemi d'integrazione.
Mediante tali tool è possibile ad esempio risolvere problematiche di data mapping e/o data transformation senza dovere necessariamente sviluppare codice "ad hoc".
Grazie ai Wizard è quindi possibile gestire in modo grafico il mapping di dati da sorgenti diverse, come come da CVS a XML, da SQL (JDBC, ADO, …) ad XML, da HTML ad XML, da WSDL ad XML, ecc …così come è possibile ottenenere processi di data conversion per trasformare i dati da un sistema ad un altro con differenti caratteristiche. Ad esempio un sistema potrebbe utilizzare la codifica Little Endian mentre un altro la codifica Big Endian o avere code page diverse (ASCII, EBCDIC,…).
Tutte queste problematiche di conversione sono risolte dall'opportuno tool che permette di scegliere quali conversioni effettuare senza richiedere nessun sviluppo di codice.

Figura 4: Tool di mapping

Gli IM rendono inoltre disponibili "ready to use" i Resource Adapter (in modo "nativo" o installabili in un secondo momento) proprietari o standard (es: JCA vedere ([MOKABOOK2_JCA]]) che permettono di risolvere le problematiche di accesso a sistemi EIS eterogenei come DBMS, Host (CICS,IMS,3270,…), ERP, …

Figura 5: Configurazione di un RA per accedere a CICS

Mediante tool di workflow è possibile comporre, in modalità "drag & drop" processi che coinvolgono componenti e/o servizi trattati come "black box".

Figura 6: Tool di workflow di processo

Ogni suite d'integrazione permette di sviluppare servizi/componenti "ad hoc" per risolvere le specifiche esigenze di integrazione e/o di business.
Si tratta di sviluppare classi che si "appoggiano" su FWK proprietari. Tali classi saranno utilizzabili anche in modalità "drag & drop" nella fase di disegno del processo.

Un esempio d'integrazione
Concludiamo l'articolo con un esempio pratico. Riprendendo in esame lo scenario presentato in [MOKA_INT6] si realizzerà un processo che integri il servizio di concatenazione (l'EJB Concat installato su JBoss) ed il servizio di calcolo lunghezza (l'oggetto .NET Remoto) centralizzando nell'Integration Middlewarele problematiche d'integazione.

Figura 7: Introduzione di un Integration Middleware nello scenario proposto
(clicca sull'immagine per ingrandire)

Per l'esempio si è scelto, tra i tanti prodotti disponibili, Weblogic Integration 8.1 di BEA, la cui versione trial è liberamente scaricabile da Internet (vedere [WLI_DWNLD]).
La piattaforma WLI permette di avere i "tipici ingredienti" per affrontare l'integrazione in modo organico e centralizzato.
La suite d'integrazione di Bea permette di sviluppare dei Java Control che altro non sono che classi che incapsulano la logica di business e/o di accesso alle risorse da integrare.
L'IDE Weblogic Workshop permette lo sviluppo del Java Control sia in modalità grafica (design view) che via codice (code-view).
E' possibile quindi incapsulare il servizio di concatenazione delle stringhe all'interno di un Java Control di nome MokaConcat.

package services.ConcatJCS;
import com.bea.control.*;
public class ConcatImpl implements Concat, ControlSource {
  static final long serialVersionUID = 1L;
  public String getConcat(String x0, String x1) {
    // Aggiungere qui l'invocazione IIOP all'EJB Concat (Applicazione A)
    return x0 + x1; // per test
  }
}

Figura 8: Weblogic Workshop: design view/code view del Java Control MokaConcat

Analogo discorso può essere fatto per il Java Control MokaCalculator.

package services.CalculatorJCS;

import com.bea.control.*;

public class CalculatorImpl implements Calculator, ControlSource {
  public Callback callback;
  static final long serialVersionUID = 1L;
  
  public int getLength(String s) {
    // Aggiungere qui l'invocazione SOAP al WS Calculator (Applicazione C)
    return s.length(); // per test
  }
}

Sviluppati i controlli è possibile creare un processo che li utilizzi. Un processo è un file JPD (Java Process Definition) che è "accompagnato" da un file XML che definisce il flusso del processo. Anche il JPD può essere creato in modalità Design View o Code View visto che il processo non è altro che una classe che deve implementare l'interfaccia com.bea.jpd.ProcessDefinition.

Definiti il punto d'ingresso e di uscita del processo, è possibile inserire via drag & drop i controlli all'interno del processo, definendo le variabili per memorizzare i dati di input e di output dei vari step del processo.

public class MokaSample implements com.bea.jpd.ProcessDefinition{

// dati di input del processo
public java.lang.String m_param2;
public java.lang.String m_param1;

// dato di output del processo
public int m_length;

// Reference ai Java Control
private services.ConcatJCS.Concat MokaConcat;
private services.CalculatorJCS.Calculator MokaCalculator;
. . . . . .

Figura 9: Design view del processo MokaSample

Di fatto il processo, una volta ricevuti i parametri in ingresso (x0 e x1) e memorizzati nelle sue proprietà (m_param1, m_param2)

public void clientRequest(java.lang.String x0, java.lang.String x1) {
//#START: CODE GENERATED - PROTECTED SECTION - you can safely add code above this comment in this method. #//
// input transform
// parameter assignment
this.m_param1 = x0;
this.m_param2 = x1;
//#END : CODE GENERATED - PROTECTED SECTION - you can safely add code below this comment in this method. #//
}

provvede ad invocare il Java Control MokaConcat (memorizzando il risultato della concatenazione nella proprietà "di appoggio" m_concat)

public void mokaConcatGetConcat() throws Exception {
//#START: CODE GENERATED - PROTECTED SECTION - ….. #//
this.m_concat = MokaConcat.getConcat(this.m_param1, this.m_param2);
//#END : CODE GENERATED - PROTECTED SECTION - ….. #//
System.out.println("MokaSample.mokaConcatGetConcat: this.m_Concat["+this.m_concat+"]...");
}

e successivamente il Java Control MokaCalculator (memorizzando il risultato nella proprietà m_length)

public void mokaCalculatorGetLength() throws Exception {
//#START: : CODE GENERATED - PROTECTED SECTION - ….. #//
this.m_length = MokaCalculator.getLength(this.m_concat);
//#END : : CODE GENERATED - PROTECTED SECTION - ….. #//
}

per poi ritornare al client il risultato

public int clientReturn() {
//#START: : CODE GENERATED - PROTECTED SECTION - ….. #//
return this.m_length;
//#END : : CODE GENERATED - PROTECTED SECTION - ….. #//
}

Per verificare il corretto funzionamento del processo, è possibile utilizzare l'utility Workshop Test Browser, attraverso cui è possibile invocare il processo specificando i parametri d'ingresso e verificandone il corretto svolgimento.

Figura 10: Test del processi MokaSample
(clicca sull'immagine per ingrandire)

Sino ad ora si è costruito un processo che incapsula e gestisce, in modo centralizzato, l'invocazione dei servizi di concatenazione e di calcolo.
Vediamo adesso come rendere disponibile il processo anche agli altri client, che, nello specficio esempio, sono l'Applicazione A (AXIS) e l'Applicazione B (.NET).
Per permettere l'invocazione del processo da parte di altre applicazione è possibile esportare il processo come Web Service.
Il file WSDL può essere generato o mediante il Workshop stesso o a run-time invocando l'URL

http://localhost:7001/Tutorial_Process_ApplicationWeb/MokaSample.jpd?WSDL

analogamente a quanto visto in [MOKA_INT4].
Per invocare il processo con Axis bisogna innanzitutto utilizzare l'utility WSDL2Java (vedere [MOKA_INT4]) sul file WSDL:

%JAVA_HOME%\bin\java org.apache.axis.wsdl.WSDL2Java -o . -p ws.axis
http://localhost:7001/Tutorial_Process_ApplicationWeb/MokaSample.jpd?wsdl

per ottenere i file Stub, Locator e l'interfaccia del servizio.
A questo punto è possibile sviluppare un client Java per invocare il processo:

public class MokaSampleTestClient {
  //Main method
  public static void main(String[] args){
    new MokaSampleTestClient().test(args[0],args[1]);
  }
  
  public MokaSampleTestClient() {}
  public void test(String word1, String word2) {
    try{
      MokaSampleSoap srv=new MokaSampleLocator().getMokaSampleSoap();
      System.out.println("RISULTATO: " + srv.clientRequest1(word1,word2));
    }
    catch(javax.xml.rpc.ServiceException rpce){ . . . }
    catch(Exception e) { . . . }
  }
}

Per invocare il Web Service da .NET, si utilizza il programma wsdl.exe (vedere [MOKA_INT5]) per ottenere la classe stub C# partendo dal WSDL del processo:

wsdl.exe /l:cs /o:MokaService.cs
http://localhost:7001/Tutorial_Process_ApplicationWeb/MokaSample.jpd?WSDL /n:moka

Ottenuta e compilata la classe stub (MokaSample.cs) è possibile creare un client C# per invocare il processo:

using moka;
public class MokaSampleTestClient {
public static void Main(string[] args) {
MokaSampleTestClient client = new MokaSampleTestClient();
client.test(args[0],args[1]);
}
public void test(string word1, string word2) {
MokaSample obj = new MokaSample();
Console.WriteLine("Risultato:" + obj.clientRequest1(word1, word2));
}
}

Figura 11: Scenario finale

Conclusioni
In questo articolo abbiamo mostrato un semplice esempio d'uso di un Integration Middleware.
Utilizzando gli strumenti forniti dal prodotto esaminato, abbiamo visto come sia semplice definire processi che integrino servizi Java con servizi .Net.
Sul piano architetturale abbiamo proposto un approccio in cui il Middleware gestisce centralmente le problematiche d'integrazione ed agisce come unica interfaccia verso il client, diventando di fatto il punto di normalizzazione tra i vari sistemi integrati.

Bibliografia
[MOKA_INT6] S.Rossini: Integrazione di applicazioni Enterprise (VI) Mokabyte N.83-Marzo 2004
[MOKABOOK2_JCA] S.Rossini-G.Morello: "Manuale pratico di Java: La piattafroma J2EE" (Capitolo 12: JCA), Ed.HOPS-2004 [http://www.mokabyte.it/manualejava2/download.htm]
[MOKA_INT1] S.Rossini: Integrazione di applicazioni Enterprise (I) MokabyteN.71-Aprile 2003
[MOKA_INT2] S.Rossini: Integrazione di applicazioni Enterprise (II) MokabyteN.72-Maggio 2003
[MOKA_INT3] S.Rossini, A. D'Angeli: Integrazione di applicazioni Enterprise (III) Mokabyte N.73-Giugno 2003
[MOKA_INT4] S.Rossini: Integrazione di applicazioni Enterprise (IV) MokabyteN.74-Luglio/Agosto 2003
[MOKA_INT5] S.Rossini, A. D'Angeli: Integrazione di applicazioni Enterprise (V) MokabyteN.74-Settembre 2003
[OSISJ] Open Source Integration Solutions Written In Java:
http://www.manageability.org/blog/stuff/open-source-messaging-integration-transformation-routing-java/view
[BEA] http://www.bea.com
[WLI_DWNLD] http://commerce.bea.com/index.jsp