Architetture per la Cooperazione Applicativa

Architetture per la Cooperazione Applicativa

In questo capitolo valuteremo alcuni strumenti di recente sviluppo o attualmente in fase di completamento che implementano architetture o specifiche presentate nel capitolo precedente.

Nel primo paragrafo introdurremo l'attuale architettura di OpenSPCoop.

Nel secondo paragrafo ci addentreremo in Synapse, promettente progetto di Service Mediation di Apache, sviluppato per implementare un Enterprise Service Bus basato su XML e Web Service in sinergia con Axis2. La valutazione di Synapse è stata fatta prima del rilascio della versione 1.0, quando ancora non era stato promosso a sottoprogetto di Apache. Le funzionalità chiave di nostro interesse comunque non sono cambiate, quindi questa valutazione è da ritenersi valida anche per la versione 1.0 rilasciata a Giugno del 2007.

Nel secondo paragrafo studieremo un'architettura basata su un broker JMS,

1 L'architettura del Progetto OpenSPCoop

La progettazione di OpenSPCoop [05] è stata effettuata cercando di fare cooperare tutti i soggetti descritti dalle specifiche CNIPA, quali le porte di dominio, il registro dei servizi ed il gestore degli eventi. La figura seguente illustra una visione d'insieme di tutte le componenti distribuite di OpenSPCoop.

Come si può notare, l'unico mezzo di accesso per un Sistema Informativo Locale, per  arrivare a consultare un altro SIL è la busta e-Gov, attraverso la mediazione della propria porta di dominio. Nella figura viene illustrato, tra i vari componenti, anche il gestore degli eventi, che sarà utilizzabile, da un SIL, per pubblicazioni o ricezioni di eventi attraverso la solita mediazione della porta di dominio ed attraverso l'utilizzo della busta e-Gov. Per avere una visione progettuale di ogni singolo componente, viene elencata di seguito una descrizione funzionale generica di ognuno.

La Porta di Dominio è costituita dal componente periferico OpenSPCoop PdD, ospitato da macchine appositamente create ed impostate nel dominio di gestione. La caratteristica principale di questo componente è il disaccoppiamento totale della componente di ricezione e consegna delle buste da quella di controllo e gestione delle buste SOAP/e-Gov in transito, tramite l'uso di code persistenti per il mantenimento dei dati, realizzate tramite JMS. Sarà OpenSPCoop PdD ad interagire direttamente sia con i SIL che con i componenti centrali dell'infrastruttura (Gestore degli eventi e Registro dei servizi). L'adozione di una porta di dominio, strumento di mediazione della comunicazione tra SIL, permette di assicurare un maggior controllo dal punto di vista della sicurezza e del tracciamento dei messaggi. E' stato adottato un componente di integrazione SIL-to-PdD composto da un proxy dinamico, che richiede la presenza di una tabella per la registrazione di porte delegate e applicative necessarie a OpenSPCoop PdD per sapere in che modo gestire le richieste, sia in uscita (porte delegate), che in ingresso (porte applicative).

Le porte di dominio, oltre che dialogare con altre porte di dominio, potranno accedere ad un gestore di eventi direttamente tramite listener in ascolto su code (o topic) interne al gestore, ottenendo una maggiore efficienza di prestazioni, o anche interagendoci tramite scambio di buste e-Gov, vedendo il gestore come un servizio che si occupa di trasmettere le comunicazioni di evento tra i soggetti interessati (sistemi informativi locali). Il Gestore degli eventi è strutturato quindi come una porta applicativa, il cui compito è ricevere e consegnare messaggi contenenti eventi, utilizzando la busta SPCoop.

Un componente molto importante della PdD, è quello che si occupa di gestire la logica SPCoop. Il componente in questione, nominato Modulo di Controllo, viene chiamato in causa all'arrivo di una richiesta di servizio da parte di un SIL, prima di redirigere il messaggio verso un'altra porta di dominio, e all'arrivo di una busta SPCoop che includa una richiesta di servizio destinata ad un SIL. Tra i vari compiti del modulo di controllo vi sono tutti gli aspetti di gestione della specifica CNIPA riguardante la busta SPCoop. Viene quindi effettuata una validazione della busta (controllo semantico e sintattico), un controllo di autorizzazione, una eventuale gestione dei duplicati (affidabilità), una gestione dei riscontri (alla ricezione dei messaggi e alla spedizione della conferma ricezione), una gestione del tracciamento del messaggio e una gestione delle eccezioni. Il modulo di controllo si occupa anche di interagire con il registro dei servizi per conoscere le varie informazioni del servizio, sia nel momento dell'imbustamento, per effettuare la creazione della busta, sia al momento dello sbustamento, per effettuare una validazione della busta. Inoltre, durante l'accesso al registro per ottenere informazioni di imbustamento, verrà effettuata una ulteriore ricerca per conoscere l'indirizzo fisico della porta di dominio destinataria a cui spedire la busta SPCoop prodotta.

