Prototipo di OpenSPCoop 2.0, basato sull'architettura progettata

Prototipo di OpenSPCoop 2.0, basato sull'architettura progettata

A conclusione della progettazione della nuova architettura è seguita l'implementazione di un prototipo. La produzione del prototipo è stata condotta in due fasi:

• Riduzione delle funzionalità di OpenSPCoop 1.0 e introduzione di CXF
• Aggiunta del "canale preferenziale"

La prima fase consiste nel ridurre la complessità del modulo di controllo di OpenSPCoop1.0. Per far questo sono state eliminate tutte le operazioni non necessarie alla gestione del messaggio in termini di presa in carico e inoltro al nodo successivo. Per i nostri scopi ci siamo limitati all'implementazione della Porta Delegata del modulo di controllo, tralasciando l'implementazione della Porta Applicativa, sostanzialmente speculare, riducendola ad un semplice servizio di echo del messaggio in arrivo.

Prima di mostrare il comportamento del modulo di controllo, forniamo una breve descrizione delle operazioni effettuate da ogni fase (stage) del canale tradizionale nel prototipo:

RicezioneContenutiApplicativi L'interfaccia con l'esterno è costituita dal Web Service implementato in RicezioneContenutiApplicativiWS in standard JAX-WS, gestito dal Web Service Framework CXF.

Questa fase si occupa di:

• Ricevere il messaggio SOAP.
• Identificare la Porta Delegata dall'URL di destinazione del messaggio.
• Salvare il messaggio SOAP su FileSystem.
• Aggiungere su database informazioni sullo stato del messaggio e sulla Porta Delegata identificata precedentemente, utili alle fasi successive.
• Creare il messaggio ImbustamentoMessage e inserirlo nella coda JMS Imbustamento
• Aspettare e prelevare il messaggio RicezioneContenutiApplicativiMessage dalla JMS RicezioneContenutiApplicativi correlato al messaggio di richiesta.
• Ricostruire il messaggio di risposta recuperato da FileSystem, sbustandolo se necessario.
• Inviare la risposta al SIL Mittente.

Imbustamento. Questa fase si occupa di:

• Individuare il tipo di scambio di messaggi incorso tra i SIL (OneWay o Sincrono).
• Se OneWay:
• Creare una risposta di OK.
• Salvare la risposta su FileSystem
• Inserire un opportuno messaggio RicezioneContenutiApplicativiMessage nella coda JMS RicezioneContenutiApplicativi correlato alla richiesta.
• Costruire la Busta eGov da inoltrare alla fase successiva.
• Aggiornare su Database le informazioni sullo stato del messaggio SOAP.
• Inserire un messaggio InoltroBusteEGovMessage contenente la busta creata nella coda JMS InoltroBusteEGov.

InoltroBusteEGov. Questa fase si occupa di:

• Prelevare da FileSystem il messaggio SOAP
• Costruire, partendo dall'header eGov e dal messaggio SOAP, la Busta EGov.
• Inviare il messaggio alla Porta Applicativa opportuna.
• Ricevere la risposta
• Salvare la risposta su FileSystem
• Estrarre la Busta eGov dalla risposta
• Inserire la Busta eGov in uno SbustamentoRisposteEGovMessage e inoltrarlo nella coda SbustamentoRisposteEGov.

SbustamentoRisposteEGov. Questa fase si occupa di:

• Effettuare parte dei controlli sulla Busta EGov
• Se il tipo di comunicazione è Sincrono
• Inoltrare un messaggio RicezioneContenutiApplicativiMessage alla coda RicezioneContenutiApplicativi correlato alla richiesta.

L'elenco delle operazioni di ciascuna fase non è esaustivo, ma in linea di massima descrive la suddivisione dei compiti del processo di mediazione e permette di capire meglio i grafici successivi. Si nota comunque la mancanza di molti servizi di base comuni a molti servizi web e specifici di SPCoop che sono stati eliminati nel prototipo per ridurne la complessità e isolare il processo di presa in consegna e inoltro. Tra questi cito a titolo di esempio: la verifica delle autorizzazioni necessarie all'uso del servizio, il tracciamento, la validazione sintattica e semantica dei messaggi, l'applicazione di politiche di sicurezza, la gestione dei duplicati, la consegna in ordine di messaggi multipli etc. I due grafi seguenti mostrano la sequenza con cui il controllo sul processo di mediazione passa di fase in fase nello scenario di comunicazione OneWay e Request Response Sincrono.

Completata la prima fase di produzione del prototipo, possiamo procedere con l'introduzione del nuovo "canale preferenziale", alla base della nuova architettura.

Raccogliendo le operazioni distribuite tra le quattro fasi del canale originale, sono state implementate le funzionalità nel nuovo processo di mediazione, epurandolo degli accessi a database, per lo stato del messaggio, ed a filesystem, per il salvataggio dello stesso. Per favorire l'interpretazione del codice a chi conosce l'architettura tradizionale, il processo è sempre suddiviso in fasi, anche se non ci sono code JMS a dividerle. Tutte le informazioni sul processo di mediazione del messaggio sono contenute in un oggetto MediationContext passato di modulo in modulo.

RicezioneContenutiApplicativi Utilizza come interfaccia per l'esterno il solito Web Service del canale tradizionale, essendo una funzionalità trasparente all'utente.

