Introduzione
Tutti gli scenari Enterprise devono affrontare il problema dell'eterogeneità data la presenza congiunta di pacchetti applicativi acquisiti dal mercato, di applicazioni legacy e di applicazioni sviluppate in outsourcing. Oltre a queste problematiche tradizionali, gli scenari moderni devono affrontare ed indirizzare in maniera organica i nuovi requirements portati dall'e-commerce/e-business: comunicazione B2B, apertura verso nuovi canali, estensione di funzionalità, aumento dei livelli di servizio (es. 7x24), comunicazioni con info providers, on-line trading broker, ecc.
E' dunque indispensabile per l'azienda costruire un'infrastruttura IT capace di assorbire in maniera flessibile gli impatti delle nuove tecnologie, salvaguardando il patrimonio informativo esistente e rispondendo alle necessità di comunicazione real-time fra le differenti componenti dei Sistemi Informativi.
La somma di questi fattori porta i principali analisti a considerare l'Enterprise Application Integration (EAI) come uno dei settori fondamentali del mercato Software e come uno dei fattori di successo per tutte le aziende che, a partire da una consistente realtà Enterprise, intendono adottare nuovi modelli di business e competere sul mercato. Integrare sistemi ed applicazioni sviluppati e progettati da team differenti, in tempi differenti e con l'adozione di tecnologie e paradigmi differenti è chiaramente un compito arduo.
Tipicamente l'integrazione si applica all'idea di Enterprise Information Systems (EIS). Con il termine EIS, si identifica un sistema che fornisce un'infrastruttura di informazioni per un'applicazione Enterprise. Esempi tipici di EIS sono i sistemi Legacy, le basi dati (relazionali Oracle,SQLServer,MySQL,... e non Lotus Notes), i sistemi ERP (Enterprise Resource Planning), i sistemi CRM (Customer Relationship Management), , ecc…
Il mercato dei tool EAI è molto complesso ed offre un set vastissimo di famiglie di prodotti non facilmente comparabili, di difficile utilizzo e soprattutto totalmente dominato da soluzioni proprietarie. La specifica Java Connector Architecture (JCA), seppur orientata al solo ambito J2EE, assume in questo scenario una grande rilevanza in quanto è uno dei primi tentativi di stabilire uno standard nel campo dell'integrazione di EIS.

Integrazione e comunicazione
Integrare applicazioni significa essenzialmente portare sistemi disegnati e sviluppati indipendentemente a lavorare insieme. Lo scambio di informazioni tra sistemi informativi eterogenei ed autonomi richiede un livello di comunicazione e varie tipologie di servizi atti a gestire ed automatizzare lo scambio di grandi quantità di informazione.
L'incompatibilità di base dei vari sistemi informativi, la presenza di un gran numero di protocolli, di linguaggi, di applicazioni e di piattaforme rende problematica la comunicazione e l'integrazione tra differenti EIS.
Le esigenze di comunicazione ed integrazione sono spesso affrontate con meccanismi di comunicazione asincrona mediante processi batch. Questo comporta alti costi e forti rallentamenti nell'attivazione di nuovi canali di comunicazione (es. esposizione Internet di applicazioni Legacy) e sostanzialmente impedisce la definizione ed il management di processi di business interaziendali real-time e di alto livello.
Questi limiti rendono ad esempio molto onerosa l'integrazione di Sistemi Informativi a seguito di operazioni di acquisizione/fusione aziendali, portando nella quasi totalità delle situazioni ad integrazioni assolutamente verticali di difficile manutenzione/evoluzione. In questi scenari sono di grande aiuto le funzionalità tipiche dei prodotti EAI.

Funzionalità base EAI
All'interno dello scenario di soluzioni EAI, sono individuabili alcune funzionalità/problematiche base:

• 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
• Data Mapping: tipicamente i dati acquisiti da un RA in un formato proprietario devono essere trasformati secondo le esigenze del business object richiedente. Di solito è l'operazione più costosa nell'integrazione di EIS
• Messaging brokers: tipicamente opera come messaging layer ed può operare in modalità point-to-point e publish/subscribe
• Workflow: in questo contesto si intende il coordinamento di business object e messaggi nell'esecuzione di processi di business

Queste funzionalità EAI vengono tipicamente fornite dagli Integration Middleware. Esempi di questa tipologia di Middleware sono gli Integration Broker (IBM MQSeries Integrator, Tibco ActiveEnterprise, Microsoft BizTalk Server, …), i Business Process Managers (IBM MQSeries Workflow, iPlanet ProcessBuilder, Vitria Technology BusinessWare Automator), i Gateways (Database, MOM e Platform) e gli Adapter.
Rispetto a questo scenario, lo scope di JCA ad oggi è sostanzialmente limitato al mondo degli Adapter e copre quindi una parte relativamente piccola dell'intera piattaforma d'integrazione. La maggior parte delle funzionalità appena discusse ed alcuni pattern tipici d'integrazione, non sono ancora indirizzati da J2EE. Mancano ad esempio il supporto per il Workflow, il data mapping (anche se J2EE fornisce per i DB qualcosa di simile con gli EJB CMP), il supporto per la trasformazione semantica dei dati ed il supporto per gli Adapter asincroni.
Per affrontare con successo uno scenario di integrazione Enterprise, la tecnologia e le funzionalità appena citate non sono sufficienti: è necessario un opportuno approccio metodologico.
Metodologie di integrazione: approccio Spaghetti vs approccio centralizzato
Affrontare problematiche di integrazione complesse all'interno di uno scenario Enterprise non è semplicemente un problema tecnologico, ma ha pesanti implicazioni metodologiche ed organizzative.
Nella maggior parte degli scenari attuali, l'integrazione tra programmi e dati è fatta tramite batch file transfer invece che con meccanismi di accesso in tempo reale. Si implementano cioè connessioni punto a punto (via specifiche API) senza utilizzare un'architettura/infrastruttura organica e centralizzata di integrazione. Questo approccio viene definito "Spaghetti Integration".
Operare l'integrazione tra applicazioni in un contesto simile comporta complessità e costi di manutenzione ed evoluzione via via crescenti, senza alcuna garanzia di raggiungere i risultati attesi.
L'adozione di tecnologie più sofisticate quali sistemi di Messaging, Gateway e Middleware di comunicazione consentono di semplificare le problematiche di comunicazione e supportano meccanismi sincroni e real-time. 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".
L'approccio metodologico corretto presuppone una gestione organica e centralizzata delle problematiche di integrazione. Analizzata in questi termini, l'integrazione non è più un problema del singolo gruppo di sviluppo, ma un problema comune che coinvolge le applicazioni dei vari dipartimenti, data center, uffici e partners. Come tale va affrontato definendo un'infrastruttura centralizzata presidiata da un team specialistico su cui andranno ad interagire tutte le applicazioni.
L'elemento cardine dell'infrastruttura è l'Integration Broker. Questo componente deve essere l'interfaccia unica attraverso cui transita ogni richiesta di comunicazione tra sistemi applicativi disomogenei. L'Integration Broker è il punto di normalizzazione tra i vari sistemi applicativi. Le funzionalità principali di un Integration Broker sono l'intelligent routing e la trasformazione sintattica e semantica dei messaggi.

L'Adapter
Comunque si operi, il primo problema che è necessario affrontare in ambito integrazione è essenzialmente un problema di comunicazione. Sia che si adotti una visione centralizzata, sia che si operi punto-punto il problema principale è la normalizzazione del protocollo specifico della risorsa con un'interfaccia fruibile dal chiamante. Come si è detto, il problema viene tipicamente affrontato attraverso componenti denominati genericamente Adapter. Nel caso specifico di Adapter destinati alla comunicazione con risorse EIS, vengono più precisamente detti Resource Adapter (RA).
Il RA è un componente che espone delle interface di accesso (client API) per permettere la comunicazione con la corrispondente risorsa EIS.
Il RA ha quindi un duplice scopo:

• fornire un'interfaccia omogenea ai client per accedere all'EIS
• mascherare la complessità dell'interazione con l'EIS al client

Il RA può essere sincrono o asincrono. Nel caso sincrono, il client, dopo aver invocato un metodo del RA, inoltra la request e si pone in attesa della relativa response (modello RPC).

Nel caso asincrono, il client prosegue la sua elaborazione senza attendere l'arrivo della response (modello Messaging).

Lo standard JCA consente unicamente l'integrazione mediante comunicazione sincrona.
Cos'è JCA?
JCA è l'acronimo di Java Connector Architecture. Definisce un'architettura standard [SPEC] per uniformare l'accesso ad EIS eterogenei all'interno di applicazioni J2EE. Si focalizza sul design di Adapter software destinati a connettere applicazioni J2EE con applicazioni non-Java, risorse legacy e pacchetti applicativi.

L'architettura JCA è costituita da tre elementi : le API Common Client Interface (CCI), i Resource Adapter ed i System Contracts.

CCI definisce un insieme di API per uniformare l'accesso a EIS da parte di applicazioni J2EE. Grazie a CCI non è necessario affrontare un'integrazione ad hoc per ogni tipologia di EIS, analogamente a quanto avviene con JDBC, JNDI e JMS.
Il connettore vero e proprio (Resource Adapter) viene fornito dai produttori di sistemi EIS. Il Resource Adapter (RA) può essere invocato mediante le API CCI e deve essere installato (modello plugin) all'interno dell'Application Server J2EE.
Un mercato di Adapter standard preconfezionati, pluggable nell'infrastruttura J2EE potrebbe consentire la riduzione dei tempi e dei costi di sviluppo dell'integrazione, riducendo il time-to-market (tanto caro ai "commerciali") ed indirizzando soluzioni standard scalabili, sicure e transazionali.
E' bene comunque notare che l'implementazione delle API CCI non è mandatoria. Nel caso in cui non sia disponibile l'accesso via CCI, utilizzando direttamente l'interfaccia proprietaria del RA, si perderebbe l'indipendenza del codice dallo specifico EIS.
L'approccio JCA consente in generale di ridurre la complessità delle connessioni da gestire. Si veda ad esempio il caso in cui si hanno n Application Server che hanno la necessità di connettersi con m EIS. Approcciando il problema con una soluzione proprietaria (senza JCA), si dovrebbero sviluppare n x m connessioni punto-punto come mostrato nella figura seguente

Affrontando la medesima situazione con l'ausilio di JCA il problema viene ridimensionato passando ad una gestione di m + n connessioni risolte mediante l'installazione del RA su ogni Application Server come mostrato nella figura che segue

Gli elementi dell'architettura JCA
Vediamo nel dettaglio i componenti dell'architettura JCA.