Il Registro dei Servizi è costituito da un server LDAP, che mantiene le informazioni relative ai servizi e ai diritti di accesso dei Sistemi Informativi Locali ai servizi. E' stato inserito nell'architettura un registro UDDI compatibile con le specifiche SPCoop ed utilizzato da OpenSPCoop PdD per identificare le caratteristiche del Servizio, come il profilo (sincrono, asincrono, simmetrico, asimmetrico) e gli altri parametri di quality of service.

L'architettura presentata permette di gestire comunicazioni OneWay, sincrone e asincrone con presa in consegna dei messaggi scambiati. Vediamo come questa architettura si comporta negli scenari più rappresentativi.

Quello sopra rappresentato è il diagramma di sequenza di una comunicazione OneWay con possibili errori di comunicazione.

Il diagramma di sequenza è uno schema in Unified Modeling Language (UML) utilizzato per descrivere uno scenario. Uno scenario è una determinata sequenza di azioni in cui tutte le scelte sono state già effettuate; in pratica nel diagramma non compaiono scelte, né flussi alternativi. Il diagramma di sequenza descrive le relazioni che intercorrono, in termini di messaggi, tra Attori, Oggetti di business, Oggetti od Entità del sistema che si sta rappresentando. Le entità che partecipano allo scenario sono rappresentate da linee verticali e parallele mentre, con frecce orizzontali, sono rappresentati i messaggi scambiati tra loro, nell'ordine in cui sono emessi. Le frecce continue sono messaggi di richiesta, con punte piene sono sincroni, con mezza punta sono asincroni. Le frecce tratteggiate sono messaggi di risposta. Le frecce rientranti sono chiamate interne, come ad esempio la Write DB del nostro diagramma, che indica l'operazione di salvataggio del messaggio su database. Gli orologi stilizzati rappresentano una sospensione dell'elaborazione. I diagrammi qui rappresentati non intendono essere esaustivi, ma vogliono solo rappresentare la porzione di realtà di nostro interesse, allo scopo di chiarificare i concetti espressi.

Tornando al diagramma sopra rappresentato, si notano le quattro entità coinvolte nello scenario: i due Sistemi Informativi Locali, mittente e destinatario, e le due Porte di Dominio che fungono da interfaccia al sistema OpenSPCoop e mediano i messaggi. Il SIL Mittente comincia la comunicazione inviando un messaggio SOAP. In comunicazione OneWay, il client invia il messaggio di richiesta aspettando come risposta un messaggio SOAP di ack, se la comunicazione è andata a buon fine, o un messaggio SOAP di fault, altrimenti.

La Porta di Dominio che ha ricevuto la richiesta dal SIL Mittente non conferma subito la ricezione, ma ritarda l'invio dell'ack SOAP finché non ha garantendo così la persistenza, salvando il messaggio su database. Solo dopo aver salvato il messaggio risponderà al mittente, il quale considererà consegnato con successo il messaggio. La Porta di Dominio procede quindi alla mediazione, processo che verrà discusso più approfonditamente nei capitoli successivi, e cercherà di inoltrare la Busta eGov creata alla Porta di Dominio destinataria. Se dovesse fallire per problemi di comunicazione, tenterà l'invio in un momento successivo.

Il sistema quindi è tollerante ad errori di comunicazione o di sistema ed ogni nodo intermedio prende in consegna il messaggio notificandolo al nodo precedente. Il tempo di risposta, in questo tipo di scambio di messaggi, è ottimale per il SIL Mittente. Non appena la Porta di Dominio Mittente può garantire la presa in consegna del messaggio, notifica la ricezione al SIL Mittente, che può considerare conclusa la comunicazione nonostante il messaggio sia ben lontano dall'essere consegnato effettivamente al SIL Destinatario. Lo stesso vale anche per i nodi intermedi. Il sistema di mediazione, in una comunicazione OneWay, tende quindi ad ottimizzare i tempi di risposta, riducendo al mimino la durata delle connessioni tra i nodi. Questo riduce conseguentemente i casi di errori di comunicazione. Il rovescio della medaglia è rappresentato dal tempo totale della comunicazione. Considerando solo il tempo di presa in consegna, il processo qui presentato aggiunge almeno quattro accessi a database per la scrittura e lettura del messaggio, senza considerare gli accessi per scrivere e leggere le informazioni di corredo per coordinare l'intero processo.

