Analisi delle tecnologie studiate - OpenSPCoop

Analisi delle tecnologie studiate - OpenSPCoop

In questo capitolo ci occuperemo di valutare come le tecnologie introdotte nel capitolo precedente si adattano a risolvere le problematiche di un'implementazione di SPCoop. Partiremo da un'analisi dell'architettura attualmente in uso in OpenSPCoop confrontandola con le architetture introdotte nel terzo capitolo. Durante questa analisi metteremo alla luce i comportamenti che hanno generato la necessità di una revisione dell'architettura corrente. A seguire sarà valutata l'applicazione delle tecnologie introdotte nei capitoli precedenti al progetto OpenSPCoop, analizzando i benefici che possono apportare e se questi costituiscono una soluzione alle problematiche presentate.

1 Architettura e tecnologie utilizzate in OpenSPCoop

L'architettura SOA, introdotta nel primo capitolo, si occupa della gestione dei servizi e di comunicazioni punto a punto. Su quest'architettura si basa quella ESB, che concerta l'uso di più entità (servizi) per il completamento di una comunicazione più complesa, prendendosi carico di fornire alcuni servizi evitando che siano gli utenti ad implementarli. A livello di processo, è stata presentata l'architettura SEDA, nata da quella EDA, che fornisce un modello di sviluppo della logica di un processo e che si propone di risolvere alcune problematiche in ambito Web Service. Quella che viene implementata in OpenSPCoop è una soluzione che sfrutta tutte queste architetture.

Abbiamo quindi a livello di servizio un'architettura ESB, con i servizi forniti dai Sistemi Informativi Locali che per comunicare gli uni con gli altri passano attraverso nodi intermedi, le Porte di Dominio. Inoltre implementa l'architettura EDA attraverso il Gestore degli Eventi, usando il modello Publish and Subscribe (P&S) attraverso scambio di Buste eGov con una Porta di Dominio di interfaccia al Gestore Eventi.

Infine il modulo di controllo della Porta di Dominio è implementato in modo da ricordare il modello SEDA, con il processo suddiviso in moduli Event Driver Bean (EDB) che implementano porzioni della logica ben definiti separati da code JMS. Questo approccio consente di svincolare il numero di richieste accettate dal numero di thread attivabili. Una gestione così modulare si presta ad operazioni di load balancing, operando sui pool di thread in ascolto su ogni coda. L'attuale implementazione prevede che le code JMS siano persistenti, ma è in previsione un'implementazione che consenta di renderle volatili, pur mantenendo la robustezza del sistema.

I test effettuati hanno messo in luce un problema legato alle performance del modulo di controllo della Porta di Dominio in OpenSPCoop. Inviare il messaggio tramite l'infrastruttura di OpenSPCoop, rapportato ad un invio diretto, accumula un overhead eccessivo dovuto al processo di mediazione. I test hanno evidenziato che gran parte di questo overhead è imputabile agli accessi in database effettuati per salvare il messaggio e le informazioni sullo stato del processo di mediazione, utili a concertare le operazioni che lo implementano, senza considerare quello introdotto dalle code JMS persistenti che saranno sostituite da code volatili in future release del sistema. La figura seguente schematizza la struttura del modulo di controllo mostrando come la logica sia suddivisa in blocchi applicativi che si scambiano i dati da processare tramite code JMS.

I messaggi, appena arrivati, sono salvati su database, mentre i dati necessari per svolgere le operazioni di contorno del processo di mediazione, attraversano i vari stadi (stages) procedendo attraverso le code JMS. Al termine, per essere inviato alla Porta Applicativa destinataria, il messaggio originale viene letto dal database, imbustato in una opportuna Busta eGov e inoltrato al destinatario. Speculare il processo lato destinatario per la richiesta e per l'eventuale risposta. Sono appunto gli accessi a database e, marginalmente, l'overhead introdotto dal partizionamento del processo in stages la causa delle prestazioni poco soddisfacenti di OpenSPCoop.