Questa fase si occupa di:

• Ricevere il messaggio SOAP.
• Creare il messaggio ImbustamentoMessage e inserirlo contesto di mediazione.
• Passare il controllo al modulo successivo e attendere che il controllo torni.
• Inviare la risposta contenuta nel contesto di mediazione.

Imbustamento. Questa fase si occupa di:

• Individuare il tipo di scambio di messaggi in corso tra i SIL (OneWay o Sincrono).
• Costruire la Busta eGov da inoltrare alla fase successiva.
• Inserire un messaggio InoltroBusteEGovMessage contenente la busta creata nel contesto di mediazione.
• Passare il controllo al modulo successivo

InoltroBusteEGov. Questa fase si occupa di:

• Costruire, partendo dall'header eGov e dal messaggio SOAP, la Busta EGov.
• Inviare il messaggio alla Porta Applicativa opportuna.
• Se fallisce
• One Way
• Inserisce una risposta OK nel contesto di mediazione
• Inserisce il messaggio di richiesta nel canale tradizionale
• Salva il messaggio
• Aggiunge un messaggio InoltroBusteEGovMessage nella coda JMS InoltroBusteEGov
• Inserisce opportuni record sullo stato del messaggio in database.
• Sincrono
• Inserisce un messaggio di risposta di errore nel contesto di mediazione
• Se, invece, riceve la risposta la inserisce nel contesto di mediazione
• Passa il controllo al modulo successivo

SbustamentoRisposteEGov. Questa fase non compie nessuna operazione nel prototipo, non dovendo sbustare i messaggi e fare tutte le verifiche. Passa direttamente il controllo a RicezioneContenutiApplicativi.

Nel Web Service di interfaccia alla porta delegata è inserito il controllo sulla dimensione del messaggio. Questo viene effettuato prelevando dagli headers HTTP l'header Content-Length e confrontandolo con il valore di soglia impostato.

In futuro il canale da dover utilizzare sarà impostato come parametro di configurazione della Porta di Dominio. Se il canale configurato è quello preferenziale, a runtime interviene comunque il controllo sulla dimensione dei messaggi che possono fruire del canale e, in caso il controllo fallisca, ignora la configurazione e instrada il messaggio nel canale tradizionale. Molto importante sarà decidere il giusto valore di soglia da impostare per decidere se una richiesta può o meno essere gestita dal nuovo canale. Un valore troppo basso rischia di inibirne l'utilizzo anche in situazioni favorevoli, mentre un valore troppo alto riduce il numero di messaggi gestibili contemporaneamente.

Il punto cruciale e costituito dalle operazioni che gestiscono la transizione del messaggio dal canale preferenziale a quello tradizionale.

Vengono eseguite solitamente quando, durante l'utilizzo del canale preferenziale, si verifica un errore di comunicazione con il nodo successivo, nel nostro caso con la Porta Applicativa per la richiesta o con il SIL Mittente per la risposta.

L'operazione di "transitamento" implica il dover costruire esattamente lo stato che il messaggio avrebbe nel canale tradizionale.

In caso di un errore di comunicazione per il messaggio di risposta non viene eseguita nessuna operazione, dal momento che, non avendo implementato funzionalità come la Gestione Duplicati, non è di nessuna utilità salvare le risposte non consegnate. Questo ovviamente cambierà quando saranno implementate le funzionalità più evolute.

Il prototipo sviluppato fornisce la conferma sulla correttezza dell'architettura proposta riuscendo a replicare la funzionalità di presa in consegna dell'architettura precedente. Testare la performance del prototipo comparando i due canali, tradizionale e preferenziale, non fornirebbe dati utili. Sarebbe una vittoria schiacciante e scontata del canale preferenziale. Solo un'analisi su un prodotto più avanzato, valutato in un ambiente che simula la realtà, con percentuali di fallimento delle comunicazioni attendibili e con un processo di mediazione completo fornirebbe una valutazione attendibile sul miglioramento della performance ottenuto.

Conclusioni

In questa tesi è stato presentato il processo tramite il quale è stato perseguito l'obiettivo di aggiornare il progetto OpenSPCoop, sia da un punto di vista architetturale e funzionale, sia per quanto concerne le specifiche supportate.

Risultati Ottenuti

Sviluppare una nuova architettura per il progetto OpenSPCoop ha richiesto una lunga ed approfondita analisi delle tecnologie e degli strumenti allo stato dell'arte utili per implementare le specifiche SPCoop. Questa analisi ci ha portato a valutare l'ambito Web Service in ogni suo aspetto: le architetture ideate, le implementazioni delle specifiche, i Web Service Framework ed i Web Service Mediator sviluppati dalla comunità open source. Grazie alle conoscenze acquisite in questa ricerca, è stato possibile ideare e sviluppare una nuova architettura per la mediazione di messaggi in grado di fornire la stessa qualità di servizio della precedente, incrementando il numero di messaggi gestibili.

Come mostrato nel quarto e quinto capitolo, quest'architettura introduce una gestione dei messaggio in transito non riscontrata in altri prodotti concorrenti, evolvendo la precedente ed eliminando alcune inefficienze. La doppia gestione fornita, permette all'architettura di adattarsi alle necessità degli utenti nei diversi scenari di utilizzo.