Vediamo le comunicazioni e le operazioni principali in una comnicazione sincrona:

Anche in questo caso vengono fornite funzionalità simili alla comunicazione OneWay. La gestione di fallimenti, non mostrata nel diagramma, è simile a quella del OneWay, avendo memorizzato il messaggio. Dovendo aspettare la risposta, il canale del SIL Mittente ovviamente rimane aperto in attesa della risposta SOAP. In questo scenario risulta ancora più evidente l'overhead introdotto dagli accessi a database, che sostanzialmente raddoppiano dovendo gestire anche la risposta, gravando per il SIL Mittente sul tempo totale che intercorre dall'invio del messaggio alla ricezione della risposta.

2 Web Service Framework

I Web Service Framework sono studiati per fungere da endpoint di una comunicazione. Questo significa che il loro compito si limita alla ricezione, elaborazione e replica dei messaggi. Axis [08], attuale Web Service Framework utilizzato da OpenSPCoop, è basato su un modello RPC e non supporta le ultime specifiche SOAP e non ha la capacità nativa di eseguire mediazione tra servizi. Di Axis vengono solo utilizzate le funzionalità di ricezione e manipolazione dei messaggi tramite SAAJ. Tutta la logica di gestione della mediazione è implementata separatamente.

Anche i nuovi Web Service Framework, quali Axis2 [09] e CFX [10], pur supportando nuovi standard non sono in grado di gestire comunicazioni più complesse. Quindi le architetture fornite dai Web Service Framework ci consentono di effettuare comunicazioni punto a punto, e sarà necessaria l'implementazione di una architettura più evoluta per trattare le comunicazioni previste da SPCoop.

Axis è stato uno dei Web Service Framework di maggior rilievo della sua generazione. Quando si voleva valutare un Web Service Framework, solitamente lo si paragonava ad Axis. L'evoluzione delle specifiche esistenti e l'introduzione di nuove, hanno spinto il team di sviluppo a cogliere l'occasione per ripensare l'intera architettura di Axis e risolvere alcune problematiche sorte negli anni di utilizzo e sviluppo. Questo processo di rinnovo ha dato vita ad Axis2, progetto che non mantiene la compatibilità con il predecessore, ed ha decretato l'abbandono dello sviluppo di Axis. Da qui nasce la necessità di migrare il progetto OpenSPCoop verso un nuovo Web Service Framework, sia per il motivo appena descritto, l'interruzione dello sviluppo di Axis, sia per poter contare sull'appoggio di uno strumento conforme alle specifiche più recenti.

Nei paragrafi successivi saranno valutati i due progetti open source di Web Service Framework di nuova generazione più promettenti, Axis2 e CXF, le specifiche che implementano e le performance ottenute, per poter decidere quale sia il più adatto a sostituire Axis.

2.1 AXIS2

Il progetto Apache Axis2 [08] è un'implementazione basata su Java sia della parte client che di quella server del modello di Web Service. Progettato partendo dall'esperienza maturata dal progetto Axis 1.0, Apache Axis2 fornisce un Object Model completo e un'architettura modulare che permette di aggiungere facilmente funzionalità e supporto a nuove specifiche collegate ai Web Service. Axis2 permette con facilità di:

Inviare messaggi SOAP

Ricevere ed elaborare messaggi SOAP

Creare Web Service partendo da POJO (Plain Old Java Object)

Creare le classi che implementano sia il lato client sia quello server partendo dal WSDL

Recuperare facilmente il WSDL di un servizio.

Inviare e ricevere messaggi SOAP con Attachments.

Creare e utilizzare servizi basati su REST (REpresentational State Transfer)

Creare o utilizzare servizi che sfruttano specifiche quali WS-Security, WS-ReliableMessaging, WS-Addressing, WS-Coordination, e WS-Atomic Transaction