Un altro aspetto da considerare sono le tecnologie utilizzate per l'implementazione di OpenSPCoop 1.0. Il Web Service Framework scelto è Apache Axis. Come mostrato nel terzo capitolo, le specifiche in ambito Web Service si sono evolute, in alcuni casi sono diventate obsolete, in altri ne sono state introdotte di nuove. Il team di sviluppo di Axis ha colto l'occasione per effettuare una profonda modifica all'architettura del loro Web Service Framework, chiamandolo Axis2, cessando contestualmente il supporto del predecessore. Questo significa che alcune delle specifiche più recenti e quelle che verranno non saranno supportate, quindi, prevedendo un adeguamento delle specifiche SPCoop, è necessario sostituire gli strumenti utilizzati con i nuovi proposti dal panorama Web Service.

Procediamo quindi con l'analisi degli strumenti introdotti nel capitolo precedente nel contesto dell'implementazione delle specifiche SPCoop e quali benefici può trarne l'attuale implementazione OpenSPCoop.

2 Web Service Framework

Come anticipato, Axis, l'attuale Web Service Framework, non è più mantenuto. Dopo anni di sviluppo, il team che lo curava ha deciso di cogliere il momento di grande cambiamento in ambito Web Service per rivoluzionare l'architettura, applicando migliorie che gli anni di esperienza hanno permesso di ideare, dando vita a Axis2. L'abbandono di Axis ha reso necessaria la sua sostituzione, sia perché si basa su un'architettura datata, quindi potenzialmente meno efficiente di concorrenti più "giovani", sia perché, in previsione di future revisioni delle specifiche SPC, non sarà in grado di fornire supporto a nuove specifiche. Abbiamo introdotto due nuovi Service Framework nel capitolo precedente, vediamo come si adattano al progetto OpenSPCoop.

2.1 Axis2

Dal momento che la corrente versione di OpenSPCoop utilizza Axis, è parso naturale, visto il suo "pensionamento", orientarsi verso il suo successore Axis2. Vediamo come si adatta ad un'eventuale integrazione in OpenSPCoop.

Partiamo dall'object model AXIOM ed a valutarne la performance rispetto ad altri object models basati su StAX. I test sono stati effettuati utilizzando tre set di documenti XML:

• Quakes: (18k) Elementi ripetuti con numerosi attributi.
• Persons: (202k) Struttura singola ripetuta con poche variazioni nei valori contenuti.
• SOAP: (19k) un set di 30 piccoli messaggi SOAP

I primo test consiste nella costruzione e nella lettura del contenuto dei documenti presi in esame:

Axiom risulta migliore solo di Xerces2 ed è evidente la difficoltà di alcuni modelli nel gestire i piccoli messaggi SOAP, soprattutto per Xerces2, ma anche Axiom sembra soffrire di questa difficoltà: basta paragonarlo a dom4j che impiega circa un terzo del tempo impiegato da Axiom in quella porzione di test.

Nel secondo test sono valutati i tempi di scrittura dei documenti:

In questo caso Xerces2 è il migliore con un buon margine sugli altri, mentre Axiom risulta di gran lunga il peggiore e rimarca la sua difficoltà nel gestire i piccoli documenti.

Nel terzo test è valutata l'occupazione di memoria:

Dom4j è indiscutibilmente il migliore, come Axiom il peggiore. La sua elevata occupazione di memoria è dovuta a due fattori: primo, il parser deve essere referenziato dal documento costruito, quindi una sua istanza deve essere in memoria finché l'istanza del documento è in uso; secondo, i singoli oggetti del modello sono più "pesanti" in termini di memoria delle corrispondenti controparti negli altri modelli.