Per valutare meglio l'architettura proposta è stato creato un prototipo di OpenSPCoop che ne implementa alcune funzionalità cruciali. Oltre questo, il prototipo utilizza un nuovo Web Service Framework, CXF, che sostituisce il vecchio, Axis. Il codice di OpenSPCoop è stato quindi revisionato completamente per utilizzare le API più recenti messe a disposizione da questo strumento, raggiungendo così l'altro obiettivo della tesi, quello di conformare OpenSPCoop alle nuove specifiche in ambito Web Service.

Il prototipo costruito si presenta quindi come un ottimo banco di prova per gli sviluppatori, sia per testare la nuova gestione dei messaggi che l'architettura introduce, sia per valutare le funzionalità aggiunte dalle API.

Sviluppi Futuri

Il prototipo sviluppato non implementa tutta la fase di gestione dei messaggi, ma solo quello che concerne la presa in consegna e l'inoltro in comunicazioni OneWay e Sincrone, pur mantenendo, per quello definito canale tradizionale, la stessa architettura di OpenSPCoop1.0. Inoltre non sono gestiti tutti i possibili errori che possono presentarsi nel processo di mediazione, ma si limita a gestire parte degli errori di comunicazione con la Porta Applicativa.

In future versioni saranno gestiti tutti gli scenari di comunicazione ed aggiunte le funzionalità che implementano le specifiche SPCoop. Questo inciderà sulle operazioni che dovrà eseguire il modulo preposto alle operazioni di transito dal canale tradizionale al canale preferenziale.

Per poter valutare in maniera esaustiva la nuova architettura occorre implementare tutte le funzionalità di OpenSPCoop e testarlo in scenari reali di utilizzo.

Gestore della Memoria

Il componente che gestisce l'utilizzo del canale rapido sarà cruciale per non sovraccaricare il sistema e contemporaneamente gestire il maggior numero di messaggi con il canale preferenziale.

Componente di Transizione

Le operazioni di accesso a database che permettono di transitare da un canale all'altro nella nuova architettura sono, come era per l'architettura precedente, il maggiore responsabile dell'overhead introdotto dalle operazioni di presa in carico. Sarà necessario quindi un lungo lavoro di ottimizzazione per ridurle al minimo.

Applicazioni

L'introduzione della nuova architettura nel progetto OpenSPCoop è stata programmata per la versione 2.0, non appena il prototipo sarà evoluto in un prodotto completo e testato adeguatamente. L'architettura proposta è comunque applicabile non solo al progetto OpenSPCoop, ma anche ad altri sistemi di Web Service Mediation e in generale ad applicazioni in ambito ESB.
Appendice: codice allegato

Nelle pagine seguenti viene riportata una porzione del codice del prototipo sviluppato.

Il prototipo implementa le sole funzioni di presa in carico e consegna per alcuni scenari di utilizzo. La parte di codice si riferisce all'implementazione del canale preferenziale, mentre è stata omessa quella del canale tradizionale.

Le librerie OpenSPCoop sulle quali si appoggia sono quelle della versione 1.0b1 reperibili sul sito di riferimento [05].

Il Web Service Framework utilizzato è CXF versione 2.0.3-incubator-20071016.175632-4. L'Application Server J2EE usato nello sviluppo è JBOSS, versione 4.0.5GA.

Sono presentati i seguenti file:

• web.xml: E' il Deployment Descriptor, un componente delle applicazioni J2EE che fornisce informazioni utili all'application server, JBOSS, per eseguire il depoy dell'applicazione.
• openspcoop_cxf.xml: Un file di configurazione di Spring, un framework open source utilizzato per lo sviluppo di applicazioni web su piattaforma Java, utilizzabile, con qualche modifica, nei Web Service Framework che lo supportano. Nel nostro caso è configurato per CXF.
• MediationContext.java: La classe che definisce il contenitore degli oggetti creati durante il processo di mediazione. Viene solo mostrata la parte di definizione degli oggetti contenuti, omettendo i metodi che ne consentono l'accesso (setter e getter).
• RicezioneContenutiApplicativiWS.java: Implementazione del Web Service di Porta Delegata in standard JAX-WS. Include il modulo che gestisce l'inoltro sul canale tradizionale o su quello preferenziale in base alla dimensione del messaggio di richiesta.
• RicezioneContenutiApplicativi.java: Prima fase di mediazione. Si occupa di integrare informazioni sulla porta delegata richiamata e di inoltrare la richiesta al modulo successivo.
• Imbustamento.java: Seconda fase di mediazione. Si occupa di creare la BustaEGov.
• InoltroBusteEGov: Terza fase di mediazione. Imbusta la richiesta nella BustaEGov e la inoltra al destinatario, la Porta Applicativa. Se non riesce l'inoltro, effettua la presa in consegna, passando il controllo del processo di mediazione al canale tradizionale. Se la consegna procede correttamente passa la risposta alla fase successiva.
• SbustamentoRisposte.java: Quarta e ultima fase di mediazione. Nel prototipo non esegue nessuna operazione. In future versioni eseguirà le operazioni di analisi sulla BustaEGov della risposta. Si limita a consegnare la risposta al Web Service per inviarla al SIL Mittente.
• SoapUtils.java: Classe di utility per la creazione di messaggi SOAP di Ok o di errore.

Configurazione deployment descriptor: web.xml

<web-app>

<context-param>

<param-name>contextConfigLocation</param-name>