Usare l'architettura modulare di Axis2 per aggiungere il supporto a nuove specifiche quando rilasciate

Dal punto di vista di Axis2, l'architettura atta a gestione lo scambio di messaggi è questa:

Supponendo che su ogni lato (client e server) sia in esecuzione Axis2, il processo per lo scambio di messaggi può essere sintetizzato in questo modo:

Il mittente crea un messaggio SOAP con Axiom.

Gli "handlers" Axis2 si occupano di tutte le azioni necessarie al messaggio, come crittografarlo in conformità con WS-Security.

Il Transport sender invia il messaggio.

Sul lato ricevente, il Transport listener riceve il messaggio.

Il Transport listener inoltra il messaggio alla catena di "handlers" definite per il lato server.

Una volta eseguite le operazioni della fase di "pre-dispatch" il messaggio viene passato ai dispatcher che lo inoltreranno alla giusta applicazione.

In Axis2 tutte queste azioni sono raggruppate in "phases", molte delle quali pre-definite nell'architettura, come la fase "pre-dispatch", "dispatch", "message processing". Ogni fase è una collezione di "handlers". Axis2 permette di controllare quali handlers si inseriscono in ogni fase e il loro ordine di esecuzione all'interno di una fase. E' anche possibile definire delle fasi e degli handlers aggiuntivi. Uno o più handler compongono un "modulo" che può essere inserito in Axis2. Il concetto di modulo rappresenta il cuore dell'espandibilità di Axis2. Ognuno di questi moduli svolge un compito, come ad esempio Sandesha2 che implementa il WS-ReliableMessaging o Rampart2 che implementa il WS-Security, e possono essere inseriti all'interno della catena di handlers in modo da gestire i messaggi e aggiungere le funzionalità implementate in maniera totalmente trasparente all'utente. Inoltre, grazie al modello di deployment di Axis2, è possibile pubblicare un modulo e "agganciarlo" a uno o più servizi senza dover fermare Axis2.

2.1.1 AXIOM

Come anticipato nell'introduzione, Axis2 fornisce un Object Model completo. Quando si è parlato di JAXP, sono stati individuati due modelli di processare un documento XML:

• Tree-based: caricato in memoria e facile da gestire per il programmatore. Costo di memoria elevato e costo computazionale per la costruzione degli oggetti.
• Event-based: gestisce direttamente lo stream con ottime prestazioni. Difficile gestione per il programmatore, si legge solo "in avanti" e non si può tornare indietro.

Uno degli obiettivi del recente StAX era quello di fornire un modello Event-based, quindi dalle ottime performance, facile da utilizzare come un Tree-based, ma il limite invalicabile di un modello basato sugli eventi è quello che gli eventi passati non sono riproducibili, lo stream può essere processato una sola volta.

AXIS Object Model, a.k.a. OM (AXIOM) [11,46,47,48] è stato introdotto proprio per ovviare a questo limite e fondere finalmente il modello Event-based con quello Tree-based. AXIOM si basa sulle API StAX per l'input e l'output dei dati. Il punto innovativo di questo modello è il supporto alla costruzione del modello differita. Questo modello, infatti, non costruisce l'intero documento una volta ricevuto, come avviene ad esempio per il DOM, ma ritarda la costruzione fino a quando non è necessaria. Il modello ad oggetti contiene solo quello che è stato costruito, il resto è ancora nello stream. Inoltre AXIOM può generare eventi StAX partendo da qualsiasi punto del documento ricevuto, indipendentemente dal fatto che sia stato processato o meno. Ancora, AXIOM può generare questi eventi StAX costruendo o meno il modello corrispondente. Questo in AXIOM è chiamato caching.

Come mostrato in figura, AXIOM accede allo stream XML attraverso StAX. L'implementazione del parser StAX utilizzata da AXIOM è quella Woodstox, ma ovviante è possibile sostituirla con qualsiasi altra implementazione delle API StAX.

AXIOM "vede" l'input stream XML attraverso lo stream reader di StAX, che viene incapsulato dall'interfaccia del costruttore fornito. Ci sono più implementazioni del costruttore, ad esempio StAXOMBuilder che costruisce completamente l'XML info-set model, oppure lo StAXSOAPModelBuilder che costruisce l'object model specifico per SOAP. Ogni implementazione supporta la costruzione differita ed il caching.

