Gestione XML della Porta di Dominio OpenSPCoop

Transcript

1 i Gestione XML della Porta di Dominio

2 ii Copyright Link.it srl

3 iii Indice 1 Introduzione 1 2 Hello World! 2 3 Configurazione XML della Porta di Dominio Soggetto SPCoop Attributi Nested Element Riferimenti Porta Delegata Attributi Nested Element Riferimenti Porta Applicativa Attributi Nested Element Riferimenti Soggetto SPCoop Erogatore, Servizio e Azione Attributi Riferimenti Servizio Applicativo Attributi Nested Element Riferimenti Invocazione Porta Attributi Nested Element Riferimenti Credenziali Attributi Riferimenti Invocazione Servizio Attributi Nested Element Riferimenti Gestione Errore Attributi

4 iv Nested Element Riferimenti Risposta Asincrona SPCoop Property Attributi Riferimenti Connettore Attributi Nested Element Riferimenti WS-Security Attributi Nested Element Riferimenti Validazione Contenuti Applicativi Attributi Riferimenti Correlazione Applicativa Attributi Nested Element Riferimenti Configurazione della Porta di Dominio Nested Element Riferimenti Configurazione politiche di Routing Nested Element Riferimenti Accesso Registro dei Servizi Nested Element Validazione Buste E-Gov Attributi Riferimenti Messaggi diagnostici Attributi Nested Element Tracciamenti delle buste e-gov Attributi Nested Element

5 v 4 Il Registro dei Servizi XML di Accordo di Cooperazione Attributi Nested Element Riferimenti Accordo di Servizio Attributi Nested Element Riferimenti Azione di un accordo di Servizio Attributi Riferimenti Port-Type Attributi Nested Element Riferimenti Azione (Operation) di un Port Type Attributi Nested Element Riferimenti Message Attributi Nested Element Riferimenti Porta di Dominio Attributi Riferimenti Soggetto SPCoop Attributi Nested Element Riferimenti Servizio Attributi Nested Element Riferimenti Servizio Correlato Differenziazione connettore per specifica Azione/Fruitore di un Servizio Attributi Nested Element Fruitore Attributi Nested Element Riferimenti

6 vi 5 Esempi di utilizzo di Scenario di Riferimento Funzionalità di Cooperazione Profilo di Collaborazione: OneWay Profilo di Collaborazione: Sincrono Profilo di Trasmissione: Consegna affidabile e senza duplicati Scadenza temporale associata ad una busta egov WS-Security: Funzionalità Generali WS-Security: Autorizzazione dei mittenti di una busta egov Profili di Collaborazione Asincroni Profilo di Collaborazione Asincrono Simmetrico con Richiesta Sincrona Profilo di Collaborazione Asincrono Simmetrico con Richiesta Asincrona Profilo di Collaborazione Asincrono Asimmetrico con Richiesta Sincrona Profilo di Collaborazione Asincrono Asimmetrico con Richiesta Asincrona Profilo di Collaborazione Asincrono Asimmetrico con azioni di uno stesso servizio ID di Collaborazione Consegna in Ordine Cooperazione applicativa con SOAP With Attachments Accordo di Servizio, Port-Types e operations Profilo di gestione della busta e-gov Adeguamento degli accordi alle specifiche CNIPA Dominio di cooperazione: accordi di cooperazione e servizi composti Import/Export degli accordi nel registro dei servizi Funzionalità di Integrazione Autenticazione dei Servizi Applicativi Autorizzazione dei Servizi Applicativi Implementazioni del servizio Ricezione Contenuti Applicativi Implementazioni del servizio Consegna Contenuti Applicativi Propagazione delle informazioni egov ai Servizi Applicativi Riferimento per nome ai Servizi Applicativi Imbustamento Contenuti Applicativi Identificazione dinamica dei servizi erogati Servizio di Message Box Associazione di diversi Servizi Applicativi ad una stessa porta applicativa Correlazione applicativa tra contenuti applicativi e id e-gov Validazione dei contenuti applicativi delle richieste di servizio e delle buste egov Header di Integrazione per i Servizi Applicativi Modalità di trasmissione per un profilo oneway Modalità di gestione Stateless/Stateful

7 vii 5.4 Integrazione dei Servizi Applicativi Funzionalità Avanzate Gestione di più domini di servizi sulla stessa porta di dominio Gestione avanzata dell errore nell invocazione di un Servizio Applicativo Gestione avanzata dell errore ritornato ad un Servizio Applicativo che invoca una Porta Delegata Routing Autorizzazione delle buste egov in ingresso

8 viii Elenco delle figure 1 Scenario Introduttivo Cooperazione con profilo di collaborazione Oneway Scenario di riferimento Cooperazione con profilo di collaborazione sincrono Cooperazione affidabile con riscontri Cooperazione affidabile: ricezione del riscontro Cooperazione con filtro dei duplicati Cooperazione con WS-Security