<param-value>WEB-INF/openspcoop_cxf.xml</param-value>

</context-param>

<listener>

<listener-class>

org.springframework.web.context.ContextLoaderListener

</listener-class>

</listener>

<servlet>

<servlet-name>openspcoop</servlet-name>

<display-name>openspcoop</display-name>

<servlet-class>

org.apache.cxf.transport.servlet.CXFServlet

</servlet-class>

<load-on-startup>1</load-on-startup>

</servlet>

<servlet-mapping>

<servlet-name>openspcoop</servlet-name>

<url-pattern>/*</url-pattern>

</servlet-mapping>

</web-app>

Configurazione Spring di OpenSPCoop: openspcoop_cxf.xml

<beans

xmlns='http://www.springframework.org/schema/beans' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xmlns:jaxws='http://cxf.apache.org/jaxws'

xsi:schemaLocation=

'http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd'>

<import resource='classpath:META-INF/cxf/cxf.xml' />

<import resource='classpath:META-INF/cxf/cxf-extension--binding.xml' />

<import resource='classpath:META-INF/cxf/cxf-servlet.xml' />

<import resource='classpath:META-INF/cxf/cxf-extension-soap.xml' />

<jaxws:endpoint id='PD' implementor='org.openspcoop.pdd.services.RicezioneContenutiApplicativiWS' address='/PD' />

<jaxws:endpoint id='PA' implementor='org.openspcoop.pdd.services.RicezioneBusteEGovWS' address='/PA' />

</beans>

Contesto di Mediazione: MediationContext.java

package org.openspcoop.pdd.fastchannel;

import org.openspcoop.pdd.mdb.ImbustamentoMessage;

import org.openspcoop.pdd.mdb.InoltroBusteEGovMessage;

import org.openspcoop.pdd.mdb.SbustamentoRisposteMessage;

import org.openspcoop.pdd.services.RicezioneContenutiApplicativiContext;

import org.openspcoop.pdd.services.RicezioneContenutiApplicativiMessage;

public class MediationContext

Web Service Porta Delegata: RicezioneContenutiApplicativiWS.java

package org.openspcoop.pdd.services;

import javax.xml.soap.SOAPMessage;

import javax.xml.ws.Provider;

import javax.xml.ws.ServiceMode;

import javax.xml.ws.WebServiceProvider;

import javax.xml.ws.Service.Mode;

import org.openspcoop.pdd.core.ParametriPortaDelegata;

import org.openspcoop.pdd.fastchannel.MediationContext;

//Modalità di ricezione della richiesta

@ServiceMode(value=Mode.MESSAGE)

//Implementiamo Provider<SOAPMessage> per avere un messaggio SAAJ

@WebServiceProvider

* Definizione di un Web Service in standard JAX-WS.

*

* Il servizio è la Porta Delegata di una PdD

* CXF si preoccupa di fornirci il messaggio in

* ingresso in forma di SOAPMessage di SAAJ

*

* Il servizio è fruibile da

* https://localhost:8080/openspcoop/PD/

*

* Finchè non ritorna il controllo dalle fasi di

* mediazione il mittente non riceve alcuna risposta

*/

public class RicezioneContenutiApplicativiWS implements Provider<SOAPMessage>

/**

* Chiamo il canale giusto

*/

if(size<1000)

else

return context.getMessageResponse();

}

MediazioneFase 1: RicezioneContenutiApplicativi.java

package org.openspcoop.pdd.fastchannel;

import org.apache.log4j.Logger;

import org.openspcoop.dao.config.driver.IDPortaDelegata;

import org.openspcoop.dao.registry.driver.IDSoggetto;

import org.openspcoop.egov.Imbustamento;

import org.openspcoop.egov.ProprietaErroreApplicativo;

import org.openspcoop.pdd.config.OpenSPCoopProperties;

import org.openspcoop.pdd.config.RichiestaDelegata;

import org.openspcoop.pdd.core.CostantiPdD;

import org.openspcoop.pdd.core.IdentificazionePortaDelegata;

import org.openspcoop.pdd.core.ParametriPortaDelegata;

import org.openspcoop.pdd.core.autorizzazione.IAutorizzazione;

import org.openspcoop.pdd.core.integrazione.IGestoreIntegrazionePD;

import org.openspcoop.pdd.mdb.ImbustamentoMessage;

import org.openspcoop.pdd.services.RicezioneContenutiApplicativiContext;

* Implementazione del servizio RicezioneContenutiApplicativi

* del canale Preferenziale

*

* Questa fase si occupa principalmente di raccogliere

* le informazioni sulla porta delegata chiamata

* e passarle al contesto di mediazione.

*

* Fatto questo passa il controllo alla fase di imbustamento.

*

* Quando torna il controllo si occupa di inoltrare il

* messaggio di risposta al mittente.

* Se non riesce a inoltrarlo, nel caso Sincrono, dovrebbe salvarlo,

* ma poichè nel prototipo

* non gestiamo configurazioni quali la consegna

* ALPIUUNAVOLTA, se fallisce non facciamo niente.

*

* Importante: Non sono gestiti gli errori di processamento.

* Ne qui, ne in molte altre parti del prototipo.

* Nel prototipo e in un ambiente di test non si verificano

* mai e vogliamo tenerlo il più semplice possibile.

*

*/