L'API AXIOM lavora sopra l'interfaccia dei costruttori e si interfaccia all'utente attraverso una semplice, ma potente, API. Fornisce la massima flessibilità potendo cambiare l'implementazione del costruttore o dell'object model in maniera indipendente dal resto. AXIOM è fornito con due implementazioni di questa API. La prima è basata su un modello a liste collegate (Linked List Object Model, LLOM) considerata l'implementazione di default. L'altra, conosciuta come DOOM (DOM over OM) fornisce un livello di interfaccia DOM su AXIOM. DOOM consente così di poter sfruttare le implementazioni di altre API sviluppate per DOM, come ad esempio WSS4J usato per implementare WS-Security.

Per lavorare con più implementazioni AXIOM usa il concetto di Factory. La factory è concepita in modo che se non è specificata un'implementazione da utilizzare, sarà usata quella di default dal class path.

2.2 CXF

Divenuto uno dei Web Service Framework per Java, Apache CXF è un framework open source sviluppato dalla Apache Software Foundation. Nato dalla prosecuzione e fusione di due progetti open source, il progetto XFire di Codehaus [56] e il progetto Celtix di IONA [57], CXF consente la creazione di Web Service usando tecnologie Java. Fornisce supporto per una varietà di standard Web Service, inclusi WS-I Basic Profile 1.0, WS-Addressing, WS-Policy e WS-Security.

CXF permette di utilizzare più protocolli di trasporto, come  e JMS. Il formato dei messaggi supportati includono SOAP, XML, RESTFul e CORBA. Oltre a supportare lo standard JAXB per il databinding, CXF fornisce anche il databinding Aegis [58].

CXF è JAX-WS compatibile e la versione 2.0 ha passato con successo il Test Compatibily Kit (TCK) per JAX-WS 2.0. Quest'ultimo fa un uso intenso di Java 5 e delle annotazioni, quindi richiede JDK/JRE 5.0 e successivi per funzionare.

L'architettura alla base di CXF può essere suddivisa nel seguenti componenti:

1. Bus: costituisce la spina dorsale dell'intera architettura.
2. Messaging & Interceptors: forniscono il livello di messaggio e di pipeline sopra i quali sono costruite molte funzionalità.
3. Front ends: forniscono un modello di programmazione per creare i servizi (es. JAX-WS).
4. Services: i servizi ospitano un Service model, un modello basato sul WSDL, che descrive il servizio stesso.
5. Transport: Destinator e Conduit forniscono la necessaria astrazione per garantire la neutralità di CXF rispetto al trasporto utilizzato.

Il bus si occupa di gestire e fornire risorse condivise a CXF. Può essere facilmente esteso per aggiungere risorse e servizi propri. L'implementazione di default del bus è basata su Spring [59], un framework open source per lo sviluppo di applicazioni web su piattaforma Java, che lega i componenti a runtime tra loro. CFX è costruito su un generico livello di messaggio comprendente Interceptors e InterceptorsChains. L'Interceptor costituisce il mattone fondamentale per implementare funzionalità. Può essere configurato in qualsiasi punto del processamento può essere concatenato ad altri Interceptors, formando una InterceptorsChain. Esempi di Interceptors predefiniti sono:

• Un Interceptor che parsa solo l'header di un messaggio SOAP in elementi DOM.
• Un WS-Security Interceptor che decripta o autentica un messaggio in ricezione
• Un Interceptor che esegue il data binding di un messaggio in uscita

Gli Interceptors sono uni-direzionali e non sono informati del fatto che il messaggio che stanno elaborando sia di richiesta, di risposta o di errore. Per comunicare con CXF viene fornito un frontend di programmazione. Il principale frontend è JAX-WS e permette di definire i servizi e configurare gli Interceptors per ognuno di essi. L'implementazione di SAAJ fornita con CXF è quella sviluppata dalla SUN, ma è possibile sostituirla con quella preferita semplicemente sostituendo la libreria corrispondente.

3 Synapse

Apache Synapse [49] è un broker di mediazione utilizzabile per costruire ESB (Enterprise Service Bus). Synapse permette di porsi come intermediario tra due o più servizi in maniera semplice ed efficiente secondo un modello basato su ruoli.

Synapse offre una capacità di mediazione ampia, incluso il supporto a vari standard aperti, inclusi XML, XSLT, XPath, SOAP, , JMS, WS-Security, WS-ReliableMessaging, WS-Addressing, SMTP.