9 1 / 91 1 Introduzione Questa guida documenta la sintassi, nel linguaggio XML, utilizzata per la gestione della Porta di Dominio e del Registro dei Servizi. supporta per le configurazioni i seguenti repository: Configurazione Porta di Dominio Database Relazionale File XML Configurazione Registro dei Servizi Database Relazionale File XML WEB/HTTP UDDI Nelle sezioni seguenti si farà riferimento esclusivamente alla metodologia XML, sia per quanto riguarda la Porta di Dominio che il Registro dei Servizi. Occorre però precisare che per i due componenti, sulla base delle specifiche esigenze, si possono adottare scelte metodologiche assolutamente indipendenti. Al fine di rendere maggiormente incisiva la presentazione degli argomenti, introduciamo uno scenario d uso esemplificativo, illustrato nella figura seguente, che mostra un tipico scenario d interazione tra due servizi applicativi in accordo allo standard SPCoop. A questo stesso scenario faranno poi riferimento anche la maggior parte degli esempi d uso mostrati nel resto di questa guida (vedi Sezione 5). Figura 1: Scenario Introduttivo Nello scenario è possibile identificare un Sistema Informativo Locale che eroga uno specifico servizio applicativo. Il Sistema può essere contattato dall esterno solo tramite la Porta Applicativa del servizio, presente sulla Porta di Dominio del proprio Dominio di Servizi. Sull altro versante, il Sistema Informativo Locale che intende fruire del servizio può farlo tramite la Porta Delegata del servizio, presente sulla Porta di Dominio del proprio Dominio di Servizi. Entrambe le Porte di Dominio dovranno condividere l accesso a un Registro dei Servizi contenente l elenco dei Soggetti abilitati alle comunicazioni SPCoop, l elenco dei servizi erogati da ogni Soggetto e i relativi accordi di servizio.

10 2 / 91 2 Hello World! In questa sezione viene presentato un primo esempio di utilizzo di. Il caso presentato illustra lo scambio di una busta egov con profilo di collaborazione OneWay, effettuato tra un soggetto fruitore SPC/MinisteroFruitore ed un soggetto SPC/MinisteroErogatore che eroga il servizio oneway SPC/ComunicazioneVariazione. I passi da effettuare, per la configurazione in di questo scenario sono i seguenti: 1. Configurazione del registro dei servizi di : registrazione dell accordo di servizio definito tra i due soggetti, registrazione dei soggetti SPCoop e del servizio che istanzia l accordo di servizio. 2. Configurazione del dominio MinisteroErogatoreSPCoopIT nella porta di dominio : registrazione di una porta applicativa per il servizio SPC/ComunicazioneVariazione. 3. Configurazione del dominio MinisteroFruitoreSPCoopIT nella porta di dominio : registrazione della porta delegata utilizzata dal soggetto SPC/MinisteroFruitore per invocare il servizio SPC/ComunicazioneVariazione. La seguente figura illustra lo scenario di questo esempio: Figura 2: Cooperazione con profilo di collaborazione Oneway 1) Configurazione del registro dei servizi di Il codice seguente mostra come definire l accordo di servizio tra i due soggetti, come registrare i soggetti spcoop e come istanziare il servizio. Le linee 3-7 mostrano come definire un accordo di servizio con nome ComunicazioneVariazione. I servizi istanziati su questo accordo, hanno un profilo di collaborazione OneWay e abilitano l invocazione del servizio senza l utilizzo di un azione.

11 3 / 91 Le linee 9 e 15 mostrano come definire un soggetto SPCoop, fornendo tipo e nome del soggetto. Le linee e definiscono il punto di accesso (url http) delle porte di dominio che ospitano rispettivamente i soggetti SPC/MinisteroFruitore e SPC/MinisteroErogatore. Le linee definisce l istanziazione di un servizio SPC/ComunicazioneVariazione che implementa l accordo di servizio ASComunicazioneVariazione. 1. <registro-servizi xmlns=" xmlns:xsi=" xsi:schemalocation=" openspcoop.org/dao/registry registroservizi.xsd"> <accordo-servizio nome="ascomunicazionevariazione" profilo-collaborazione=" oneway" 4. wsdl-definitorio=" ComunicazioneVariazione/Definitorio.xsd" 5. wsdl-concettuale=" ComunicazioneVariazione/Concettuale.wsdl" 6. wsdl-logico-erogatore=" ComunicazioneVariazione/InterfacciaErogatore.wsdl" 7. utilizzo-senza-azione="true" / > <soggetto-spcoop tipo="spc" nome="ministerofruitore"> 10. <connettore tipo="http" nome="pddministerofruitore"> 11. <property nome="location" valore=" openspcoop/pa" /> 12. </connettore> 13. </soggetto-spcoop> <soggetto-spcoop tipo="spc" nome="ministeroerogatore"> 16. <connettore tipo="http" nome="pddministeroerogatore"> 17. <property nome="location" valore=" openspcoop/pa" /> 18. </connettore> 19. <servizio tipo="spc" nome="comunicazionevariazione" accordo-servizio=" ASComunicazioneVariazione" 20. wsdl-implementativo-erogatore=" pdderogatore:8080/comunicazionevariazione/erogatore.wsdl"/> 21. </soggetto-spcoop> </registro-servizi> 2) Configurazione del dominio MinisteroErogatoreSPCoopIT nella porta di dominio. Il codice seguente illustra sia come configurare un porta applicativa associata all erogazione del servizio SPC/Comunicazione- Variazione nella porta di dominio, sia come configurare la porta di dominio stessa. La linea 5 definisce il soggetto SPC/MinisteroErogatore che la porta di dominio deve gestire. Le linee 6-7 definisce una porta applicativa che permette di rendere pubblica l erogazione del servizio SPC/ComunicazioneVariazione da parte del soggetto SPC/MinisteroErogatore. Le linee 8-14 definiscono il servizio applicativo cui consegnare le richieste e, specificando un connettore, il punto di accesso al servizio erogato (url http). Le linee definiscono invece la configurazione della porta di dominio attraverso la definizione dell accesso ad un registro dei servizi XML reperibile all indirizzo (linee 19-21), la definizione della cadenza di tempo per la gestione dei riscontri (linea 22, funzionalità illustrata nella sezione Profilo di Trasmissione: Consegna affidabile e senza duplicati) e la gestione dei log, che configura openspcoop a produrre solo determinati tipi di log (linea 23, funzionalità illustrata nella sezione Configurazione del sistema di log della porta di dominio). 1. <openspcoop xmlns=" 2. xmlns:xsi=" 3. xsi:schemalocation=" config.xsd"> 4.