public class RicezioneContenutiApplicativi

/** Metodo di mediazione **/

public MediationContext process(MediationContext mc)

catch(Exception e)

* Spedizione a modulo Imbustamento dell canale Preferenziale

**/

System.out.println('[Canale Preferenziale] [RicezioneContenutiApplicativi] Invio messaggio al modulo di Imbustamento');

String idModuloInAttesa = null;

if(this.msgContext.isGestioneRisposta())

idModuloInAttesa = this.msgContext.getIdModulo();

RichiestaDelegata richiestaDelegata =

new RichiestaDelegata(

soggettoFruitore,

parPD.getLocation(),

servizioApplicativo,

idModuloInAttesa,

proprietaErroreAppl,

identitaPdD);

// Inserisco il contesto di RicezioneContenutiApplicativi

// nel Contesto di Mediazione

mc.setRicezioneContenutiApplicativiContext(msgContext);

//Creo oggetto ImbustamentoMessage con i dati raccolti

ImbustamentoMessage imbustamentoMSG = new ImbustamentoMessage();

imbustamentoMSG.setRichiestaDelegata(richiestaDelegata);

//Inserisco l'oggetto ImbustamentoMessage nel contesto di mediazione

mc.setImbustamentoMessage(imbustamentoMSG);

org.openspcoop.pdd.fastchannel.Imbustamento imbustamento =

new org.openspcoop.pdd.fastchannel.Imbustamento();

//Procedo alla fase successiva

return imbustamento.mediate(mc);

MediazioneFase 2: Imbustamento.java

package org.openspcoop.pdd.fastchannel;

import org.openspcoop.egov.Busta;

import org.openspcoop.egov.Costanti;

import org.openspcoop.pdd.config.RichiestaDelegata;

import org.openspcoop.pdd.mdb.ImbustamentoMessage;

import org.openspcoop.pdd.mdb.InoltroBusteEGovMessage;

* Fase imbustamento del canale preferenziale

*

* Si occupa di costruire la busta eGov partendo dalle informazioni

* contenute in ImbustamentoMessage racchiuso nel MediationContext

*

* Nel prototipo la costruzione della busta adeguata

* al messaggio di richiesta

* è sostituita da una busta di comodo.

*/

public class Imbustamento

else

richiestaDelegata.setScenario(

Costanti.SCENARIO_SINCRONO_INVOCAZIONE_SERVIZIO);

*

* Spedizione InoltroBusteEGovMessage

* al modulo InoltroBusteEGov del canale Fast

*

* ------------- **/

System.out.println('[Canale Preferenziale][Imbustamento]Invio messaggio al modulo di InoltroBusteEGov');

//Creo oggetto InoltroBusteEGovMessage

//con le info raccolte e la busta eGov creata

//Inserisco tutto nel Contesto di Mediazione

InoltroBusteEGovMessage inoltroMSG = new InoltroBusteEGovMessage();

inoltroMSG.setRichiestaDelegata(richiestaDelegata);

inoltroMSG.setBusta(eGov_Test);

mc.setInoltroBusteEGovMessage(inoltroMSG);

//Passo alla fase successiva, l'inoltroBusteEgov

InoltroBusteEGov inoltroBusteEGov = new InoltroBusteEGov();

return inoltroBusteEGov.mediate(mc);

MediazioneFase 3: InoltroBusteEGov.java

package org.openspcoop.pdd.fastchannel;

import java.sql.Connection;

import javax.xml.soap.SOAPFault;

import javax.xml.soap.SOAPMessage;

import org.openspcoop.dao.config.Connettore;

import org.openspcoop.dao.config.ConnettoreProperty;

import org.openspcoop.dao.registry.driver.IDSoggetto;

import org.openspcoop.egov.Busta;

import org.openspcoop.egov.Costanti;

import org.openspcoop.egov.Eccezione;

import org.openspcoop.egov.ProprietaErroreApplicativo;

import org.openspcoop.egov.XMLBuilder;

import org.openspcoop.pdd.config.ClassNameProperties;

import org.openspcoop.pdd.config.DBManager;

import org.openspcoop.pdd.config.RichiestaDelegata;

import org.openspcoop.pdd.core.CostantiPdD;

import org.openspcoop.pdd.core.GestoreMessaggi;

import org.openspcoop.pdd.core.GestoreMessaggiException;

import org.openspcoop.pdd.core.JMSSender;

import org.openspcoop.pdd.core.connettori.ConnettoreMsg;

import org.openspcoop.pdd.core.connettori.IConnettore;

import org.openspcoop.pdd.logger.MsgDiagnostico;

import org.openspcoop.pdd.mdb.Imbustamento;

import org.openspcoop.pdd.mdb.InoltroBusteEGovMessage;

import org.openspcoop.pdd.mdb.SbustamentoRisposteMessage;

* Fase di Inoltro del canale preferenziale

* Oltre ad inviare il messaggio alla Porta Applicativa e

* ricevere la risposta, si preoccupa di gestire la

* transizione al canale tradizionale in caso di errori di

* comunicazione.

*

* Le operazioni di transizione al canale

* tradizionale per messaggi OneWay sono

* - Salvataggio del messaggio nel repository

* - Registrazione dello stato del messaggio su DB

* - Aggiunta di InoltroBusteEGovMessage

* nella coda JMS InoltroBusteEGov