Resource Adapter
Il RA è il driver software che permette al client (sia esso un componente J2EE come un EJB o l'Application Server stesso) di connettersi fisicamente alla risorsa EIS.
Un connettore "JCA compliant" deve implementare le interfacce di sistema (System Contracts) che gli consentono di interagire con le risorse gestite dall'Application Server (resource pool, transaction manager, sicurezza, ecc…).
Il RA viene utilizzato all'interno dello spazio d'indirizzamento. Come si è visto, per agevolarne la gestione e l'installazione, i connettori sono "visti" dall'Application Server come dei componenti plugin.
Per raggiungere questo livello di "system-level pluggability" l'architettura JCA definisce un set standard di "contratti" sia a livello di sistema (Application Server/RA), sia a livello EIS (RA/EIS).
Il RA può supportare diversi gradi di interazione con l'Application Server. Parlando ad esempio di supporto transazionale, un RA può fornire una gestione non transazionale, locale all'Application Server oppure distribuita XA-based.
Il RA è contenuto in un file Archive (Resource Adapter Archive, RAR) composto dai file Java e dalle eventuali librerie native necessarie per accedere alla risorsa EIS. Un file .rar rappresenta a tutti gli effetti una risorsa J2EE e può essere installato singolarmente o all'interno di un file .ear.

System contract
Un adapter JCA interagisce con le infrastrutture del server J2EE tramite i cosiddetti system contracts. JCA specifica come il sistema Middleware deve collaborare con la risorsa EIS al fine di gestire i meccanismi di sistema. JCA definisce i contratti di Connection, Security e Transaction.

Connection Management
Determina le politiche per stabilire/chiudere le connessioni con le risorse di Backend ottimizzando la gestione degli accessi mediante un Connection Pool gestito dall'Application Server. Permette inoltre di definire dei listener per gestire eventi associati alla gestione delle connessioni.

Transaction Management
Permette di gestire l'accesso transazionale verso le risorse EIS, definendo le interazioni tra la risorsa ed il transaction manager.
Le transazioni possono richiedere la presenza di un transaction manager esterno oppure possono essere gestite internamente dal resource manager della risorsa.
Questo contratto non è obbligatorio in quanto la specifica ammette RA non transazionali.

Security
Permette di gestire la Sicurezza per accedere all'EIS. Consente allo sviluppatore del RA di implementare/fornire i meccanismi per la gestione dell'autenticazione e dell'autorizzazione, ed eventualmente consente la gestione di un security environment custom per la comunicazione sicura tra il server J2EE e la risorsa EIS.
Lo specifico meccanismo di sicurezza usato è indipendente dal meccanismo di sicurezza del sistema di Backend.

I limiti di JCA
Come si è visto, JCA rappresenta un primo significativo tentativo di standardizzazione all'interno di un mercato intricato e privo di standard. Lo scope delle specifiche è sostanzialmente limitato al mondo degli Adapter. Anche in questo ambito, le specifiche attuali non forniscono tutte le risposte necessarie.

I principali punti scoperti sono:

• supporto per Adapter bidirezionali ed asincroni: l'unico modello supportato è il modello sincrono request/reply. Un sistema remoto non può attivare una callback sull'Adapter in un momento successivo alla chiamata. Questo limite è probabilmente accettabile negli scenari classici da Application Server, ma è del tutto inaccettabile in scenari d'integrazione più complessi (es. B2C o B2B).
  
  
• supporto XML: non esiste alcun supporto nativo per la restituzione di dati in formato XML. CCI opera con dati strutturati gerarchicamente o tabulari. E' comunque possibile usare CCI con XML mediante opportune implementazioni.
  
  
• Adapter locali all'applicazione target: l'RA viene eseguito sempre in un Application Server. Non è possibile realizzare un Adapter locale ad un'applicazione/risorsa non-Java. La distribuzione dell'Adapter sulla risorsa target fornisce notevoli vantaggi in termini di integrità ed availability. E' comunque sempre possibile sviluppare un wrapper JCA per un Adapter non JCA.

Già con le specifiche 1.5 (ad oggi in draft) sono superati alcuni dei limiti sopra evidenziati. In particolare viene introdotto il supporto per gli Adapter asincroni e bidirezionali.

JCA vs. Web Services
Tipicamente JCA viene messo in contrapposizione con la tecnologia Web Services. Nonostante ambedue gli standard operino nello scenario EAI, il paragone è sicuramente riduttivo.
Ambedue gli standard sono pensati per consentire la definizione di interfacce standard per generiche risorse Enterprise. Mentre però JCA si orienta alle risorse di Backend, la piattaforma Web Services ha uno scope maggiore ed è pensata per l'esposizione di servizi ad ampio spettro.
Sebbene anche i Web Services possano essere utilizzati per l'esposizione di EIS, i Layer su cui operano naturalmente i due standard sono sostanzialmente differenti. Per l'integrazione di risorse di Backend, lo standard JCA è sostanzialmente più ricco: non ha i limiti di protocollo HTTP, gestisce la transazionalità, ecc. D'altro canto è evidente come la piattaforma Web Services ponga minori complessità d'implementazione, non dipenda necessariamente dall'implementazione dei vendors (i RA devono essere reperiti sul mercato in quanto richiedono conoscenze troppo dettagliate dell'EIS) e soprattutto non sia supportata solamente dall'architettura Java, ma anche da quella Microsoft.
E' probabile che versioni future di JCA possano comunque includere un supporto per XML e l'esposizione alternativa via CCI e via Web Services Description Language (WSDL).
Anche se sul mercato i due standard sono posti in sostanziale concorrenza, in uno scenario Java è naturale pensare all'uso congiunto delle due tecnologie: Web Services utilizzati per l'esposizione dei servizi verso l'esterno, JCA utilizzato per la comunicazione interna con il Backend.