12 4 / <soggetto-spcoop tipo="spc" nome="ministeroerogatore" > 6. <porta-applicativa nome="comunicazionevariazione"> 7. <servizio tipo="spc" nome="comunicazionevariazione" /> 8. <servizio-applicativo nome="sa_erogatore" > 9. <invocazione-servizio> 10. <connettore tipo="http" nome="tracer"> 11. <property nome="location" valore=" :8080/TRACE/trace" /> 12. </connettore> 13. </invocazione-servizio> 14. </servizio-applicativo> 15. </porta-applicativa> 16. </soggetto-spcoop> <configurazione> 19. <accesso-registro> 20. <registro tipo="xml" location=" registroservizi.xml" /> 21. </accesso-registro> 22. <inoltro-buste-non-riscontrate cadenza="60" /> 23. <messaggi-diagnostici spcoop="infospcoop" openspcoop="infoopenspcoop" /> 24. </configurazione> 25. </openspcoop> 3) Configurazione del dominio MinisteroFruitoreSPCoopIT nella porta di dominio. Il codice seguente illustra come configurare un porta delegata utilizzata da un servizio applicativo appartenente ad un fruitore per fruire del servizio SPC/ComunicazioneVariazione. Inoltre il codice mostra la configurazione della porta di dominio che gestisce il soggetto SPC/Fruitore, che è esattamente uguale a quella precedentemente descritta per il dominio MinisteroErogatoreSPCoopIT. La linea 5 definisce il soggetto SPCoop SPC/MinisteroFruitore che la porta di dominio deve gestire. Le linee 6-9 definisce una porta delegata che permette un servizio applicativo appartenente ad un fruitore di invocare il servizio SPC/ComunicazioneVariazione erogato dal soggetto SPC/MinisteroErogatore. Le linee definiscono invece la configurazione della porta di dominio. 1. <openspcoop xmlns=" 2. xmlns:xsi=" 3. xsi:schemalocation=" config.xsd"> <soggetto-spcoop tipo="spc" nome="ministerofruitore" > 6. <porta-delegata nome="helloworld" autenticazione="none" autorizzazione ="none"> 7. <soggetto-spcoop-erogatore tipo="spc" nome="ministeroerogatore" /> 8. <servizio tipo="spc" nome="comunicazionevariazione" /> 9. </porta-delegata> 10. </soggetto-spcoop> <configurazione> 13. <accesso-registro> 14. <registro tipo="xml" location=" registroservizi.xml" /> 15. </accesso-registro> 16. <inoltro-buste-non-riscontrate cadenza="60" /> 17. <messaggi-diagnostici spcoop="infospcoop" openspcoop="infoopenspcoop" /> 18. </configurazione> 19. </openspcoop> La busta egov prodotta dalla porta del dominio MinisteroFruitoreSPCoopIT, utilizzata per l invocazione del servizio SPC/ComunicazioneVariazione è la seguente: <egov_it:intestazione SOAP_ENV:actor="

13 5 / 91 SOAP_ENV:mustUnderstand="1" xmlns:egov_it=" xmlns:soap_env=" <egov_it:intestazionemessaggio> <egov_it:mittente> <egov_it:identificativoparte tipo="spc"> MinisteroFruitore </egov_it:identificativoparte> </egov_it:mittente> <egov_it:destinatario> <egov_it:identificativoparte tipo="spc"> MinisteroErogatore </egov_it:identificativoparte> </egov_it:destinatario> <egov_it:profilocollaborazione> EGOV_IT_MessaggioSingoloOneWay </egov_it:profilocollaborazione> <egov_it:servizio tipo="spc">comunicazionevariazione</egov_it:servizio> <egov_it:messaggio> <egov_it:identificatore> MinisteroFruitore_MinisteroFruitoreSPCoopIT_ _ _09:55 </egov_it:identificatore> <egov_it:oraregistrazione tempo="egov_it_locale"> T09:55: </egov_it:oraregistrazione> </egov_it:messaggio> <egov_it:profilotrasmissione inoltro="egov_it_piudiunavolta" confermaricezione="false"/> </egov_it:intestazionemessaggio> <egov_it:listatrasmissioni> <egov_it:trasmissione> <egov_it:origine> <egov_it:identificativoparte tipo="spc"> MinisteroFruitore </egov_it:identificativoparte> </egov_it:origine> <egov_it:destinazione> <egov_it:identificativoparte tipo="spc"> MinisteroErogatore </egov_it:identificativoparte> </egov_it:destinazione> <egov_it:oraregistrazione tempo="egov_it_locale"> T09:55: </egov_it:oraregistrazione> </egov_it:trasmissione> </egov_it:listatrasmissioni> </egov_it:intestazione> 3 Configurazione XML della Porta di Dominio La configurazione di una Porta di Dominio in consiste principalmente nella definizione dei seguenti elementi: Soggetti SPCoop, definiscono i soggetti SPCoop (generalmente uno solo) gestiti dalla porta di dominio e prevedono, all interno del Soggetto, la definizione dei seguenti elementi principali: Porte Delegate, permettono a servizi applicativi del Soggetto SPCoop di accedere ai servizi applicativi erogati da altri Domini. Porte Applicative, permettono l accesso da parte di servizi applicativi di altri domini di accedere a servizi applicativi erogati dal Soggetto SPCoop. Servizi Applicativi, descrivono gli aspetti rilevanti per l interazione con i servizi applicativi (fruitore ed erogatore) che interagiscono con le porte delegate ed applicative della porta di dominio.