Se valutiamo Axiom sulla base di questi tests, risulta il peggiore sotto ogni aspetto, ma dobbiamo ricordare che per l'architettura sottostante, i documenti elaborati costituiscono il caso pessimo, ovvero quando tutto il documento deve essere costruito, mentre i benefici di questo modello vengono alla luce qualora non sia necessaria l'intera costruzione del documento.

Vediamo allora cosa accade se prendiamo in considerazione solo la prima parte dei documenti in esame senza lavorare su tutto il messaggio:

Come da previsioni, in questo scenario Axiom risulta il vincitore indiscusso, soprattutto per quanto riguarda per i documenti di grandi dimensioni, dove è maggiore il lavoro risparmiato da una valutazione parziale del contenuto.

In conclusione questi test mostrano che Axiom è da prendere in considerazione solo nel caso in cui i messaggi da processare non richiedano la costruzione completa dell'object-tree in memoria, altrimenti sia i tempi di processamento sia l'occupazione di memoria aumentano vertiginosamente rispetto ad altri object model.

Vediamo allora come OpenSPCoop tratta i messaggi che deve mediare e come questo influenza le performances di AXIOM. Logicamente, la parte di mediazione di OpenSPCoop interessante per questa valutazione può essere schematizzata in questo modo:

• Ricezione del messaggio sulla porta delegata.
• Salvataggio del messaggio.
• Imbustamento.
• Tracciamento.
• Applicazione servizi aggiuntivi.
• Inoltro verso la porta applicativa.

Questo schema considera solo la parte di mediazione lato mittente, quella lato destinatario è sostanzialmente speculare.

La ricezione del messaggio sulla porta delegata non comporta nessun problema. Gli handlers in ingresso lavorano solo sull'header del messaggio e non s'interessano del payload che non deve essere costruito. Quindi siamo in un caso dove Axiom si comporta bene, la costruzione solo dell'header del messaggio.

Per il salvataggio ci possono essere dei problemi, infatti se non viene effettuato il caching dei dati questi non saranno più disponibili per un successivo utilizzo, quindi è importante eseguire il salvataggio sincerandosi di non aver più bisogno del messaggio.

Il messaggio poi sarà riletto e l'header modificato secondo le specifiche della Busta eGov. Qui vanno distinti due casi: il messaggio SOAP contiene o meno allegati. Se non ha allegati le modifiche apportate nel modulo d'imbustamento coinvolgeranno solo l'header, mentre nel caso siano presenti allegati la modifica coinvolgerà anche il body causandone la costruzione da parte dell'Object Model.

Nella fase successiva, il tracciamento, verrà loggato l'header eGov, quindi rimaniamo ancora con una costruzione parziale del modello.

Il passaggio critico è quello dell'applicazione di servizi aggiuntivi, in particolare delle politiche di sicurezza. Se il corpo del messaggio deve essere cifrato, necessariamente sarà effettuata la completa costruzione dell'Object Model del messaggio SOAP. Questo avviene solo se configurato, ma si può assumere che avverrà per la maggior parte delle Porte di Dominio.

Questa situazione costituisce per Axiom un caso pessimo per ogni messaggio. Consideriamo comunque Axis2 nella sua interezza, per valutare se il suo utilizzo in un'implementazione di SPCoop rimane comunque una possibilità da prendere in considerazione.

Inizialmente è stato compiuto un porting di OpenSPCoop usando le soluzioni standard di Axis2, quindi usando l'implementazione LLOM di AXIOM, inserendo gli handlers in un modulo e inserendo un dispatcher personalizzato per indirizzare i messaggi ai giusti servizi. Il grafico seguente mostra solo alcuni componenti, oltre a quelli standard,