Il mercato
Sebbene JCA possa essere considerato un passo importante per il mondo Java e per il mercato EAI in genere, la versione attuale dello standard presenta alcuni limiti e non soddisfa tutti i requisiti legati ad un reale progetto di integrazione.

Nonostante le notevoli promesse, l'impatto di JCA sul mercato potrebbe quindi essere limitato. Il peso che JCA assumerà negli anni a venire sarà, come per ogni proposta di standard, soprattutto dettato dal supporto e dalla fiducia che i principali player del mercato decideranno di accordare alla specifica SUN, soprattutto nell'eventualità che alcune specifiche (solo in parte alternative come i Web Service) riescano ad imporsi rapidamente sul mercato.
Ad oggi molti vendor già dichiarano ufficialmente di supportare la specifica JCA, tra questi spiccano: BEA, IBM, IONA, Oracle e TIBCO.
Le più recenti versioni degli Application Server sono JCA-compliant, tra questi BEA Weblogic, IBM WebSphere e OracleAS [PRINF]. Inoltre sul mercato sono già disponibili molti Resource Adapter per differenti EIS (tra questi SAP, CICS, IMS, Oracle, PeopleSoft). Per una lista completa vedere [PRINF].

Conclusioni
In questo articolo sono stati introdotti i temi e le problematiche base legate all'EAI. In questo contesto è stata collocata la proposta SUN per la connessione di sistemi eterogenei: JCA.
Nell'articolo è stata introdotta l'architettura JCA con una panoramica sulle API CCI e sul concetto di Resource Adapter.
A partire dal prossimo articolo verrà presentato un esempio completo di connettore JCA.
Bibliografia e riferimenti
[JCA] http://java.sun.com/j2ee/connector/
[SPEC] J2EE Connector Architecture Specification, http://java.sun.com/j2ee/download.html#connectorspec
[JW1] Dirk Reinshagen: Connect the enterprise with the JCA, Part 1,JavaWorld Novembre 2001
[GIGA] Jane Stanhope: J2EE Connector Architecture Promises to Simplify Connection to Back-End Systems, Novembre 2000,Giga Information Group
[GART]Yefim Natis: JCA: Java steps into Application Integration, Gartner,Giugno 2001
[JCAPI] JCA API JAVADOC, http://java.sun.com/j2ee/tutorial/download.html
[PROD] JCA Industry Support, http://java.sun.com/j2ee/connector/industry.html
[PRINF] JCA Product Information, http://java.sun.com/j2ee/connector/products.html
[BBTW] David Marks: J2EETM CONNECTOR ARCHITECTURE BRINGS BUSINESS SYSTEMS TO THE WEB, http://java.sun.com/features/2000/08/connect.html
[PROF] Matjaz B. Juric with Basha,Leander,Nagappan : Professional J2EE EAI, Wrox