In questa sezione sono descritte le principali nuove funzionalità introdotte nella versione 1.2 di OpenSPCoop. Per un'elenco dei problemi risolti si rimanda invece al bugzilla del progetto ed al file ChangeLog di questa versione.
In vista dell'attivazione dei servizi del SICA generale, il CNIPA ha specificato ulteriormente i formati degli accordi di servizio parte comune e specifica.
In particolare, un accordo di servizio parte comune può contenere oltre alle specifiche di interfaccia (WSDL) e alle specifiche di conversazione (WSBL) anche altri documenti:
allegati, documenti non formali di interesse per l'Accordo di Servizio in un qualsiasi formato.
specifice semiformali, specifiche a livello concettuale e logico su altri eventuali aspetti dell'accordo redatte mediante semiformalismi (XML, UML, HTML) o in linguaggio naturale.
Un accordo di servizio parte specifica può contenere oltre alle specifiche dei porti di accesso (WSDL) anche altri documenti:
allegati, documenti non formali di interesse per l'Accordo di Servizio in un qualsiasi formato.
specifiche semiformali, specifiche a livello concettuale e logico su altri eventuali aspetti dell'accordo redatte mediante semiformalismi (XML, UML, HTML) o in linguaggio naturale.
specifiche livelli servizio, i formati dei documenti ammessi sono WS-Agreement e WSLA.
specifiche sicurezza, specifiche sulla sicurezza associata al servizio redatte mediante WS-Policy o in linguaggio naturale.
Le diverse implementazioni del registro dei servizi di OpenSPCoop e le relative interfacce grafiche sono state adeguate per gestire tutti i documenti previsti negli accordi di servizio.
Un esempio completo di configurazione del registro dei servizi che utilizza accordi di servizio e servizi spcoop nel nuovo formato è fornita nella Sezione 9.2.13, «Adeguamento degli accordi alle specifiche CNIPA».
Nella versione 1.2 del Registro dei Servizi di OpenSPCoop è stata completata l'implementazione della gestione degli accordi di cooperazione e dei servizi composti, solo parzialmente presente nelle precedenti versioni.
Un accordo di cooperazione contiene la specifica dei servizi offerti da un Dominio di Cooperazione. Tre sono gli elementi fondamentali che caratterizzano l'erogazione dei servizi da parte di un dominio di Cooperazione:
servizi composti, sono i servizi che il dominio di cooperazione offre all'esterno; dal punto di vista di un fruitore i servizi composti sono indistinguibili da qualsiasi altro servizio SPCOOP e vengono descritti attraverso normali accordi di servizio;
servizi componenti, servizi che il dominio di cooperazione utilizza internamente, componendoli, per realizzare i servizi composti;
-
modalità di composizione, per ogni servizio composto deve essere fornita la specifica di coordinamento per indicare come i servizi componenti vengono coordinati al fine di erogare il servizio composto; tale specifica potrà essere definita secondo due diverse modalità:
orchestrazione, (punto di vista interno al servizio composto) viene descritto il processo mediante il quale i servizi componenti devono essere coordinati per offrire il servizio composto. Il formalismo utilizzato è WS-BPEL.
coreografia, (punto di vista esterno) vengono descritti i vincoli sugli scambi di messaggi tra i vari servizi componenti. Il formalismo utilizzato è WS-CDL.
L'accordo di cooperazione contiene poi l'elenco dei soggetti partecipanti al dominio di cooperazione. Tale elenco include:
fruitori, soggetti che intendono ricevere la prestazione del servizio composto;
erogatori di servizi componenti, soggetti che garantiscono le prestazioni dei servizi componenti;
erogatore del servizio composto, soggetto che si rende responsabile della corretta composizione dei servizi componenti per fornire ai fruitori l'erogazione del servizio composto;
referente, soggetto referente dell'accordo di cooperazione.
Nel registro dei servizi di OpenSPCoop 1.2 è stata completata la gestione di:
accordi di cooperazione, contenente i documenti per il dominio di cooperazione (vedi Sezione 5.1.1, «Accordo di Cooperazione»)
servizi composti, ovvero accordi di servizio che oltre agli elementi standard contengono l'elenco dei servizi componenti necessari alla implementazione del servizio composto e le specifiche di coordinamento (WS-BPEL o WS-CDL, vedi Sezione 5.1.2, «Accordo di Servizio»)
Un esempio di configurazione del registro dei servizi contenente accordi di cooperazione e servizi composti è disponibile nella Sezione 9.2.14, «Dominio di cooperazione: accordi di cooperazione e servizi composti».
L'interfaccia grafica del registro dei servizi di OpenSPCoop 1.2 è stata modificata per permettere agli utenti di gestire il ciclo di vita degli accordi di servizio e di coooperazione. In particolare, sono stati previsti tre diversi stati per gli Accordi:
-
bozza, un accordo può essere modificato in ogni sua parte. Tuttavia tale accordo non è visibile alla porta di dominio OpenSPCoop.
Questo stato è stato previsto per evitare che la porta di dominio OpenSPCoop possa attingere ad informazioni su servizi solo parzialmente definiti, generando così situazioni di inconsistenza nella gestione delle richieste in arrivo.
operativo, un accordo può ancora essere modificato in ogni sua parte, ma è già visibile alla porta di dominio OpenSPCoop.
-
finale, l'accordo è stato completamente definito e non può più essere modificato.
Questo stato è stato introdotto per rispettare la specifica SPCoop che prevede che, una volta che l'Accordo sia stato registrato sul SICA Generale, questo non possa più essere ulteriormente modificato, se non attraverso la pubblicazione di una diversa versione dell'Accordo.
L'interfaccia grafica del registro dei servizi di OpenSPCoop 1.2 è stata modificata per permettere l'import e l'export di accordi nel formato di archivio formalizzato dal CNIPA.
Esempi di package CNIPA importabili nel registro dei servizi sono riportati in Sezione 9.2.15, «Import/Export degli accordi nel registro dei servizi».
Con la versione 1.2 di OpenSPCoop è possibile personalizzare il livello di severità e il corpo del messaggio dei principali messaggi diagnostici emessi dalla porta di dominio. Tale personalizzazione è effettuabile agendo sul file di configurazione msgDiagnostici.properties.
In questa sezione sono descritte le principali nuove funzionalità introdotte nella versione 1.1 di OpenSPCoop. Per un'elenco dei problemi risolti si rimanda invece al bugzilla del progetto ed al file ChangeLog di questa versione.
La Porta di Dominio è stata adeguata a quanto previsto nel documento Sistema Pubblico di Cooperazione: Linee Guida all'uso della Busta eGov 1.1, che ha modificato significativamente le modalità di gestione della busta e-Gov da parte dalla Porta.
Il documento definisce un profilo d'uso per la gestione dell'header della busta e-Gov. Alcuni elementi sono stati deprecati, per altri è stato definito un sottoinsieme di valori validi e un contesto specifico di utilizzo. Le principali modifiche della busta e-Gov richieste dal documento e realizzate nella 1.1 sono elencate di seguito.
Busta SPCoop:
Mittente, il tipo del mittente deve essere SPC, l'indirizzo telematico è stato deprecato.
Destinatario, il tipo del destinatario deve essere SPC, l'indirizzo telematico è stato deprecato.
Profilo di Collaborazione, nei profili asincroni è stato deprecato l'utilizzo degli attributi servizioCorrelato e tipo.
Collaborazione, deve essere valorizzato solo nel caso di profili Asincroni con l'identificativo del messaggio contenente la richiesta (Identificazione a capostipite).
Servizio, il tipo del servizio deve essere SPC ed il nome deve essere valorizzato con il nome del port-type con cui viene specificato il servizio nell'accordo di servizio (WSDL).
Azione, la sua presenza è obbligatoria e il nome deve essere valorizzato con il nome della operation all'interno del port type con cui nell'accordo di servizio viene specificata l'azione invocata (WSDL).
Profilo Trasmissione con filtro duplicati, il filtro duplicati è obbligatoriamente abilitato per ogni richiesta di servizio, quindi l'attributo inoltro dell'elemento ProfiloTrasmissione deve assumere il valore EGOV_IT_ALPIUUNAVOLTA.
Profilo Trasmissione con confermaRicezione e Riscontri, la gestione dei riscontri è stata deprecata, quindi l'attributo confermaRicezione dell'elemento ProfiloTrasmissione deve assumere il valore false.
Sequenza, la consegna in ordine è stata deprecata.
Busta SPCoop Errore:
Rilevanza, la tipologia di eccezione di rilevanza LIEVE non deve essere prevista. L'attributo rilevanza dell'elemento Eccezione deve assumere solo uno dei due valori INFO o GRAVE. Se la porta riceve una busta che contiene solo eccezioni di rilevanza INFO, deve essere emesso solamente un messaggio diagnostico che segnali le loro presenze nella busta; la busta deve essere normalmente processata, sbustata e inoltrata al servizio applicativo. Solo in presenza di eccezioni di rilevanza GRAVE, la porta non inoltra il messaggio al servizio applicativo.
Posizione, l'attributo posizione dell'elemento Eccezione deve indicare l'elemento o attributo della busta che ha generato l'errore (xpath like).
Elementi deprecati, eventuali elementi deprecati presenti nella busta, devono essere segnalati al mittente con eccezioni di livello INFO.
L'aderenza al nuovo profilo d'uso è richiesta per la qualificazione delle Porte di Dominio. Resta comunque possibile fruire ed erogare servizi SPCoop aderenti alle specifiche originali della busta e-Gov, come descritte nel documento Sistema Pubblico di Cooperazione: Busta e-Gov 1.1. Questo sia per poter gestire la backward compatibility verso i servizi preesistenti sia per poter utilizzare, laddove necessario, i servizi a valore aggiunto previsti dalla specifica SPCoop, quali consegna affidabile, consegna in ordine, conversazioni, deprecati nelle nuove linee guida.
Per assicurare la massima flessibilità la Porta di Dominio 1.1 permette di configurare il tipo di profilo utilizzato, usando il parametro bustaEGov1.1 per indirizzare il profilo di busta e-Gov 1.1 completa, e lineeGuida1.1 per indirizzare il profilo corrispondente alle nuove linee guida. La configurazione può avvenire sia a livello complessivo del Soggetto SPCoop, in modo da indirizzare tutti i servizi di quel soggetto, sia per i singoli servizi fruiti e/o erogati dalla PdD.
Nella sezione Sezione 5.1.8, «Soggetto SPCoop» viene descritta la sintassi xml da utilizzare per impostare il profilo di gestione al livello del Soggetto. Le sezioni Sezione 5.1.9, «Servizio» e Sezione 5.1.12, «Fruitore» descrivono invece la sintassi xml da utilizzare per impostare il profilo di gestione nell'elemento xml servizio o fruitore (profilo).
L'interfaccia grafica del Registro dei Servizi (Sezione 5.2, «I Registri DB/WEB/UDDI e l'Interfaccia Web di Gestione del Registro») è stata adeguata alle nuove linee guida e per default definisce quindi Soggetti e Servizi in accordo al profilo lineeGuida1.1. È possibile comunque agire sulla configurazione dell'applicazione di gestione per passare ad una modalità estesa di gestione, che permette di modificare il profilo d'uso di soggetti e servizi, indirizzando quindi anche le funzionalità del profilo bustaEGov1.1.
Il Registro Servizi xml e la maggior parte degli esempi che vengono esposti in questa Guida continuano invece ad usare per default il profilo e-Gov 1.1 completo, in parte per motivi storici ma anche perché illustrano alcune funzionalità deprecate nelle linee guida (come Riscontri, Consegna in ordine,...). La sezione Sezione 9.2.12, «Profilo di gestione della busta e-Gov» illustra degli esempi di configurazione di servizi istanziati sul profilo di gestione aderente alle nuove linee guida.
Nella versione 1.0 di OpenSPCoop un Accordo di Servizio può corrispondere ad un unico PortType del WSDL del Servizio. Questo limite è stato superato nella versione 1.1, introducendo la gestione esplicita dei PortType all'interno dell'Accordo. La creazione di un nuovo erogatore fa quindi ora riferimento non solo all'Accordo di Servizio, ma anche al PortType dell'Accordo implementato da quel Servizio. La vecchia modalità è stata comunque mantenuta per motivi di backward compatibility.
Nelle sezioni Sezione 5.1.4, «Port-Type» e Sezione 5.1.5, «Azione (Operation) di un Port Type» viene descritta la nuova sintassi xml da utilizzare per la registrazione dei PortType all'interno di un accordo di servizio.
Gli esempi riportati in questa guida continuano ad usare la vecchia modalità di definizione dell'Accordo di Servizio per motivi storici. La sezione Sezione 9.2.11, «Accordo di Servizio, Port-Types e operations» contiene invece un esempio di configurazione di un Accordo di Servizio che contiene diversi port type.
Nella versione 1.1 di OpenSPCoop è stato introdotto il supporto per la verifica che il soggetto mittente di una busta eGov sia effettivamente afferente alla PdD che sta effettuando la trasmissione della busta. Per supportare questa funzionalità è stata introdotta la gestione delle PdD nel registro dei Servizi di OpenSPCoop e un'implementazione di default del sistema di autorizzazione delle buste in ingresso nella Porta di Dominio.
Nelle sezioni Sezione 5.1.7, «Porta di Dominio» e Sezione 5.1.8, «Soggetto SPCoop» viene descritta la nuova sintassi xml da utilizzare per la registrazione delle porte di dominio e per l'associazione della porta ad un soggetto.
La sezione Sezione 7.5, «Autorizzazione buste eGov in ingresso» documenta le implementazioni degli algoritmi di autorizzazione utilizzabili nella Porta di Dominio OpenSPCoop, mentre nella sezione Sezione 9.5.5, «Autorizzazione delle buste eGov in ingresso» è mostrato un esempio d'uso di questa funzionalità.
La PdD OpenSPCoop include già nella versione 1.0 funzioni di validazione dei contenuti applicativi dei messaggi SPCoop. Nella versione 1.1 tale funzionalità è stata drasticamente migliorata.
In particolare, il processo di validazione non utilizza più solamente il wsdl definitorio ma l'intero set di documenti wsdl. In tal modo è possibile realizzare una validazione più accurata del messaggio applicativo basata sul wsdl logico/implementativo che dovrà in tal caso essere presente nel registro dei servizi. Questo tipo di validazione assume che la cooperazione SPCoop avvenga in accordo alle linee guida del CNIPA, che prevedono che il nome del servizio SPCoop coincida con il nome del port type del WSDL e che l'azione coincida con il nome dell'operation. La validazione controlla che il messaggio applicativo, oltre a superare la validazione xsd, coincida proprio con quanto previsto nei wsdl per la richiesta (message-input) o la risposta (message-output) di una determinata operation (azione).
La modalità di validazione è stata resa configurabile a livello di porta delegata, applicativa e di configurazione generale (default). La sezione Sezione 4.1.14, «Validazione Contenuti Applicativi» descrive la nuova sintassi xml, mentre la sezione Sezione 9.3.12, «Validazione dei contenuti applicativi delle richieste di servizio e delle buste eGov» fornisce alcuni esempi di validazione dei contenuti applicativi.
Le informazioni presenti nei wsdl (message-input,message-output,soapAction,style,use...), necessarie per la validazione dei contenuti applicativi, sono registrabili anche esplicitamente all'interno degli elementi che descrivono un accordo di servizio nel registro (vedi Sezione 5.1.4, «Port-Type», Sezione 5.1.5, «Azione (Operation) di un Port Type» e Sezione 5.1.6, «Message»). Queste informazioni sono utilizzabili per la validazione dei contenuti nel caso di mancata disponibilità di file WSDL corretti per il servizio. Nella sezione Sezione 9.3.12, «Validazione dei contenuti applicativi delle richieste di servizio e delle buste eGov» sono forniti alcuni esempi.
La versione 1.1 della PdP introduce sulle porte delegate e applicative un nuovo parametro (stateless) che permette di discriminare tra due diverse modalità di trasmissione per il profilo Oneway:
Asincrona (stateless=disabilitato), la Porta di Dominio prende in carico la richiesta da consegnare e sblocca subito il client.
Sincrona (stateless=abilitato), la risposta al client non viene restituita fino a che la porta di dominio non ha finito di gestire la richiesta.
Per la documentazione del nuovo parametro stateless vedi Sezione 4.1.2, «Porta Delegata» e Sezione 4.1.3, «Porta Applicativa»). La Sezione 9.3.14, «Modalità di trasmissione per un profilo oneway» fornisce degli esempi relativi alla modalità di trasmissione del profilo oneway.
Nella versione 1.0 della Porta di Dominio, un profilo asincrono asimmetrico deve essere configurato nel registro obbligatoriamente tramite due servizi SPCoop, di cui uno correlato. I due servizi SPCoop, essendo erogati dallo stesso soggetto, devono necessariamente utilizzare due nomi diversi. Questo vincolo diventa un limite quando è necessario mappare un servizio asincrono asimmetrico la cui definizione WSDL è formata da un unico port type e operation differenti per la richiesta e la richiesta-stato.
Nella versione 1.1 è stata introdotta la possibilità di mappare correttamente nell'accordo di servizio un servizio asincrono asimmetrico la cui definizione WSDL è formata da un unico port type e azioni (operation) differenti per la richiesta e la richiesta-stato. In questo modo è possibile utilizzare un'unico servizio, realizzando la correlazione tramite le due azioni. Nelle sezioni Sezione 5.1.3, «Azione di un accordo di Servizio» e Sezione 5.1.5, «Azione (Operation) di un Port Type» viene descritta la nuova sintassi xml da utilizzare per correlare l'azione di richiesta stato all'azione di richiesta asincrona (attributo correlata).
La sezione Sezione 9.2.7.5, «Profilo di Collaborazione Asincrono Asimmetrico con azioni di uno stesso servizio» fornisce un esempio di profilo asincrono asimmetrico, dove sia l'azione di richiesta che l'azione di richiesta stato appartengono allo stesso servizio SPCoop.
Nella versione 1.1 sono state realizzate numerose ottimizzazioni nella gestione dele richieste oneway e sincrone, finalizzate principalmente a limitare l'eccessivo uso del database della versione 1.0. La principale ottimizzazione è stata introdotta tramite l'uso del parametro stateless sulle porte delegate e applicative (vedi sezioni Sezione 4.1.2, «Porta Delegata» e Sezione 4.1.3, «Porta Applicativa»), o agendo sulla configurazione globale della PdD (vedi Configurazione Avanzata della Guida Utente).