Il porting è stato molto difficoltoso, non solo per doversi adattare alla diversa architettura del Web Service framework, ma anche per conformarsi alle nuove specifiche. Utilizzare le API AXIOM anche per la manipolazione del messaggio al posto di SAAJ ha comportato la riscrittura quasi completa del codice, anche se la logica rimaneva la stessa. Non implementando il solito standard, c'era la possibilità di produrre risultati diversi anche utilizzando metodi simili delle due API. Questo imponeva la necessità di eseguire numerosi e approfonditi test al termine di ogni fase. La portabilità di un simile sistema sarebbe compromessa visto che sia le API usate per manipolare i messaggi sia il formato dei dati salvati non si riferiscono a nessuno standard.

Il 13 Agosto 2007 Axis2 è giunto alla versione 1.3 e solo in questa versione è stato aggiunto il supporto a JAX-WS. Si è quindi concretizzata la possibilità di effettuare il porting in standard JAX-WS riutilizzando gran parte del vecchio codice, scritto in standard SAAJ, anche se la versione implementata in Axis2 è diversa da quella di Axis, e contestualmente garantendo portabilità.

Il supporto a JAX-WS si è però dimostrato molto acerbo e afflitto da numerosi bugs. In particolare è stato impossibile definire l'handler chain tramite annotazioni, come prevede lo standard JAX-WS, mentre, cercando di aggirare il problema utilizzando il metodo standard di Axis2 aggiungendo un componente modulo, si verifica una perdita di informazioni quando il messaggio incapsulato nell'oggetto MessageContext di Axis2 viene convertito in un oggetto SOAPMessage di SAAJ, vanificando il lavoro degli handlers. Inoltre, i moduli di Axis2 che si occupano delle funzionalità aggiuntive, come Rampart2, Sandesha2, Kandula2 lavorano sul messaggio partendo dal MessageContext, quindi occorre passare comunque da uno standard all'altro se non si vogliono sviluppare soluzioni ad hoc, sempre pagando poi il costo aggiuntivo per mantenere il codice aggiornato.

E' comunque stato completato un porting funzionante per alcuni degli scenari possibili di utilizzo di OpenSPCoop che utilizza in maniera ibrida le tecniche fin qui descritte. Nel dettaglio usa le API AXIOM ed il formato standard del MessageContext per gli handler e l'inizializzazione, poi passa all'implementazione di SAAJ per la parte di manipolazione del messaggio e il salvataggio ed eventualmente di nuovo al MessageContext per essere passato a Rampart2. Lo sviluppo del prototipo è stato poi sospeso in attesa che le API di Axis2 maturino e permettano una gestione più elegante dei messaggi senza questi "balzelli" che ne compromettono le performance.

2.2 CXF

Abbiamo effettuato alcuni test funzionali con CFX per controllarne le effettive capacità. L'implementazione di JAX-WS è di buon livello e siamo riusciti a configurare i servizi web Porta Delegata e Porta Applicativa con i relativi Interceptors grazie alle annotazioni introdotte con JAX-WS. Sempre grazie a JAX-WS è stato possibile implementare il servizio a livello di messaggio ottenendolo in forma di SOAPMessage di SAAJ, senza dover ricorrere a laboriose conversioni di tipo. Nei test effettuati abbiamo riscontrato dei problemi con l'uso degli attachment, che non venivano correttamente incapsulati dentro l'oggetto SOAPMessage. Collaborando con gli sviluppatori di IONA abbiamo risolto il problema ed i test sono proseguiti con successo. CXF è stato sviluppato seguendo l'approccio "use standards everywhere when possible". Al contrario di Axis2 che implementa gli standard con api proprie, CXF usa standard anche per il modello di programmazione, implementando JAX-WS, e come meccanismo di configurazione, scegliendo Spring. Questo non implica certo che l'approccio scelto dagli sviluppatori di CFX risulti il migliore, ma in un campo in fermento come quello dei Web Service Framework dove non si è ancora delineata una soluzione preferenziale alle altre, l'uso di implementazioni standard garantisce un buon livello di portabilità da uno strumento all'altro.

3 Synapse