* - Impostazione messaggio OK da inviare

* al mittente nel MediationContext

* - Passare il controllo a RicezioneContenutiApplicativi

* (per l'inviio della risposta)

*

* Se qualcosa va male invia al mittente un

* messaggio di errore e fa il rollback di tutto

*

* Se l'errore è nella conegna di un Sincrono manda indietro subito

* il messaggio di errore senza transire nel canale tradizionale.

*

* In caso di errore il controllo ritorna a

* RicezioneContenutiApplicativi.

*

* Se la comunicazione va a buon fine trasmette il

* controllo al modulo successivo

* per lo sbustamento, SbustamentoRisposte.

*

*/

public class InoltroBusteEGov catch(Exception e)

// Utilizzo il connettore ed

// inoltro la richiesta alla porta applicativa

System.out.println('[Canale Preferenziale] [InoltroBusteEGov] Invio Messaggio SPCoop a Porta Applicativa');

errorConsegna = !connectorSender.send(connettoreMsg);

motivoErroreConsegna = connectorSender.getErrore();

interpretazione esito consegna

codiceRitornato = connectorSender.getCodiceTrasporto();

responseSOAPMessage = connectorSender.getResponse();

//Controllo la risposta

//Vediamo se c'è stato un errore

if(errorConsegna)catch(Exception e)

presaInConsegnaFallita('Connessione a DB fallita');

return mc;

}

//Salvo il messaggio di richiesta

//su database per successivi tentativi di inoltro

System.out.println('[Canale Preferenziale] [InoltroBusteEGov] Registrazione messaggio di richiesta nel RepositoryMessaggi');

GestoreMessaggi msgRequest =

new GestoreMessaggi(

connectionDB,

idEGovRequest,

Costanti.OUTBOX);

try

catch(GestoreMessaggiException e)

/* Spedizione InoltroBusteEGovMessage alla JMS InoltroBusteEGov del canale tradizionale */

// Creazione InoltroBusteEGovMessage

System.out.println('[Canale Preferenziale] [InoltroBusteEGov] Invio messaggio al modulo di InoltroBusteEGov del Canale Tradizionale');

String errorSenderJMS = null;

try

} catch (Exception e)

if(errorSenderJMS!=null)

System.out.println('[Canale Preferenziale] [InoltroBusteEGov] Profilo OneWay. Invio OK al SIL Mittente');

mc.getRicezioneContenutiApplicativiContext().setMessageResponse(okSoap);

else

// Se arrivo qui significa che ho una risposta

// dalla Porta Applicativa. La mando allo Sbustamento

System.out.println('[Canale Preferenziale] [InoltroBusteEGov] Ricevuta risposta['+codiceRitornato+']');

mc.getRicezioneContenutiApplicativiContext().setMessageResponse(responseSOAPMessage);

* Costruisco un'opportuna busta eGov di risposta

* Nella realtà sarebbe contenuta dalla

* risposta della Porta Applicativa

*** ------------*/

boolean presenzaRispostaSPCoop = true;

Busta bustaRisposta = bustaRichiesta.invertiBusta();

bustaRisposta.setProfiloDiCollaborazione(bustaRichiesta.getProfiloDiCollaborazione());

bustaRisposta.setTipoServizio(bustaRichiesta.getTipoServizio());

bustaRisposta.setServizio(bustaRichiesta.getServizio());

bustaRisposta.setAzione(bustaRichiesta.getAzione());

bustaRisposta.setRiferimentoMessaggio(bustaRichiesta.getID());

mc.setIdEGovRisposta(

org.openspcoop.egov.Imbustamento.buildID_eGov(

null,

bustaRisposta.getMittente()+'SPCoopIT',

bustaRisposta.getMittente()));

bustaRisposta.setID(mc.getIdEGovRisposta());

/* Gestione Risposta (operazioni comuni per tutti i profili) */

SOAPFault fault = null;

boolean isMessaggioSPCoopErrore = false;

boolean bustaDiServizio = false;

String idEGovResponse = null;

java.util.Vector<Eccezione> errors = null;

SbustamentoRisposteMessage sbustamentoRisposteMSG = null;

// Gestione Specifica per Buste SPCoop

idEGovResponse = bustaRisposta.getID();

isMessaggioSPCoopErrore = false;

bustaDiServizio = false;

// Costruzione oggetto da spedire al modulo    

// 'SbustamentoRisposte' anche se non fa nulla

// servirà per applicazioni successive

sbustamentoRisposteMSG = new SbustamentoRisposteMessage();

sbustamentoRisposteMSG.setRichiestaDelegata(richiestaDelegata);

sbustamentoRisposteMSG.setBusta(bustaRisposta);

sbustamentoRisposteMSG.setErrors(errors);

sbustamentoRisposteMSG.setIsSPCoopErrore(isMessaggioSPCoopErrore);

sbustamentoRisposteMSG.setIsBustaDiServizio(bustaDiServizio);

* Passo alla fase successiva.. lo sbustamentoRisposte

*/

System.out.println('[Canale Preferenziale][InoltroBusteEGov] Spedizione messaggio verso SbustamentoRisposte');

mc.setSbustamentoRisposteMessage(sbustamentoRisposteMSG);  

catch(Exception e)

SbustamentoRisposte sbustamento = new SbustamentoRisposte();