14 6 / 91 Configurazione, contiene la definizione di parametri di configurazione della porta di dominio (ad esempio le policy di routing, o il registro utilizzato). Andiamo adesso a vedere come si realizza il file config.xml, utilizzato per configurare la Porta di Dominio. Per ciascun elemento, sarà presentata la struttura generale del formato xml, una descrizione introduttiva delle funzionalità gestite da quell elemento, l elenco degli attributi validi per l elemento, l elenco degli elementi definibili annidati al suo interno (nested element) ed infine i riferimenti ad esempi della documentazione rilevanti per quell elemento. 3.1 Soggetto SPCoop Definisce un soggetto SPCoop gestito dalla porta di dominio. Il Soggetto SPCoop viene utilizzato per identificare un organizzazione/dominio che eroga o fruisce di servizi applicativi. Un soggetto e il proprio dominio vengono identificati da un nome simbolico il più possibile autoesplicativo della missione istituzionale del soggetto stesso. L elemento ha la seguente struttura XML: <soggetto-spcoop tipo="tiposoggetto" nome="nomesoggetto" identificativo-porta=" dominiosoggetto" descrizione="descrizionesoggetto" router="true/false"> <porta-delegata...pd1...>... <porta-delegata...pdn...> <porta-applicativa...pa1...>... <porta-applicativa...pan...> <servizio-applicativo...s1...>... <servizio-applicativo...sn...> <connettore...c1...>... <connettore...cn...> </soggetto-spcoop> Attributi tipo [tipo: xsd:string], rappresenta il tipo di soggetto SPCoop. La specifica SPCoop indica di utilizzare il tipo SPC, comunque la porta di dominio permette di definire anche altri tipi (es. AOO, CodiceFiscale...); nome [tipo: xsd:string], rappresenta il nome associato al soggetto SPCoop; identificativo-porta (opzionale) [tipo: xsd:string], rappresenta il dominio associato al soggetto SPCoop. Se un identificativo porta non viene specificato, al soggetto sarà associato il dominio composto dal nome del soggetto con suffisso il valore SPCoopIT, come indicato nella specifica SPCoop; descrizione (opzionale) [tipo: xsd:string], informazione puramente descrittiva contenente una descrizione funzionale associata al soggetto. router [tipo: xsd:boolean] (opzionale, default: false), indica se il soggetto gestito dalla PdD assume il ruolo di router Nested Element porta-delegata, permettono a servizi applicativi del Soggetto SPCoop di accedere ai servizi applicativi erogati da altri Domini; porta-applicativa, permettono l accesso da parte di servizi applicativi di altri domini di accedere a servizi applicativi erogati dal Soggetto SPCoop; servizio-applicativo, descrivono gli aspetti rilevanti per l interazione con i servizi applicativi (fruitore ed erogatore) che interagiscono con le porte delegate ed applicative della porta di dominio; connettore (min=0 max=unbounded), definisce i parametri necessari all invocazione di un servizio applicativo.

15 7 / Riferimenti Ogni scenario esemplificativo presentato in questa guida illustra come definire un soggetto SPCoop. La Sezione illustra come definire più di un soggetto SPCoop gestito da un unica porta di dominio. La Sezione illustra come definire un soggetto che assuma il ruolo di Router in un architettura di rete diversa dal punto-punto. 3.2 Porta Delegata Una Porta Delegata permette a servizi applicativi del Soggetto SPCoop per la quale è definita di accedere ai servizi applicativi erogati da un altro dominio. La sua descrizione contiene le informazioni necessarie ad identificare il servizio SPCoop a cui la porta è abbinata e il tipo di autenticazione/autorizzazione applicato ai servizi applicativi che la invocano. L elemento ha la seguente struttura XML: <porta-delegata nome="nomepd" descrizione="descrizione Porta Delegata" location="invocazionepd" autenticazione="none/basic/ssl/..." autorizzazione="none/ openspcoop/..." autorizzazione-contenuto="..." ricevuta-asincrona-simmetrica="abilitato/disabilitato" ricevuta-asincrona- asimmetrica="abilitato/disabilitato" integrazione="soap,trasporto,urlbased..." allega-body="abilitato/disabilitato" scarta-body="abilitato/disabilitato" gestione- manifest="abilitato/disabilitato" stateless="abilitato/disabilitato" > <soggetto-spcoop-erogatore...> <servizio...> <azione...> <servizio-applicativo...s1...>... <servizio-applicativo...sn...> <ws-security...> <validazione-contenuti-applicativi...> <correlazione-applicativa...> </porta-delegata> Attributi nome [tipo: xsd:string], specifica un nome associato alla porta delegata. Se non viene definito l attributo opzionale location il nome sarà anche utilizzato per l individuazione della porta delegata nel momento in cui un servizio applicativo la invoca attraverso un servizio reso disponibile su di una determinata risorsa da (es. servizio web). Ad esempio, se viene definita una porta delegata con questo parametro uguale al valore Test, poi potrà essere invocata utilizzando il servizio web Ricezione Contenuti Applicativi reso disponibile dalla porta di dominio, associando come parte finale dell url da invocare, il valore Test. Supponendo che sia istanziata una porta di dominio all indirizzo si dovrà invocare il servizio Web per utilizzare la porta delegata. La sezione Implementazioni del servizio Ricezione Contenuti Applicativi illustra le varie modalità di invocazione delle porte delegate fornite da. descrizione (opzionale) [tipo: xsd:string], informazione puramente descrittiva contenente una descrizione funzionale della porta delegata. location (opzionale) [tipo: xsd:string], contiene un identificativo utilizzato al posto del nome, per l individuazione della porta delegata nel momento in cui un servizio applicativo la invoca attraverso un servizio reso disponibile su di una determinata risorsa da (es. servizio web). autenticazione (default:ssl) [tipo: xsd:string], indica il tipo di autenticazione che deve essere utilizzato dai servizi applicativi che invocano la porta delegata. fornisce meccanismi di autenticazione di base e permette la definizione di meccanismi custom.