Abbiamo mostrato come Apache Synapse, basato su Axis2, si proponga come valido strumento per l'implementazione di un'architettura ESB. La sua architettura si presenta quindi modulare, ma piuttosto rigida. La principale mancanza è che non può prendersi carico della consegna dei messaggi. Per spiegare questo concetto prendiamo in esame il più semplice dei paradigmi di comunicazione, il OneWay su protocollo HTTP. In modalità OneWay il client invia un messaggio al servizio senza aspettarsi una risposta.

Come mostrato in questo diagramma di sequenza, il mittente invia al mediatore il messaggio e si mette in attesa dell'ack SOAP. Il mediatore applica le proprie politiche di mediazione e costruisce così la busta eGov secondo le specifiche SPCoop e le inoltra al mediatore di destinazione, sempre con una comunicazione OneWay, aspettando un riscontro. Il Mediatore di destinazione procede alla ricostruzione del messaggio orginale ed alle operazioni di corredo. Infine, consegna il messaggio al destinatario che, in caso di successo, riscontra il messaggio con un ack SOAP che verrà propagato indietro, al mediatore del mittente ed al mittente, chiudendo così le connessioni aperte e rispettando il paradigma OneWay.

Cosa accade se qualcosa dovesse fallire durante la trasmissione del messaggio? Supponiamo ad esempio che uno dei due mediatori coinvolti nella comunicazione non sia raggiungibile:

 

Il mittente riceve dunque l'errore, nonostante parte della comunicazione fosse stata completata con successo. Inoltre sarà compito del mittente la gestione dell'errore, cosa che le specifiche SPCoop non prevede. Ancora, l'elaborazione fin qui completata sarà ripetuta al prossimo tentativo d'invio da parte del mittente, quindi abbiamo un notevole spreco di risorse. Lo stesso scenario si ripropone qualunque sia il punto che genera l'errore.

Immaginiamo quindi uno scenario dove i mediatori coinvolti non siano soltanto due come nel nostro esempio, ma una comunicazione complessa con più punti intermedi. E' facile immaginare quante risorse siano sprecate in una comunicazione che fallisce e deve ripartire da capo, vanificando il lavoro fin li svolto. Uno degli obiettivi dell'infrastruttura SPCoop è appunto evitare questi scenari prendendosi carico della consegna del messaggio. Per far questo sarebbe necessario una profonda modifica ai mediatori forniti a corredo di Synapse per rispettare il nuovo protocollo di comunicazione. Inoltre ci sarebbe bisogno di aggiungere strutture dati e funzionalità per rispettare i requisiti di robustezza che queste nuove funzionalità richiedono.

C'è da notare un altro aspetto dell'architettura, derivato da Axis2, che male si sposa con l'archiettuta SPCoop. Come mostrato precedentemente, una volta mediati i messaggi, questi vengono inoltrati al destinatario attraverso le pipes di Axis2 per essere gestiti dai moduli agganciati ad esse. Quello che ci interessa notare è che una volta spediti attraverso le pipes, il controllo sul messaggio non è più in mano del programmatore. O tutto va bene o tutto va male, e la gestione dell'errore diventa più complessa. Nell'architettura che cerchiamo di sviluppare si vuole un controllo completo sul messaggio in ogni sua fase, spostando le fasi gestite nelle pipes (Security, Addressing etc..) nella parte della logica di mediazione, stravolgendo di nuovo l'architettura di Synapse.

Inoltre questa architettura segue un approccio thread-based, dove ad ogni richiesta viene associato un thread:

Questo approccio vincola il numero di richieste gestibili al numero di thread che possono essere attivati, anche se Synapse implementa il New I/O API (NIO) potendo quindi gestire un elevato numero di connessioni.

Per ultimo, ma non meno importante, poiché  Synapse si basa su Axis2 e ne eredita le scelte implementative, esso ne usa il nuovo Object Model, AXIOM, che, come abbiamo visto, è inefficiente per implementare le specifiche SPCoop.

4 JMS