return sbustamento.mediate(mc);

/* Funzione che setta il messaggio di errore di risposta */

public void presaInConsegnaFallita(String err)

catch(Exception e)

mc.getRicezioneContenutiApplicativiContext().setMessageResponse(soapErr);

MediazioneFase 4: SbustamentoRisposte.java

package org.openspcoop.pdd.fastchannel;

* Il modulo sbustamentoRisposte deve

* elaborare le informazioni dell'header eGov della risposta.

* Ai fini del prototipo non non è interessante

* eseguire questi controlli.

*

* Il prototipo in questa fase non fa niente e ritorna il

* controllo a RicezioneContenutiApplicativi

*/

public class SbustamentoRisposte

Utility per cla costruzione di messaggi: SoapUtils.java

import javax.xml.soap.MessageFactory;

import javax.xml.soap.SOAPBody;

import javax.xml.soap.SOAPElement;

import javax.xml.soap.SOAPEnvelope;

import javax.xml.soap.SOAPFactory;

import javax.xml.soap.SOAPFault;

import javax.xml.soap.SOAPMessage;

import org.openspcoop.utils.UtilsException;

* Classe di utilità per la costruzione di messaggi SOAP

* OK o FAULT da inviare al mittente

public class SoapUtils

catch(Exception e)

* Metodo che si occupa di costruire un

*messaggio SOAPElement 'openspcoop OK'.

*/

public static SOAPElement buildOpenSPCoopOK(String idEGov) throws UtilsException catch(Exception e)

* Costruisce il messaggio di errore SOAP

* da inviare al mittente se qualcosa fallisce.

*

* @param aFault breve descrizione

* @param aActor chi ha fatto l'errore

* @param aCode codice errore

* @return Messaggio di fault da mandare al mittente

* @throws UtilsException

*/

public static SOAPMessage build_Soap_Fault(String aFault, String aActor, String aCode) throws UtilsException catch(Exception e)

Ringraziamenti

Sono molte le persone che devo ringraziare sia per questo lavoro, sia per questi anni universitari. È stata anche la loro presenza ed il loro sostegno che mi hanno permesso di raggiungere questo importante traguardo.

Ringrazio innanzi tutto i miei genitori, a cui dedico la tesi, grazie ai quali ho avuto la possibilità di coronare questo sogno.

Ringrazio i miei colleghi ed amici universitari, con i quali ho condiviso il lungo percorso che mi ha portato sin qui, aiutandomi ad affrontare i momenti difficili.

Ringrazio i ragazzi della Link.it, il Prof. Tito Flagella ed il Prof. Andrea Corradini, che mi hanno aiutato in questo lavoro con professionalità e competenza, riuscendo nel contempo a creare un clima sereno e amichevole.

Grazie a tutti di cuore,

Lorenzo

Bibliografia

[01] "Sistema Pubblico di Cooperazione: Architettura",

Versione 1.0, 25 Novembre 2004,

https://www.cnipa.gov.it/site/_files/SPCoop-Architettura_v1.0_20041125_.pdf

[02] "Sistema pubblico di cooperazione: Busta di e-Gov",

Versione 1.1, 14 Ottobre 2005,

https://www.cnipa.gov.it/site/_files/SPCoop-Busta%20e-Gov_v1.1_20051014.pdf

[03] "Sistema pubblico di cooperazione: Porta di Dominio",

Versione 1.0, 14 Ottobre 2005,

https://www.cnipa.gov.it/site/_files/SPCoop-PortaDominio_v1.0_20051014.pdf

[04] "Sistema pubblico di cooperazione: Servizi di Registro",

Versione 1.0, 14 Ottobre 2005,

https://www.cnipa.gov.it/site/_files/SPCoop-ServiziRegistro_v1.0_20051014.pdf

[05] "OpenSPCoop"

https://openspcoop.org

[06] "Link.it"

https://www.link.it

[07] "Apache Synapse"

https://ws.apache.org/synapse

[08] "Apache Axis"

https://ws.apache.org/axis

[09] "Apache Axis2"

https://ws.apache.org/axis2

[10] "Apache CXF"

https://incubator.apache.org/cxf/

[11] "Apache AXIOM"

http://ws.apache.org/commons/axiom

[12] "JBoss"

https://www.jboss.org

[13] "Simple Object Access Protocol",

https://www.w3.org/TR/soap/

[14] "Web Service Interoperability",

https://www.ws-i.org/

[15] "eXtensible Markup Language",

https://www.w3.org/xml/

[16] "SOAP with Attachment",

https://www.w3.org/TR/soap/

[17] "Web Service Description Language",

https://www.w3.org/TR/wsdl

[18] "Universal Description, Discovery and Integration"

https://www.oasis-open.org/committees/uddi-spec/

[19] "Web Service Security"

https://www.oasis-open.org/committees/wss/

[20] "Web Service Adressing"

https://www.w3.org/Submission/ws-addressing

[21] "Web Service Reliability"

https://www.oasis-open.org/committees/wsrm/

[22] "Java API for XML Processing"

https://jaxp.dev.java.net/

[23] "Java API for XML-based Remote Procedure Call"

https://jax-rpc.dev.java.net/

[24] "Java API for XML-based Web Service"

https://jax-ws.dev.java.net/

[25] "SOAP with Attachment API for Java"

https://saaj.dev.java.net/