16 8 / 91 autorizzazione (default:openspcoop) [tipo: xsd:string], indica il tipo di autorizzazione effettuato sui servizi applicativi che invocano la porta delegata. fornisce un meccanismo di autorizzazione di base e permette la definizione di meccanismi custom. autorizzazione-contenuto (opzionale) [tipo: xsd:string], indica il tipo di autorizzazione che verifica il contenuto utilizzato dai servizi applicativi per invocare la porta delegata. non fornisce un meccanismo di autorizzazione del contenuto built-in. Gli utenti che desiderano utilizzare questo tipo di autorizzazione devono creare un tipo di autorizzazione del contenuto ad hoc come descritto in Autorizzazione Contenuti dei Servizi Applicativi. ricevuta-asincrona-simmetrica (default:abilitato) [tipo: xsd:string], indica il tipo di gestione della ricevuta asincrona per il profilo di collaborazione Asincrono Simmetrico. Se l attributo assume il valore abilitato, le ricevute asincrone possiedono nel SoapBody il contenuto applicativo prodotto dall output dai servizi applicativi invocati. Il servizio applicativo che effettua la richiesta o spedisce la risposta deve rimanere in attesa del contenuto applicativo portato nella ricevuta asincrona. Se l attributo assume il valore disabilitato, le ricevute asincrone contengono un SoapBody vuoto. Il servizio applicativo che effettua la richiesta o spedisce la risposta viene immediatamente sbloccato dalla PdD, la quale si occuperà di consegnare la richiesta/risposta asincrona. Un thread effettuerà il re-invio di una busta, per la quale non è pervenuta la relativa ricevuta asincrona. ricevuta-asincrona-asimmetrica (default:abilitato) [tipo: xsd:string], indica il tipo di gestione della ricevuta asincrona per il profilo di collaborazione Asincrono Asimmetrico, nella sola fase di richiesta. Se l attributo assume il valore abilitato, le ricevute asincrone di una richiesta possiedono nel SoapBody il contenuto applicativo prodotto dall output dei servizi applicativi invocati. Il servizio applicativo che effettua la richiesta deve rimanere in attesa del contenuto applicativo portato nella ricevuta asincrona. Se l attributo assume il valore disabilitato, le ricevute asincrone di una richiesta contengono un SoapBody vuoto. Il servizio applicativo che effettua la richiesta viene immediatamente sbloccato dalla PdD, la quale si occuperà di consegnare la richiesta asincrona. Un thread effettuerà il re-invio di una busta, per la quale non è pervenuta la relativa ricevuta asincrona. Nota: nella fase di richiesta stato, la ricevuta porta sempre il contenuto applicativo del servizio invocato per effettuare la richiesta stato. integrazione (default:non definita) [tipo: xsd:string]. Un Servizio Applicativo può dover passare/ricevere informazioni SPCoop dalla Porta di Dominio. L utilizzo degli header di integrazione, permette di passare/ottenere queste informazioni nella maniera più consona all applicazione. L attributo elenca i tipi di integrazione (header di integrazione) che si desiderano abilitare sulla porta delegata, al posto di quelli utilizzati per default dalla porta di dominio (vedi proprietà org.openspcoop.pdd.integrazione.tipo.pd del file openspcoop.properties nella sezione Configurazione Avanzata della Guida di Installazione). I tipi di integrazione devono essere forniti uno di seguito all altro separati da una virgola. L ordine degli header ne definisce il livelllo di importanza in ordine crescente per l integrazione tra servizio applicativo e pdd. Esistono i seguenti tipi di integrazione: trasporto, le informazioni di integrazioni vengono scambiate negli header del protocollo di trasporto (es. header trasporto http); urlbased, le informazioni di integrazioni vengono scambiate nella url di invocazione, attraverso proprietà in stile FORMbased (es. url?proprieta1=value1); soap, le informazioni di integrazioni vengono scambiate tramite un header soap definito dallo schema fornito con la distribuzione in src/schemi/integrazione.xsd; È possibile aggiungere header soap personalizzati. allega-body (default:disabilitato) [tipo: xsd:string], permette di abilitare la funzionalità allega_body in cui il body inviato da un servizio applicativo come richiesta (porta delegata) o come risposta (porta applicativa) viene allegato come attachment, e viene riferito tramite il manifest egov. La funzionalità è utilizzabile solo da servizi applicativi che invocano con messaggi senza attachment. scarta-body (default:disabilitato) [tipo: xsd:string], permette di abilitare la funzionalità scarta_body in cui il body inviato dal servizio applicativo come richiesta (porta delegata) o come risposta (porta applicativa) viene scartato e vengono utilizzati solo gli attachments presenti, e viene creato il manifest egov. La funzionalità è utilizzabile solo da servizi applicativi che invocano con messaggi con attachment. gestione-manifest [tipo: xsd:string], permette di abilitare la funzionalità gestione_manifest a livello di porta delegata per l abilitazione/disabilitazione della gestione del manifest egov da parte della porta di dominio. stateless [tipo: xsd:string], permette di abilitare la modalità di gestione stateless per il profilo oneway e sincrono. Se viene abilitata la gestione stateless, la porta di dominio gestisce i profili di collaborazione Oneway e Sincrono senza salvare informazioni sul database e senza attivare i diversi MDB funzionali. La gestione della richiesta di servizio avviente tramite un unico