L'analisi di un'architettura basata su un broker JMS ha evidenziato che riesce ad effettuare quella "presa in carico" del messaggio che un sistema come Synapse non è progettato a fare. Inoltre implementa l'architettura EDA in maniera nativa. Ancora, centralizza totalmente lo storing e alleggerisce notevolemente il carico dei mediatori.

Ci sono però scenari di parziale fallimento che non riesce a gestire.

Come evidenziato dal diagramma di sequenza, se il Broker non è disponibile il sistema non effettua la presa in consegna. OpenSPCoop deve prevedere anche queste situazioni e prendersi carico del messaggio.

Il punto cruciale comunque è che viola il requisito delle specifiche SPC che ogni comunicazione deve essere basata su . Il JMS è uno standard JAVA e non garantisce interoperabilità con altri sistemi non Java. Fornire un'interfaccia che aggiri il problema introdurrebbe un'ulteriore overhead. E' comunque una buona fonte di riflessione su come gestire lo scambio di messaggi soprattutto per quel che concerne l'affidabilità e la velocità.

5 Conclusioni

Dagli studi fin qui compiuti possiamo arrivare alle seguenti conclusioni:

Synapse è un valido strumento di mediazione, ma la sua architettura non fornisce supporto alla completa gestione dello scambio di messaggi. Basandosi su Axis2 fornisce supporto ai più recenti standard in ambito Web Service, ma ne eredita l'inefficenza di AXIOM nel processare i messaggi nella loro interezza, come avviene in SPCoop. Questo non ne preclude l'utilizzo, ma anche dal punto di vista architetturale si è mostrato non adeguato per affrontare determinati aspetti della Cooperazione Applicativa. L'analisi approfondita del codice necessaria alla sua valutazione ha fornito in ogni caso validi spunti per la soluzione di alcuni punti critici di OpenSPCoop.

L'architettura basata su Broker JMS, come mostrato, non rispetta gli standard SPCoop, quindi non può esser presa in considerazione per essere utilizzata in una sua implementazione. Nonostante questo l'analisi di questo modello fornisce interessanti spunti per la gestione delle comunicazioni tra i partecipanti nello scambio di messaggi e costituisce una base per progettare una nuova architettura votata a migliorare le performances.

Per quanto riguarda la sostituzione di Axis con un Web Service Framework di nuova generazione, abbiamo valutato due candidati, Axis2 e CXF.

Axis2 si è dimostrato un valido strumento supportato da una vasta comunità che partecipa attivamente allo sviluppo. Per gli scenari classici di utilizzo in ambito SOA è certamente una soluzione preferenziale. Dovendo implementare la specifica SPCoop con un occhio al supporto di altre specifiche abbiamo valutato aspetti dove Axis2 è più carente, ovvero qualità dell'implementazione di JAX-WS e performances nella manipolazione dei messaggi. Come mostrato, nell'implementazione di SPCoop, AXIOM non risulta essere una scelta valida e l'implementazione di JAX-WS è stata introdotta solo da qualche mese, con alcune funzioni ancora da implementare e altre contenenti bugs. 

CXF, progetto nato dalla fusione di XFire e Celtic, gode anch'esso di una comunità vasta e attiva. La sua architettura è più semplice e snella di quella Axis2 e, per l'utente, alcune funzionalità sono più complesse da utilizzare rispetto alla sua controparte, ma per quello che concerne il nostro utilizzo si propone come scelta migliore. Si basa principalmente su standard, come richiesto da OpenSPCoop, e la loro implementazione è ad un buon livello di maturità, nonostante ci siano ancora dei problemi da risolvere.

Quindi sceglieremo CXF come componente per la gestione dei Web Service, mentre, per l'architettura ESB prevista da SPCoop, valuteremo una modifica a quella implementata in OpenSPCoop, prendendo spunto da quelle analizzate, ma senza possibilità di adottarne completamente alcuna.