[26] "Java API for XML Registry"

https://java.sun.com/webservices/jaxr/index.jsp

[27] "Java API for XML Binding"

https://jaxb.dev.java.net/

[28] "Attachment Profile v1.0"

https://www.ws-i.org/Profiles/AttachmentsProfile-1.0.html

[29] "Simple Soap Binding Profile v1.0"

https://www.ws-i.org/Profiles/SimpleSoapBindingProfile-1.0.html

[30] "Web Service Architecture"

https://www.w3.org/TR/ws-arch/

[31] "SEDA: An Architecture for Scalable, Well Conditioned Internet Services"

Matt Welsh, David Culler, and Eric Brewer

https://www.eecs.harvard.edu/~mdw/talks/seda-sosp01-talk.pdf

[32] "SEDA: An Architecture for Scalable, Well Conditioned Internet Services"

Matt Welsh, David Culler, and Eric Brewer

https://www.eecs.harvard.edu/~mdw/papers/seda-sosp01.pdf

[33] "Service-Oriented Architecture and Web Service: Concepts, Technologies, and tools."

Ed Ort

https://java.sun.com/developer/technicalArticles/WebServices/soa2/

[34] "Rethinking the Java SOAP Stack"

Steve Loughran, Edmund Smith

https://www.hpl.hp.com/techreports/2005/HPL-2005-83.pdf

[35] "What's new in SOA and Web Service"

Ed Ort

http://java.sun.com/developer/technicalArticles/WebServices/soa2/WhatsNewArticle.html

[36] "Implementing High Performance Web Service Using JAX-WS 2.0"

Bharath Mundlapudi

https://java.sun.com/developer/technicalArticles/WebServices/high_performance/

[37] "Easy and Efficient XML Processing: Upgrade to JAXP 1.3"

Neeraj Bajaj

https://java.sun.com/developer/technicalArticles/xml/jaxp1-3/

[38] "Getting started with JAX-RPC"

Arun Gupta, Beth Stearns

https://java.sun.com/developer/technicalArticles/WebServices/getstartjaxrpc/

[39] "Java API for XML-based RPC (JAX-RPC)"

Rahul Sharma

https://java.sun.com/developer/technicalArticles/xml/jaxrpc/

[40] "Intro to the JAXM Client Programming Model"

Jennifer Rodoni

https://java.sun.com/developer/technicalArticles/xml/introJAXMclient

[41] "Java Tecnology and XML - Part 1 & 2"

Thierry Violleau

https://java.sun.com/developer/technicalArticles/xml JavaTechandXML_part1

https://java.sun.com/developer/technicalArticles/xml JavaTechandXML_part2

[42] "Registration and the JAXR API"

Ed Ort, Ramesh Mandava

https://java.sun.com/developer/technicalArticles/WebServices/WSPack/

[43] "Java Architecture for XML Binding (JAXB)."

Ed Ort, Bhakti Mehta

https://java.sun.com/developer/technicalArticles/WebServices/jaxb

[44] "JAX-RPC versus JAX-WS"

Russel Butek, Nicholas Gallardo

https://www.ibm.com/developerworks/webservices/library/ws-tip-jaxwsrpc.html

https://www.ibm.com/developerworks/webservices/library/ws-tip-jaxwsrpc2.html

[45] "Introduction to StAX"

S. W. Eran Chinthaka

https://wso2.org/library/1844

[46] "Introducing AXIOM: The Axis Object Model"

S. W. Eran Chinthaka

https://wso2.org/library/26

[47] "Fast and Lighweight Object Model for XML"

S. W. Eran Chinthaka

https://wso2.org/library/291

https://wso2.org/library/351

[48] "Digging into Axis2: AXIOM".

Dennis Sosnosky

https://www-128.ibm.com/developerworks/java/library/ws-java2/index.html

[49] "Apache Synapse ESB"

Ashankha Perera

wso2.org/library/244

[50] "Java Message Service"

Ruggero Russo

https://www.slideshare.net/federico.paparoni/tutorial-su-jms-java message service

[51] "The Architecture of Service"

Kendall Grant Clark

https://www.xml.com/pub/a/2003/05/28/deviant.html

[52] "A Tour of the Web Service Architecture"

Kendall Grant Clark

http ://www.xml.com/pub/a/2003/06/18/ws-arch.html

[53] "More WS-Arch discussion"

Steve Vinoski

https://blogs.iona.com/vinoski/archives/000107.html

[54] "WS-* and the Big Picture"

Steve Vinoski

https://blogs.iona.com/vinoski/archives/000104.html

[55] "WS-Architecture? Uhm."

Steve Maine

https://hyperthink.net/blog/2004/10/15/WSArchitecture+Umm.aspx

[56] "Codehaus XFire"

http://xfire.codehaus.org/

[57] "IONA Celtix"

https://open.iona.com/

[58] "Aegis Binding"

https://xfire.codehaus.org/Aegis+Binding

[59] "Spring Framework"

https://www.springframework.org/

[60] "Progettazione di un framework open souce per la cooperazione applicative nella pubblica amministrazione"

Ruggero Barsacchi

[61] "OpenSPCoop: un'implementazione della Spwcifica di Cooperazione Applicativa per la Pubblica Amministrazione Italiana"

Andrea Poli

[62] "Oasis-Open"

https://www.oasis-open.org