17 9 / 91 thread. Questo comportamento permette di avere performance migliori rispetto alla gestione stateful. La modalità stateless differenzia da quella stateful anche nei seguenti aspetti: oneway, la porta di dominio gestisce il profilo oneway con una modalita di trasmissione sincrona, dove la risposta al client non viene restituita fino a che la porta di dominio non ha finito di gestire la richiesta. Questo comportamento differenzia da quello stateful dove la modalita di trasmissione è asincrona (versione 1.0 di ), dove la porta di dominio si prende in carico di consegnare la richiesta e sblocca subito il client; sincrono, non è possibile salvare tramite integration manager (vedi Sezione 5.3.9) eventuali risposte pervenute sulla porta, ma non consegnate al servizio applicativo a causa dello scadere del timeout; Per default, nella versione 1.1 il profilo sincrono viene gestito in modalità stateless, mentre il profilo oneway in modalità stateful, anche se in realtà viene adottato un approccio ibrido (implementazione parzialmente stateful ma con presa in carico da parte della porta di dominio). È possibile anche modificare i default utilizzati dalla porta (vedi opzioni org.openspcoop.pdd.stateless.default.o e org.openspcoop.pdd.stateless.default.sincrono della sezione Configurazione Avanzata della Guida di Installazione) Nested Element soggetto-spcoop-erogatore, indica l identificativo SPCoop del Soggetto, appartenente ad un altra porta di dominio, che fornisce l erogazione del servizio associato a questa porta delegata (vedi Sezione 3.4); servizio, indica l identificativo SPCoop del servizio erogato (vedi Sezione 3.4); azione (opzionale). Indica l identificativo SPCoop di una particolare azione fornita con l erogazione del servizio (vedi Sezione 3.4); servizio-applicativo (min=0 max=unbounded), definisce un servizio applicativo autorizzato ad invocare la porta delegata. La definizione può essere parziale, fornendo solo il nome del servizio applicativo, specificato completamente nella definizione del soggetto SPCoop, o completa (vedi Sezione 3.5 e Sezione 5.3.6). In una porta delegata possono essere specificati più servizi applicativi autorizzati ad invocarla. ws-security, contiene parametri di WS-Security associati alla porta delegata (vedi Sezione 5.2.5). validazione-contenuti-applicativi, permette di abilitare la validazione xsd del contenuto applicativo delle richieste di servizio. Lo schema di validazione xsd deve essere stato registrato nell accordo di servizio, attraverso il relativo tag wsdl-definitorio (vedi Sezione 3.14). correlazione-applicativa, se abilitato permette di riutilizzare lo stesso idegov in caso di richieste con identico contenuto applicativo. Le richieste di servizio devono essere identificabili da un identificatore applicativo, che sia parte del messaggio xml (content-based) oppure parte della url di invocazione della porta delegata (url-based) (vedi Sezione 3.15) Riferimenti Ogni scenario esemplificativo descritto nella sezione apposita di questa guida, illustra come definire porte delegate invocabili come servizi web. Inoltre la Sezione illustra le varie modalità di invocazione delle porte delegate offerte da. La Sezione illustra come definire il tipo di autenticazione associata ad una porta delegata. La Sezione illustra come definire il tipo di autorizzazione associata ad una porta delegata. La Sezione e Sezione illustrano come definire funzionalità WS-Security associate all invocazione della porta delegata. La Sezione illustra come definire ed utilizzare header di integrazione con il servizio applicativo. La Sezione illustra come la modalità di gestione stateless una porta delegata con profilo oneway, permette di gestire la richiesta in una modalita sincrona.