Synapse incorpora un buon numero di funzioni predefinite, senza necessità di programmare, ma fornisce la possibilità di ampliare questa gamma usando linguaggi di programmazione diffusi come Java e Javascript.

Synapse ha lasciato lo status di Incubator ed è stato promosso come sottoprogetto di Apache Web Service nel gennaio 2007.

La versione 1.0 è stata rilasciata a Giugno 2007 e le sue funzionalità chiave sono:

• Proxy services - facilitating transport, interface (WSDL/Schema/Policy), message format (SOAP/POX), QoS (WS-Security/RM) and optimization switching (MTOM/SwA)
• Trasporto /s non bloccante basato su Apache Core per l'esecuzione e il supporto di migliaia di connessioni ad altissima velocità.
• Registro/repository integrato per facilitare l'aggiornamento della configurazione e delle risorse associate.
• Facile estensione grazie a mediatori Java o linguaggi di scripting (Javascript, Ruby, etc..).
• Supporto a Load-balancing/Fail-over e Throttling.
• WS-Security, WS-Reliable Messaging e Throttling configurabili via WS-Policies.
• Supporto ai messaggi JMS per payload binari, plain text, XML e SOAP.
• Modello incentrato sui messaggi.
• Configurazioni serializzate nel file system per versioning, backup e ripristino.
• Supporto per gestione degli errori, timeouts e ripristino.

Synapse si basa su Axis2 ed a breve dovrebbe diventarne un modulo. Fino ad oggi ne usa le librerie funzionando come server stand alone. Synapse aggiunge il concetto di mediatore. Un mediatore è una classe Java che esegue delle azioni sui messaggi intercettati. Alcuni mediatori sono già implementati, come il SendMediator, che si occupa di inoltrare i messaggi, o il LogMediator per fare logging dei messaggi, mentre è fornita la possibilità di crearne di propri implementando le appropriate classi. Per l'inoltro dei messaggi, utilizza un oggetto org.apache.axis2.client.OperationClient pensato originalmente per l'invio dei messaggi lato client. Questo ovvia al limite sofferto dai Service Framework che sono pensati per ricevere ed eventualmente rispondere al mittente e non possono ricoprire la funzione di intermediari in una comunicazione. Possiamo allora schematizzare l'architettura di Synapse in questo modo:

4 JMS

Un'architettura alternativa già implementata e testata è quella che prevede l'utilizzo di un broker di messaggistica JMS.

Java Message Service (JMS) [50] è l'insieme di API che consentono lo scambio di messaggi tra applicazioni Java distribuite sulla rete. In ambito JMS un messaggio è un raggruppamento di dati che viene inviato da un sistema all'altro pensato più per la notifica di eventi che dovranno essere interpretati da programmi anziché direttamente da un utente umano. Vediamo gli elementi principali che compongono questo standard:

• JMS provider: Un'implementazione dell'interfaccia JMS per Message Oriented Middleware (MOM). Possono essere sia implementazioni Java che MOM non-java.
• JMS client: una applicazione o processo che produce o elabora messaggi.
• JMS producer: Un client JMS che produce e invia messaggi.
• JMS consumer: Un client JMS che riceve messaggi.
• JMS message: Un oggetto contenente i dati trasferiti tra un client JMS e l'altro.
• JMS queue: Una struttura dati contenente i dati inviati che devono ancora essere letti. Come suggerisce il nome, i messaggi sono rilasciati nell'ordine in cui sono stati inviati. Un messaggio viene rimosso dalla coda una volta letto.
• JMS topic: Un meccanismo di distribuzione di messaggi che devono essere recapitati a molteplici iscritti.

Il sistema di messaggistica che si può costruire appoggiandosi al JMS è puramente asincrono:

• Il mittente invia un messaggio ad un ricevente (o ad un gruppo di riceventi).
• Il destinatario, quando disponibile, riceve il messaggio ed esegue le operazioni corrispondenti.