18 10 / Porta Applicativa Una Porta Applicativa permette l accesso da parte di servizi applicativi di altri domini a servizi applicativi erogati dal Soggetto SPCoop. La sua descrizione include le informazioni necessarie a identificare i tipi di busta egov in arrivo da gestire e le informazioni relative al servizio applicativo da invocare per la consegna dei contenuti della busta. L elemento ha la seguente struttura XML: <porta-applicativa nome="nomepa" descrizione="descrizione Porta Applicativa" ricevuta-asincrona-simmetrica="abilitato/disabilitato" ricevuta-asincrona- asimmetrica="abilitato/disabilitato" integrazione="soap,trasporto,urlbased..." allega-body="abilitato/disabilitato" scarta-body="abilitato/disabilitato" gestione- manifest="abilitato/disabilitato" stateless="abilitato/disabilitato" autorizzazione-contenuto="..."> <soggetto-virtuale tipo="tiposoggettovirtuale" nome="nomesoggettovirtuale" > <servizio tipo="tiposervizio" nome="nomeservizio" > <azione nome="nomeazione" > <servizio-applicativo...s1...>... <servizio-applicativo...sn...> <set-spcoop-property...sp1...>... <set-spcoop-property...spn...> <ws-security...> <validazione-contenuti-applicativi...> <correlazione-applicativa...> </porta-applicativa> Attributi nome [tipo: xsd:string], informazione puramente descrittiva contenente un nome associato alla porta applicativa; descrizione (opzionale) [tipo: xsd:string], informazione puramente descrittiva contenente una descrizione funzionale associata della porta applicativa. ricevuta-asincrona-simmetrica (default:abilitato) [tipo: xsd:string], indica il tipo di gestione della ricevuta asincrona per il profilo di collaborazione Asincrono Simmetrico. Se l attributo assume il valore abilitato, le ricevute asincrone possiedono nel SoapBody il contenuto applicativo prodotto dall output dai servizi applicativi invocati. Il servizio applicativo che effettua la richiesta o spedisce la risposta deve rimanere in attesa del contenuto applicativo portato nella ricevuta asincrona. Se l attributo assume il valore disabilitato, le ricevute asincrone contengono un SoapBody vuoto. Il servizio applicativo che effettua la richiesta o spedisce la risposta viene immediatamente sbloccato dalla PdD, la quale si occuperà di consegnare la richiesta/risposta asincrona. Un thread effettuerà il re-invio di una busta, per la quale non è pervenuta la relativa ricevuta asincrona. ricevuta-asincrona-asimmetrica (default:abilitato) [tipo: xsd:string], indica il tipo di gestione della ricevuta asincrona per il profilo di collaborazione Asincrono Asimmetrico, nella sola fase di richiesta. Se l attributo assume il valore abilitato, le ricevute asincrone di una richiesta possiedono nel SoapBody il contenuto applicativo prodotto dall output dei servizi applicativi invocati. Il servizio applicativo che effettua la richiesta deve rimanere in attesa del contenuto applicativo portato nella ricevuta asincrona. Se l attributo assume il valore disabilitato, le ricevute asincrone di una richiesta contengono un SoapBody vuoto. Il servizio applicativo che effettua la richiesta viene immediatamente sbloccato dalla PdD, la quale si occuperà di consegnare la richiesta asincrona. Un thread effettuerà il re-invio di una busta, per la quale non è pervenuta la relativa ricevuta asincrona. Nota: nella fase di richiesta stato, la ricevuta porta sempre il contenuto applicativo del servizio invocato per effettuare la richiesta stato. integrazione (default:non definita) [tipo: xsd:string]. Un Servizio Applicativo può dover passare/ricevere informazioni SPCoop dalla Porta di Dominio. L utilizzo degli header di integrazione, permette di passare/ottenere queste informazioni nella maniera più consona all applicazione. L attributo elenca i tipi di integrazione (header di integrazione) che si desiderano abilitare sulla porta delegata, al posto di quelli utilizzati per default dalla porta di dominio (vedi proprietà org.openspcoop.pdd.integrazione.tipo.pd

19 11 / 91 del file openspcoop.properties nella sezione Configurazione Avanzata della Guida di Installazione). I tipi di integrazione devono essere forniti uno di seguito all altro separati da una virgola e definiscono gli header da impostare per l integrazione tra pdd e servizio applicativo. Esistono i seguenti tipi di integrazione: trasporto, le informazioni di integrazioni vengono scambiate negli header del protocollo di trasporto (es. header trasporto http); urlbased, le informazioni di integrazioni vengono scambiate nella url di invocazione, attraverso proprietà in stile FORMbased (es. url?proprieta1=value1); soap, le informazioni di integrazioni vengono scambiate tramite un header soap definito dallo schema fornito con la distribuzione in src/schemi/integrazione.xsd; È possibile aggiungere header soap personalizzati. allega-body (default:disabilitato) [tipo: xsd:string], permette di abilitare la funzionalità allega_body in cui il body inviato da un servizio applicativo come richiesta (porta delegata) o come risposta (porta applicativa) viene allegato come attachment, e viene riferito tramite il manifest egov. La funzionalità è utilizzabile solo da servizi applicativi che invocano con messaggi senza attachment. scarta-body (default:disabilitato) [tipo: xsd:string], permette di abilitare la funzionalità scarta_body in cui il body inviato dal servizio applicativo come richiesta (porta delegata) o come risposta (porta applicativa) viene scartato e vengono utilizzati solo gli attachments presenti, e viene creato il manifest egov. La funzionalità è utilizzabile solo da servizi applicativi che invocano con messaggi con attachment. gestione-manifest [tipo: xsd:string], permette di abilitare la funzionalità gestione_manifest a livello di porta delegata per l abilitazione/disabilitazione della gestione del manifest egov da parte della porta di dominio.. stateless [tipo: xsd:string], permette di abilitare la modalità di gestione stateless per il profilo oneway e sincrono. Se viene abilitata la gestione stateless, la porta di dominio gestisce i profili di collaborazione Oneway e Sincrono senza salvare informazioni sul database e senza attivare i diversi MDB funzionali. La gestione della richiesta di servizio avviente tramite un unico thread. Questo comportamento permette di avere performance migliori rispetto alla gestione stateful. La modalità stateless differenzia da quella stateful anche nei seguenti aspetti: oneway, la porta di dominio gestisce il profilo oneway con una modalita di trasmissione sincrona, dove la risposta al client non viene restituita fino a che la porta di dominio non ha finito di gestire la richiesta. Questo comportamento differenzia da quello stateful dove la modalita di trasmissione è asincrona (versione 1.0 di ), dove la porta di dominio si prende in carico di consegnare la richiesta e sblocca subito il client; sincrono, non è possibile salvare tramite integration manager (vedi Sezione 5.3.9) eventuali risposte pervenute sulla porta, ma non consegnate al servizio applicativo a causa dello scadere del timeout; Per default, nella versione 1.1 il profilo sincrono viene gestito in modalità stateless, mentre il profilo oneway in modalità stateful, anche se in realtà viene adottato un approccio ibrido (implementazione parzialmente stateful ma con presa in carico da parte della porta di dominio). È possibile anche modificare i default utilizzati dalla porta (vedi opzioni org.openspcoop.pdd.stateless.default.o e org.openspcoop.pdd.stateless.default.sincrono della sezione Configurazione Avanzata della Guida di Installazione). autorizzazione-contenuto (opzionale) [tipo: xsd:string], indica il tipo di autorizzazione che verifica il contenuto presente nelle buste e-gov in ingresso sulla porta applicativa. non fornisce un meccanismo di autorizzazione del contenuto built-in. Gli utenti che desiderano utilizzare questo tipo di autorizzazione devono creare un tipo di autorizzazione del contenuto ad hoc come descritto in Autorizzazione Contenuti delle buste egov in ingresso Nested Element soggetto-virtuale (opzionale) Permette di associare la porta applicativa, oltre al soggetto che la contiene, anche ad un altro soggetto (definito attraverso un tipo e nome). Viene indicato come soggetto virtuale, poiché non è un soggetto realmente gestito dalla porta di dominio; è solo una funzionalità avanzata utilizzata nella cooperazione per eventi su scambio diretto di buste egov. servizio, indica l identificativo SPCoop del servizio composto dalla coppia di attributi di tipo xsd:string tipo e nome. azione (opzionale), indica l identificativo SPCoop di una particolare azione fornita con l erogazione del servizio. L azione deve essere definita attraverso l attributo di tipo xsd:string nome.

20 12 / 91 servizio-applicativo (min=1 max=unbounded), definisce un servizio applicativo di un erogatore del servizio associato alla porta applicativa. La definizione può essere parziale, fornendo solo il nome del servizio applicativo, specificato completamente nella definizione del soggetto SPCoop, o completa (vedi Sezione 3.5 e Sezione In una porta applicativa possono essere specificati più servizi applicativi invocati da una busta egov. set-spcoop-property (min=0 max=unbounded). Permette di propagare le informazioni presenti nella busta egov utilizzata per identificare la porta applicativa. Definisce una proprietà da impostare nell header del protocollo di trasporto utilizzato dal servizio applicativo associato alla porta applicativa. I valori utilizzati nelle proprietà sono keyword che indirizzano ai valori presenti nella busta egov che ha richiesto il servizio (vedi Sezione ws-security, contiene parametri di WS-Security associati alla porta applicativa (vedi Sezione 5.2.5) e Sezione validazione-contenuti-applicativi, configura la validazione xsd del contenuto applicativo delle richieste di servizio. Lo schema di validazione xsd deve essere stato registrato nel servizio, nel registro dei servizi, attraverso il campo wsdl-definitoriò (vedi Sezione 3.14). correlazione-applicativa, se abilitato permette di associare un id applicativo alla cooperazione in corso. Le richieste di servizio devono essere identificabili da un identificatore applicativo, che sia parte del messaggio xml (content-based) (vedi Sezione 3.15) Riferimenti Ogni scenario esemplificativo descritto nella sezione apposita di questa guida, illustra come definire porte applicative che includono la definizione di un singolo servizio applicativo. La Sezione e la Sezione illustrano come definire funzionalità WS-Security all invocazione della porta applicativa. La Sezione illustra come propagare le informazioni della busta egov che identifica la porta applicativa, al servizio applicativo associato. La Sezione illustra un esempio di definizione di servizi applicativi associati alla stessa porta applicativa. La Sezione illustra come definire ed utilizzare header di integrazione con il servizio applicativo. La Sezione illustra come la modalità di gestione stateless una porta delegata con profilo oneway, permette di gestire la richiesta in una modalita sincrona. 3.4 Soggetto SPCoop Erogatore, Servizio e Azione Rappresentano le tre informazioni fondamentali per individuare univocamente un istanza di servizio all interno del registro dei servizi di (la presenza dell azione è opzionale). Vengono utilizzate all interno della definizione di una porta delegata e permettono alla porta di dominio di identificare il servizio SPCoop a cui la porta è abbinata. L attributo nome dei tre elementi può essere definito staticamente nell xml, o in alternativa è possibile definire una modalità di acquisizione dinamica (vedi Sezione 5.3.8). Questi elementi hanno la seguente struttura XML: <soggetto-spcoop-erogatore identificazione="static/urlbased/contentbased/inputbased" tipo=" tiposoggetto" nome="nomesoggetto" pattern="espressioneregolare"/> <servizio identificazione="static/urlbased/contentbased/inputbased" tipo="tiposervizio" nome="nomeservizio" pattern="espressioneregolare"/> <azione identificazione="static/urlbased/contentbased/inputbased" nome="nomeazione" pattern ="espressioneregolare"/> Attributi tipo [tipo: xsd:string], rappresenta il tipo del soggetto/servizio SPCoop. Non è presente nell elemento azione. nome (opzionale) [tipo: xsd:string], rappresenta il nome SPCoop. Deve essere definito solo nel caso in cui l attributo identificazione assume il valore static.