In questo senso, il sistema di messaggistica così ottenuto differisce da un sistema RMI o RPC dove il client che invoca un metodo remoto deve rimanere in attesa della risposta per poter continuare. Il sistema si basa sul paradigma peer-to-peer quindi un client può inviare e ricevere messaggi verso qualsiasi altro client utilizzando un provider. Ciascun client si connette all'agente (gestore) di messaggistica che fornisce gli strumenti per creare, inviare e ricevere i messaggi. Questo tipo di comunicazione si può definire loosely  coupled (debolmente accoppiata), infatti il mittente e il destinatario non devono necessariamente essere contemporaneamente disponibili per poter comunicare. Inoltre i membri della comunicazione possono non avere alcuna nozione l'uno dell'altro grazie all'intermediazione del messaging agent. L'unica nozione che li accomuna è l'agente stesso e il formato dei messaggi scambiati che tutti devono saper interpretare. Il sistema JMS fornisce comunicazioni

• Asincrona: il JMS Provider consegna il messaggio al destinatario non appena questo si è reso disponibile, senza che questi ne faccia richiesta specifica
• Affidabile: JMS può assicurare che il messaggio sia consegnato una e una sola volta.

Ulteriori livelli di robustezza sono garantiti in JMS

• Tramite il cosiddetto Guaranteed Message Deivery è possibile prevenire la perdita d'informazioni in caso di malfunzionamento o di crash del message server rendendo i messaggi persistenti prima di essere recapitati ai consumatori (per esempio mediante JDBC).

JMS comunque non include:

• Un sistema di Load Balancing e Fault Tolerance: la API non specifica il modo in cui più client debbano cooperare alla fine di implementare un unico servizio critico.
• Notifica degli Errori
• Security: JMS non fornisce garanzie sulla privacy e l'integrità dei messaggi gestiti

Come detto precedentemente il sistema JMS è intrinsecamente asincrono, ma viene fornita comunque la possibilità di effettuare una comunicazione Sincrona usando un MessageConsumer. Il consumer richiede esplicitamente alla destinazione di prelevare il messaggio (fetch) invocando il metodo receive(). Questo metodo è sospensivo, vale a dire rimane bloccato fino alla ricezione di un messaggio o di un timeout impostato in precedenza.

Oltre alla modalità sincrona e asincrona, JMS fornisce anche comunicazioni punto a punto (P2P) e punto a molti. La prima modalità prevede che il messaggio sia scritto su una coda di messaggi dalla quale può essere letto una ed una sola volta, quindi possiamo avere più di un lettore associato ad una lista, ma solo uno di questi può accedere al messaggio.

L'altra modalità prevede che più client si possano iscriversi ad un topic. Una volta che un messaggio è aggiunto al topic, tutti i client ad esso iscritti lo ricevono (Publish and Subscribe).  

Per confrontare questa architettura con quella fornita da OpenSPCoop, esaminiamo la comunicazione OneWay con un broker JMS.

Come si può notare, non appena la Porta di Dominio del mittente è riuscita a scrivere il messaggio sulla coda JMS invia l'ack SOAP al client mittente che può procedere all'elaborazione, con garanzia che il messaggio verrà recapitato a destinatario, anche se ancora non l'ha ricevuto, grazie alla natura asincrona del broker JMS.

Anche in caso di errore viene garantita la consegna del messaggio. Se il messaggio non raggiunge il broker il fallimento viene comunicato al mittente.

Se l'errore si verifica dopo la presa in gestione del broker JMS, il client mittente procede come se la comunicazione si fosse conclusa con successo grazie alla presa in consegna dell'infrastruttura e visto che il OneWay non prevede un messaggio di risposta. Il Broker e il Mediatore continueranno a tentare di concludere la comunicazione successivamente.

Abbiamo quindi un sistema

• Affidabile: grazie alla transazionalità del JMS possiamo garantire la consegna dei messaggi
• Veloce: grazie alla natura asincrona del Broker possiamo disaccoppiare il mittente dal destinatario, prendere in consegna il messaggio e chiudere la connessione col mittente subito dopo l'invio del messaggio.

In quest'architettura possiamo integrare il broker in due modi:

• Distribuito: Il broker è integrato nella Porta Di Dominio. Questa soluzione aumenta il carico del sistema che ospita la Porta di Dominio che deve gestire anche la coda JMS e lega la disponibilità del servizio ad una sola componente.
• Centralizzato: Il broker è stand alone e può gestire più code per più Porte di Dominio. Questa soluzione vincola la disponibilità del servizio alla disponibilità del broker. Inoltre alleggerisce il carico dei sistemi che ospitano le Porte di Dominio che non devono più preoccuparsi della persistenza dei messaggi. Il problema di questa soluzione è che se si rende indisponibile il broker saranno non disponibili tutti i servizi che si appoggiano ad esso.