Metodologie e Tecniche per la Cooperazione Applicativa

Transcript

Università di Roma “Tor Vergata”
Facoltà di Ingegneria
Laurea in Ingegneria Informatica
Metodologie e Tecniche
per la Cooperazione Applicativa nella
Pubblica Amministrazione italiana:
progettazione e sviluppo di una Porta di
Dominio
Relatore: Prof. G.F. Italiano
Correlatore: Dr. S. Fuligni
Correlatore: Ing. S. Armenia
Candidato: Vittorio Ottaviani
Tesi di Laurea
Ingegneria Informatica Università di Roma ”Tor Vergata”
Indice
Vittorio Ottaviani
_______________________________________________________________________
Copyright© Tutti i diritti sono riservati all'autore, all'Università di Roma "Tor Vergata"
ed al CNIPA" come da legge sul Diritto d'Autore n.518 del 1992 e successive
modifiche
Autore: Vittorio Ottaviani
Mail: [email protected]
Titolo: Metodologie e Tecniche per la Cooperazione Applicativa nella Pubblica
Amministrazione italiana: progettazione e sviluppo di una Porta di Dominio
Roma, 23 Febbraio 2007
1
Tesi di Laurea
Indice
Vittorio Ottaviani
_______________________________________________________________________
Indice
1.
Introduzione ............................................................................................................. 4
2.
L’interoperabilità fra sistemi informatici................................................................. 6
3.
4.
2.1
Architetture orientate ai servizi........................................................................ 7
2.2
Il modello a “Web Services”.......................................................................... 10
2.3
La cooperazione applicativa: approcci ed esperienze.................................... 13
SPC: il Sistema Pubblico di Connettività e Cooperazione .................................... 16
3.1
Il Sistema Pubblico di Connettività ............................................................... 17
3.2
Il Sistema Pubblico di Cooperazione (SPCoop) ............................................ 21
3.3
Modello e architettura del SPCoop ................................................................ 29
3.4
L’Accordo di Servizio.................................................................................... 39
3.5
La Busta e-Gov .............................................................................................. 43
3.6
La Porta di Dominio....................................................................................... 49
3.7
SICA: i servizi infrastrutturali per la cooperazione applicativa..................... 53
Sviluppo di una Porta di Dominio ......................................................................... 59
4.1
Progettazione di una “proof of concept” di Porta di Dominio....................... 59
4.2
Fasi della progettazione ................................................................................. 65
4.2.1
Definizione degli Attori ......................................................................... 66
4.2.2
Casi d’Uso.............................................................................................. 66
4.2.3
Sequence Diagrams................................................................................ 73
4.2.4
Architettura modulare ............................................................................ 92
4.2.4.1
Acquisizione ...................................................................................... 95
4.2.4.2
Inoltro................................................................................................. 96
2
Tesi di Laurea
Indice
Vittorio Ottaviani
_______________________________________________________________________
4.2.4.3
Ricezione............................................................................................ 99
4.2.4.4
Smistamento..................................................................................... 101
4.2.4.5
Smistamento degli Errori ................................................................. 102
4.2.4.6
Gestione eccezioni ........................................................................... 103
4.2.4.7
Gestione dei SOAP:FAULT ............................................................ 105
4.2.4.8
Gestione dei log ............................................................................... 106
4.2.4.9
Gestione dei messaggi diagnostici ................................................... 106
4.2.4.10 Funzionalità aggiuntive.................................................................... 107
4.2.5
4.2.5.1
Tomcat ............................................................................................. 112
4.2.5.2
AXIS ................................................................................................ 112
4.2.5.3
JAXB................................................................................................ 114
4.2.6
4.3
Realizzazione della libreria Busta di e-Gov......................................... 116
Profili di comunicazione e collaborazione................................................... 130
4.3.1
Messaggio singolo ............................................................................... 130
4.3.2
Comunicazione sincrona...................................................................... 137
4.3.3
Comunicazione asincrona .................................................................... 145
4.4
5
Strumenti utilizzati............................................................................... 110
Problemi e soluzioni .................................................................................... 149
Conclusioni e sviluppi futuri................................................................................ 154
5.1
Conclusioni .................................................................................................. 154
5.2
Sviluppi futuri .............................................................................................. 155
5.3
Community di Sviluppo............................................................................... 158
Bibliografia .................................................................................................................. 163
Indice analitico delle figure ......................................................................................... 172
Glossario ...................................................................................................................... 174
3
Tesi di Laurea
Introduzione
Vittorio Ottaviani
_______________________________________________________________________
1. Introduzione
Il presente lavoro è il primo nato dalla collaborazione tra il CNIPA e la facoltà di
Ingegneria dell’Università di Roma “Tor Vergata” sui temi dell’interoperabilità e
dell’integrazione dei sistemi informatici ed in particolare sull’evoluzione del Sistema
Pubblico di Cooperazione (SPCoop), il framework per l’interoperabilità dei servizi
telematici delle amministrazioni pubbliche italiane.
Questa tesi si pone l’obiettivo di analizzare gli aspetti peculiari relativi alla
progettazione ed implementazione di una cosiddetta “proof of concept” di una Porta di
Dominio (cfr. §3.5), cioè l’implementazione di un prototipo concettuale per la verifica
della validità delle caratteristiche fondamentali di uno degli elementi architetturali
principali del SPCoop.
Un ulteriore obbiettivo è quello di proporre un modello sostenibile per la nascita ed il
governo di una community “Open Source” con l’obiettivo di sviluppare una
implementazione di riferimento a codice aperto di una Porta di Dominio.
Nel prossimo capitolo verrà condotta preliminarmente una panoramica sulle
Architetture Orientate ai Servizi (SOA) (cfr. §2.1), a cui seguirà un’analisi della
tecnologia dei Web Services (cfr. §2.2), potenzialmente adatta all’implementazione del
modello architetturale SOA.
Verrà inoltre trattato il tema dell’interoperabilità dei sistemi informatici (cfr. §2.3), con
un’analisi sintetica di quanto accade nel mercato ICT, sia in Europa che nel nostro
paese.
Nel terzo capitolo verrà introdotto con maggiore dettaglio il concetto di cooperazione
applicativa e come stato sviluppato nella Pubblica Amministrazione italiana; ciò verrà
4
Tesi di Laurea
Introduzione
Vittorio Ottaviani
_______________________________________________________________________
fatto accennando al Sistema Pubblico di Connettività (cfr. §3.1) nonché descrivendo il
Sistema Pubblico di Cooperazione (SPCoop) (cfr. §3.2) e gli elementi che lo
caratterizzano: la Busta di e-Gov (cfr. §3.4), la Porta Di Dominio (cfr. §3.5), l’Accordo
di Servizio (cfr. §3.6) ed i Servizi di Interoperabilità, Cooperazione ed Accesso (SICA,
cfr. §3.7). Verranno, inoltre, analizzate le modalità in cui questi elementi
contribuiscono al conseguimento dell’interoperabilità e della cooperazione applicativa
tra le amministrazioni;ciò sarà illustrato nella sezione che descrive l’architettura del
Sistema Pubblico di Cooperazione (cfr. §3.3)
Nel quarto capitolo saranno descritte le attività di progettazione ed implementazione
della “proof of concept” di una Porta Di Dominio, descrivendo gli strumenti utilizzati,
le scelte progettuali ed il processo di realizzazione, i problemi incontrati e le soluzioni
adottate nonché i perfezionamenti apportati al codice in seguito alla prima stesura.
Nel quinto capitolo verranno, quindi, proposte le conclusioni tratte da questa
esperienza, le linee suggerite per sviluppi futuri ed un possibile modello per lo sviluppo
di una community open-source sui temi affronati, motivando le scelte effettuate e
descrivendo un modello di gestione compatibile con gli obiettivi del SPCoop.
5
Tesi di Laurea
L’interoperabilità fra sistemi informatici
Vittorio Ottaviani
_______________________________________________________________________
2. L’interoperabilità fra sistemi informatici
Nell’ambito dell’ICT (Information & Communications Technologies), l’interoperabilità
è definibile come la capacità dei sistemi informatici di cooperare, erogando e fruendo
servizi, con altri sistemi ed usare i servizi scambiati per effettuare operazioni più
complesse di quelle possibili agli stessi sistemi in un ambiente non cooperativo; questo
vantaggio nasce dalla disponibilità di risorse, quali dati, servizi, risorse di calcolo o
altre risorse, che in ambito non cooperativo non sarebbero disponibili.
A livello software per interoperability si intende la capacità di differenti programmi o
sistemi informatici di scambiare dati tramite gli stessi protocolli o le stesse procedure o
leggere e scrivere files dello stesso formato.
Spesso il software realizzato senza una progettazione che tenga in considerazione la
standardizzazione delle procedure effettuate dal prodotto è un software che manca di
interoperabilità.
Ci sono diverse modalità per garantire l’interoperabilità dei sistemi informatici, una di
queste è utilizzare modelli architetturali di tipo orientato ai servizi; questo modello
architetturale permette a sistemi eterogenei di interoperare utilizzando procedure e
standard comuni.
Nel seguito di questo capitolo (cfr. §2.1) verrà trattato il tema delle Service Oriented
Architecture (SOA); verrà poi esaminata la tecnologia dei Web Services, una tecnologia
che permette di sviluppare una SOA (cfr. §2.2).
6
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
2.1
Architetture orientate ai servizi
Con Service-Oriented Architecture si identifica un modello architetturale che supporta
l’uso di servizi che soddisfano le richieste degli utenti, rendendo possibile l’utilizzo
delle singole applicazioni come componenti dei processi applicativi.
Quindi, utilizzando modelli architetturali di tipo Service Oriented, si possono
modificare, in modo abbastanza semplice, sia le modalità secondo le quali
interagiscono i servizi, sia le combinazioni dei servizi stessi che vengono fruiti per
realizzare un processo; allo stesso modo risultano semplificate le operazioni di aggiunta
di servizi e la modifica di processi per rispondere alle specifiche esigenze di business: il
servizio non è più vincolato ad una specifica piattaforma o ad un'applicazione ma può
essere considerato come un componente riutilizzabile nell’ambito di processi di
business differenti.
Il modello architetturale Orientato ai Servizi si applica preferibilmente ai sistemi che si
mostrano particolarmente complessi sia nei processi che nelle applicazioni; questo
deriva dal fatto che le interazioni tra diverse realtà vengono facilitate, permettendo allo
stesso momento che le attività applicative sviluppino processi efficienti, sia all’interno
che all’esterno dei sistemi stessi, aumentandone l'adattabilità e la flessibilità.
Le Service Oriented Architecture non sono legate ad una tecnologia in particolare;
esempi delle tecnologie con le quali si possono realizzare delle SOA sono: REST, RPC,
DCOM, CORBA o i Web Services.
L’implementazione di una SOA, infatti,
può avvenire anche in assenza di questi
protocolli; una tecnica alternativa è l’uso del file system; questo si realizza attraverso il
trasferimento di dati secondo le specifiche dell'interfaccia tra i processi, in modo
conforme al concetto di SOA.
Il fulcro delle comunicazioni tra applicazioni è l'indipendenza tra i servizi che vengono
caraterizzati da un’interfaccia specifica e che, quando vengono invocati, eseguono le
7
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
proprie operazioni in maniera standard; ciò avviene mantenendo l’applicazione
chiamante all’oscuro di quale sia il servizio che effettivamente esegue l’operazione;
allo stesso modo il servizio non ha necessità di conoscere come sia realizzata
l’applicazione chiamante. La conoscenza reciproca è del tutto irrilevante visto che
erogatore e fruitore basano l’interazione sulle interfacce esposte.
Il modello architetturale SOA può essere considerato un buon metodo per implementare
architetture di sistemi informatici adatte alla creazione di applicazioni sviluppate,
combinando servizi debolmente accoppiati in modo da renderli interoperabili tra loro.
La cooperazione tra questi servizi è indipendente dalla piattaforma sottostante e dalle
tecnologie in cui sono sviluppati; importante è invece la definizione formale dei servizi
stessi.
Un esempio di ciò possono essere i servizi scritti in Java, usando la piattaforma Java EE
e quelli in C# con .NET; questi servizi possono essere utilizzati da una applicazione di
livello più alto, utilizzando le interfacce di queste applicazioni.
Le applicazioni in esecuzione su una piattaforma possono anche utilizzare servizi in
esecuzione su altre, come succede con i Web Services; questa caratteristica favorisce la
riusabilità di software già presente.
8
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Figura 11: Possibile architettura di una SOA (fonte: Wikipedia)
In Figura 1 sono mostrati i possibili elementi di una SOA; come si può vedere i servizi
sono solo una parte della struttura. Rimane il fatto che i servizi sono il cardine delle
SOA; in un servizio, non è importante come venga fatta la realizzazione delle
funzionalità stesse (Business Logic e Data); è invece fondamentale che laparte di
Contratto (Contract) e di Interfaccia (Interface) seguano le specifiche definite. Anche il
Service Repository è una parte fondamentale, è infatti su questo elemento che i servizi
della SOA vengono registrati per poi essere erogati, tramite l’Application front-end,
utilizzando il Service Bus, che può essere realizzato sia logicamente sia fisicamente.
Figura 1 è una possibile implementazione di una SOA, non è infatti obbligatorio che
l’architettura contenga tutti gli elementi mostrati nella figura; allo stesso modo è
possibile che altre implementazioniche contengano elementi non presenti in questa
immagine.
1
http://upload.wikimedia.org/wikipedia/commons/d/d4/SOA_Elements.png
9
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Questo tipo di architettura è adeguato per una realtà complessa ed eterogenea, in
termini informatici, come la Pubblica Amministrazione; per questo motivo tale modello
viene ripreso sia dai progetti di interoperability in Europa che di cooperazione
applicativa in Italia, con l’obiettivo di sviluppare un framework per le Amministrazioni
Locali e Centrali mediante il quale rendere disponibili i servizi.
Utilizzando Architetture Orientate ai Servizi, infatti, la Pubblica Amministrazione che
vuole pubblicare un servizio è responsabile di erogarlo in maniera conforme ai
protocolli utilizzati nell’architettura ma è del tutto padrona del servizio fornito e dunque
può scegliere come erogarlo.
2.2
Il modello a “Web Services”
Una tecnologia applicabile per implementare una architettura orientata ai servizi (SOA)
è quella dei Web Services.
Il W3C definisce un Web Service (servizio web) come un sistema software progettato
per supportare l'interoperabilità tra diversi sistemi che cooperano su una stessa rete; una
delle caratteristiche fondamentali di un Web Service è quella di esporre un'interfaccia
software,
che
viene
descritta
secondo
formati
che
possano
essere
gestiti
automaticamente, ad esempio, il WSDL; utilizzando questa interfaccia i sistemi possono
fruire delle prestazioni erogate dal Web Service effettuando chiamate alle operazioni
descritte nell’interfaccia tramite messaggi ad-hoc che vengono scambiati utilizzando la
"busta" SOAP [46] [47]: tali messaggi sono, solitamente, trasportati tramite il protocollo
HTTP e formattati secondo lo standard XML.
È grazie al lavoro di standardizzazione in ambiente “open” (le specifiche dei protocolli
di comunicazione utilizzati dai WS sono tutte di libero accesso e condivise), che viene
10
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
fatto da enti come consorzio OASIS (Organization for the Advancement of Structured
Information Standards) ed il W3C (World Wide Web Consortium), che è possibile
l’interoperabilità di sistemi sviluppati in linguaggi differenti, come Java e Pyton, che
lavorano su differenti piattaforme, come Linux e Windows.
La pila protocollare dei Web Services è principalmente basata su:
•
SOAP: protocollo secondo il quale vengono scambiati i dati tra i sistemi che
partecipano ad una operazione di scambio di servizi utilizzando Web Services;
•
UDDI [48]: protocollo utilizzato per elencare i servizi in un registro centrale e
comune che permetta la ricerca; questo registro (registro UDDI) ha la
funzionalità di permettere il reperimento dei servizi in maniera veloce;
•
WSDL2: linguaggio descrittivo basato su XML utilizzato per descrivere
l’interfaccia dei Web Services.
•
WS-Security [49]: protocollo che permette l'autenticazione degli utenti e la
confidenzialità dei messaggi scambiati con l'interfaccia del Web Service.
•
WS-Reliability [50]: specifiche basate su SOAP che soddisfano la richiesta di
messaggi affidabili, richiesta critica per alcune delle applicazioni che utilizzano i
Web Service come transazioni monetarie.
2
WSDL (acronimo di Web Services Description Language) è un linguaggio formale in formato XML
utilizzato per la creazione di "documenti" per la descrizione di Web Service. Mediante WSDL può
essere, infatti, descritta l'interfaccia pubblica di un Web Service ovvero creata una descrizione, basata su
XML, di come interagire con un determinato servizio: un "documento" WSDL contiene infatti,
relativamente al Web Service descritto, informazioni su:
• cosa può essere utilizzato (le "operazioni" messe a disposizione dal servizio);
• come utilizzarlo (il protocollo di comunicazione da utilizzare per accedere al servizio, il formato dei
messaggi accettati in input e restituiti in output dal servizio ed i dati correlati) ovvero i "vincoli"
(bindings in inglese) del servizio;
• dove utilizzare il servizio (cosiddetto endpoint del servizio che solitamente corrisponde all'indirizzo in formato URI - che rende disponibile il Web Service).
Le operazioni supportate dal Web Service ed i messaggi che è possibile scambiare con lo stesso sono
descritti in maniera astratta e quindi collegati ad uno specifico protocollo di rete e ad uno specifico
formato. Il WSDL è solitamente utilizzato in combinazione con SOAP e XML Schema per rendere
disponibili Web Services su reti aziendali o su internet: un programma client può, infatti, "leggere" il
documento WSDL relativo ad un Web Service per determinare quali siano le funzioni messe a
disposizione sul server e quindi utilizzare il protocollo SOAP per utilizzare una o più delle funzioni
elencate dal WSDL. La versione 1.1 di WSDL non è stata adottata come standard dal World Wide Web
Consortium (W3C), ma l'11 maggio 2005 è stata rilasciata la "bozza" della versione 2.0 che sarà invece
adottata come standard ufficiale (in forma di "raccomandazione") dal W3C [45].
11
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Semplicemente facendo riferimento alle interfacce esposte, ed utilizzando le funzioni
che sono in grado di effettuare i servizi, sistemi sviluppati in maniera differente e con
differenti scopi possono cooperare e scambiarsi informazioni.
I Web Services sono applicabili sia la caso di piccole reti locali che al caso più generale
ed eterogeneo che può essere internet.
La funzionalità più innovativa dei Web Services e più in generale delle SOA è la
possibilità di creare sistemi che cooperino in maniera completamente disaccoppiata;
infatti, l’interfaccia standard esposta dal Web Service rende possibile al sistema utente
di fruire i servizi senza conoscere le procedure che vengono svolte nel lato del sistema
erogatore.
Altra caratteristica innovativa dei Web Services è quella di permettere di modificare le
applicazioni che erogano i servizi in maniera del tutto "trasparente" all'interfaccia
esposta; questo significa che mantenendo stabile l’interfaccia, il programma, o più in
generale il sistema erogatore, può cambiare senza creare problemi all’interoperabilità tra
i sistemi che cooperano.
La flessibilità data dalla possibilità di disaccoppiare il Web Service dalla logica
applicativa che effettivamente fornisce la prestazione consente la creazione di sistemi
software complessi costituiti da componenti svincolati l'uno dall'altro ed una forte
riusabilità di codice ed applicazioni già sviluppate.
L’interazione fra i Web Services avviene sulla base del paradigma find-bind-execute.
12
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Figura 2: Paradigma Find-Bind-Execute
In Figura 2 è mostrato uno schema di come funzioni questo paradigma articolato in tre
fasi:
1.
find: dove il servizio viene ricercato sui sistemi di registro, tipicamente i registri
UDDI nel caso dei Web Services;
2.
bind: dove il client si collega al sistema server del servizio che vuole eseguire;
3.
execute: dove il client accede al Web Service eseguendo le procedure fornite dal
sistema server.
2.3
La cooperazione applicativa: approcci ed esperienze
Numerose iniziative sono state avviate nei paese dell’Unione Europea in tema di
interoperability: l’Inghilterra, per esempio, sta sviluppando e-GIF (e-Government
Interoperability Framework), un framewok per l’interoperabilità tra le amministrazioni
pubbliche tramite l’uso di Servizi Web; la Germania sta implementando il sistema
13
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
SAGA (Standards und Architekturen für E-Government); sistema modellato con
un’architettura del tipo SOA riportata nella prossima figura.
Figura 3: Architettura del Sistema SAGA [21]
Anche paesi relativamente meno sviluppati sono attivi in questo settore e stanno
presentando i propri modelli di interoperability: l’Ungheria ne è un esempio; il suo
sistema di interoperability prende il nome di MEKIK (Hungarian Electronic Public
Administration Interoperability Framework) ed è un adattamento del sistema di tedesco
alla realtà ungherese.
Un progetto di rilevanza europea è IDABC (Interoperable Delivery of Pan-European eGovernment Services to Public Administrations, Business and Citizens), nato con
l’obiettivo di definire un modello per l’interoperabilità transnazionale fra i Paesi membri
dell’UE.
Maggiore dettagli su IDABC sono riportati in Appendice1.
14
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Nel nostro paese il modello per l’interoperabilità fra i sistemi informatici della PA è
definito dal SPCoop (Sistema Pubblico di Cooperazione), parte del progetto SPC
(Sistema Pubblico di Connettività e Cooperazione), istituito dal Governo con il D.lvo n.
42 del 28 febbraio 2005 [1] poi confluito nel CAD [2] e sviluppato dal CNIPA.
Il Sistema Pubblico di Cooperazione si caratterizza per l’approccio a 360 gradi che ha
riguardato sia gli aspetti normativi che tecnici ed organizzativi, curando particolarmente
la condivisione del metodo e dei risultati fra tutti gli interlocutori coinvolti,
amministrazioni centrali e locali ed operatori del settore ICT.
15
Tesi di Laurea
SPC: il Sistema Pubblico di Connettività e Cooperazione
Vittorio Ottaviani
_______________________________________________________________________
3. SPC:
il
Sistema
Pubblico
di
Connettività
e
Cooperazione
Le amministrazioni pubbliche italiane interagiranno in rete attraverso il Sistema
Pubblico di Connettività e Cooperazione, costituito da due livelli di servizi
infrastrutturali:
•
il Sistema Pubblico di Connettività, che ha come obbiettivo quello di fornire una
infrastruttura di rete affidabile e sicura (cfr §3.1);
•
il Sistema Pubblico di Cooperazione, il cui scopo è quello di fornire un
framework per l’iteroperabilità fra servizi applicativi (cfr. §3.2).
Nella prossima figura (Figura 4) viene mostrata l’architettura del Sistema Pubblico di
Connettività e Cooperazione; si può vedere come il SPCoop si appoggi sui servizi offerti
dallo strato di Connettività.
S
P
C
Amministrazioni pubbliche
Servizi
applicativi
SP Cooperazione
Messaggi
SP Connettività
Pacchetti
Figura 4: Pila SPC
16
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
3.1
Il Sistema Pubblico di Connettività
“La legge n. 59 del 15 marzo 1997 ha provveduto a colmare la lacuna di un’unica rete,
omogenea per qualità sicurezza e costi che aveva caratterizzato le Pubbliche
Amministrazioni fino agli anni novanta; infatti, precedentemente a questa norma, non
esisteva un organismo che operasse armonicamente nel contesto delle comunicazioni ma
si era proceduto individualmente sulla base delle differenti esigenze che si erano
presentate nel corso degli anni, dando vita ad una pluralità di reti dati non dialoganti tra
loro.
Questa rete unitaria ha rappresentato per le Amministrazioni Centrali la piattaforma di
sviluppo delle applicazioni. Le precedenti reti delle Amministrazioni, realizzate con
CDN e accessi X.25, si sono evolute in reti IP favorendo l’utilizzo della posta
elettronica e del web.
Attualmente si sta convertendo in un sistema più moderno, denominato Sistema
Pubblico di Connettività, la Rete unitaria della Pubblica Amministrazione (RUPA) che
collegava la quasi totalità delle sedi delle Pubbliche Amministrazioni centrali. Tale
sistema utilizza tecnologie e protocolli attuali.
I principali obiettivi del Sistema Pubblico di Connettività sono:
•
fornire un insieme di servizi di connettività condivisi dagli Enti interconnessi,
definiti negli aspetti di omogeneità, qualità e sicurezza, ampiamente graduabili
in maniera tale da poter essere ritagliati al meglio sulle esigenze delle diverse
amministrazioni.
•
Garantire inoltre l’interazione della pubblica amministrazione centrale e locale
con tutti gli altri soggetti connessi ad Internet, nonché con le reti di altri Enti
che debbano interagire con la P.A., facilitando l’erogazione di servizi di qualità
17
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
e la fruibilità degli stessi da parte dei cittadini e delle imprese. Tale operazione
non potrà prescindere, in fase di qualificazione anche da requisiti circa la
connettività degli ISP verso i NAP commerciali. Questi ultimi non dovranno
costituire un collo di bottiglia per la fruizione dei servizi esposti dalle
Amministrazioni da parte dei cittadini.
•
Fornire
un’infrastruttura
condivisa
di
interscambio
che
consenta
l’interoperabilità tra tutte le reti delle Pubbliche Amministrazioni oggi esistenti,
favorendone lo sviluppo omogeneo su tutto il territorio, salvaguardando gli
investimenti effettuati.
•
Fornire, alle Amministrazioni che ne faranno richiesta, servizi telematici
(connettività e applicazioni) per permettere l’interconnessione delle proprie sedi
e realizzare così anche l’infrastruttura interna di comunicazione (dominio
dell’Amministrazione).
•
Realizzare un modello di provisioning dei servizi multifornitore coerente con
l’attuale situazione di mercato e le dimensioni del progetto stesso.
•
Realizzare un sistema che, ancorché si basi sull’utilizzo dei paradigmi tipici di
Internet, permetta la definizione di flussi di traffico con caratteristiche di
disponibilità e prestazioni garantite tra soggetti serviti da operatori qualificati
diversi.
•
Garantire, tramite il mantenimento di un sistema di raccolta dei dati di
prestazioni e disponibilità, uno strumento di valutazione indipendente della
qualità dei servizi offerti dai provider qualificati
•
Implementare opportune misure di sicurezza atte a garantire una adeguata
continuità dei propri servizi, in quanto l’indisponibilità degli stessi potrebbe
causare disservizi anche di grande impatto sui processi G2G e quindi sui servizi
erogati ai cittadini.3
3
Sistema Pubblico di Connettività: scenario introduttivo, emesso dal Gruppo di Lavoro SPC, p. 9
18
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Poiché il Sistema Pubblico di Connettività costituisce l’ossatura di rete del sistema di
interconnessione italiana il suo sviluppo risulta prioritario rispetto a quello rispetto a
quello dei servizi tra i soggetti interoperanti.
Il Sistema Pubblico di Connettività permette di attivare lo scambio di servizi fra
soggetti pubblici in una logica Government to Government (G2G), mentre la
contemporanea interconnessione ad Internet garantisce la fruibilità dei servizi stessi da
parte dei cittadini e delle imprese in una logica di Government to Citizen (G2C).
La possibilità di sviluppare servizi fra le diverse Pubbliche Amministrazioni, in una
logica di G2G, permette di ottenere maggior efficienza nei procedimenti
interamministrazioni e di raggiungere l’obiettivo di presentare le diverse pubbliche
amministrazioni al cittadino e all’impresa, in modo unitario. In tale ottica questo
strumento potrà permettere un’erogazione di servizi secondo modalità diverse di
integrazione, che realizzano una maggiore sinergia, utilizzando diversi strumenti di
accesso tra i quali i Portali nazionali e locali della Pubblica Amministrazione.
Il Sistema Pubblico di Connettività
è da intendersi quindi anche come una
infrastruttura abilitante per lo sviluppo di applicazioni cooperative fra PA Centrali, fra
PA Locali, fra PA Centrali e Locali, fra PA e Imprese/Cittadini.
In Figura 5 si può vedere schematizzata l’architettura della Qualified eXchange
Network del Sistema Pubblico di Connettività.
19
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Figura 54: Esempio di una QXN del Sistema Pubblico di Connetività
Per soddisfare alcuni degli obiettivi del Sistema Pubblico di Connettività il QXN dovrà
poter supportare diverse tipologie di traffico tra le PA e, in particolare, anche il traffico
tra i cittadini e le PA afferenti ai diversi ISP qualificati.
Sarà possibile lo scambio sicuro di dati internamente e tra le Amministrazioni,
utilizzando sistemi crittografici per realizzare reti private virtuali (VPN); le VPN
verranno utilizzate solo in caso di necessità, e comunque la scelta sull’utilizzo resta
prerogativa delle singole Amministrazioni.
Per quanto riguarda le infrastrutture, l’obiettivo condiviso dalle reti regionali è quello di
portare a sistema nell’ambito di strategie di livello provinciale e regionale tutte le
opportunità presenti nei territori, lasciando alle singole Amministrazioni la libertà di
stipulare contratti diversi a seconda delle opportunità che possono trovare sui propri
4
Sistema Pubblico di Connettività: scenario introduttivo, emesso dal Gruppo di Lavoro SPC, p. 11
20
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
territori, con la priorità di garantire l’uniformità di adeguati livelli di servizio e modalità
di interconnessione indipendentemente dalla densità di popolazione.
L’altra parte del SPC è il progetto SPCoop (Sistema Pubblico di Cooperazione);
progetto che si occupa di curare lo sviluppo della cooperazione applicativa.
Il CNIPA, con i rappresentanti di Amministrazioni centrali e locali, e delle
Associazioni dei fornitori, ha redatto un insieme di documenti che delineano un quadro
tecnico-implementativo del sistema.” 5
3.2
Il Sistema Pubblico di Cooperazione (SPCoop)
Negli ultimi anni l’Italia sta operando verso un decentramento amministrativo delle
competenze secondo le nuove forme di federalismo con più efficienti modelli di
Pubblica Amministrazione che hanno come riferimento il sistema delle regioni e delle
autonomie locali e da questa tendenza emerge il problema di come organizzare la
cooperazione tra le amministrazioni che devono condividere le risorse ed i servizi.
Ciò è tanto più pressante alla luce del dettato della legge 241/90 – art. 14 e 18 (concetto ripreso anche negli art. 5 e 7 del D.Lgs. SPC 42/2005), secondo cui, la PA ha
il dovere di farsi carico (attraverso la conferenza dei servizi telematici, la
riorganizzazione
dei
processi
e
l’integrazione
telematica
dei
back-office)
dell’integrazione dei procedimenti delle diverse amministrazioni interessate al processo
interamministrativo che riguarda una qualsiasi istanza di un cittadino o un’impresa.
Si realizza così un servizio caratterizzato come “multi-ente”, che nasce della
cooperazione delle varie Amministrazioni le quali concorrono, ognuna per la sua parte
di competenza nell’ambito del processo, a comporre il procedimento che porta
all’erogazione del servizio richiesto dall’utente finale.
5
rielaborazione delle parti ritenute interessanti del documento Sistema Pubblico di Connettività: scenario
introduttivo, emesso dal Gruppo di Lavoro SPC [4].
21
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
La progettazione e lo sviluppo del Sistema Pubblico di Cooperazione in CNIPA
prendono il nome di SPCoop.
SPCoop è un progetto che fa parte dell’area d’interesse del progetto SPC.
Un’infrastruttura così complessa ed articolata può mantenere ed accrescere nel tempo il
consenso solo se da un lato viene supportato a livello organizzativo e politico e
dall’altro viene mantenuto un approccio analitico in grado di coinvolgere il mercato ed
il mondo della ricerca.
Entrambi questi aspetti devono essere tenuti in considerazione. In tale direzione si
colloca la collaborazione con l’università di Roma “Tor Vergata” così come anche in
altri ambiti a livello regionale. Queste collaborazioni saranno utili al fine di mantenere
attiva l’attenzione sul tema della cooperazione applicativa ed a creare in tal modo una
connessione tra diversi soggetti del mondo della ricerca e delle amministrazioni al fine
sia di accrescere la sensibilità per quanto riguarda le applicazioni dei concetti relativi ai
sistemi distribuiti che per la creazione di comunità e grouppi di interesse su aluni dei
temi specifici.
Il Sistema Pubblico di Connettività e Cooperazione che si sta realizzando permetterà di
vedere tutti i servizi di ogni Amministrazione Pubblica sia centrale che locale in
maniera integrata ed indipendente dal canale di erogazione. Per questo è stato
necessario definire un modello comune di interazione on-line tale da valorizzare la
specificità di ogni erogatore di servizi così che possa assicurare allo stesso tempo
uniformità di interazione e certezza nell’identificazione dell’erogatore e del fruitore, o
allo stesso modo degli attori dell’interazione.
Essendo già presenti a livello nazionale molteplici soluzioni architetturali per la
Cooperazione Applicativa è emersa la necessità di individuare una soluzione
infrastrutturale unica che da un lato tendesse a preservare l’autonomia delle scelte delle
amministrazioni e, dall’altro, consentisse ai diversi sistemi di interoperare fra loro per
erogare servizi integrati agli utenti.
22
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
L’obiettivo dell’architettura di cooperazione applicativa è quello di permettere
l’integrazione dei processi e dei dati di amministrazioni diverse basati su sistemi
informatici estremamente eterogenei. Per ottenere questo risultato, lo scambio di dati e
di servizi tra le amministrazioni deve avvenire tra entità di pari livello (amministrazioni
di grado e complessità organizzativa differenti sono paritetiche rispetto alla
cooperazione applicativa) attraverso la condivisione delle modalità di individuazione
dei dati di interesse e delle modalità di accesso ai servizi applicativi: un blackbone
condiviso per l’interazione fra servizi applicativi attraverso interfacce standard
pubbliche.
In sintesi, la cooperazione tra differenti Amministrazioni, ed in generale tra soggetti
pubblici, richiede la definizione di un modello di cooperazione che sia:
•
indipendente dagli assetti organizzativi dei soggetti cooperanti;
•
indipendente dai sistemi informatici interni dei soggetti cooperanti;
•
progettato in maniera rigorosa e sostenibile, tale che la sua evoluzione sul
medio termine sia già pensata sin dall’inizio, con passi ben delineati.6
I principi sui quali si basa il SPCoop sono i seguenti:
Cooperazione tra amministrazioni.
Per mezzo dell’erogazione e della fruizione di Servizi Applicativi le Amministrazioni
cooperano; ogni amministrazione offre questi servizi tramite un unico elemento del
proprio sistema informativo denominato Porta di Dominio. L’amministrazione gode di
completa autonomia grazie a questo principio, in fase di progettazione, realizzazione e
gestione dei Servizi Applicativi. Questo è possibile vista la caratteristica dei Servizi
Applicativi di potersi basare su qualsiasi piattaforma applicativa, preesistente o di
6
Sistema Pubblico di Cooperazione: quadro tecnico d’insieme, redatto dal Gruppo di Lavoro SPCoop in
CNIPA, p.8.
23
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
nuova acquisizione, purché vengano poi erogati attraverso la Porta di Dominio. I servizi
applicativi vengono fruiti attraverso lo scambio di messaggi applicativi, secondo il
formato definito nel documento di specifica della busta di e-Gov.
Ambito di responsabilità.
La responsabilità dei servizi erogati e dei dati forniti attraverso tali servizi è attribuita
alla singola Amministrazione cooperante, che apparirà come un singolo dominio con
responsabilità del singolo elemento e non del dominio stesso.
Accordi.
L’utilizzo di un servizio applicativo tra almeno due soggetti (erogatore e fruitore) deve
essere regolamentato da degli accordi che vengono stipulati a monte della cooperazione
tra i soggetti cooperanti. Questi accordi hanno basi sia sul piano normativo/istituzionale
che su quello tecnico e vanno formalizzati perché possano essere acceduti in maniera
(semi-)automatica così da supportare il ciclo di sviluppo e di esercizio dei servizi stessi.
La formalizzazione dell’accordo prende il nome di Accordo di Servizio ed è basata su
linguaggio XML.
Tecnologie di cooperazione.
I servizi applicativi vengono erogati/fruiti attraverso tecnologie e standard indicati
genericamente come Web Service, che rappresentano una soluzione in grado di
soddisfare i requisiti sopraindicati al problema dell’interoperabilità di sistemi
applicativi eterogenei; infatti grazie a queste tecnologie/standard, qualsiasi funzionalità,
indipendentemente dal tipo di piattaforma, diventa esportabile, in modo da essere
invocata remotamente.
Tali caratteristiche rendono SPCoop un modello con molte attinenze alle SOA descritte
precedentemente (cfr. §2.1); infatti, la necessità di disaccoppiamento tra applicazioni
eterogenee che attualmente vengono utilizzate nelle differenti Amministrazioni ed i
servizi erogati in rete, la necessità di avere una interfaccia che permetta di interagire ad
24
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
un livello superiore di quello della logica applicativa, unito alla necessità di rendere
utilizzabili i sistemi gia presenti nelle Amministrazioni Locali e Centrali, hanno portato
a vedere l’architettura del SPCoop come la declinazione di una SOA adattata alle
necessità della PA.
SPCoop è dunque caratterizzato dai seguenti elementi:
•
un protocollo di comunicazione;
•
una serie di linguaggi per descrivere le caratteristiche dei servizi definite in base
agli accordi di servizio (ad ese. interfacce, livelli di sicurezza e servizio, ecc.);
•
un sistema di registri per gli accordi di servizio;
•
un elemento capace di implementare il paradigma find-bind-execute.
Attualmente le tecnologie su cui si basano i Web Services presentano diversi livelli di
definizione e maturazione; mentre, infatti, su alcuni aspetti, indicati come aspetti di
base, gli standard e le tecnologie che implementano tali standard hanno un livello di
maturità sufficiente, su altri aspetti, definiti avanzati, si è ancora nella fase intermedia
tra il conseguimento dei risultati delle ricerche effettuate e l’utilizzo degli stessi per le
prime realizzazioni.
In particolare risultano ben definiti i seguenti aspetti di base:
•
protocolli applicativi per l’invocazione remota dei servizi: SOAP (Simple Object
Access Protocol);
•
linguaggi per la descrizione dell’interfaccia (intesa come insieme di operazioni)
offerta da un servizio: WSDL (Web Service Description Language);
•
architettura ed interfaccia di un sistema di registro con accesso prevalentemente
basato su identificatori univoci: UDDI (Universal Description, Discovery and
Invocation); mentre risultano non ancora sufficientemente sviluppati i seguenti
aspetti avanzati:
25
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
•
protocolli per l’invocazione remota con caratteristiche di affidabilità, auditing e
sicurezza point-to-point;
•
descrizione delle conversazioni supportate/ammesse dal servizio;
•
descrizione dei livelli di qualità del servizio;
•
descrizione dei requisiti e caratteristiche di sicurezza end-to-end del servizio;
•
descrizione della semantica del servizio e della semantica dell’informazione
veicolata dal servizio;
•
definizione dell’architettura e dell’interfaccia di un sistema di registro con
caratteristiche di accesso più flessibili, basate sugli aspetti avanzati
precedentemente menzionati.7
Ai fini della cooperazione applicativa gli aspetti di base non sono sufficienti, ma anche
gli aspetti avanzati risultano indispensabili; da ciò si evince che il modello ipotizzato
deve prevedere:
•
la caratterizzazione di alcuni aspetti avanzati attraverso la definizione di
standard a livello nazionale, da sviluppare nel tempo e/o far convergere verso
standard internazionali equivalenti quando verranno emessi;
•
l’inserimento di alcuni aspetti descrittivi della qualità nell’Accordo di Servizio,
in maniera da caratterizzare il servizio applicativo in una forma più completa.
Inizialmente, questi elementi saranno non obbligatori, ma opzionali. Quando in
futuro saranno disponibili per tali elementi degli appositi standard, o quando
sarà raggiunto a livello nazionale un opportuno accordo su tutti gli aspetti, tale
da permetterne la loro standardizzazione, anche questi elementi dell’Accordo di
Servizio diverranno obbligatori.8
7
CNIPA, p.10.
8
CNIPA, p.10.
26
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Cooperazione fra Amministrazioni.
Il Dominio di Cooperazione è costituito da più insiemi di Amministrazioni che
concorrono alla fornitura di Servizi Applicativi composti; per ogni servizio erogato dal
Dominio, deve esistere un Accordo di Servizio che lo descrive, nel caso di servizi
composti l’Accordo di Servizio va corredato di una specifica che spiega come le varie
Amministrazioni componenti concorrono al servizio composto finale. Questo
documento viene definito Accordo di Cooperazione ed è trasparente rispetto ai fruitori
del servizio composto, mentre ha utilità interna al Dominio di Cooperazione.
Si
definisce così un modo per distinguere tra servizi la cui responsabilità ricade
esclusivamente
sul
singolo
dominio/amministrazione
e
servizi
di
più
domini/amministrazioni per i quali una singola amministrazione assume (per legge, per
delega concordata dagli altri, ecc.) la responsabilità che dovrebbe essere di tutte le
Amministrazioni che erogano il servizio composto.
In questo ambito si nota la differenza tra Dominio Applicativo e Dominio di
Cooperazione;
•
il primo infatti rappresenta l’insieme dei Servizi Applicativi erogati dalla singola
Amministrazione in ambito SPCoop;
•
mentre il secondo rappresenta un insieme di amministrazioni che cooperano per
l’automazione di un insieme di procedimenti amministrativi su di uno specifico
tema.
Un altro componente di rilevante importanza nel modello sono i Servizi di
Interoperabilità, Cooperazione ed Accesso (SICA), che offrono una serie di servizi e
componenti software infrastrutturali (non riconducibili a nessuna amministrazione
specifica), il cui obiettivo è di mediare e supportare la cooperazione tra le
amministrazioni; le varie funzionalità svolte dai SICA sono:
•
la specifica di come un Accordo di Servizio e di Cooperazione deve essere
costruito, formalizzato e composto;
27
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
•
la specifica di come tutti gli elementi “nominabili” nella cooperazione (ovvero
Accordi di Servizio, soggetti, caratteristiche dei servizi, ecc.) devono essere
identificati, secondo uno specifico schema di nomenclatura;
•
la specifica di un modello di sicurezza, che definisce i requisiti di sicurezza (in
termini di autenticità, riservatezza, integrità, non ripudio e tracciabilità) che
devono essere garantiti da tutti gli elementi del sistema;
•
i Servizi di Registro SICA;
•
il Catalogo degli Schemi/Ontologie SICA;
•
i Servizi di Indice dei Soggetti;
•
i Servizi di Sicurezza SICA;
•
iI Servizi di Supporto al Controllo e Gestione.9
In sintesi, il modello di cooperazione applicativa del SPCoop è basato sul paradigma
SOC (Service Oriented Computing) ed organizzato come una SOA (Service Oriented
Architecture); mentre, però, gli aspetti base di questa SOA sono già definiti a livello di
tecnologie/standard, su altri è necessario operare delle estensioni, al fine di rendere
tale architettura adeguata al contesto del e-Government italiano. Va notato, infine, che
tutte le architetture a servizi/SOA richiedono la presenza di un elemento “logicamente”
neutro, con il compito di mediare tra i differenti soggetti che cooperano attraverso
l’erogazione/fruizione di servizi. Il SICA costituisce di fatto tale elemento mediatore,
dotato di funzionalità evolute in virtù del fatto che il modello di cooperazione proposto
prevede la gestione non solo degli aspetti di base, ma anche e soprattutto di alcuni
aspetti avanzati dei Web Services.10 “11
9
CNIPA, pp.16-17.
10
Sistema Pubblico di Cooperazione: quadro tecnico d’insieme, redatto dal Gruppo di Lavoro SPCoop
in CNIPA, p.11.
11
rielaborazione delle parti ritenute interessanti del documento Sistema Pubblico di Cooperazione:
Quadro Tecnico d’Insieme, redatto dal Gruppo di Lavoro SPCoop in CNIPA [12].
28
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Nel paragrafo successivo è descritta in dettaglio la modalità di erogazione e fruizione
dei servizi su SPCoop da parte delle amministrazioni.
3.3
Modello e architettura del SPCoop
Come accennato in precedenza, gli elementi fondamentali dell’architettura del SPCoop
sono: l’Accordo di Servizio, i Servizi SICA, la Busta di e-Government e la Porta di
Dominio.
Nella prossima figura (Figura 6) viene mostrata l’architettura del SPC, si può notare il
ruolo infrastrutturale che svolgono i SICA a livello di coordinamento, per
regolamentare le interazioni tra le amministrazioni (PAC e PAL), e come le
aministrazioni stesse si interfacciano al sistema attraverso le Porte di Dominio (PDC e
PDL), utilizzando l’infrastruttura di trasporto, fornita dal Sistema Pubblico di
Connettività a livello di interazione, dove vengono scambiati i Servizi Applicativi dei
quali indirettamente traggono beneficio i cittadini.
Figura 6: Modello Architetturale del SPCoop
29
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Nello specifico, l’Accordo di Servizio è la descrizione formale dei servizi applicativi,
cioè dell’applicazione software che può essere invocata remotamente da un soggetto
interessato.
Gli aspetti del servizio che sono descritti nell’Accordo di Servizio sono:
•
interfaccia del servizio, intesa come insieme di operazioni (con la rispettiva
segnatura) offerte dal servizio;
•
protocollo conversazionale del servizio, ovvero quali possibili sequenze di
invocazione di operazioni (conversazioni) sono supportate/ammesse dal servizio;
•
punti d’accesso (endpoint di rete) presso cui effettivamente il servizio è
dispiegato;
•
livelli di qualità del servizio garantiti (SLA);
•
requisiti e caratteristiche di sicurezza del servizio;
•
descrizione della semantica del servizio e della semantica dell’informazione
veicolata dal servizio. [12]
Il primo ed il terzo punto possono essere descritti tramite WSDL (Web Service
Description Language).
In assenza di un linguaggio specifico per descrivere il protocollo di conversazioni
ammesse, è stato proposto un linguaggio pensato appositamente, il WSBL12 (Web
Service Behavioral Language), a cui potranno sostituirsi o affiancarsi eventuali
linguaggi definiti in futuro.
Analogamente, sia per la descrizione dei livelli di servizio (SLA) che dei requisiti di
sicurezza si hanno diverse opzioni in termini di linguaggi formali utilizzabili; le
specifiche prevedono al momento l’utilizzo WSLA o WS-Agreement per gli SLA e WSSecurity Framework per gli aspetti di sicurezza.
12
Sistema Pubblico di Cooperazione: accordo di servizio, redatto dal Gruppo di Lavoro SPCoop in
CNIPA, pp. 37-41
30
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Per quanto riguarda gli aspetti semantici, la necessità della loro descrizione formale
emerge dal fatto che, nel contesto dell’e-Government, i concetti che intuitivamente
dovrebbero essere condivisi ed universalmente accettati, di fatto presentano sia
differenze di significato anche sostanziali fra diversi soggetti cooperanti che differenti
possibili descrizioni e formati.
emerge, quindi, il bisogno di descrivere non solo le interfacce che caratterizzano un
servizio applicativo ma anche gli schemi concettuali e le ontologie sottostanti alle
informazioni che attraverso lo stesso servizio vengono veicolate; grazie a ciò sarà
possibile accedere, pur non conoscendo il nome o l’erogatore, ai servizi applicativi
disponibili sulla base della loro semantica funzionale.
In tal modo sarà possibile, ad esempio, compiere ricerche semantiche sui servizi
applicativi disponibili in SPCoop. Allo stato attuale esistono vari standard che
permettono di descrivere questi aspetti; quello che sembra più rispondente ai requisiti è
OWL [51].
Un componente nevralgico del SPCoop è il Servizio di Registro SICA che,
semplificando, ha il compito di garantire la gestione di tutti gli aspetti dell’Accordo di
Servizio, mettendo a disposizione tutte le funzioni necessarie allo scopo.
In Errore. L'origine riferimento non è stata trovata. sono schematizzate a livello
logico i vari servizi erogati dai SICA cioè:
•
servizi di gestione, monitoraggio e sicurezza interna;
•
servizi di supporto alla qualificazone delle Porte di Dominio;
•
servizi di supporto alla qualificazone dei Registri SICA secondari;
•
servizi di registro SICA generale;
•
servizi di di catalogo schemi e ontologie;
•
servizi di gestione federate delle identità digitali;
31
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
•
servizi di indice dei soggetti;
•
servizi di certificazione.
Servizio di
Registro
SICA
Generale
Servizio di
Catalogo
Schemi
e
Ontologie
Servizio di
Gestione
Federate
delle
Identità
Identità
digitali
Servizio di
supporto alla qualificazione
della Porta di Dominio
Servizio di
Indice
dei
Soggetti
Servizio di
Certificazione
Servizio di
supporto alla qualificazione
del Servizio di
Registro SICA Secondario
PortadidiDominio
DominioSICA
SICA
Porta
Servizi di
Monitoraggio, Gestione e Sicurezza Interna
Infrastruttura per la cooperazione applicativa
Supporto alla qualificazione di componenti di cooperazione applicativa
Figura 7: Architettura dei servizi SICA
La Porta di Dominio (PDD) e la Busta di e-Gov rappresentano rispettivamente
l’interfaccia tramite la quale interoperano le Amministrazioni ed il protocollo con il
quale le PDD comunicano tra loro.
Descrivendo più nello specifico cosa è una PDD, si può dire che tutti i servizi
applicativi sono erogati/fruiti attraverso questo unico elemento logico. Di fatto la PDD
è la piattaforma presso cui sono disponibili le interfacce applicative dei servizi; non
necessariamente i componenti software che realizzano tali servizi sono poi ospitati sulla
stessa piattaforma della PDD, anzi molto frequentemente ed opportunamente essa
svolgerà le funzioni di semplice proxy e dispatcher verso altre piattaforme di back-end
presso cui sono effettivamente dispiegate le logiche applicative dei servizi.
32
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
La Busta di e-Gov è il protocollo applicativo con cui i servizi applicativi sono
invocabili remotamente ed è una estensione dello standard SOAP 1.1, necessaria al fine
di supportare la sicurezza point-to-point, l’affidabilità della trasmissione e la tracciatura
di tutte le comunicazioni (aspetti avanzati non ancora standardizzati a livello SOAP).
La Busta e-Gov è dunque una estensione di SOAP specificatamente progettata per
SPCoop. Prevede l’utilizzo di un header appositamente predisposto, elaborato dalle
Porte di Dominio, in grado di veicolare tutte le informazioni necessarie per
implementare le suddette funzionalità; tutto questo in maniera trasparente alle
applicazioni che fanno uso delle Porte.
La Figura 8 mostra un esempio di comunicazione tra porte.
Porta di Dominio
Richiesta
Richiesta
Busta e-gov
Busta e-gov
SPC
Trasporto
Modulo di
Integrazione
Busta e-gov
Risposta
Porta di Dominio
Busta e-gov
Risposta
Dominio di
Amministrazione
Figura 8: Esempio di comunicazione tra porte
Quindi una Porta di Dominio è una piattaforma in grado di offrire servizi applicativi in
maniera tale da poter essere invocati remotamente secondo le specifiche della Busta eGov.
33
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
La Busta e-Gov è logicamente suddivisa in due parti: una contiene tipicamente
informazioni infrastrutturali, l’altra veicola il contenuto applicativo del servizio oggetto
della interazione.
Poiché la finalità è quella di mantenere totalmente autonome le amministrazioni nella
definizione del contenuto applicativo e nel contempo di uniformare le informazioni
necessarie alla gestione dello scambio in modalità sicura e affidabile, nella specifica
della Busta e-Gov vengono esclusivamente definiti gli elementi di carattere
infrastrutturale, senza entrare nel contenuto dei dati applicativi trasportati.
L’Header contiene infatti i dati necessari alle Porte di Dominio per implementare le
funzioni di gestione del messaggio comuni ai paradigmi di cooperazione previsti quali:
affidabilità, sicurezza, logging, auditing, ecc.
L’Accordo di Servizio è il cardine del ciclo di vita del servizio. I servizi SPCoop sono
obbligatoriamente gestiti per versioni dell’Accordo di Servizio. Più versioni di uno
stesso servizio (corrispondenti a versioni diverse dell’Accordo di Servizio) possono
essere erogate nello stesso momento. Ogni versione segue un ciclo di vita autonomo,
che è definito dal soggetto responsabile dell’Accordo di Servizio stesso.
Per ogni versione del servizio applicativo, il ciclo di vita è composto da 6 fasi:
•
Definizione dell’accordo di servizio.
•
Registrazione dell’accordo di servizio sul registro SICA nazionale generale.
•
Implementazione del servizio.
•
Presentazione del servizio sul SPCoop.
•
Erogazione/fruizione del servizio sul SPCoop.
•
Dismissione dell’accordo di servizio e del servizio dal SPCoop.13
13
Sistema Pubblico di Cooperazione: Architettura, redatto dal Gruppo di Lavoro SPCoop in CNIPA,
p.60.
34
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Nella fase di Definizione dell’AS il servizio viene ideato e formalizzato nell’accordo
generale di servizio e eventualmente negli accordi specifici sul livello di servizio e sul
livello di utilizzo.
Il processo che porta alla definizione del servizio segue fondamentalmente due
approcci:
•
Approccio unilaterale: Nell’approccio unilaterale, l’accordo generale di
servizio viene concepito unilateralmente dal soggetto titolare dell’erogatore, o
da un soggetto delegato. Accordi specifici di livello di servizio o di livello di
utilizzo possono seguire l’approccio unilaterale o l’approccio concordato.
•
Approccio concordato: Nell’approccio concordato, l’accordo di servizio è
ideato in modo congiunto dall’erogatore (o il suo rappresentante) e dal fruitore
(o il suo rappresentante).14
Nel SPCoop, la Registrazione del servizio è obbligatoria e deve essere attuata nella
seconda fase. La registrazione comprende molteplici attività da effettuare attraverso il
Servizio di Registro SICA (generale o secondari):
•
registrazione dei titolari dei sistemi erogatori nell’indice dei soggetti della
comunità SPCoop (SICA generale),
•
registrazione degli accordi generali di servizio nel catalogo degli accordi
(SICA generale),
•
registrazione degli accordi specifici di servizio nel catalogo degli accordi
(SICA generale o secondario),
•
registrazione dei servizi da presentare nel registro dei servizi (SICA generale o
secondario),
•
registrazione dei porti di accesso ai sistemi erogatori nella rubrica degli
indirizzi (SICA generale o secondario). 15
14
p.61.
35
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Nella terza fase, cioè l’Implementazione del servizio, il servizio viene realizzato
secondo le specifiche concordate nell’AS.
In questa fase, i sistemi per l’erogazione e per la fruizione del servizio vengono
implementati dai rispettivi titolari in una modalità che sia in accordo con quanto
definito nell’AS a proposito dei livelli di servizio e dei livelli di utilizzo.
Per come è modellata l’architettura del sistema è possibile minimizzare i livelli di
aderenza e interdipendenza reciproca delle architetture e delle tecnologie di
implementazione dei sistemi erogatori e fruitori; infatti, l’unico elemento tenuto al
rispetto dei vincoli è l’interfaccia di scambio di messaggi. Sul piano tecnico i vincoli
che devono essere rispettati sono quelli relativi all’implementazione delle tecnologie di
connessione e di trasporto; vale a dire che i servizi implementati devono essere
assolutamente conformi ai limiti imposti al momento di definizione degli Accordi di
Servizio per quanto riguarda SLA e funzionalità fornite.
Nello scambio dei messaggi sia le interfacce, sia le tecnologie di interconnessione e
trasporto, devono essere obbligatoriamente specificate nell’AS e devono conformarsi
agli standard SPCoop.
È evidente la necessità di un ambiente nel quale si possa effettuare il testing durante la
fase di implementazione, in modo da dare agli sviluppatori la possibilità di qualificare i
sistemi erogatori e fruitori e di provare l’erogazione/fruizione del servizio.
Il ciclo di implementazione è un sottociclo di quello generale che regola la vita di un
servizio; questo può essere ripreso più volte nel caso di interventi di manutenzione sia
di tipo correttivo, adattativo e migliorativo. Il titolare del sistema erogatore è l’unico
responsabile del ciclo di implementazione; il titolare è dunque tenuto a rispettare gli
15
p.61.
36
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
accordi che sono stati inseriti nell’AS (affidabilità del software, impegno di non
regressione, rapidità di correzione di anomalie, ecc.).
Nella fase di Presentazione del servizio, questo viene presentato in rete dai titolari dei
sistemi erogatori; in questa fase si ha la messa in opera del servizio. La presentazione è
la fase che precede immediatamente la fase di erogazione/fruizione.
Nella fase di erogazione/fruizione il servizio è erogato in conformità con l’Accordo di
Servizio. In questa fase vengono anche svolte attività di tracciatura e, se definito
nell’Accordo di Servizio, può essere effettuato il monitoraggio delle interazioni che si
verificano tra erogatore e fruitore.
La fase di Dismissione del servizio prevede l’archiviazione del servizio, dell’Accordo
di Servizio e dei giornali di tracciatura e può comprendere l’archiviazione di eventuali
supporti di non repudiabilità definiti nell’Accordo di Servizio.
In questa fase il servizio viene “tolto” dal SPCoop dopo aver comunicato ai sistemi
fruitori che esso verrà dismesso.
37
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Figura 9: Modalità di Erogazione di un Servizio
Come mostrato in Figura 9, l’erogazione di un servizio ha bisogno di una infrastruttura
tutte le operazioni che sono state descritte fino ad ora.
Si può notare come sia simile quello che si vede in Figura 9 con quello mostrato nella
Figura 2 quando si parlava del paradigma find–bind–execute.
Anche nel caso del SPCoop, infatti si fa uso di questo paradigma essendo il SPCoop
basato su SOA.
In sintesi, erogatore e fruitore concordano un Accordo di Servizio (nel caso di
approccio concordato) che viene poi registrato e pubblicato attraverso il Servizi di
Registro SICA a cura dell’erogatore.
Successivamente, erogatore e fruitore implementano il servizio per il suo utilizzo.
inizia, quindi, la fase simile a quella che era stata descritta in §2.2, dove il servizio
viene “cercato”, “agganciato” ed eseguito attraverso lo scambio di messaggi Applicativi
mediante la Busta di e-Gov.
38
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
3.4
L’Accordo di Servizio
“Quando due sistemi iniziano una relazione secondo le regole del SPCoop è
obbligatorio definire un accordo esplicito sulla erogazione/fruizione delle prestazioni
del servizio: l’Accordo di Servizio (AS).
L’AS contiene la definizione delle prestazioni e delle modalità di erogazione/fruizione
del servizio, inoltre nell’AS sono indicate le funzionalità del servizio, le interfacce di
scambio dei messaggi tra erogatore e fruitore, i requisiti di qualità di servizio
dell’erogazione/fruizione ed i requisiti di sicurezza dell’erogazione/fruizione. Viene
anche mantenuto un riferimento all’ontologia/schema concettuale che definisce la
semantica dell’informazione veicolata dal servizio in modo da rendere i servizi
scopribili da sistemi terzi.
I termini dell’AS sono consegnati in un insieme di documenti, secondo la struttura che
verrà descritta in nelle seguenti pagine. Detto insieme di documenti costituisce:
•
una specifica per l’implementazione dei sistemi erogatore e fruitore: è utilizzato
dai progettisti e dagli ambienti di sviluppo nelle fasi di implementazione dei
sistemi erogatore e fruitore;
•
un riferimento per l’esecuzione e la gestione dei sistemi erogatore e fruitore: è
utilizzato dai sistemi di gestione dell’esecuzione durante l’operatività dei
sistemi.16
La definizione di un servizio è il processo organizzativo il cui prodotto è l’Accordo di
Servizio (AS). Un AS si riferisce alla coppia <erogatore, fruitore> dei soggetti erogatori
e fruitore che andranno ad interagire: è obbligatorio che in un AS siano definite le due
16
Sistema Pubblico di Cooperazione: Accordo di Servizio, redatto dal Gruppo di Lavoro SPCoop in
CNIPA, p.11.
39
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Amministrazioni <erogatore, fruitore>, che sono le due organizzazioni che cooperano
su SPCoop, una che eroga un particolare servizio e l’altra che ne è fruitrice.
L’AS si compone di due parti fondamentali: la parte comune, e la parte specifica; la
prima espone in maniera formale quegli aspetti che sono comuni a molte interazioni
erogatore-fruitore dello stesso tipo, la seconda invece è quella parte che definisce le
caratteristiche della particolare interazione tra le due Amministrazioni, istanziando la
particolare coppia <erogatore, fruitore> a cui il particolare AS fa riferimento.
Per esempio, la parte specifica dettaglia i livelli di servizio ed i livelli di utilizzo di una
data coppia <erogatore, fruitore> che adopera una parte comune impiegata anche da
altre coppie come base per la definizione del proprio AS.
In seguito si utilizzerà il termine derivare, quando si vorrà indicare che la parte comune
è la base per la definizione di un AS, e specializzare quando si aggiungono dettagli,
relativi ad una particolare istanza, alla parte comune; per cui considerando una parte
comune ed una parte specifica che la specializza alla coppia <erogatore, fruitore>,
l’AS<erogatore, fruitore> che ne deriva è dato dall’unione di parte comune e parte
specifica.
In caso di cooperazione tra più di due soggetti emergono gli effettivi benefici che
comporta la divisione dell’AS in parte comune e parte specifica; in queste eventualità si
ha una ripetizione di molte parti degli AS tra coppie differenti di erogatori e/o fruitori.
Qui emerge il vantaggio che si ha a rendere modulare l’AS, in modo da mantenere
costante la parte comune per un dato servizio e cambiare solamente la parte specifica al
variare della coppia <erogatore, fruitore>.
L’AS si compone poi unendo la parte comune, usata da tutte le coppie che fruiscono un
servizio dello stesso tipo, e la parte specifica relativa alla particolare coppia <erogatore,
fruitore>.
40
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
I servizi che sono disponibili su SPCoop si distinguono, dal punto di vista della portata
della loro erogazione/fruizione, in 4 classi:
•
Servizi mono-erogatore/mono-fruitore;
•
Servizi mono-erogatore/multi-fruitore;
•
Servizi multi-erogatore/mono-fruitore;
•
Servizi multi-erogatore/multi-fruitore.
Altra differenziazione che si ha tra parti dell’AS oltre a quella tra parte comune e parte
specifica, è scomposizione che si può notare tra la componente formalizzata della
specifica ed una componente non formalizzata:
•
Specifica Formalizzata.
•
Specifica Non-formalizzata.
Quello appena detto significa che le stesse informazioni sulla cooperazione che si
hanno in un AS vengono espresse sia in maniera formale, tramite opportuni linguaggi
basati su XML, che in maniera non formale, comunque seguendo regole che obbligano
a tenere una coerenza tra AS differenti.
Nella prossima pagina in Errore. L'origine riferimento non è stata trovata. sono
mostrate le due coordinate (parte comune vs. parte specifica, componente formalizzata
vs. componente non formalizzata) in cui è possibile sezionare un accordo di servizio.”
17
17
Rielaborazione delle parti interessanti del documento Sistema Pubblico di Cooperazione: Accordo di
Servizio, redatto dal Gruppo di Lavoro SPCoop in CNIPA. [6]
41
Figura 1018 : Struttura completa di un Accordo di Servizio
18
Sistema Pubblico di Cooperazione: Accordo di Servizio, redatto dal Gruppo di Lavoro SPCoop in CNIPA, p.20.
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
3.5
La Busta e-Gov
I messaggi scambiati tra Enti e PA attraverso le Porte di Dominio, sono racchiusi in una
Busta (Busta di e-Gov) costituita da un uso della struttura SOAP 1.1 con estensioni;
questa si divide logicamente in due parti: la prima che normalmente contiene
informazioni infrastrutturali e la seconda che raccoglie informazioni che dipendono dal
tipo di servizio applicativo oggetto della interazione.
Considerando che l’obiettivo è quello di preservare l’autonomia delle Amministrazioni
nella definizione del contenuto applicativo e allo stesso tempo mantenere uniformi le
informazioni necessarie alla gestione dello scambio in modalità sicura e affidabile, la
definizione della busta è stata fatta in maniera poco rigorosa, sono, infatti, state definite
esclusivamente la definizione degli elementi di carattere infrastrutturale, senza entrare
nel contenuto dei dati applicativi trasportati.
Nell’Header sono contenuti che le Porte di Dominio necessitano per implementare
funzioni di gestione del messaggio comuni ai paradigmi di cooperazione previsti quali:
affidabilità, sicurezza, logging, auditing, ecc.
Tra gli obiettivi del piano di azione di e-Gov si individua l’erogazione di servizi
integrati ai cittadini e alle imprese, con la conseguente integrazione dei i servizi di
diverse amministrazioni.
Sul piano tecnologico ciò si traduce nel definire un sistema che risponda ai seguenti
requisiti:
•
gestire gli scambi di informazioni in modo indipendente dalle applicazioni;
•
definire un’interfaccia uniforme per le interazioni tra le amministrazioni ed,
eventualmente, tra le amministrazioni ed entità esterne;
43
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
•
permettere il raggiungimento di predeterminati livelli di servizio per quanto
concerne un insieme di tematiche quali, ad esempio, affidabilità e sicurezza.19
Come è stato detto la Busta usa una struttura SOAP 1.1 con estensioni; in Figura 11 è
rappresentata questa struttura nei due casi con e senza attachments.
Figura 1120: Busta SOAP
19
Sistema Pubblico di Cooperazione: Busta di E-GOV, redatto dal Gruppo di Lavoro SPCoop in
CNIPA, p.9.
20
CNIPA, p.16.
44
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
La struttura generale di ciascun messaggio è suddivisa in più parti:
•
la busta (envelope) del messaggio contenente le informazioni necessarie alla
gestione del messaggio da parte del provider, nel caso specifico un provider
SOAP1.1;
o
l’header, che contiene due elementi:

l’elemento “Intestazione” che contiene le informazioni relative al
trattamento del messaggio da parte delle Porte di Dominio in
termini di affidabilità, tracciamento, indirizzamento, ecc.
Contiene gli elementi custom della busta di e-Gov.

l’elemento Wsse:Security, contenente un blocco conforme alle
specifiche WS-Security. Questo elemento è opzionale, può essere
presente una o più volte e può contenere più blocchi di firma. Può
essere usato per garantire la provenienza del messaggio.
o
il corpo, contenente il contenuto applicativo relativo al servizio di
business (richiesto/erogato);
•
una eventuale sezione di attachment contenente informazioni “trasportate” (il
cui contenuto rimane opaco alla cooperazione).21
Ciò che è stato appena mostrato non rappresenta la Busta ma il suo contenitore; la
Busta infatti viaggia all’interno di una struttura SOAP 1.1, qui di seguito vedremo come
è strutturata na tipica Busta di e-Gov.
21
CNIPA, p.16-17.
45
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
La Busta è composta da elementi che fanno parte dell’Header o del Body di una SOAP
Envelope.
L’Header è composto da elementi ed attributi che hanno la finalità di implementare i
requisiti generali di un Messaging layer, ovvero delle Porte di Dominio.
La parte più rilevante della Busta di e-Gov è l’intestazione, che costituisce un”header
element” che contiene informazioni utili per la gestione del messaggio. Come illustrato
in
Figura 12 l’elemento si suddivide a sua volta in quattro elementi:
•
Intestazione Messaggio. Contiene le informazioni relative al mittente, al
destinatario, al servizio richiesto, alle modalità dell’interazione ecc;
•
Lista Riscontri. Contiene i riscontri generati in risposta a messaggi per i quali
il mittente ha richiesto la conferma di ricezione;
•
Lista Trasmissioni. Contiene informazioni utili per il tracciamento del
messaggio
•
Lista Eccezioni. Contiene tutte le informazioni relative alle eventuali eccezioni
occorse durante il trattamento dell’elemento Intestazione del messaggio.22
Figura 1223: Intestazione
22
CNIPA, p.18-19.
23
CNIPA, p.19.
46
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
In questa notazione grafica i quattro elementi appena citati sono parti dell’elemento
intestazione, ma la bordatura continua del primo elemento rispetto ai tre successivi
indica che il primo è obbligatorio mentre gli altri sono opzionali.
Si vede ora come sono costituiti alcuni degli elementi appena mostrati.
L’elemento Intestazione Messaggio si compone degli elementi indicati nella prossima
figura (Figura 13).
Figura 1324: IntestazioneMessaggio
Il contenuto della maggior parte degli elementi è abbastanza evidente, e comunque per
maggiori chiarimenti sui campi che caratterizzano la Busta e-Gov si fa riferimento alle
specifiche CNIPA25 dove si può trovare tutto lo schema della Busta di e-Gov descritto
con dovizia di particolari.
Per lo schema della Busta di e-Gov completo si fa riferimento alla Errore. L'origine
riferimento non è stata trovata. (cfr. §Appendice 1).
24
CNIPA, p.19.
25
CNIPA, p.18-37.
47
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Vista
la
rilevanza,
ai
fini
della
mia
ricerca,
dell’elemento
ProfiloCollaborazione qui di seguito ne esamineremo brevemente il contenuto.
Il profilo di collaborazione riferisce il tipo di interazione, normalizzando gli schemi di
interscambio di messaggi tra porte di dominio e applicazioni; questo tag può essere
utilizzato per supportare interazioni di tipo asincrono tra Porte di Dominio.
Sono possibili quattro profili di collaborazione:
•
EGOV_IT_MessaggioSingolo_OneWay: la porta delegata invia un
messaggio alla porta applicativa senza attendere alcuna risposta.
•
EGOV_IT_ServizioSincrono: la porta delegata invia la propria richiesta
applicativa ed attende quindi la risposta della porta applicativa.
•
EGOV_IT_ServizioAsincronoSimmetrico: la porta delegata invia la
propria richiesta applicativa; la risposta della porta applicativa può essere
inviata in un tempo successivo e la porta delegata non rimane quindi in attesa.
•
EGOV_IT_ServizioAsincronoAsimmetrico: la porta delegata invia
la propria richiesta applicativa senza restare in attesa; in un tempo successivo
la porta delegata richiede lo stato di esecuzione della propria richiesta alla
porta applicativa rimanendo in attesa della risposta. Se il servizio è stato
eseguito la Porta Applicativa inoltra alla Porta Delegata la risposta
applicativa, altrimenti segnala che il processamento non è stato ancora
completato e l’interrogazione sullo stato si ripete.26
26
CNIPA, p.22.
48
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
L’header è la parte più importante ai fini dell’interoperabilità, infatti è sull’header che
le Porte di Dominio effettuano le operazioni che permettono al sistema di interoperare.
Il Body può essere strutturato in modo diverso a seconda dei casi. Il contenuto del Body
è dipendente dal particolare servizio applicativo sia per le interazioni SOAP utilizzate
per trasportare chiamate RPC, sia per quelle utilizzate per lo scambio di documenti
XML-Based. La specifica dei diversi contenuti, pertanto, dovrà essere fornita dalle
Amministrazioni man mano che queste esporranno i propri servizi.
La Busta di e-Gov in pratica è il protocollo utilizzato per lo scambio di messaggi sul
SPCoop.
Descriveremo ora le modalità tramite cui le Porte di Dominio gestiscono le
informazioni scambiate tramite la Busta di e-Gov.
3.6
La Porta di Dominio
I Servizi Applicativi registrati sul SICA attraverso Accordi di Servizio vengono poi
erogati dalle Pubbliche Amministrazioni, locali o centrali che siano, tramite un unico
elemento logico, utilizzando il “protocollo” appena descritto.
Questo elemento prende il nome di Porta Di Dominio, essendo l’elemento che funge da
porta di ingresso, verso il dominio per le altre amministrazioni che vogliono fruire dei
servizi erogati, e da porta di uscita dal dominio per l’amministrazione interna al
dominio che vuole fruire di servizi erogati esternamente.
La Porta di Dominio di fatto è la piattaforma sulla quale vengono pubblicate le
interfacce applicative dei servizi; non è detto che i componenti software che realizzano
tali servizi effettivamente risiedano sulla stessa piattaforma. Sarà invece più frequente
che le funzioni siano realizzate su altre piattaforme e la PDD svolga semplicemente
funzione di proxy e dispatcher verso le altre piattaforme di back-end nelle quali
vengono effettivamente erogati i servizi, tramite opportuni componenti software.
49
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
I compiti delle Porte sono: interagire con i Servizi Applicativi esposti dalle singole
Amministrazioni e colloquiare tra loro secondo gli standard definiti nell’ambito
dell’SPCoop in maniera paritetica.
Per attuare tale disegno occorre che tutti gli attori (amministrazioni centrali e locali,
enti ed aziende):
•
condividano le specifiche, gli standard e le modalità di realizzazione e gestione
dei complessi elementi infrastrutturali comuni che disaccoppiano i sistemi
(eventualmente legacy) delle amministrazioni ed implementano i servizi che
abilitano la cooperazione applicativa tra sistemi;
•
si impegnino ad esporre ed utilizzare (in qualità di fruitori) servizi erogati da
terzi secondo modalità standard predefinite e consolidate tecnologie di mercato.
Le porte dovranno implementare diverse funzionalità infrastrutturali:
o funzionalità di base, tra cui la gestione della Busta e-Gov, delle
tracciature, dei diagnostici, del SOAP with Attachments e della modalità
in consegna affidabile;
o funzionalità di Sicurezza, in accordo alle raccomandazioni WSI Basic
Security Profile con la gestione della Sicurezza base SSL;
o funzionalità di Consolle di Monitoraggio, con consolle Base e consolle
Evoluta dove la consolle Base offre servizi di configurazione e gestione
delle porte in modalità testo e la consolle evoluta deve offrire, oltre alle
caratteristiche dell’ altra, la navigazione dei log in maniera grafica.
La porta è dunque un elemento logico che offre servizi Applicativi internamente ed
all’esterno del Dominio Applicativo.
50
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Le funzionalità sopra citate fanno riferimento ai documenti CNIPA27 riguardanti il tema
della PDD.
Ogni PDD che entra a far parte del SPCoop deve essere qualificata, secondo le
caratteristiche definite nei documenti CNIPA a riguardo; ogni PDD deve essere
conforme ad adeguati livelli di servizio, sicurezza, e deve supportare tutte le
funzionalità obbligatorie ai fini di garantire interoperabilità al dominio del quale sarà
porta.
Andando un po’ più nel dettaglio di quanto accennato tra le funzionalità si può
affermare che per gestione della busta si intendono tutti quei meccanismi di
instradamento delle richieste applicative, gestione della coerenza della busta, vale a dire
che i campi abbiano valori consistenti con quello richiesto da specifiche, gestione degli
acknowledgement etc.
Per funzionalità di Sicurezza si intendono tutte quelle operazioni atte a garantire il
trasporto sicuro dei dati veicolati e la verifica dell’integrità delle Buste svolta tramite il
controllo sulla veridicità dei mittenti e delle richieste presenti nella Busta.
Queste funzionalità vengono trattate con maggiore dettaglio nelle specifiche CNIPA
che trattano di Security in SPCoop [14].
Anche la funzionalità di Consolle di Monitoraggio è molto importante e deve garantire
la possibilità di gestire i messaggi di diagnostica ed i log files. Inoltre la Consolle di
Monitoraggio deve dare la possibilità all’utente di configurare la PDD a proprio
piacimento.
La PDD non contiene logica applicativa ovvero è disaccoppiata dal servizio in modo da
poter essere distribuita ed utilizzabile in Domini di tipo differente.
Al fine di spiegare a grandi linee il funzionamento della PDD, utilizzeremo come
esempio la comunicazione che si può vedere nella Figura 14.
27
Sistema Pubblico di Cooperazione: Porta di Dominio, redatto dal Gruppo di Lavoro SPCoop in
CNIPA [11].
Sistema Pubblico di Cooperazione: Quadro Tecnico d’Insieme, redatto dal Gruppo di Lavoro SPCoop in
CNIPA, p.15-16.
51
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Ogni Amministrazione avrà la sua PDD che svolgerà funzione di porta delegata,
mostrerà cioè al client i servizi fruibili remotamente come se fossero fruibili
localmente. Il client effettua la richiesta alla propria PDD (delegata), questa viene
intercettata da un handler delle richieste che ne formatta l’header secondo il protocollo
definito dalla Busta di e-Gov e successivamente la spedisce all’Interfaccia Applicativa
della PDD remota, cioè a quella che effettivamente eroga il servizio che il client vuole
fruire; la richiesta viene intercettata dall’handler della porta Applicativa che gestisce
l’header e richiede il servizio all’erogatore.
L’erogatore fornisce il servizio. Nel caso in cui la comunicazione richieda una risposta
alla propria PDD (tutti i casi eccetto la comunicazione One Way, o a messaggio
singolo), questa funge da porta delegata dell’erogatore, rimandando indietro la risposta
alla PDD che per l’erogatore ha funzione di porta applicativa, cioè quella del client che
aveva richiesto il servizio, che a sua volta eroga il servizio al client.
Quando la comunicazione è asincrona, le PDD devono anche erogare dei servizi di
attesa risposta e quando questa arriva, esse devono gestire il tracciamento dei messaggi;
per fare ciò si è pensato di utilizzare dei DBMS.
Porta
di
Dominio
Porta
di
Dominio
Servizio
Interfaccia Delegata
Client
Primitiva 1
Primitiva 2
Primitiva 4
Primitiva 1
Primitiva 2
Primitiva 4
Figura 14: Comunicazione tra Porte di Dominio
52
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Tutti questi elementi saranno illustrati con maggiore dettaglio in seguito, verrà anche
esaminata più specificamente la maniera in cui sono state affrontate alcune tematiche
come la gestione dell’handler e della trasmissione asincrona.
Si è appena accennato come un Servizio Applicativo venga gestito da una PDD; il ciclo
di vita di un servizio è però ben più lungo, la parte appena spiegata è infatti solo quella
di erogazione-fruizione del servizio sul SPCoop.
Si esamina ora la gestione dell’intero ciclo di vita del servizio in maniera tale da
rendere chiaro al lettore come gli elementi che sono stati appena descritti collaborino al
fine di dare interoperabilità al sistema.
3.7
SICA: i servizi infrastrutturali per la cooperazione
applicativa
Da quanto esposto in precedenza emerge come la cooperazione ruoti intorno al concetto
di Accordo di Servizio. Come accennato nel precedente capitolo si può affermare che i
servizi infrastrutturali SICA nascono per consentire la gestione, in tutti i suoi aspetti,
dell’Accordo di Servizio, mettendo a disposizione tutte le necessarie funzioni allo
scopo.
In pratica i servizi infrastrutturali SICA sono un aggregato di differenti elementi, alcuni
di carattere documentale ed altri veri e propri componenti software.
Le caratteristiche di questi elementi, di cui si è parlato nelle pagine precedenti, veranno
approfondite in questo capitolo, spiegando più dettagliatamene le varie funzioni svolte
dai servizi infrastrutturali SICA.
Il modello di cooperazione identifica due elementi base SICA:
•
servizi di registrazione e ricerca (Servizi di Registro SICA);
53
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
•
servizi di infrastruttura a chiave pubblica (AC SICA).
L’accesso ad una occorrenza dei Servizi di Registro SICA, deve essere permessa sia ai
sistemi, sia agli utenti afferenti alle organizzazioni della comunità SPCoop, attraverso
una interfaccia utente accessibile sia agli amministratori che agli utenti che operano
sotto la responsabilità dei soggetti della comunità SPCoop, inserendo, aggiornando e
cancellando le informazioni sulle risorse di cui tali soggetti sono responsabili.
Responsabili e progettisti dei sistemi fruitori attuali e potenziali dei servizi utilizzano
l’interfaccia utente nelle fasi di analisi e progettazione, per richiedere informazioni sui
soggetti, i servizi, gli erogatori, gli accordi di servizio e gli indirizzi dei punti di
accesso.
Dal punto di vista funzionale, i Servizi di Registro SICA devono offrire le seguenti
funzionalità:
•
gestione dell’indice dei soggetti organizzativi della comunità del SPCoop;
•
gestione del catalogo degli accordi di servizio e cooperazione sottoscritti e
implementati su SPCoop;
•
gestione dell’elenco degli erogatori presenti su SPCoop;
•
gestione della rubrica degli indirizzi dei punti di accesso dei sistemi erogatori e
fruitori.28
Descrivendo più specificamente ogni singola funzionalità si vede:
L’Indice dei Soggetti Organizzativi.
Costruzione dell’indice dei soggetti organizzativi costituisce il primo stadio nella
realizzazione dei Servizi di Registro SICA. Il Comitato di gestione SPC è addetto ad
28
Sistema Pubblico di Cooperazione: Servizi di Registro, redatto dal Gruppo di Lavoro SPCoop in
CNIPA, p.8.
54
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
identificare tali soggetti organizzativi pubblici e privati, e rilascia al soggetto un codice
identificatore unico (formato URI/URN) nell’ambito di SPCoop.
Il Catalogo degli Accordi di Servizio e Cooperazione.
Ogni accordo di servizio e/o di cooperazione è costituito da un insieme di documenti29
ed è identificato tramite un codice, in formato URI/URN, univoco in ambito SPCoop.
L’accordo di servizio/cooperazione deve essere registrato nei Servizi di Registro SICA,
in cui viene effettuato un controllo di universalità del codice identificatore in ambito
SPCoop.
L’Elenco delle Occorrenze dei Servizi.
La costituzione dell’indice dei soggetti e del cataloghi degli accordi permette in seguito
la registrazione delle occorrenze di erogazione dei servizi.
La gestione della Rubrica degli Indirizzi dei Punti d’Accesso.
Ad ogni occorrenza di servizio, l’erogatore può rendere disponibili più punti per
accedere al servizio. In fase di registrazione di un punto d’accesso, viene utilizzata una
struttura che contiene come elemento principale l’indirizzo del punto di accesso e degli
eventuali punti d’accesso secondari a cui rivolgersi al verificarsi di problemi.
L’utilizzo di queste funzionalità avviene sia in fase di design che a run-time.
I progettisti dell’erogatore e del fruitore utilizzano i Servizi di Registro SICA in fase di
progettazione e realizzazione dei servizi applicativi SPCoop, con l’ obiettivo di:
•
registrare l’accordo di servizio affinché assuma valore di riferimento,
•
accedere alle informazioni necessarie allo sviluppo dei Web Service lato
erogatore e lato fruitore.
29
Sistema Pubblico di Cooperazione: Accordo di Servizio, redatto dal Gruppo di Lavoro SPCoop in
CNIPA [6].
55
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Viene analizzato ora come i Servizi di Registro SICA sono articolati, verificando
l’organizzazione dell’erogazione dei Servizi di Registro a livello architetturale.
I Servizi di Registro SICA sono organizzati in modo distribuito attraverso
un’architettura master-slave con replicazione dell’informazione, come rappresentato in
Figura 15.
Figura 1530: Interazione tra Registro Generale e Registri Secondari
30
Sistema Pubblico di Cooperazione: Servizi di Registro, redatto dal Gruppo di Lavoro SPCoop in
CNIPA, p.14.
56
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Questo tipo di architettura offre ai client la possibilità, in caso di interesse ad accedere a
particolari
funzionalità
di
registrazione
e
ricerca
(per
effettuare
inserimenti/aggiornamenti/cancellazioni), di fare le proprie richieste sia sul Registro
Generale sia su uno dei Registri Secondari, scegliendo, in piena libertà, in base a
requisiti di sicurezza, velocità di risposta, costi o qualsiasi altro criterio ritenuto
rilevante.
Nell’eventualità di effettuare operazioni su registri Secondari, questi assumono il ruolo
di steward (“responsabile”) per l’informazione in esame: questo significa che quando il
client voglia operare una successiva operazione di aggiornamento/cancellazione, esso
può operare o presso il Registro Generale o presso il Registro Secondario steward, e
non può più rivolgersi agli altri Registri Secondari.
I registri Secondari e quello Generale utilizzeranno poi il meccanismo di
sincronizzazione per rendere l’informazione sempre “up to date”.
Sono definiti anche gli altri servizi che verranno erogati dal SICA, quali:
•
il catalogo di schemi ed ontologie che è il componente software che offre
funzionalità per “ragionare” sulla semantica dei servizi e delle informazioni da
essi veicolati, ai fini della individuazione dei servizi migliori candidati
all’erogazione delle prestazioni richieste.
•
i Servizi di Indice dei Soggetti offrono un insieme di funzionalità necessarie a
gestire la “rubrica” degli operatori/utenti della PA. Oltre alle classiche
funzionalità di registrazione, accesso, aggiornamento, cancellazione e ricerca
delle informazioni relative agli operatori (ad es., nome, cognome, riferimenti
telefonici ed e-mail, funzioni, responsabilità, mansioni, etc.).
•
i Servizi di Sicurezza: Il modello di cooperazione prevede che, sia per i servizi
applicativi che per quelli infrastrutturali SICA, siano garantititi degli adeguati
livelli di sicurezza: ogni elemento del sistema deve essere qualificato, ovvero
deve essere verificato il superamento di determinati test che garantiscono il
soddisfacimento di alcuni requisiti minimi di sicurezza, e su tutti i messaggi
57
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
applicativi scambiati tra elementi devono essere assicurati opportuni requisisti
di autenticità, riservatezza, integrità, non ripudio e tracciabilità degli stessi. La
sicurezza di un sistema complesso quale SPCoop presenta molte sfaccettature,
sia di carattere architetturale che tecnologico che organizzativo, in particolare:
•
o
Aspetti Architetturali.
o
Aspetti Tecnologici
o
Aspetti Organizzativi e di Gestione della Sicurezza
i Servizi di Supporto e Controllo della Gestione: un sistema complesso quale
SPCoop, costituito da elementi distribuiti appartenenti ad organizzazioni
differenti (le Porte di Dominio che erogano/fruiscono dei servizi applicativi) e
da elementi terzi (i servizi infrastrutturali SICA), anch’essi dispiegati in alcuni
casi in maniera distribuita, richiede un adeguato supporto al Controllo ed alla
Gestione.
L’architettura di un registro sica è illustrata nelle Figura 7 (cfr. §3.3), Figura 7 e
Errore. L'origine riferimento non è stata trovata. (cfr. §Appendice 2)
58
Tesi di Laurea
Sviluppo di una Porta di Dominio
Vittorio Ottaviani
_______________________________________________________________________
4. Sviluppo di una Porta di Dominio
Oggetto di questo lavoro è lo sviluppo di una Porta Di Dominio (PDD); nei precedenti
capitoli si è spiegato cosa sia e quali siano le funzioni di questo componente del sistema
che si va a sviluppare, nel presente capitolo approfondirà l’argomento per dare
maggiore completezza di informazione.
4.1
Progettazione di una “proof of concept” di Porta di
Dominio
Per realizzare una Porta di Dominio che rispetti i requisiti sopra citati si è dovuto
considerare due opzioni: se considerare la Porta come uno Strato Protocollare, o come
un Proxy Applicativo.
•
Nel primo caso la PDD ha proprie primitive verso i propri peer ( altre porte di
dominio) e primitive di interfaccia verso lo strato superiore ( il servizio). La
porta espone un servizio di messaggistica, tipicamente una receive(),
nascondendo le primitive del servizio per veicolarle all’interno del proprio
payload.
La Porta gestisce la parte dinamica del protocollo e-Gov, ovvero la logica
associata all’Intestazione realizzando le modalità di colloquio previste dalla
Busta e-Gov e implementa tutti i requisiti richiesti in termini di affidabilità nella
consegna e requisiti di sicurezza ai vari livelli.
•
Nel caso della soluzione Proxy la porta espone le stesse primitive del servizio,
aggiunge in trasmissione e rimuove in ricezione l’Intestazione della Busta e-
59
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Gov a quella già preparata dal servizio, gestisce la parte dinamica del protocollo
e-Gov, ovvero la logica associata all’Intestazione.
La soluzione Proxy è sembrata quella che più si avvicinasse ai requisiti che la
PDD doveva rispettare ed implementare.
Si è scelto di sviluppare una PDD che avesse le caratteristiche di un Proxy Applicativo
che alla ricezione di un messaggio SOAP effettui le operazioni di sbustamento della
Busta e-Gov, lettura dei vari campi di interesse come “mittente”, ”destinatario” etc. ,
erogazione del servizio o re-invio nel caso il destinatario non sia la PDD in esame.
Dopo l’erogazione di un servizio, la porta deve imbustare nuovamente la risposta in un
Messaggio Applicativo che contenga i vari campi della Busta di e-Gov ed inviarlo alla
PDD destinataria del messaggio.
Figura 16: Porta di Dominio come Strato Protocollare
Nella soluzione Proxy la PDD ha una interfaccia Applicativa che è rivolta all’esterno
con lo scopo di erogare messaggi esternamente al Dominio ed una interfaccia Delegata
60
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
che ha la funzione di connettere i clients interni al Dominio con servizi presenti su
Domini esterni.
Praticamente la PDD si interfaccia con la risorsa che eroga il servizio tramite le
primitive (in Figura 17 primitiva 1, primitiva 2, primitiva 4) e replica le primitive
all’esterno del dominio tramite la sua interfaccia Applicativa.
Quando arriva una richiesta, la PDD la processa, effettuando tutti i controlli che sono
stai descritti nel precedente paragrafo e, in caso la richiesta sia “buona”, la sottomette
all’erogatore del servizio tramite la primitiva chiamata nel messaggio ricevuto.
Se la richiesta ha bisogno di risposta, la PDD aspetta che arrivi la risposta dal Servizio
chiamato e poi la inserisce in una Busta e-Gov e la spedisce alla PDD del Dominio che
aveva inviato la richiesta.
La PDD ha anche una interfaccia di gestione che permette di effettuare le operazioni di
monitoraggio e configurazione che sono state descritte precedentemente.
Nel caso in cui un client interno al Dominio voglia fruire un servizio dalla propria
PDD, quanto deve passare dall’interfaccia Delegata che si interfaccia con l’interfaccia
Applicativa ed effettua la richiesta come se la stessa arrivasse dall’esterno del Dominio.
Quanto appena descritto è il comportamento di una Porta sviluppata come un Proxy
Applicativo “internamente” al Dominio.
Viene mostrato come si comportano due PDD Proxy quando devono colloquiare tra
loro.
Il client effettua la propria richiesta all’ interfaccia Delegata della propria PDD, la PDD
si occupa di imbustare la richiesta alla primitiva desiderata in una Busta di eGovernment effettuando tutte le operazioni descritte precedentemente e di inviare la
richiesta sotto forma di Messaggio Applicativo all’interfaccia Applicativa della PDD
remota, cioè a quella che espone le primitive per fruire i servizi desiderati.
61
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Questa PDD effettua le operazioni descritte sopra: sbusta la richiesta, effettua i
controlli, sottomette la richiesta al server tramite la primitiva invocata dal client e, nel
caso non necessiti risposta, chiude la comunicazione; in caso contrario attende la
risposta, la imbusta nuovamente in una Busta con i dati del fruitore come “destinatario”
e la invia alla PDD del Dominio del destinatario.
La PDD del Dominio del fruitore, al momento dell’arrivo di un Messaggio Applicativo,
effettua i controlli del paragrafo precedente e, vedendo che il messaggio è una risposta
ad una precedente richiesta, individua il fruitore del servizio e gli comunica la risposta
che era stata richiesta.
Porta
di
Dominio
Porta
di
Dominio
Servizio
Interfaccia Delegata
Client
Primitiva 1
Primitiva 2
Primitiva 4
Primitiva 1
Primitiva 2
Primitiva 4
Figura 17: Porta di Dominio come Proxy Applicativo
Quando la comunicazione non ha bisogno di risposta, il tipo di colloquio è quello
rappresentato in Figura 18.
62
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Figura 1831: Comunicazione Messaggio Singolo
In questo caso la PDD del Dominio fruitore trasmette la richiesta e non attende nessuna
risposta. La connessione viene chiusa subito dopo l’invio della richiesta all’interfaccia
Applicativa della PDD erogatrice.
Quando si ha una situazione di comunicazione sincrona, lo scenario è quello
rappresentato in Figura 19.
Figura 1932: Comunicazione Sincrona
Viene inviata la richiesta di servizio all’interfaccia applicativa della PDD erogante e
viene attesa la risposta, positiva o negativa che sia, mantenendo la connessione attiva.
Nel caso di una comunicazione Asincrona, gli scambi che si verificano sono pressoché
gli stessi.
31
CNIPA, p.42.
32
CNIPA, p.43.
63
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
La differenza sta nel fatto che le risposte dai Servizi non arrivano immediatamente alle
Porte di Dominio, questo comporterebbe un dispendio di risorse estremamente oneroso
nel caso di molte richieste di Servizio visto che dovrebbero rimanere aperte N
connessioni con N uguale al numero di richieste Asincrone ancora non evase.
Per ovviare a questo problema si è pensato di chiudere la connessione dopo l’arrivo
della richiesta al servizio, per aprire un servizio in ascolto sull’interfaccia Applicativa
del Dominio del client fruitore (richiedente) che accetti connessioni da parte del
dominio erogatore (esportante) in modo che il secondo possa comunicare al primo la
risposta del servizio quando quest’ultima è disponibile.
Figura 2033: Comunicazione Asincrona Simmetrica
Questo succede nel caso di comunicazione Asincrona Simmetrica, nel caso di
comunicazione Asincrona Asimmetrica invece, dopo aver chiuso la connessione
all’avvenuto invio della richiesta
33
CNIPA, p.46.
64
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Figura 2134: Comunicazione Asincrona Asimmetrica
sulla Porta del Dominio esportante (erogatore), viene aperto un servizio di accesso allo
stato di processamento della richiesta di servizio; questo servizio sarà il prossimo ad
essere chiamato dalla PDD del fruitore per monitorare lo stato della propria richiesta di
servizio o ricevere la risposta del servizio stesso.
Questa ultima soluzione, è più dispendiosa a livello di traffico generato sulla rete, evita
però al fruitore l’onere di dover attivare un servizio di ricezione risposta.
4.2
Fasi della progettazione
Finora è stato visto cosa è una Porta di Dominio, in che ambito nasce la necessità di
averne una, ne sono state esaminate le funzionalità che deve possedere, è stata mostrata
la modalità di comunicazione, quali protocolli vengono utilizzati al fine di effettuare
queste comunicazioni, quali strumenti possono aiutarci ad implementare una PDD in
ambiente open source che abbia le funzionalità sopra citate.
34
CNIPA, p.50.
65
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
È stato visto il ruolo di questo elemento logico nell’ambito del Sistema Pubblico di
Cooperazione e ci si è resi conto dell’importanza di un elemento di questo tipo per il
funzionamento di tutto il sistema.
Al fine di costruire un elemento tanto importante per il sistema è evidente la necessità
di una fase di progettazione della PDD.
4.2.1 Definizione degli Attori
Innanzitutto in un processo di progettazione software devono essere definiti gli attori
che si interfacciano con il sistema; nel nostro sistema gli attori principali sono sembrati
essere il Dominio Applicativo, L’Amministrazione Locale o Centrale, la base di dati e
la consolle di monitoraggio.
Il Dominio Applicativo o dei servizi applicativi è formato da qualsiasi Amministrazione
che vuole cooperare. Ogni Amministrazione è responsabile dei servizi erogati sul
proprio Dominio Applicativo.
L’Amministrazione locale rappresenta ciascuna amministrazione che vuole erogare
servizi.
La base di dati è il luogo dove vengono registrate le interazioni tra amministrazioni e
tra le varie PDD.
Nel normale processo di progettazione vengono poi analizzati i casi d’uso che il sistema
si troverà a gestire in seguito.
4.2.2 Casi d’Uso
Qui di seguito c’è una possibile vista generale dei casi d’uso che regolano il sistema.
66
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Figura 22: Vista generale degli Use Case
Le Amministrazioni possono far parte di un Dominio di Collaborazione, del quale fa
parte anche il sistema di Monitoraggio; attraverso le interfacce che collegano le
amministrazioni alle PDD, le amministrazioni possono comunicare con altri domini
fruendo servizi offerti dalle interfacce applicative di Porte remote.
L’Amministrazione inoltra all’interfaccia delegata della Porta del proprio Dominio il
Messaggio Applicativo contenente i dati da trasmettere. Il messaggio contiene
indicazioni relative a: la Parte destinataria, la Parte mittente, l’identificativo del
Servizio Applicativo richiesto, oppure erogato, i parametri applicativi della richiesta
oppure i dati di risposta, e i parametri che specificano il profilo di collaborazione (es.
67
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
“Richiesta senza risposta”, “Richiesta/risposta”) e le caratteristiche di messaging
desiderate come affidabilità etc.
Figura 23: Use Case Trasmetti Messaggio
La PDD verifica la correttezza del Messaggio Applicativo e lo inserisce in un
Messaggio SPCoop ossia in una struttura SOAP rispondente alle specifiche della Busta
di e-Gov rappresentante il protocollo standard tramite il quale colloquiano le Porte in
ambito SPCoop (fase Imbustamento). Infine (fase di Invio), la PDD invia il Messaggio
SPCoop alla PDD destinataria mediante il protocollo HTTPs. La localizzazione del
servizio richiesto può essere effettuata dal Servizio Applicativo richiedente oppure
dalla PDD richiedente e può avvenire staticamente, mediante tabelle di corrispondenza,
oppure dinamicamente mediante interrogazione del servizio di registo SICA.
In ricezione, la Porta dovrà gestire il protocollo HTTPs ed effettuare la verifica formale
(parsing) del Messaggio SPCoop proveniente da una Porta di Dominio mittente (fase di
Sbustamento). Individuato quindi il Servizio Applicativo destinatario, la PDD dovrà
estrarre il Messaggio Applicativo (richiesta o risposta) presente nel body o nell’allegato
della Busta di e-Gov per consegnarlo al servizio applicativo (fase di Smistamento).
68
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
In caso di eccezioni nella fase di sbustamento, ovvero di smistamento, di Messaggi
SPCoop relativi a richieste che prevedono un messaggio di risposta (“profilo di
collaborazione” di tipo “Richiesta/risposta”) la Porta di Dominio deve inviare alla Parte
Mittente un Messaggio di Errore SPCoop.
Figura 24: Use Case Ricevi Messaggio
Nel caso in cui il Messaggio SPCoop ricevuto sia, in realtà, un Messaggio di Errore
SPCoop, la segnalazione di eccezione ivi contenuta deve essere recapitata al Servizio
Applicativo che ha originato la richiesta mediante un Messaggio di Errore Applicativo.
69
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
La correlazione tra richiesta e risposta, a livello di Porta, viene effettuata a seconda
delle
modalità
di
interazione
utilizzando
i
campi
Identificatore
e
RiferimentoMessaggio presenti nella header della Busta di e-Gov oppure le
caratteristiche di sincronismo proprie dei messaggi di request e reply del protocollo
http.
Le altre funzioni descritte all’inizio di questo capitolo riguardano sopratutto la consolle
di monitoraggio.
La Consolle di Monitoraggio interagisce con la Porta di Dominio per la gestione dei
tracciamenti e della diagnostica: Use Case Gestione Tracciamenti e Use Case Gestione
Diagnostica. L’interazione avviene attraverso Messaggi di Comando inviati alla Porta
dalla Consolle.
La Consolle può impartire alla Porta di Dominio comandi per definire la configurazione
dei parametri di persistenza delle tracce (periodo di backup, supporti da utilizzare per lo
storage ecc) oppure per richiedere l’export di un insieme selezionato di tracce,
specificando uno o più parametri di scelta (per esempio un periodo temporale, la Parte
mittente, la tipologia di messaggi, il servizio applicativo oggetto del messaggio ecc.).
70
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Figura 25: Use Case Gestione Tracciamenti
Nello Use Case si può vedere come la gestione dei tracciamenti sia eseguita attraverso
due operazioni: la gestione della persistenza dei tracciamenti e la gestione
dell’esportazione dei tracciamenti; queste sono le due operazioni che si interfacciano
con la base di dati per effettuare le operazioni che rendono persistenti i dati e che
permettono di effettuare operazioni quali statistiche o controlli sui dati stessi.
71
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Figura 26: Use Case Gestione Diagnostici
La gestione dei messaggi di diagnostica è invece il risultato delle operazioni che
gestiscono la persistenza dei diagnostici, li esportano, consumano i messaggi
diagnostici in sospeso e filtrano i messaggi diagnostici generati.
Come si può vedere dal caso d’uso, queste ultime operazioni effettuano i veri e propri
interfacciamenti con la base di dati.
I casi d’uso riguardanti la console di monitoraggio sono stati descritti solo per
completezza, non è tra gli obbiettivi di questo lavoro la realizzazione di un sistema di
monitoraggio delle PDD.
Ma in che modo i servizi appena descritti vengano effettivamente forniti ai servizi che
usano le Porte di Dominio?
72
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Nei sequence diagram seguenti è descritto come si intende sviluppare il sistema e come
i vari elementi debbano comunicare tra loro nei differenti Profili di Collaborazione.
4.2.3 Sequence Diagrams
Le prossime due figure (Figura 27 e Figura 28) si riferiscono al caso in cui il profilo di
collaborazione è di tipo “EGOV_IT_MessaggioSingoloOneWay” che indica il caso in
cui si ha una richiesta che non necessita risposta: la prima immagine (Figura 27) fa
riferimento alla parte mittente (fruitore) e la seconda (Figura 28) alla parte ricevente
(erogatore) del messaggio.
In trasmissione alla PDD arriva un Messaggio Applicativo contenente la richiesta di
servizio, la Porta innanzitutto controlla che il formato del messaggio sia valido, cioè
che effettivamente vi sia un servizio fruibile che coincide con quello richiesto nel
Messaggio Applicativo.
In caso negativo viene mandato un messaggio di errore altrimenti vengono iniziate le
operazioni di creazione del messaggio SPCoop e di imbustamento. Il messaggio viene
processato dal controlloreHandleRequest che, utilizzando i metodi delle varie classi
controllore che si possono vedere nella Figura 27, raccoglie i dati che gli servono: cioè
il valore del tempo di sistema ed i vari valori che identificano mittente, destinatario e
tutti i campi che devono essere inseriti nel messaggio. Questi valori vengono poi settati
nei rispettivi campi, chiamando la classe che si occupa di fare le operazioni sul
messaggio.
Dopo che tutte le informazioni sono state istanziate nelle varie classi che rappresentano
la Busta di e-Government, il messaggio viene serializzato35 in una stringa XML per
essere poi inviato.
All’arrivo dell’Ack http viene tracciato l’invio del messaggio nel database.
35
serializzare: l’atto di inserire i valori contenuti in una istanza di classe in una stringa di qualche tipo.
73
:
Amministrazion...
: InterfacciaAmministrazioneLocale
:
ControlloreHandleRequest
: ControlloreMarshaller
: ControlloreMessaggio
: ControllorePorta
:
ControlloreTempoDiSi...
: ControlloreTracciamenti
: Messaggio
: InterfacciaDataBase
: DataBase
ottieniServizioOneWay( )
controllaValiditàRichiesta( )
imbustaMsg( )
getTempoDiSistema( )
creaMessaggioSPC( )
setMessaggio( )
setPart( )
serializzaMsg( )
inviaMsg( )
msgInviato( )
setTraccia( )
Figura 27: Sequence diagram del caso di comunicazione a messaggio singolo (trasmissione)
setTrack( )
writeDB( )
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Nell’altra figura (Figura 28) vengono analizzate le operazioni che svolge la parte
ricevente all’arrivo di una Busta di e-Government.
Come si può vedere all’arrivo di un Messaggio la Busta di e-Government viene aperta,
vengono effettuate tutte le operazioni di controllo sulla validità della richiesta e la busta
viene deserializzata36 in una serie di classi che la rappresentano, viene controllato il
contenuto delle parti di interesse, come mittente, servizio richiesto, profili di
collaborazione etc... Questi dati indicheranno alla PDD erogatrice la maniera nella
quale si deve comportare.
Queste operazioni vengono effettuate sempre. Nel caso di una richiesta che abbia nel
campo
profiloCollaborazione
il
valore
“EGOV_IT_MessaggioSingoloOneWay” viene chiamato il servizio richiesto e
viene tracciato l’arrivo del messaggio.
Negli altri casi i comportamenti saranno più articolati vista la maggiore complessità
delle operazioni da svolgere.
36
Deserializzare: l’atto di impostare i valori di una istanza di classe con i valori contenuti in una stringa
formattata in un qualche modo.
75
: ControllorePorta
:
: Messaggio
:
Amministrazion...
riceviMsg( )
sbustaMsg( )
deserializzaMsg( )
creaMessaggioSPC( )
getMessaggio( )
getPart( )
smistaMsg( )
setTraccia( )
setTrack( )
trasmettiRichiesta( )
processaRichiestaOneWay( )
Figura 28: Sequence diagram del caso di comunicazione a messaggio singolo (ricezione)
writeDB( )
: DataBase
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Nella prossima figura (Figura 29) viene esaminato il caso in cui si effettua la
trasmissione di una richiesta SPCoop con profilo di collaborazione di tipo
“EGOV_IT_ServizioSincrono”; questo profilo di collaborazione invia una
richiesta che ha bisogno di una risposta che può arrivare repentinamente.
La connessione tra le Porte non viene dunque chiusa ma la PDD fruitrice rimane in
attesa della risposta da parte del Dominio erogatore.
Quando all’interfaccia Delegata della PDD arriva un Messaggio Applicativo viene
controllata innanzitutto la validità della richiesta effettuata, se nella richiesta viene
chiamato un Servizio Applicativo di tipo richiesta/risposta Sincrona allora la PDD
inizia le operazioni di creazione del messaggio SPCoop secondo le specifiche della
Busta di e-Government.
Innanzitutto vengono raccolti i dati riguardo al tempo di sistema, al mittente, al
destinatario, e tutto quello che serve per compilare i campi della Busta, poi viene creata
una istanza di messaggio e vengono impostati i campi con i dati raccolti.
Ciò significa che viene impostato il campo profilo di collaborazione a
“EGOV_IT_ServizioSincrono” e il campo mittente con l’identificativo
dell’Amministrazione fruitrice, vengono poi impostati tutti i campi relativi al servizio
richiesto e al dominio erogante.
Il messaggio viene poi serializzato, inviato e viene effettuata la tracciatura dell’invio di
un messaggio SPCoop.
Fino a qui le operazioni effettuate sono a grandi linee le stesse del caso precedente, le
operazioni che seguono sono invece quelle che differenziano maggiormente i due casi,
infatti qui la connessione tra le due PDD non viene chiusa ma il Dominio fruitore
rimane in attesa del messaggio SPCoop di risposta che contenga i dati relativi al
servizio richiesto.
77
:
Amministrazion...
:
: ControllorePorta
:
: Messaggio
: DataBase
ottieniServizioSyn( )
imbustaMsg( )
creaMessaggioSPC( )
setMessaggio( )
setPart( )
setTraccia( )
setTrack( )
serializzaMsg( )
writeDB( )
il messaggio
viene inviato
all'altra porta
di dominio
inviaMsg( )
sbustaMsg( )
smistaMsg( )
setTraccia( )
trasmettiRisposta( )
Figura 29: Sequence diagram del caso di comunicazione sincrona (trasmissione)
setTrack( )
writeDB( )
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Spiegheremo tra poco quello che succede nel lato erogatore quando viene ricevuto un
messaggio per un servizio di tipo “EGOV_IT_ServizioSincrono”; adesso ci si
limita a dire che l’erogatore gestisce la richiesta e invia sulla connessione rimasta aperta
una Busta di e-Government contenente i dati relativi al Servizio Applicativo richiesto.
Questa busta viene aperta, il messaggio viene controllato per appurare la validità, e
viene inviata una Risposta Applicativa all’Amministrazione che aveva effettuato la
richiesta.
Fatto ciò viene tracciata l’avvenuta ricezione del messaggio richiesto nel caso fosse
tornato un errore sarebbe stato inviato all’Amministrazione e sarebbe stato tracciato
allo stesso modo della risposta.
Dal lato erogatore (Figura 30), cioè la PDD remota all’arrivo di un messaggio SPCoop
vengono effettuate le stesse operazioni che si verificano in tutti i casi: vale a dire la
Busta di e-Government viene aperta, vengono effettuate tutte le operazioni di controllo
sulla validità della richiesta e la busta viene deserializzata in una serie di classi che la
rappresentano, viene controllato il contenuto delle parti di interesse, come mittente,
servizio richiesto, profili di collaborazione etc... questi dati indicheranno alla PDD
erogatrice la maniera nella quale si deve comportare.
In questo caso il profilo di collaborazione che viene incontrato è quello di tipo
“EGOV_IT_ServizioSincrono” ciò significa che dal lato del Dominio fruitore la
PDD sta aspettando una risposta.
La ricezione della richiesta viene tracciata e viene inviata all’Amministrazione
erogatrice la richiesta di servizio, essendo un servizio di tipo sincrono la richiesta viene
evasa in tempi brevi e dunque vengono iniziate dalla PDD erogatrice le operazioni di
79
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
ricostruzione di un nuovo messaggio SPCoop da inviare in risposta alla PDD del
Dominio fruitore.
Vengono settate le varie parti che vengono settate quando viene inviato un messaggio
SPCoop, in più la PDD fa attenzione che il campo RiferimentoMessaggio abbia
lo stesso valore del campo identificativo del messaggio di richiesta.
In verità non è molto utile che questo campo abbia un valore di questo tipo, visto che la
connessione non è stata chiusa la PDD fruitrice farà riferimento sui campi del
protocollo http.
Sarà invece di fondamentale importanza che il campo RiferimentoMessaggio
abbia un valore consistente nel caso di trasmissioni asincrone dove il messaggio http
non ha nessun valore per la PDD fruitrice.
Compilati tutti i campi il messaggio viene serializzato ed inviato alla PDD del Dominio
fruitore che gestisce l’arrivo del messaggio come si è spiegato in precedenza.
Come in ogni scambio di messaggi l’invio viene tracciato sulla base di dati.
80
: ControllorePorta
:
: ControlloreMarshaller : ControlloreMessaggio
: Messaggio
:
Amministrazion...
: DataBase
riceviMsg( )
sbustaMsg( )
il messaggio viene dalla
porta del fruitore
deserializzaMsg( )
creaMessaggioSPC( )
getMessaggio( )
getPart( )
smistaMsg( )
setTraccia( )
setTrack( )
writeDB( )
processaRichiestaSyn( )
imbustaMsg( )
serializzaMsg( )
creaMessaggioSPC( )
il messaggio dirisposta viene
inviato al fruitore
setMessaggio( )
setPart( )
inviaMsg( )
setTraccia( )
msgInviato( )
Figura 30: Sequence diagram del caso di comunicazione sincrona (ricezione)
setTrack( )
writeDB( )
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Nella figura seguente (Figura 31) è rappresentato il caso in cui all’interfaccia Delegata
della PDD arrivi un Messaggio Applicativo con il valore del campo profilo di
collaborazione “EGOV_IT_ServizioAsincronoSimmetrico”, in questo caso la richiesta
ha bisogno di una risposta che però non può arrivare in poco tempo, ma necessita di un
periodo abbastanza lungo per essere evasa.
In questo caso si è scelto di chiudere la connessione tra le PDD fruitrice ed erogatrice e
fare in modo che al completamento della richiesta da parte del Servizio Applicativo,
venga inviata la risposta dalla parte erogatrice alla parte fruitrice tramite un messaggio
SPCoop che faccia riferimento al messaggio di richiesta.
In Figura 31 sono riportate le operazioni che deve compiere il sistema fruitore quando
arriva una richiesta di tipo “EGOV_IT_ServizioAsincronoSimmetrico”.
Come in tutti i casi, vengono effettuati i controlli sulla validità della Richiesta
Applicativa, e se l’esito è positivo vengono iniziate le operazioni di imbustamento:
viene dunque creata una istanza di Messaggio SPCoop che rispetti le specifiche della
Busta di e-Government, vengono raccolti tutti i dati che vanno poi inseriti nel
messaggio, vengono di seguito settati i valori dei campi interessanti, il messaggio viene
poi serializzato in una stringa XML e viene inviato alla Porta del Dominio erogatore.
Dopo aver inviato il messaggio SPCoop, l’operazione viene tracciata, la connessione tra
i due Domini viene chiusa e vengono effettuate una serie di operazioni che
differenziano il caso asimmetrico dai casi precedenti.
Viene infatti pubblicato sulla PDD del Dominio fruitore un Servizio Applicativo atto
alla ricezione di messaggi di risposta per la richiesta effettuata.
In seguito vedremo quello che accade nel dominio erogatore, per ora ci si limita a dire
che la richiesta viene evasa dal Servizio Applicativo che era stato invocato e viene
82
:
Amministrazion...
:
: ControlloreMessaggio : ControllorePorta
:
: Messaggio
: DataBase
ottieniServSynSim( )
imbustaMsg( )
creaMessaggioSPC( )
setMessaggio( )
setPart( )
setTraccia( )
setTrack( )
writeDB( )
serializzaMsg( )
inviaMsg( )
il messaggio
viene inviato
all'altra porta
di dominio
pubblicaServizioRicezione( )
sbustaMsg( )
smistaMsg( )
setTraccia( )
Figura 31: Sequence diagram del caso di comunicazione asincrona simmetrica (trasmissione)
setTrack( )
writeDB( )
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
inviata la risposta al nuovo Servizio Applicativo che è stato pubblicato sulla Porta del
Dominio erogatore.
Tornando invece a parlare di ciò che succede sul lato fruitore, si vede che quando arriva
la risposta asincrona, il messaggio viene sbustato, vengono controllati i campi di
interesse come ProfiloCollaborazione e RiferimentoMessaggio per
vedere a quale richiesta fa riferimento il messaggio di risposta.
Appurata l’appartenenza del messaggio, viene inviata la risposta applicativa
all’Amministrazione che aveva effettuato la richiesta e viene tracciata l’operazione.
Ciò che accade sul lato erogatore è riportato nella prossima figura (Figura 32).
All’evento di ricezione di un Messaggio SPCoop vengono effettuati i controlli sulla
validità del Messaggio Applicativo, poi viene creata una istanza di messaggio dentro la
quale viene deserializzato il messaggio XML ricevuto.
Vengono controllati i campi di interesse in modo che la PDD possa decidere quale
comportamento assumere, in questo caso la connessione con l’altra PDD viene
terminata, poi viene tracciato lo scambio avvenuto e viene invocato il servizio
Applicativo Asimmetrico richiesto.
Quando il servizio viene erogato, la risposta deve essere trasmessa, viene dunque
effettuata una lettura sulla base di dati per vedere quale sia il riferimento del messaggio
di richiesta in modo da poter impostare il campo RiferimentoMessaggio in
maniera consistente.
Viene dunque creata una istanza di Messaggio e vengono inseriti i vari campi, il
messaggio viene poi serializzato in una stringa XML che rispetti le specifiche della
Busta di e-Gov ed inviato al Servizio Applicativo schierato (da deploy inglese) per
ricevere questa risposta Applicativa.
84
: ControllorePorta
:
: Messaggio
:
Amministrazion...
: DataBase
riceviMsg( )
sbustaMsg( )
porta del fruitore
deserializzaMsg( )
creaMessaggioSPC( )
getMessaggio( )
getPart( )
smistaMsg( )
setTraccia( )
setTrack( )
writeDB( )
processaRichiestaAsynSimm( )
l'amministrazione locale fornisce il
servizio richiesto dal fruitore
getTraccia( )
getTrack( )
readDB( )
contollaTracciatura( )
imbustaMsg( )
serializzaMsg( )
creaMessaggioSPC( )
il messaggio dirisposta viene
inviato al fruitore
setMessaggio( )
setPart( )
inviaMsg( )
setTraccia( )
setTrack( )
writeDB( )
msgInviato( )
Figura 32: Sequence diagram del caso di comunicazione asincrona simmetrica (ricezione)
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Fatto ciò l’operazione viene tracciata sul database e la connessione tra i due Domini
viene chiusa.
Sul lato fruitore, dopo il ricevimento del messaggio SPCoop, dopo l’avvenuta risposta
Applicativa, il Servizio Applicativo di ricezione delle risposte Asimmetriche viene
ritirato (da undeploy) dalla Porta.
L’ultimo profilo di collaborazione che viene definito nelle specifiche SPCoop è quello
di tipo Asincrono Asimmetrico.
Nella prossima figura (Figura 33) si può vedere come si comporta il lato fruitore di
fronte ad una richiesta per un servizio di questo tipo. A grandi linee, il comportamento
tenuto dal fruitore è lo stesso del caso Asincrono Simmetrico appena visto; infatti la
differenza tra i due casi si ha dopo l’invio della richiesta, in questo caso, inviata la
richiesta, la connessione viene sempre chiusa e viene schierato un servizio differente da
quello richiesto tra i due Domini, come succedeva nel caso precedente. Questo nuovo
Servizio Applicativo viene posto in essere sulla PDD del Dominio erogante, ed è un
servizio che serve al Dominio fruitore per avere notizie sullo stato del servizio o per
accedere alla risposta del servizio asincrono richiesto in precedenza.
Nella prossima figura (Figura 33) si può vedere nel Sequence Diagram il
comportamento della PDD sul lato fruitore all’arrivo di un Messaggio Applicativo
contenente una richiesta per un servizio di tipo Asincrono Asimmetrico.
All’arrivo della richiesta Applicativa vengono effettuate le operazioni di verifica della
validità della richiesta; viene controllato se esiste un servizio fruibile che coincide con
quello richiesto nel Messaggio Applicativo con le specifiche richieste.
86
:
:
Amministrazion...
: ControlloreMessaggio : ControllorePorta
:
: Messaggio
: DataBase
ottieniServSynAsim( )
imbustaMsg( )
creaMessaggioSPC( )
setMessaggio( )
setPart( )
setTraccia( )
setTrack( )
writeDB( )
serializzaMsg( )
il messaggio
viene inviato
all'altra porta
di dominio
inviaMsg( )
sbustaMsg( )
smistaMsg( )
setTraccia( )
Figura 33: Sequence diagram del caso di comunicazione asincrona asimmetrica (trasmissione)
setTrack( )
writeDB( )
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Nella fase successiva, vengono avviate le operazioni di imbustamento, cioè vengono
raccolti i dati che servono per compilare i campi che la Busta di e-Government utilizza
per veicolare le richieste in maniera corretta, vengono raccolti dunque i dati su tempo di
sistema, mittente, destinatario, profilo di collaborazione servizio richiesto etc.
Viene poi creata una istanza di messaggio ed il Messaggio SPCoop di richiesta inizia a
prendere forma con i vari set dei campi di interesse i cui valori erano stati raccolti in
precedenza; importante è sottolineare che il campo ProfiloCollaborazione
viene impostato con un valore “EGOV_IT_ServizioAsincronoAsimmetrico”.
Questo valore dirà poi all’erogatore come comportarsi all’arrivo della richiesta.
L’istanza di messaggio con i valori che erano stati raccolti viene poi serializzata in una
stringa XML e questa stringa viene inviata alla PDD del Dominio erogatore.
Dopo l’invio viene tracciata la comunicazione tra i due Domini Applicativi.
Esamineremo nei paragrafi seguenti quello che succede nella parte erogatrice. Per ora è
sufficiente dire che la richiesta viene inviata all’Amministrazione che eroga il Servizio
Applicativo che a sua volta mette in essere un servizio di richiesta di stato e manda in
risposta all’Amministrazione fruitrice un messaggio di acknowledgement.
Alla ricezione dell’acknowledgement la PDD fruitrice comunica l’avvenuta risposta di
Accettazione della richiesta con i dati relativi all’Amministrazione che aveva effettuato
l’invio del Messaggio Applicativo.
Quando la parte fruitrice vorrà ricevere la risposta o accedere allo stato del servizio, se
la risposta non è ancora pronta, le operazioni da svolgere sono quelle citate per il caso
di una richiesta Sincrona Simmetrica con la differenza che il servizio da contattare è
quello schierato per accedere allo stato di processamento dell’altra richiesta e che nel
campo
ProfiloCollaborazione
ci
sarà
il
valore
“EGOV_IT_ServizioAsincronoAsimmetrico”.
88
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Alla ricezione di uno stato o della effettiva risposta avverranno tutti i tracciamenti soliti
e le operazioni che si verificano in qualsiasi risposta Sincrona Simmetrica.
Sul lato erogatore invece il comportamento è leggermente più complesso di quello degli
altri casi. La prossima figura (Figura 34) illustra ciò che avviene quando ad una PDD
arriva una richiesta di tipo Asincrono Asimmetrico.
Quando ad una PDD arriva un Messaggio SPCoop, la prima cosa che succede è la
verifica di validità del messaggio.
Effettuata questa operazione, viene creata una istanza di messaggio e la stringa che è
arrivata dalla PDD remota viene deserializzata in questa istanza.
I dati della Busta di e-Gov ricevuta vengono analizzati dalla PDD erogatrice per capire
il
comportamento
da
seguire,
dunque
viene
controllato
il
campo
ProfiloCollaborazione affinché la Porta decida il comportamento da tenere.
Quando
il
valore
di
è
uguale
a
“EGOV_IT_ServizioAsincronoAsimmetrico” la PDD deve comportarsi come
segue:
innanzitutto la ricezione del messaggio deve essere tracciata con tutti i valori relativi a
mittente, destinatario, servizio richiesto e sopratutto deve essere impostato il campo
RiferimentoMessaggio, che poi servirà quando verranno gestite le richieste di
stato;
•
effettuata la tracciatura la PDD erogatrice sottomette un messaggio di richiesta
di servizio all’Amministrazione interna al Dominio che effettivamente eroga il
servizio.
89
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
In seguito a questa operazione, sulla PDD viene pubblicato il servizio di
ricezione delle richieste di stato per quel Servizio Applicativo;
•
a questo punto la prima parte della comunicazione sembra conclusa, e lo stato
del sistema presenta un servizio in ricezione di richieste di stato sulla PDD
erogatrice per la richiesta Asincrona Asimmetrica che era stata effettuata in
precedenza.
Qui inizia la seconda parte della comunicazione, nel momento in cui alla Porta del
Dominio erogatore arriva una richiesta di stato per una richiesta di tipo Asincrono
Asimmetrico; vengono innanzitutto effettuate le operazioni di verifica del Messaggio
SPCoop che arriva, poi viene creata l’istanza di messaggio sulla quale viene poi
deserializzata la stringa XML che è arrivata alla PDD. Vengono controllate le parti
relative alla tracciatura, cioè ProfiloCollaborazione, mittente, destinatario ma
sopratutto RiferimentoMessaggio, parte fondamentale con il fine di identificare
l’operazione cui fa riferimento la richiesta di stato arrivata.
Con questi dati si interroga la base di dati delle tracciature per verificare se esiste e
quale è la richiesta a cui si fa riferimento.
Se viene trovata una corrispondenza si prosegue come si vede sul sequence diagram
altrimenti viene inviato un messaggio di errore.
La tracciatura che viene ricevuta come risposta dalla base di dati, viene controllata al
fine di smistare il messaggio all’Amministrazione che si occupa di erogare il servizio al
quale si fa riferimento. Viene dunque trasmesso un Messaggio Applicativo
all’Amministrazione per richiedere lo stato del servizio precedentemente invocato.
90
: ControllorePorta
riceviMsg( )
:
: Messaggio
:
Amministrazion...
sbustaMsg( )
deserializzaMsg( )
creaMessaggioSPC( )
porta del fruitore
getMessaggio( )
getPart( )
smistaMsg( )
setTraccia( )
setTrack( )
processaRichiestaAsynAsym( )
pubblicaServizioAccesso( )
l'amministrazione locale fornisce il
servizio richiesto dal fruitore
riceviMsg( )
sbustaMsg( )
writeDB( )
deserializzaMsg( )
creaMessaggioSPC( )
getMessaggio( )
getPart( )
getTraccia( )
getTrack( )
contollaTracciatura( )
readDB( )
smistaMsg( )
processaRichiestaAsynAsym( )
imbustaMsg( )
setTraccia( )
setTrack( )
writeDB( )
serializzaMsg( )
il messaggio di risposta viene
inviato al fruitore
creaMessaggioSPC( )
setMessaggio( )
inviaMsg( )
setPart( )
setTraccia( )
setTrack( )
msgInviato( )
Figura 34: Sequence diagram del caso di comunicazione asincrona asimmetrica (ricezione)
writeDB( )
: DataBase
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Fatto ciò si eseguono le operazioni di tracciatura dell’avvenuto scambio di messaggi,
come accade in tutti gli scambi di messaggi.
La richiesta di stato viene processata dall’Amministrazione e vengono trasmessi lo stato
o la risposta del servizio alla parte fruitrice sempre tramite una Busta di e-Government
che viene costruita istanziando un messaggio, compilando le varie parti e poi
serializzando il messaggio in una stringa XML che rappresenti la risposta.
Lo scambio di messaggi viene tracciato sulla base di dati.
Nei diagrammi delle pagine precedenti si è deciso espressamente di considerare solo i
casi nei quali le PDD non si debbano trovare a gestire errori. Essendo questa una “proof
of concept” si è ritenuto ridondante gestire tutti i possibili errori che possono verificarsi
in una comunicazione tra PDD e tra PDD e Amministrazioni.
4.2.4 Architettura modulare
La Porta di Dominio è quel componente logico che si occupa di effettuare le operazioni
di gestione della Busta di e-Gov, delle tracciature, dei messaggi diagnostici, del SOAP
with Attachments e della modalità in consegna affidabile.
Inoltre la Porta di Dominio deve avere funzionalità di gestione della Security e di
Consolle di Monitoraggio, sia evoluta che di base.
Non è detto che una PDD debba contenere i Servizi Applicativi che effettivamente
vengono erogati dalle Porte, anzi molto spesso questi software che erogano servizi
saranno dislocati in siti differenti dalla Porta. Questo disaccoppiamento tra PDD e
servizi erogati rende la Porta distribuibile su sistemi ed architetture differenti, e
sopratutto permette a questo componente di essere utilizzato per erogare servizi di
qualsiasi tipo.
La PDD, infatti, spesso avrà funzione di proxy o dispatcher verso altre PDD o altre
piattaforme erogatrici presso le quali i servizi sono effettivamente realizzati.
92
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Sono previste due tipologie di servizio in base alle funzionalità implementate: Servizio
di Porta Applicativa Light e Servizio di Porta Applicativa Advanced.
Il servizio di Porta Applicativa Light implementa le seguenti caratteristiche:
•
•
Funzionalità di base
o
Gestione Busta e-gov
o
Gestione Tracciatura
o
Gestione Diagnostici
o
Gestione SOAP with Attachments
o
Gestione modalità consegna affidabile
Gestione della Sicurezza
o
•
Sicurezza di Base SSL
Consolle di Monitoraggio
o
Consolle base
Il servizio di Porta Applicativa Advanced implementa le seguenti caratteristiche
•
Funzionalità di base
o
Gestione Busta e-gov
o
Gestione Tracciatura
o
Gestione Diagnostici
o
Gestione SOAP with Attachments
o
Gestione modalità consegna affidabile
93
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
•
•
Gestione della Sicurezza
o
Sicurezza di Base SSL
o
Sicurezza avanzata Wsse:Security
Consolle di Monitoraggio
o
Consolle evoluta
Per l’erogazione di questi servizi devono essere gestite diverse casistiche che si
possono verificare nel dominio.
Nelle specifiche pubblicate dal CNIPA vengono esaminati:
•
il caso nel quale la porta deve effettuare l’acquisizione di Messaggi
Applicativi37, ricevuti dai Servizi Applicativi presenti all’interno del Dominio;
•
il caso nel quale la porta deve inoltrare un Messaggio Applicativo ad un altro
Dominio destinatario;
•
il caso in cui la Porta riceve un messaggio e dunque deve gestire i Messaggi
SPCoop38 provenienti dalle altre Porte di Dominio secondo le specifiche della
Busta di e-Gov;
•
il caso in cui la Porta deve smistare i Messaggi Applicativi ai servizi presenti
all’interno del Dominio;
37
Messaggio Applicativo: Rappresenta i dati che vengono scambiati tra un Servizio Applicativo e la Porta
di Dominio. Il messaggio deve essere costruito secondo una sintassi predefinita che dipente dagli
standard e dalle tecnologie utilizzate all’interno del Dominio (es. messaggio soap, rmi, chiamata a
procedura ecc). Il messaggio contiene oltre ai dati di interesse del servizio applicativo (Payload
Applicativo), anche i dati necessari affinchè la Porta di Dominio possa attivare le proprie funzionalità
secondo quanto richiesto del Servizio Applicativo. I Messaggi Applicativi possono contenere dati relativi
ad una richiesta, oppure ad una risposta applicativa.
38
Messaggio SPCoop: Rappresenta i dati che vengono scambiati tra le Porta di Dominio e deve essere
implementato secondo le specifiche della Busta di e-Gov. Tale messaggio contiene nella header i dati
necessari per il colloquio tra le Porte e nel body (o in allegato) il Payload Applicativo.
94
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
•
il caso in cui la PDD deve gestire i Messaggi d’Errore che arrivano e smistarli ai
Servizi Applicativi destinatari;
•
il caso nel quale la porta deve gestire (generare e sollevare) gli errori derivanti
da problemi in fase di gestione della busta stessa;
•
il caso in cui la PDD deve gestire i SOAP:FAULT (non contenuti in Messaggi
di Errore SPCoop39) generati automaticamente dal Soap Server destinatario a
seguito di richieste relative a profili di collaborazione “Richiesta/risposta”;
•
il caso in cui la Porta deve gestire i log delle operazioni effettuate;
•
il caso in cui la Porta deve gestire i Messaggi Diagnostici40 generati;
•
il caso in cui la PDD deve gestire l’allineamento al tempo di sistema.
Vengono descritte qui di seguito con maggiore dettaglio le operazioni che la PDD va ad
effettuare in ognuno di questi casi.
La seguente parte è una interpretazione personale delle specifiche CNIPA, da questa
interpretazione sono poi state tratte le conclusioni per la definizione del sistema e per
l’implementazione della “proof of concept”.
4.2.4.1
Acquisizione
Quando alla PDD arriva un Messaggio Applicativo da un servizio interno al Dominio la
Porta lo va ad acquisire. Innanzitutto deve identificare il Servizio Applicativo che ha
generato il Messaggio Applicativo, verificare la correttezza del formato del Messaggio
Applicativo ricevuto secondo la sintassi e le modalità di interazione dell’interfaccia
utilizzata, tracciare il Messaggio Applicativo ricevuto, identificare la tipologia del
messaggio ricevuto ed i relativi parametri; nel caso sia una richiesta di servizio
applicativo deve contenere la Parte richiedente, la Parte che eroga il servizio,
39
Messaggio d’errore SPCoop:
Messaggio SPCoop che presenta nel body solo l’elemento
SOAP:FAULT.
40
Messaggio Diagnostico: Messaggio che ogni Funzione della Porta di Dominio emette in
corrispondenza all’occorrenza di un evento di rilievo prestabilito. I Messaggi Diagnostici sono utili per
monitorare il comportamento delle Funzioni della Porta di Dominio.
95
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
l’identificativo del Servizio Applicativo da invocare, i dati applicativi della richiesta e il
profilo di collaborazione richiesto.
Se invece si tratta di una risposta Applicativa deve contenere la Parte che eroga il
Servizio Applicativo, la Parte che ha richiesto il servizio, l’identificativo del Servizio
Applicativo erogato, i dati applicativi della risposta, il profilo di collaborazione
richiesto.
La Porta di Dominio deve emettere un Messaggio Diagnostico che indichi la ricezione
del Messaggio Applicativo.
Se la PDD verifica un errore nel Messaggio Applicativo, o nel caso di anomalia in fase
di ricezione dello stesso, la PDD deve inviare al Servizio Applicativo mittente un
Messaggio di Errore Applicativo41; la Porta di Dominio deve emettere un Messaggio
Diagnostico che indichi l’eccezione.
4.2.4.2
Inoltro
Nel caso arrivi alla PDD un Messaggio Applicativo da inoltrare ad un Dominio esterno
la Porta deve generare un Messaggio SPCoop secondo le specifiche della Busta di eGov (Fase di Imbustamento); deve poi generare il Messaggio SPCoop da inviare al
Dominio destinatario, identificare univocamente il Messaggio SPCoop generato,
inserire nell’elemento IdentificativoParte (IdentificativoParte è una
parte del messaggio definito nella Busta di e-gov) del Mittente l’identificativo della
Parte mittente, deve poi generare il valore da assegnare all’elemento Identificatore del
Messaggio SPCoop, inserire nell’elemento OraRegistrazione l’ora di creazione
dell’header, identificare il destinatario del Messaggio SPCoop ed inserire nell’elemento
IdentificativoParte del Destinatario l’identificativo della Parte destinataria del
Messaggio SPCoop; la Porta di Dominio deve poi determinare la URI destinatario del
Messaggio SPCoop e dunque dovrebbe inserire, nell’elemento Servizio, l’identificativo
41
Messaggio di Errore Applicativo: Messaggio generato dalla Porta di Dominio (dalle Funzioni della
Porta di Dominio) in corrispondenza del verificarsi di una anomalia o di una condizione di errore.
96
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
del Servizio Applicativo riferito dal Messaggio SPCoop, e nell’elemento Azione,
l’identificativo dell’azione richiesta nell’ambito del Servizio, inoltre deve gestire il
profilo di collaborazione richiesto dall’interazione, che:
•
nel caso di interazione di tipo “Richiesta senza risposta”, oppure “Notificazione
senza
risposta”
la
PDD
deve
inserire,
nell’elemento
ProfiloCollaborazione del Messaggio SPCoop da inviare, il valore
“EGOV_IT_MessaggioSingoloOneWay”,
•
nel caso di interazione di tipo “Richiesta/risposta” sincrona, oppure
“Notificazione/risposta”
sincrona
deve
inserire,
nell’elemento
ProfiloCollaborazione del Messaggio SPCoop da inviare, il valore
“EGOV_IT_ServizioSincrono”,
•
nel caso in cui il Messaggio SPCoop contenga la “risposta”, sebbene la
correlazione a livello di protocollo di trasporto http sia automatica, la Porta di
Dominio dovrebbe inserire, nell’elemento RiferimentoMessaggio, il
contenuto dell’elemento Identificatore del Messaggio SPCoop contenente la
relativa “Richiesta” o “Notificazione”; questa operazione è utile ai fini del
tracciamento.
•
Nel caso di interazione di tipo “Richiesta/risposta” asincrona, oppure
“Notificazione/risposta” asincrona la Porta di Dominio deve inserire,
nell’elemento ProfiloCollaborazione del Messaggio SPCoop da
inviare, il valore “EGOV_IT_ServizioAsincronoSimmetrico”.
La PDD che prepara il Messaggio SPCoop contenente la “Richiesta” oppure la
“Notificazione” deve inserire, nell’attributo {servizioCorrelato} dell’elemento
ProfiloCollaborazione, l’identificativo del Servizio Applicativo preposto alla
ricezione della risposta; inoltre deve inserire, nell’attributo {servizioCorrelato}
dell’elemento ProfiloCollaborazione, il valore “SPC”.
97
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
La Porta di Dominio che prepara il Messaggio SPCoop contenente la “risposta” deve
correlare il messaggio di risposta alla relativa richiesta, inserendo l’identificatore del
Messaggio di e-Gov della relativa “Richiesta” o “Notificazione” nell’elemento
RiferimentoMessaggio del messaggio da inviare; oltre a fare ciò deve inserire,
nell’elemento ProfiloCollaborazione del messaggio da inviare, il valore
“EGOV_IT_ServizioAsincronoSimmetrico”.
La PDD deve inserire, nell’elemento Scadenza del Messaggio SPCoop, il periodo di
validità del Messaggio Applicativo sempre che sia indicato dal Servizio Applicativo;
deve anche accertarsi di inviare il Messaggio SPCoop alla Porta del Dominio della
Parte destinataria entro il periodo di validità del Messaggio Applicatico (se richiesto).
Il protocollo utilizzato da questo elemento logico deve essere l’http. Tra i compiti la
PDD deve inoltre di individuare l’URL del servizio da invocare,
indirizzare il
messaggio http alla URL del servizio, attivare le modalità di interazione con la Porta di
Dominio destinataria del Messaggio SPC secondo il profilo di collaborazione richiesto.
Nel caso di interazione di tipo “Richiesta senza risposta”, oppure “Notificazione senza
risposta”
(ProfiloCollaborazione
pari
a
“EGOV_IT_MessaggioSingoloOneWay”) la Porta di Dominio deve utilizzare lo
scambio elementare del tipo “messaggio senza risposta”, cioè la PDD inoltra il
Messaggio SPCoop alla PDD destinataria e resta in attesa della sola reply del protocollo
di trasporto http.
Nel
caso
di
interazione
di
sincrona
tipo
“Richiesta/risposta”
sincrona,
oppure
pari
a
“EGOV_IT_ServizioSincrono”) la Porta di Dominio deve utilizzare lo scambio
elementare di tipo “messaggio/replica sincroni”, cioè la PDD che inoltra il Messaggio
SPCoop contenente la “Richiesta”, oppure la “Notificazione” deve restare in attesa
della reply del protocollo di trasporto http contenente il Messaggio SPCoop di risposta;
98
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
la PDD che inoltra il Messaggio SPCoop contenente la “risposta” deve inserire tale
messaggio nella reply del protocollo di trasporto http relativa alla richiesta.
Nel
caso
di
interazione
di
tipo
asincrona
asincrona,
oppure
pari
a
“EGOV_IT_ServizioAsincronoSimmetrico”) la Porta di Dominio deve
utilizzare lo scambio elementare di tipo “messaggio/replica asincroni”, cioè la PDD
inoltra il Messaggio SPCoop alla Parte destinataria e resta in attesa della sola reply del
protocollo di trasporto http, la PDD deve tracciare il Messaggio SPCoop inoltrato.
La Porta di Dominio deve produrre un Messaggio Diagnostico contenente
l’identificativo del Messaggio SPCoop inoltrato, la Parte destinataria e l’esito della
trasmissione a livello HTTP.
Se la PDD non riesce ad inoltrare il Messaggio SPCoop alla Porta di Dominio
destinataria entro il periodo di validità del Messaggio Applicativo, deve allora inviare al
Servizio Applicativo mittente un Messaggio di Errore Applicativo e produrre un
opportuno Messaggio Diagnostico.
Se la PDD non riesce ad inoltrare il Messaggio SPCoop alla PDD destinataria deve
inviare al Servizio Applicativo mittente un Messaggio di Errore Applicativo e produrre
un opportuno Messaggio Diagnostico.
4.2.4.3
Ricezione
Un altro caso che può verificarsi nelle comunicazioni tra PDD è quello nel quale una
porta riceva Messaggi SPCoop provenienti dalle altre Porte di Dominio secondo le
specifiche della Busta di e-Gov: in questo caso la PDD deve tracciare la ricezione del
Messaggio SPCoop ricevuto, deve poi controllare la correttezza del messaggio stesso a
livello formale. La verifica formale non deve essere effettuata sul payload dei Servizi
Applicativi: body element e contenuto degli attachments. Se il Messaggio SPCoop
contiene un Messaggio di Errore SPCoop, la verifica deve essere effettuata anche sul
99
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
formato dell’unico elemento del Body, il SOAP:FAULT previsto dalle Specifiche della
Busta di e-Gov.
Quando viene ricevuto un Messaggio SPCoop la PDD deve produrre un Messaggio
Diagnostico che indichi la ricezione: questo dovrà contenere l’identificativo della Parte
Mittente e l’identificativo del Messaggio SPCoop ricevuto; nel caso il cui la Porta di
Dominio, durante il processamento del Messaggio SPCoop, rilevi un errore sintattico,
non deve processare ulteriormente il messaggio.
Le eccezioni sollevate dalla PDD devono essere riportate in un Messaggio Diagnostico
contenente la Parte mittente, l’identificativo del Messaggio SPCoop ricevuto e il codice
di eccezione previsti dalle specifiche della Busta di e-Gov. Se l’elemento del
ProfiloCollaborazione del Messaggio SPCoop ricevuto contiene il valore
“EGOV_IT_ServizioSincrono”
oppure
“EGOV_IT_ServizioAsincronoSimmetrico”,
l’eccezione
relativa
alla
Richiesta, oppure alla Notificazione deve essere comunicata alla Parte mittente
attraverso un Messaggio di Errore SPCoop che sostituisce il messaggio di risposta.
La PDD potrebbe effettuare dei controlli di consistenza del Messaggio SPCoop
ricevuto: per fare ciò potrebbe verificare che i valori contenuti nell’elemento
IdentificativoParte del Mittente, nell’elemento Identificatore del
messaggio
siano
ammissibili,che
il
valore
contenuto
nell’elemento
IdentificativoParte del Destinatario contenga il proprio identificativo, che il
valore contenuto nell’elemento opzionale Servizio contenga l’identificativo del servizio
applicativo riferito dal messaggio, che il valore contenuto nell’elemento opzionale
Azione contenga l’identificativo dell’operazione richiesta nell’ambito del Servizio.
In caso di anomalie, la Porta di Dominio non deve processare ulteriormente il
messaggio, ma deve emettere un Messaggio Diagnostico contenente l’identificativo
della Parte Mittente, l’identificativo del Messaggio SPCoop ricevuto e il codice (o i
codici) di eccezione come previsto nelle specifiche della Busta di e-Gov.
Se l’elemento del ProfiloCollaborazione del Messaggio SPCoop ricevuto
contiene
il
valore
oppure
100
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
“EGOV_IT_ServizioAsincronoSimmetrico”,
l’eccezione
relativa
alla
Richiesta, oppure alla Notificazione deve essere comunicata alla Parte mittente
attraverso un Messaggio di Errore SPCoop che sostituisce il messaggio di risposta.
4.2.4.4
Smistamento
Un altro tipo di azione che può trovarsi a svolgere una PDD è quella di smistamento, in
cui la PDD deve inoltrare i Messaggi Applicativi ai servizi applicativi destinatari
presenti all’interno del Dominio.
Quando la Porta di Dominio deve inoltrare il Messaggio Applicativo contenuto nel
Messaggio SPCoop al Servizio Applicativo destinatario, le modalità di identificazione
del Servizio Applicativo destinatario dipendono dall’Interfaccia di integrazione
utilizzata; la PDD deve gestire il profilo di collaborazione richiesto dall’interazione.
Se l’elemento ProfiloCollaborazione del Messaggio SPCoop ricevuto contiene
il valore “EGOV_IT_MessaggioSingoloOneWay” (interazione di tipo “Richiesta
senza risposta”, oppure “Notificazione senza risposta”) la PDD deve inviare alla PDD
mittente
solo
la
reply
del
trasporto
http;
se
invece
l’elemento
ProfiloCollaborazione del Messaggio SPCoop ricevuto contiene il valore
(interazione
di
tipo
sincrona, oppure “Notificazione/risposta” sincrona), la Porta di Dominio, deve adottare
lo scambio elementare di tipo “messaggio/replica sincroni”.
Se il Messaggio SPCoop ricevuto è relativo ad una “Richiesta”, oppure ad una
“Notificazione”, la Porta di Dominio deve attendere il Messaggio Applicativo di
risposta proveniente dal Servizio Applicativo indirizzato.
La Porta dovrebbe utilizzare l’identificativo del Messaggio SPCoop contenente la
“Richiesta”, oppure la “Notificazione”, per correlare il successivo Messaggio SPCoop
di “risposta”.
101
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Se l’elemento ProfiloCollaborazione del Messaggio SPCoop ricevuto contiene
il valore “EGOV_IT_ ServizioAsincronoSimmetrico” (interazione di tipo
“Richiesta/risposta” asincrona, oppure “Notificazione/risposta” asincrona), la Porta di
Dominio deve adottare lo scambio elementare di tipo “messaggio/replica asincroni” e
inviare alla PDD mittente solo la reply del trasporto http.
Se il Messaggio SPCoop ricevuto è relativo ad una “Richiesta” oppure ad una
“Notificazione”, la Porta di Dominio dovrà attendere il successivo Messaggio
Applicativo di risposta proveniente dal Servizio Applicativo indirizzato, gestire
l’identificativo del Messaggio SPCoop contenente la “Richiesta” o la “Notificazione”,
per correlare il successivo Messaggio SPCoop di “risposta”; deve poi gestire il
contenuto dell’ attributo {servizioCorrelato} del Messaggio SPCoop contenente la
“Richiesta”, oppure la “Notificazione” per indirizzare il successivo Messaggio SPCoop
di “risposta”.
In caso di errore nello smistamento, (es. il Servizio Applicativo destinatario non è
Disponibile), se l’elemento del ProfiloCollaborazione del Messaggio SPCoop
ricevuto
contiene
il
valore
oppure
“EGOV_IT_ServizioAsincronoSimmetrico”, la PDD deve inviare alla Parte
mittente un
messaggio di Errore SPCoop, emettere un Messaggio Diagnostico contenente
l’identificativo della Parte Mittente, l’identificativo del Messaggio SPCoop ricevuto e
il codice di eccezione rilevato.
4.2.4.5
Smistamento degli Errori
Un’altra funzione svolta da una PDD è quella di inoltrare un Messaggio Applicativo
Errore, dopo aver ricevuto un Messaggio di Errore SPCoop, al servizio applicativo
destinatario presente all’interno del Dominio.
102
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
In questo caso la PDD deve generare il Messaggio Applicativo Errore da inoltrare al
Servizio Applicativo destinatario; le modalità di identificazione del Servizio
Applicativo destinatario dipendono dall’Interfaccia di integrazione utilizzata.
Nel Messaggio Applicativo Errore devono essere riportati gli elementi SOAP:FAULT e
ListaEccezioni (se presente) contenuti nel Messaggio SPCoop Errore ricevuto.
4.2.4.6
Gestione eccezioni
Un’altra funzionalità che deve possedere la PDD è quella di poter generare un
Messaggio SPCoop Errore nel caso di eccezioni, gestite dalla Porta, sollevate durante la
fase di sbustamento oppure durante la fase di smistamento di Messaggi SPCoop
contenenti richieste di interazioni sincrone o asincrone di tipo “Richiesta/risposta”
oppure “Notificazione/risposta”.
In questo caso la PDD deve generare un Messaggio SPCoop Errore da inviare al
Dominio destinatario secondo le specifiche della Busta di e-Gov (Fase di Imbustamento
Errore SPCoop).
Se è stato rilevato un errore nella sintassi o nella semantica del tag Intestazione
dell’Header del Messaggio SPCoop contenente la richiesta, il corrispondente elemento
Eccezione, generato secondo le Specifiche della Busta di e-Gov, deve essere inserito
nella ListaEccezioni del Messaggio SPCoop Errore da inviare; l’attributo
{contestoCodifica}
dell’elemento
Eccezione
“ErroreIntestazioneMessaggioSPCoop”;
deve
assumere
il
valore
l’attributo
{codiceEccezione} dell’elemento Eccezione deve essere un opportuno codice
scelto tra quelli riportati nelle Specifiche della Busta di e-Gov; l’attributo
{rilevanza} dell’elemento Eccezione deve assumere il valore “GRAVE”; l’attributo
{posizione} dell’elemento Eccezione deve indicare l’elemento della Intestazione
che ha generato l’errore.
103
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Se è stato rilevato un errore nella fase di processamento del Messaggio SPCoop
contenente la richiesta, la ListaEccezioni del Messaggio SPCoop Errore da
inviare non deve essere presente.
Il body del Messaggio SPCoop di Errore deve contenere solo un elemento
SOAP:FAULT, se è stato rilevato un errore nella sintassi o nella semantica del tag
Intestazione dell’Header del Messaggio SPCoop contenente la richiesta, l’elemento
faultcode deve assumere il valore “soap:Client”; l’elemento faultstring deve assumere il
valore “EGOV_IT_001 - Formato Busta non corretto”; l’elemento opzionale faultactor,
se presente, deve rispettare le specifiche SOAP 1.1; l’elemento opzionale detail non
deve essere presente.
Se è stato rilevato un errore durante il processamento del Messaggio SPCoop
contenente la richiesta, l’elemento faultcode deve assumere il valore “soap:Server”;
l’elemento faultstring deve assumere il valore “EGOV_IT_300 – Errore nel
processamento del Messaggio SPCoop”; l’elemento opzionale faultactor, se presente,
deve rispettare le specifiche SOAP 1.1; l’elemento detail deve essere presente e deve
indicare ulteriori dettagli sull’errore verificatosi.
La PDD deve identificare univocamente il Messaggio SPCoop Errore generato; deve
inserire nell’elemento IdentificativoParte del Mittente del Messaggio SPCoop
Errore
l’IdentificativoParte
presente
nell’elemento
Destinatario
del
Messaggio SPCoop ricevuto; deve generare il valore da assegnare all’elemento
Identificatore del Messaggio SPCoop Errore e infine inserire nell’elemento
OraRegistrazione del Messaggio SPCoop Errore l’ora di creazione della header.
La Porta deve inserire, nell’elemento IdentificativoParte del Destinatario del
Messaggio SPCoop Errore, l’IdentificativoParte presente nell’elemento
Mittente del Messaggio SPCoop ricevuto.
Dovrebbe inoltre inserire, nell’elemento Servizio del Messaggio SPC Errore,
l’identificativo del Servizio Applicativo riferito dal Messaggio SPC ricevuto.
La PDD dovrebbe inserire nell’elemento Azione del Messaggio SPCoop Errore,
l’identificativo
dell’azione
riferita
dal
Messaggio
SPCoop
ricevuto,
invece
104
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
nell’elemento ProfiloCollaborazione del Messaggio SPCoop Errore, deve
inserire il valore dello stesso elemento presente nel Messaggio SPCoop ricevuto.
Dovrebbe poi inserire, nell’elemento RiferimentoMessaggio del Messaggio
SPCoop Errore, il contenuto dell’elemento Identificatore del Messaggio
SPCoop ricevuto; questa operazione è utile in fase di tracciamento.
La Porta di Dominio deve inviare il Messaggio SPCoop Errore alla Porta del Dominio
della Parte destinataria (Fase di Inoltro dell’Errore SPCoop) utilizzando il protocollo di
connessione http e inserendo il Messaggio SPCoop Errore nella reply di http relativa al
Messaggio SPCoop di richiesta che ha generato l’eccezione.
La PDD deve poi tracciare il Messaggio SPCoop Errore inoltrato, produrre un
Messaggio Diagnostico contenente l’identificativo del Messaggio SPCoop inoltrato e la
Parte destinataria, e l’esito della trasmissione a livello HTTP.
Se la Porta di Dominio non riesce ad inoltrare il Messaggio SPCoop Errore alla Porta di
Dominio destinataria, deve produrre un opportuno Messaggio Diagnostico.
4.2.4.7
Gestione dei SOAP:FAULT
Un’altra funzionalità che deve possedere la PDD è la gestione dei SOAP:FAULT (non
contenuti in Messaggi di Errore SPCoop) generati automaticamente dal Soap Server
destinatario
a
seguito
di
richieste
relative
a
profili
di
collaborazione
“Richiesta/risposta”.
La correlazione tra il SOAP:FAULT ed il messaggio contenente la richiesta deve essere
effettuata utilizzando le proprietà di sincronismo dei messaggi del protocollo http.
La PDD deve produrre un Messaggio Diagnostico che indichi la ricezione del
SOAP:FAULT e deve generare il Messaggio Applicativo Errore da inoltrare al Servizio
Applicativo destinatario; le modalità di identificazione del Servizio Applicativo
destinatario dipendono dall’Interfaccia di integrazione utilizzata.
Inoltre nel Messaggio Applicativo Errore devono essere riportati gli elementi del SOAP
Fault.
105
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
4.2.4.8
Gestione dei log
Importante è anche la gestione dei log dei Messaggi SPCoop ricevuti/inviati.
La Porta deve garantire la persistenza e consentire l’export dei messaggi tracciati,
queste funzionalità devono essere gestite attraverso parametri di configurazione e
comandi inoltrati da una console di I/O.
Il comando di export può specificare i criteri di selezione delle tracce (es. il periodo
temporale, la Parte mittente, la tipologia di messaggi, il servizio applicativo oggetto del
messaggio ecc.) ed il supporto da utilizzare. Il comando per la gestione della
persistenza può modificare i parametri relativi, quali il periodo di backup, il supporto da
utilizzare per lo storage ecc.
4.2.4.9
Gestione dei messaggi diagnostici
Oltre ai log devono essere gestiti dalla PDD anche i Messaggi diagnostici generati.
Il testo dei Messaggi Diagnostici prodotti ed il relativo livello di severità deve essere
configurabile. I Messaggi Diagnostici hanno un livello di severità compreso tra 0 e 7, in
cui l’importanza di un Messaggio Diagnostico è inversamente proporzionale al livello
di severità.
La Porta deve essere dotata di una Funzione preposta alla gestione dei Messaggi
Diagnostici che garantisca la persistenza dei messaggi prodotti internamente e consenta
l’export dei messaggi diagnostici storicizzati.
I Messaggi Diagnostici devono essere inviati alla Console di Monitoring che riceve i
Messaggi Diagnostici caratterizzati da un livello di severità di default.
La Consolle di Monitoring può impostare un filtro sulle caratteristiche dei Messaggi
Diagnostici che desidera ricevere, il filtraggio può essere attivato per livello di severità,
per identificativo del produttore o per entrambi i criteri.
Le funzionalità di persistenza, di export o di filtraggio devono essere gestite attraverso
comandi ( Order Message) inviati dalla Consolle di Monitoring.
106
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
4.2.4.10 Funzionalità aggiuntive
Altre funzionalità della PDD sono quelle di allineare il tempo di sistema al riferimento
temporale di rete, di gestione della sicurezza a livello connessione (SSL, TLS), di
gestione dello smistamento a livello porta, di gestione della sicurezza a livello porta
(WS-Security).
L’architettura SPCoop prevede che esistano due tipi di porte di dominio: Porte
Applicative e Porte Delegate.
Una Porta Applicativa è quella porta che effettivamente si interfaccia con l’erogatore
del servizio Applicativo richiesto, la Porta Delegata invece è la PDD alla quale il
fruitore si rivolge per fruire il servizio Applicativo che viene erogato remotamente.
Questa divisione tra Porta Delegata e Porta Applicativa può essere solo a livello logico.
Infatti, la PDD che interfaccia un Dominio con il resto del Sistema Pubblico di
Connettività può svolgere funzioni di Porta Applicativa per i fruitori che desiderano
interfacciarsi con Servizi Applicativi erogati dal Dominio e come Porta Delegata per gli
utenti del Dominio stesso che vogliono usufruire di servizi erogati da altri domini.
Lo scopo è quello di rendere la fruizione dei servizi il più possibile trasparente in modo
tale che gli utenti possano fruire alla stessa maniera di servizi “locali” al Dominio e di
servizi “remoti”, dando all’utente l’idea che tutti i servizi risiedano sulla propria PDD.
Dopo queste spiegazioni risulteranno sicuramente più chiari i meccanismi di
cooperazione che venivano accennati nell’esempio del capitolo introduttivo.
La PDD è dunque il componente architetturale preposto alla gestione della busta e-Gov
ed alla implementazione delle funzionalità ad essa relative: verifica formale e gestione
del contenuto del campo Intestazione.
107
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
In ricezione provvede alle attività di controllo formale, sbustamento ed instradamento
delle richieste verso i servizi applicativi.
In trasmissione provvede alla formazione della busta e-Gov ed alla trasmissione verso il
destinatario.
Inoltre gestisce la sicurezza a livello di connessione SSL3 o TLS e di messaggio SOAP
(WS-Security), fornisce servizi di consolle di comando e configurazione e servizi di
gestione dei messaggi diagnostici.
Dalla rilettura delle specifiche, notando l’attinenza dell’architettura del sistema a quella
di una SOA, ed in particolare notando che la Porta di Dominio può essere vista come
l’interfaccia sulla quale vengono pubblicati i Servizi Applicativi, si è scelto di costruire
la PDD come un servizio Web Che effettui funzione di Proxy: cioè si occupi di
imbustare e sbustare richeste applicative utilizzando il protocollo definito dalla Busta di
e-Gov.
Per costruire una Porta che rispecchi le specifiche sopra citate si è notata la necessità di
costruire un sistema del tipo di Figura 35.
108
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Figura 35: Architettura della Porta di Dominio
Che sia fatto cioè di un Application Server che funga da Servlet container, da un Web
Service engine che gestisca il protocollo SOAP e permetta lo schieramento dei servizi
sull’Application Server.
Inoltre per la gestione della Busta di e-Gov nella parte che estende la busta SOAP cioè
l’header si è notata la necessità di un serializzatore di stringhe XML.
La gesione dei vari profili di collaborazione definiti dalla Busta di e-Gov (cfr. §3.5) ha
sollevato la necessità di progettare una architettura il più possibile modulare.
Nel caso della comunicazione a messaggio singolo (cfr. §4.2.3) può sembrare
ridondante l’utilizzo di molte classi per svolgere quello che può sembrare la lettura di
una stringa XML ma ognuna delle classi identificate svolge un compito fondamentale
al fine del lavoro che viene effettuato per la gestione della Busta ed negli altri profili di
collaborazione ci si rende conto di quanto sia utile rendere il software modulare per
gestire meglio delle operazioni così articolate (cfr. §4.2.3).
109
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Nelle prossime pagine vedremo gli strumenti che sono stati scelti e daremo la
motivazione delle scelte effettuate.
4.2.5 Strumenti utilizzati
Vista l’attinenza del progetto di una Porta di Dominio a sistemi di tipo SOA
(Architetture Orientate ai Servizi) è sembrata una scelta ottimale improntare lo sviluppo
della PDD come un sistema di gestione di Servizi Web.
Come già detto, i Web Services stanno prendendo largamente piede nello sviluppo di
nuove tecnologie che utilizzano la rete grazie alla loro propensione all'interoperabilità
tra diverse applicazioni software su diverse piattaforme hardware, grazie al fatto che
utilizzando standard e protocolli "open" che li rendono di facile comprensione ed
utilizzo da parte degli sviluppatori, e alla tendenza ad essere facilmente integrabili in
servizi già esistenti.
Visto l’utilizzo e lo sviluppo che stanno avendo i Web Services nel mondo
dell’information technology esistono già implementazioni di motori di gestione per i
servizi web; è stato così deciso di basare la nostra “proof of concept” su uno di essi
poiché è inutile sviluppare nuovamente prodotti gia esistenti.
La Porta di Dominio infatti può essere vista come una serie di Web Services che vanno
a gestire la Busta di e-Gov nelle varie implementazioni di connessione e di
comunicazione tra PDD.
Altra considerazione da fare è quella che la Busta di e-Gov è una estensione della busta
SOAP e dunque perché gestire tutta la Busta SOAP quando ci si può concentrare
solamente sulla parte di estensione e gestire la parte standard tramite dei tool-kits già
presenti sul “mercato” open source?
110
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
La strada che ho scelto di percorrere è questa appena descritta e gli strumenti utilizzati
per percorrerla sono i seguenti:
•
Tomcat: Application Server adatto alla gestione di JSP / Servlet Engine
•
AXIS: motore di gestione per Web Services
•
JAXB: librerie per la serializzazione e deserializzazione del protocollo XML
Si farà ora una piccola panoramica sulle funzionalità di questi strumenti al fine di dare
al lettore la possibilità di capire perché sono state effettuate tali scelte.
L’architettura del sistema che risulta dall’integrazione dei tre elementi di cui sopra
risulta quella di Figura 36.
Figura 36: Strumenti utilizzati per realizzare l’architettura della Porta di Dominio
111
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
4.2.5.1
Tomcat
Tomcat, anche noto come Jakarta Tomcat, dall'omonimo progetto in seno alla Apache
Software Foundation, è un JSP / Servlet Engine.
Oltre alle funzionalità HTTP statiche offerte da altre applicazioni simili (come lo stesso
web server Apache), Tomcat è in grado di fungere da contenitore e di eseguire le
servlet o Java Server Pages (JSP): specifiche di Sun Microsystems. Questo lo rende in
grado quindi di supportare e processare pagine web dinamiche. Spesso, per questo
motivo, Tomcat viene usato in abbinamento ad Apache, lasciando al secondo il compito
di processare le pagine statiche e occupandosi solo dei contenuti dinamici.
Tomcat è scritto interamente in Java ed è un progetto open source, rilasciato sotto
licenza Apache Software License. Esso può quindi essere eseguito su qualsiasi
architettura supporti un JVM.
Visto che si è scelto di sviluppare i Web Services di cui sarà fatta la porta in JAVA,
Tomcat sembra il server più adatto a gestire questo tipo di sviluppo.
4.2.5.2
AXIS
AXIS è un progetto che nasce in seno a Tomcat, prodotto da Apache Software
Foundation.
AXIS è un toolkit che implementa il protocollo SOAP e si è dimostrato essere una
ottima base sulla quale implementare Servizi Web in Java.
AXIS supporta molte funzionalità:
•
Supporto per SOAP 1.1. Ad esempio viene supportato il concetto degli header
mustUnderstand SOAP.
112
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
•
Supporto per la gestione di XML tramite SAX (Simple API for XML) che lo
rende più rapido di quei toolkits che utilizzano DOM (Document Object
Model).
•
Supporto per la generazione del WSDL (Web Services Description Language)
dai servizi schierati. Inoltre ha la funzionalità di generare codice Java per lo
scheletro dei Servizi da documenti scritti in WSDL tramite il tool wsdl2java.
•
Supporto per lo sviluppo di servizi come EJB (Enterprise JavaBeans)
•
Supporto ad esporre come servizi, classi Java, semplicemente spostandoli nel
“motore” e pubblicando il servizio tramite un file di deploy.
Da quanto sopra elencato si può comprendere il perché delle scelte sia, il
processamento della busta SOAP sia la gestione dei Web Services, tramite AXIS.
Grazie ad AXIS ci si può concentrare sulla logica della PDD e non pensare ad
implementare la gestione di come le porte debbano essere interfacciate tra loro,
evitando tutti i problemi che potrebbero sorgere andandosi a scontrare con i vari
protocolli di rete di cui fa parte il protocollo SOAP.
Inoltre, in una visione futura, la funzionalità di AXIS di generare il WSDL direttamente
dal Web Service che è stato schierato sul server, potrebbe facilitare infinitamente il
lavoro di sviluppo dell’Accordo di Servizio e allo stesso tempo renderebbe
estremamente più semplice lo sviluppo delle applicazioni Web Server per
l’implementazione della PDD utilizzando il tool wsdl2java.
Anche le chiamate ai Web Services saranno più semplici attraverso l’utilizzo di AXIS,
infatti, è possibile effettuare chiamate ai Servizi Web tramite semplici chiamate a
classi.
113
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
4.2.5.3
JAXB
JAXB, acronimo di Java Architecture for XML Binding, rappresenta una maniera facile
di collegare uno “Schema” XML con una rappresentazione in codice Java. Grazie a
JAXB è facile utilizzare dati schematizzati in XML in applicazioni basate su codice
Java semplicemente utilizzando i dati come se fossero in classi Java.
In pratica JAXB semplifica la creazione e la manutenzione di applicazioni Java che
utilizzano XML.
JAXB fornisce un compilatore ed un framework a runtime per supportare la mappatura
bi-direzionale tra documenti XML ed oggetti Java. Il compilatore traduce gli Schema
XML in una o più classi Java in modo da evitare allo sviluppatore di fare classi
complesse che facciano il parsing e di concentrare la propria attenzione sulla vera e
propria logica del software che va a sviluppare.
Le classi generate tramite lo Schema ed il framework di collegamento a runtime
permettono di fare validazione sugli Schema XML che vengono passati al sistema.
Questo rende possibile che solo messaggi XML validi e senza errori possano essere
accettati dal sistema.
Ci sono diverse implementazioni di JAXB; tra tutte la scelta è ricaduta su JAXME che
è una implementazione open source che ha le stesse funzionalità previste dalle
specifiche di JAXB per il collegamento tra Java e XML. inoltre le classi generate
tramite JAXME possono:
•
salvare i Java bean in un database, preferibilmente database XML ma anche in
database relazionali come MySql;
•
fare query sui database per estrarre le istanze dei bean.
114
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
In poche parole semplicemente facendo uno Schema e dandolo in pasto al compilatore
JAXME.
Figura 37: Schema di funzionamento di JAXME
Automaticamente vengono generate le classi che implementano il completo workflow
di una applicazione Web.
115
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Figura 38: Schema di funzionamento del processo di serializzazione/deserializzazione
4.2.6 Realizzazione della libreria Busta di e-Gov
Molte delle operazioni che sono state descritte sopra possono essere effettuate
sfruttando gli strumenti elencati precedentemente.
Nello specifico è stato scelto Tomcat come Application Server in maniera da poter
utilizzare il tool-kit AXIS, che ci permette di operare in maniera del tutto trasparente a
tutta l’architettura di connessione ed ai vari protocolli di rete che permettono ai
messaggi di viaggiare sul web come http, smtp, tcp, udp e tutti gli altri protocolli
utilizzati a basso livello nell’architettura del Sistema Pubblico di Connettività.
AXIS ci permette di operare in maniera semplificata anche sul protocollo SOAP,
protocollo che permette la comunicazione nelle architetture di rete orientate ai servizi
(SOA).
Inoltre grazie all’utilizzo del tool-kit AXIS si può avere una gestione semplificata
anche dell’erogazione dei servizi web sul nostro Application Server, basterà infatti
116
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
effettuare lo schieramento ed il Server si occuperà della pubblicazione delle nostre
classi Java come servizi di tipo Web.
Questa funzionalità ci ha permesso di occuparci solamente della logica Applicativa
della Porta di Dominio, senza dover pensare a come i servizi vengano pubblicati sulla
rete.
L’altra facilitazione che è stata trovata per implementare una “proof of concept” di
Porta di Dominio in open source sono le librerie di serializzazione (marshalling) e
deserializzazione (unmarshalling) che ci vengono offerte dal framework JAXME;
infatti grazie a queste librerie è possibile, con un semplice comand, fare la
serializzazione da una classe Java ad una stringa XML e viceversa in maniera del tutto
trasparente che toglie allo sviluppatore l’onere di pensare alle operazioni di parsing di
stringhe XML.
Per l’utilizzazione di JAXME è necessario creare una architettura di classi che
rappresenti la struttura del messaggio XML che si va a deserializzare o a serializzare.
L’implementazione di questa struttura può avvenire sia in maniera manuale, cioè
scrivendo tutte le classi, le interfacce ed i metodi a mano sia utilizzando dei tool che
generano codice Java a partire da files XML.
Questi tool normalmente non possono generare classi che effettuano operazioni troppo
complesse, ma nel nostro caso le classi devono contenere solo metodi che svolgono
delle operazioni di “set” e “get” cioè impostare e leggere i valori di alcuni campi di
nostro interesse.
Esempi
di
questi
campi
possono
essere
o
RiferimentoMessaggio, i due campi che servono per vedere come la PDD si
deve comportare di fronte ad una richiesta.
Considerate le caratteristiche delle classi da implementare, si è scelto di utilizzare tool
fornito da JAXME.
117
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Si tratta di del software ANT42 che utilizza la generazione effettuata tramite ant tasks.
ANT utilizza un file di configurazione che deve avere il nome di build.xml dove
vengono definite le librerie che devono generare il codice, il file XML che deve essere
preso come Schema per la generazione delle classi, che poi rappresenta lo Schema del
file XML che verrà deseralizzato nelle classi e serializzato dalle classi.
Qui di seguito è mostrato il file di build appena descritto.
<project default= "taskdef">
<target name="taskdef">
<path id="generate.class.path">
<pathelement location="C:/javaDevelop/lib/jaxme/jaxme2-0.5.1.jar"/>
<pathelement location="C:/javaDevelop/lib/jaxme/jaxmejs-0.5.1.jar"/>
<pathelement location="C:/javaDevelop/lib/jaxme/jaxmexs-0.5.1.jar"/>
<pathelement location="C:/javaDevelop/lib/jaxme/jaxmeapi-0.5.1.jar"/>
</path>
<taskdef name="xjc"
classname="org.apache.ws.jaxme.generator.XJCTask"
classpathref="generate.class.path"/>
<xjc
schema=" bustaEGov.xsd"
target="src"
extension="true">
<produces includes="*.java"/>
</xjc>
</target>
</project>
Il tag <target> identifica il task che deve essere svolto, che corrisponde al target
impostato come default per il progetto, come si può vedere all’interno del tag
<project>, successivamente si vedono tra i tags <path> la definizione delle classi
che servono per la generazione delle classi Java.
Nella sezione <taskdef> viene definito il nome del task da eseguire e le classi
utilizzate per generare le classi.
42
http://ant.apache.org/projects.html
118
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Infine viene definito il tag relativo al task che si va ad eseguire per generare codice, in
questo caso il nome del task è stato definito come xjc e dunque il tag nel quale si fa
riferimento al task si chiamerà <xjc>; nella definizione del task viene indicata la
sorgente dello Schema da seguire nella generazione (bustaEGov.xsd) e la directory
da utilizzare per mettere le classi generate (src).
Si lancia dunque il generatore di classi ANT che genera le classi secondo quello che
viene indicato nel file il cui path è inserito nel campo schema della sezione riguardante
il task.
<?xml version="1.0"?>
il file è composto da diverse sezioni; innanzitutto c’è la parte che dichiara che si tratta
di un file che segue uno schema xml
<xsd:schema targetNamespace=http://www.cnipa.it/schemas/2003/eGovIT/Busta1_0/
xmlns:eGov_IT=http://www.cnipa.it/schemas/2003/eGovIT/Busta1_0/
xmlns=http://www.cnipa.it/schemas/2003/eGovIT/Busta1_0/
xmlns:xsd=http://www.w3.org/2001/XMLSchema
xmlns:SOAP_ENV=http://schemas.xmlsoap.org/soap/envelope/
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xsd:import namespace=http://schemas.xmlsoap.org/soap/envelope/
schemaLocation="./envelopeMustUnderstandActorDef-.xsd"/>
successivamente c’è una sezione nella quale vengono effettuate le dichiarazioni di
namespaces ed importati namespaces esterni e schema esterni.
<xsd:element name="Azione" type="xsd:string"/>
<xsd:element name="Collaborazione" type="IdentificatoreType"/>
Successivamente vengono definiti gli altri elementi, che possono essere elementi
semplici (vedi sopra nel caso dell’elemento Azione), o possono essere elementi che
119
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
sono fatti di altri elementi la cui struttura viene definita in questo stesso file come
succede per il caso di Collaborazione che è fatto del tipo di dato
IdentificatoreType che viene definito in questo stesso file come tipo di dato
semplice come si può vedere qui di seguito.
<xsd:simpleType name="IdentificatoreType">
<xsd:restriction base="xsd:string">
<xsd:pattern value="[\w]+_[\w]+_\d{7}_\d{4}\-\d{2}\-\d{2}_\d{2}:\d{2}"/>
</xsd:restriction>
</xsd:simpleType>
elementi di tipo simpleType possono essere anche più complessi come
strutturazione del tipo di dato IdentificatoreType si veda per esempio
codiceEccezioneType qui di seguito che può assumere uno dei valori
dell’enumerazione. Per brevità non viene mostrato tutto il tipo di dato ma solo alcuni
elementi della enumerazione
<xsd:simpleType name="codiceEccezioneType">
<xsd:enumeration value="EGOV_IT_001">
<xsd:annotation>
<xsd:appinfo>
Formato Busta non corretto
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:annotation>
<xsd:appinfo>
Formato Intestazione non corretto
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:annotation>
<xsd:appinfo>
Formato Corpo non corretto
</xsd:appinfo>
</xsd:annotation>
120
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
Altri elementi possono essere costituiti da tipi di dato complessi, cioè tipi di dato fatti di
altri tipi di dato semplici o complessi.
A titolo di esempio si può vedere quello che appare nel file xsd quando si vuole che
ANT generi classi che gestiscono tipi di dato complessi:
<xsd:element name="Eccezione">
<xsd:complexType>
<xsd:attribute name="contestoCodifica"
type="xsd:string"
use="required"/>
<xsd:attribute name="codiceEccezione"
type="codiceEccezioneType"
use="required"/>
<xsd:attribute name="rilevanza" use="required">
<xsd:simpleType>
<xsd:enumeration value="INFO"/>
<xsd:enumeration value="LIEVE"/>
<xsd:enumeration value="GRAVE"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<xsd:attribute name="posizione"
type="xsd:string"
use="required"/>
</xsd:complexType>
</xsd:element>
Si vede la definizione di alcuni campi di cui si è ampiamente parlato in precedenza e
che ci saranno utili al fine di spiegare come sono stare implementate alcune funzionalità
in futuro.
Per esempio la classe IntestazioneMessaggio verrà creata seguendo questo
schema
121
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
<xsd:element name="IntestazioneMessaggio">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="Mittente"/>
<xsd:element ref="Destinatario"/>
<xsd:element ref="ProfiloCollaborazione" minOccurs="0"/>
<xsd:element ref="Collaborazione" minOccurs="0"/>
<xsd:element ref="Servizio" minOccurs="0"/>
<xsd:element ref="Azione" minOccurs="0"/>
<xsd:element ref="Messaggio"/>
<xsd:element ref="ProfiloTrasmissione" minOccurs="0"/>
<xsd:element ref="Sequenza" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
dove la classe Messaggio sarà costruita con elementi di questo tipo.
<xsd:element name="Messaggio">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="Identificatore"/>
<xsd:element ref="OraRegistrazione"/>
<xsd:element ref="RiferimentoMessaggio" minOccurs="0"/>
<xsd:element ref="Scadenza" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
La classe ProfiloCollaborazione di cui si è gia parlato ampiamente prima sarà
composta
come
un
tipo
complesso
costituito
da
tipi
semplici
come
ProfiloCollaborazioneBaseType, che è un tipo che accetta solamente valori
che siano consistenti con quello riportato nelle specifiche SPCoop
<xsd:simpleType name="ProfiloCollaborazioneBaseType">
<xsd:enumeration value="EGOV_IT_MessaggioSingoloOneWay"/>
<xsd:enumeration value="EGOV_IT_ServizioSincrono"/>
<xsd:enumeration value="EGOV_IT_ServizioAsincronoSimmetrico"/>
<xsd:enumeration value="EGOV_IT_ServizioAsincronoAsimmetrico"/>
122
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
</xsd:restriction>
</xsd:simpleType>
<xsd:element name="ProfiloCollaborazione">
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="ProfiloCollaborazioneBaseType">
<xsd:attribute name="servizioCorrelato"
type="xsd:string"
use="optional"/>
<xsd:attribute name="tipo"
use="optional">
<xsd:simpleType>
<xsd:enumeration
value="URL"/>
<xsd:enumeration
value="WSDL"/>
<xsd:enumeration
value="LDAP"/>
<xsd:enumeration
value="UDDI"/>
<xsd:enumeration
value="ebXMLRegistry"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
In questa sezione si è cercato di spiegare in modo sintetico le logiche secondo le quali
vengono generate le classi. In appendice verrà riportato il listato completo del file
bustaEGov.xsd nel caso in cui il lettore voglia approfondire l’argomento.
È mostrato ciò che accade dopo il lancio del programma ANT.
A titolo esemplificativo sono mostrate le classi generate per alcuni degli elementi che
analizzati fino ad ora; considerata l’attenzione che è stata posta sulla classe
ProfiloCollaborazione sembra opportuno continuare a mostrare questa classe,
essendo più importante la logica che effettivamente il codice generato.
123
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
La classe generata risulta essere come mostrato qui di seguito:
Per quanto riguarda la sola classe ProfiloCollaborazione il generatore ci da in
output diversi files Java:
una
interfaccia
che
estende
l’interfaccia
ProfiloCollaborazioneType
ereditando da quest’ultima i vari metodi set,
una classe che implementa l’interfaccia di cui sopra estendendo l’implementazione
dell’interfaccia
ProfiloCollaborazioneType,
cioè
ProfiloCollaborazioneTypeImpl.
Osservando solo questi due file sembra che il generatore non abbia creato nulla,
essendoci solo dei files con all’interno delle definizioni di classi che dichiarano di
estendere altre classi ma in verità non fanno quasi nulla.
Qui sotto viene presentata l’interfaccia:
package it.cnipa.www.schemas._003.egovit.busta1_0;
public interface ProfiloCollaborazione extends javax.xml.bind.Element ,
it.cnipa.www.schemas._003.egovit.busta1_0.ProfiloCollaborazioneType {
}
e qui l’implementazione dell’interfaccia:
package it.cnipa.www.schemas._003.egovit.busta1_0.impl;
public class ProfiloCollaborazioneImpl
extends it.cnipa.www.schemas._003.egovit.busta1_0.impl.ProfiloCollaborazioneTypeImpl
implements it.cnipa.www.schemas._003.egovit.busta1_0.ProfiloCollaborazione ,
org.apache.ws.jaxme.JMElement
{
124
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
private final static javax.xml.namespace.QName __qName = new
javax.xml.namespace.QName("http://www.cnipa.it/schemas/2003/eGovIT/Busta1_0/",
"ProfiloCollaborazione", "eGov_IT");
public javax.xml.namespace.QName getQName() {
return __qName;
}
}
Guardando invece i files che vengono estesi, si può valutare l’utilità del lavoro svolto
dal
tool
utilizzato.
Qui
di
seguito
è
presentata
l’interfaccia
ProfiloCollaborazioneType:
public interface ProfiloCollaborazioneType {
public java.lang.String getServizioCorrelato();
public void setServizioCorrelato(java.lang.String pServizioCorrelato);
public java.lang.String getTipo();
public void setTipo(java.lang.String pTipo);
public java.lang.String getValue();
public void setValue(java.lang.String pValue);
}
qui si possono vedere i metodi set e get per impostare i valori dei vari campi del profilo
di collaborazione e per accedervi.
Inoltre qui di seguito, viene descritta l’implementazione dell’interfaccia appena vista
public class ProfiloCollaborazioneTypeImpl
implements it.cnipa.www.schemas._003.egovit.busta1_0.ProfiloCollaborazioneType {
private java.lang.String _servizioCorrelato;
125
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
private java.lang.String _tipo;
private java.lang.String _value;
public java.lang.String getServizioCorrelato() {
return _servizioCorrelato;
}
public void setServizioCorrelato(java.lang.String pServizioCorrelato) {
_servizioCorrelato = pServizioCorrelato;
}
public java.lang.String getTipo() {
return _tipo;
}
public void setTipo(java.lang.String pTipo) {
_tipo = pTipo;
}
public java.lang.String getValue() {
return _value;
}
public void setValue(java.lang.String pValue) {
_value = pValue;
}
}
in cui sono presenti i tre campi che caratterizzano il tipo ProfiloCollaborazione,
_servizioCorrelato, _tipo e _value e tutte le implementazioni dei metodi set e
get visti nell’interfaccia
public class ProfiloCollaborazioneTypeDriver
implements org.apache.ws.jaxme.impl.JMSAXDriver {
public org.xml.sax.helpers.AttributesImpl
getAttributes(org.apache.ws.jaxme.impl.JMSAXDriverController pController,
java.lang.Object pObject) throws org.xml.sax.SAXException {
126
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
org.xml.sax.helpers.AttributesImpl _1 = new org.xml.sax.helpers.AttributesImpl();
it.cnipa.www.schemas._003.egovit.busta1_0.ProfiloCollaborazioneType _2 =
(it.cnipa.www.schemas._003.egovit.busta1_0.ProfiloCollaborazioneType) pObject;
java.lang.String _3 = _2.getServizioCorrelato();
if (_3 != null) {
_1.addAttribute("", "servizioCorrelato", pController.getAttrQName(this, "",
"servizioCorrelato"), "CDATA", _2.getServizioCorrelato());
}
java.lang.String _4 = _2.getTipo();
if (_4 != null) {
_1.addAttribute("", "tipo", pController.getAttrQName(this, "", "tipo"), "CDATA",
_2.getTipo());
}
return _1;
}
public java.lang.String getPreferredPrefix(java.lang.String pURI) {
return null;
}
public void marshalChilds(org.apache.ws.jaxme.impl.JMSAXDriverController pController,
org.xml.sax.ContentHandler pHandler, java.lang.Object pObject) throws
org.xml.sax.SAXException {
(it.cnipa.www.schemas._003.egovit.busta1_0.ProfiloCollaborazioneType) pObject;
java.lang.String _2 = _1.getValue();
if (_2 != null
&&
_2.length() > 0) {
char[] _3 = _2.toCharArray();
pHandler.characters(_3, 0, _3.length);
}
}
}
inoltre vengono create anche una classe Driver ed una classe Handler per gestire le
operazioni di serializzazione e deserializzazione che avverranno poi sulle istanze di
queste classi. Qui di seguito è mostrato quello che viene creato quando viene fatto
girare il tool ANT sui files mostrati prima:
127
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
public class ProfiloCollaborazioneTypeHandler extends
org.apache.ws.jaxme.impl.JMSAXElementParser {
public void addAttribute(java.lang.String pURI, java.lang.String pLocalName,
java.lang.String pValue) throws org.xml.sax.SAXException {
if (pURI == null) {
pURI = "";
}
(it.cnipa.www.schemas._003.egovit.busta1_0.ProfiloCollaborazioneType) result;
if ("".equals(pURI)) {
if ("servizioCorrelato".equals(pLocalName)) {
_1.setServizioCorrelato((java.lang.String) pValue);
return;
} else if ("tipo".equals(pLocalName)) {
_1.setTipo((java.lang.String) pValue);
return;
}
}
super.addAttribute(pURI, pLocalName, pValue);
}
public boolean startElement(java.lang.String pNamespaceURI, java.lang.String
pLocalName, java.lang.String pQName, org.xml.sax.Attributes pAttr) throws
org.xml.sax.SAXException {
return false;
}
public void endElement(java.lang.String pNamespaceURI, java.lang.String pLocalName,
java.lang.String pQName, java.lang.Object pResult) throws org.xml.sax.SAXException {
(it.cnipa.www.schemas._003.egovit.busta1_0.ProfiloCollaborazioneType) result;
_1.setValue((java.lang.String) pResult);
}
public boolean isFinished() {
return true;
}
public boolean isEmpty() {
return false;
}
public boolean isAtomic() {
return true;
}
128
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
}
Le classi generate rappresentano totalmente la struttura della Busta di e-Government
versione 1.0; ultime specifiche in vigore al momento della scrittura di questo testo.
Questa rappresentazione dello schema XML che regola la Busta rende possibile la
serializzazione (Marshalling) e la deserializzazione (Unmarshalling) delle stringhe
XML che arrivano alla PDD come richieste a servizi web.
Il fatto di deserializzare la stinga XML dentro una struttura a classe semplifica tutto il
lavoro di gestione dei valori, infatti, avendo i valori dentro una struttura a classi, viene
permesso l’accesso in lettura tramite i metodi get ed in scrittura tramite i metodi set che
si è visto prima per il caso particolare ProfiloCollaborazione ma che sono poi
metodi applicabili su tutte le classi create dell’architettura create.
Anche il sistema ad interfacce ed implementazioni è estremamente potente. Rende
infatti possibile di cambiare il contenuto delle implementazioni, aggiungendo
funzionalità, modificando funzionalità esistenti o eseguendo qualsiasi operazione che si
desideri su queste classi senza portare conseguenze alle interfacce che continuano a
fornire come interfaccia per il programma i soli metodi che veramente gli necessitano,
vale a dire get e set.
Avendo scelto di generare automaticamente le classi, ci si è potuti concentrare sulla
logica applicativa vera e propria della PDD senza dover pensare ad implementare
funzionalità poco interessanti ma molto impegnative da stilare.
Valutata l’ampiezza del progetto, è stato stabilito di realizzare solamente parte delle
modalità secondo le quali le PDD comunicano.
129
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
In questa “proof of concepts“ sono state dunque realizzate solamente le modalità di
comunicazione di tipo a messaggio singolo ed a servizio sincrono.
Si vede qui di seguito come sono state implementati questi profili e come
effettivamente sia provato che i concetti possono essere applicati per lo sviluppo di un
progetto di più ampio respiro che includa tutti i profili di comunicazione e che possa
essere una implementazione di riferimento per i “vendors” che andranno poi a
sviluppare gli elementi del Sistema Pubblico di Cooperazione.
In questo lavoro è stata analizzata anche l’implementazione degli altri profili di
collaborazione, non c’è stato però modo di implementare le classi che avrebbero
realizzato la comunicazione asincrona.
La PDD viene implementata come un qualsiasi Servizio Web sull’application server del
Dominio; ogni Amministrazione per fruire di servizi, siano essi interni o esterni al
dominio, deve inviare richieste alla PDD del proprio Dominio che si occuperà poi di
effettuare la vera e propria comunicazione tra Domini passando per le varie PDD.
4.3
Profili di comunicazione e collaborazione
Il SPCoop definisce quattro possibili profili di collaborazione, come spiegato nella
sezione che descrive la struttura di una Busta di e-Gov (cfr. §3.5).
Qui di seguito viene spiegato come sono stati implementati i profili di collaborazione
nella realizzazione di questa “proof of concept”.
4.3.1 Messaggio singolo
La gestione della comunicazione a messaggio singolo è la più semplice di quelle
presenti nel progetto del SPCoop; infatti alla PDD arriva un Messaggio Applicativo che
130
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
contiene una richiesta per un servizio che svolge una operazione della quale alla parte
fruitrice non interessa il risultato.
Nel caso reale l’operazione potrebbe essere quella che si trova a fare una
Amministrazione Locale come un Comune che alla morte di un residente debba
comunicare alla Motorizzazione Civile l’annullamento della patente di guida del
defunto.
Questo è un tipico caso nel quale all’Amministrazione Comunale non interessa il
risultato dell’operazione, ma è importante solo che la richiesta sia arrivata a
destinazione in modo da essere gestita poi internamente all’Amministrazione
Motorizzazione.
Le operazioni che la PDD deve svolgere sono quelle viste nella parte di progettazione
precedente, è analizzato come sono state realizzate, evidenziando le parti salienti sul
codice Java.
La PDD deve gestire una Busta di e-Government di questo tipo:
<SOAP_ENV:Header xmlns="http://schemas.xmlsoap.org/soap/envelope/">
<eGov_IT:Intestazione xmlns="http://www.cnipa.it/schemas/2003/eGovIT/Busta1_0/"
SOAP_ENV:actor="http://www.cnipa.it/eGov_it/portadominio" SOAP_ENV:mustUnderstand="1">
<eGov_IT:IntestazioneMessaggio>
<eGov_IT:Mittente>
<eGov_IT:IdentificativoParte tipo="CodicePA">ParteA</eGov_IT:IdentificativoParte>
</eGov_IT:Mittente>
<eGov_IT:Destinatario>
<eGov_IT:IdentificativoParte tipo="CodicePA">ParteB</eGov_IT:IdentificativoParte>
</eGov_IT:Destinatario>
<eGov_IT:ProfiloCollaborazione>
EGOV_IT_MessaggioSingoloOneWay
</eGov_IT:ProfiloCollaborazione>
<eGov_IT:Collaborazione>
ParteA_ANGPD_0000630_2003-06-05_17:58
</eGov_IT:Collaborazione>
<eGov_IT:Servizio tipo="TEST">
NomeServizio
</eGov_IT:Servizio>
131
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
<eGov_IT:Azione>
NomeAzione
</eGov_IT:Azione>
<eGov_IT:Messaggio>
<eGov_IT:Identificatore>
ParteA_ANGPD_0000630_2003-06-05_15:58
</eGov_IT:Identificatore>
<eGov_IT:OraRegistrazione tempo="EGOV_IT_SPC">
2003-06-05T17:58:10
</eGov_IT:OraRegistrazione>
<eGov_IT:Scadenza>
2003-06-10T17:58:20
</eGov_IT:Scadenza>
</eGov_IT:Messaggio>
<eGov_IT:ProfiloTrasmissione inoltro="EGOV_IT_PIUDIUNAVOLTA"/>
</eGov_IT:IntestazioneMessaggio>
</eGov_IT:Intestazione>
</SOAP_ENV:Header>
L’elemento
che
caratterizza
questo
tipo
di
comunicazione
è
ProfiloCollaborazione; l’interfaccia delegata della PDD fruitrice, verificando
che il campo ha valore EGOV_IT_MessaggioSingoloOneWay, chiude la
comunicazione appena la richiesta è inviata alla PDD erogatrice.
Altri elementi fondamentali sono Servizio e Azione che identificano il servizio da
invocare sulla PDD remota e l’azione che il servizio deve svolgere.
Negli esempi, quando viene mostrato l’XML che descrive le Buste di e-Gov viene
mostrata solo la parte di estensione, infatti non è utile mostrare la Busta SOAP che
veicola le Buste di e-Gov. In questo documento viene mostrato solo l’header
(SOAP_ENV:Header) che è la parte che viene estesa utilizzando la Busta di e-Gov
invece della semplice busta SOAP.
La parte del SOAP body non è importante ai fini della gestione della comunicazione,
invece sarà fondamentale al momento in cui le Buste effettivamente dovranno veicolare
dati.
132
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
La Busta SOAP viene gestita tramite le API di AXIS, infatti, grazie a questo tool-kit, è
possibile avere un controllo quasi assoluto sul protocollo SOAP.
L’utilizzo di AXIS ci permette di ragionare sulla logica della PDD e non sulla gestione
della busta SOAP:
MessageFactory mf = MessageFactory.newInstance();
SOAPMessage smsg = mf.createMessage( new MimeHeaders(),
new ByteArrayInputStream(str.getBytes()));
SOAPPart sp = smsg.getSOAPPart();
SOAPEnvelope se = (SOAPEnvelope)sp.getEnvelope();
SOAPHeader sh = se.getHeader();
String intestazione ="";
Iterator headers = sh.extractAllHeaderElements();
while (headers.hasNext())
{
SOAPHeaderElement he = (SOAPHeaderElement)headers.next();
intestazione = intestazione + DOM2Writer.nodeToString(he, true);
}
Grazie alle poche istruzioni riportate sopra, infatti, viene letto il contenuto dell’header
SOAP e messo all’interno di una stringa di testo.
Le richieste che arrivano alla Porta, sia all’interfaccia delegata sia all’interfaccia
applicativa, sono richieste SOAP che rispettano il protocollo SOAP1.1; essendo la PDD
implementata come un sevizio web.
Visto che la busta di e-Gov è racchiusa nell’Header si va a prendere la parte header e si
estrae la Busta. Ciò avviene nel ciclo while.
Viene poi istanziata una classe intestazione e la stringa XML estratta dall’header viene
deserializzata all’interno dell’istanza;
Intestazione intes = new IntestazioneImpl();
intes = unmarshallIntestazione(isource);
133
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Si fa il controllo sul profilo di collaborazione per vedere se effettivamente è un profilo a
messaggio singolo;
if(intes.getIntestazioneMessaggio().getProfiloCollaborazione().getValue()
.equal("EGOV_IT_MessaggioSingoloOneWay")){
//
VIENE GESTITA LA COMUNICAZIONE A MESSAGGIO SINGOLO ONE WAY
si controlla il servizio che si vuole fruire;
if(intes.getIntestazioneMessaggio().getServizio().getValue().equals("pigro")){
In questo caso il servizio si chiama pigro, essendo un servizio “giocattolo” che non
compie nessuna azione rilevante, ma effettua solo una stampa sullo standard output del
server;
Service
service = new Service();
Call
call
= (Call) service.createCall();
call.setTargetEndpointAddress( new java.net.URL(endpoint) );
call.setOperationName( method );
call.invoke(new Object[]{});
viene poi creata l’istanza di un Servizio ed il servizio viene invocato con i parametri
passati dall’utente.
Il servizio pigro come si è detto non svolge nessuna operazione particolare. È mostrato
qui di seguito il codice;
public void pigro(){
System.out.println("chiamato il metodo pigro");
}
Fino ad ora è stato esaminato il codice della Porta e quello del Servizio Applicativo che
viene fruito. Non è stato però fino ad ora spiegato come questo codice venga schierato
su un application server e come dal codice si abbia il servizio desiderato.
134
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Riporteremo nei prossimi paragrafi un esempio di fruizione, tramite una PDD, di un
servizio da parte di una Amministrazione.
All’interfaccia Delegata della PDD del dominio che vuole fruire il servizio, cioè al Web
Service schierato sulla PDD interna al Dominio, arriva una richiesta di servizio che
presenta come parametro una stringa XML con i parametri della Busta di e-Gov relativi
a
Servizio,
Azione,
Destinatario
(identificativo
amministrazione),
Mittente
(identificativo amministrazione), e gli altri dati che necessitano alla PDD per invocare il
Servizio Applicativo sulla PDD remota.
Attualmente questi dati vengono passati come parametro ma in seguito, quando
verranno sviluppati i servizi di registro SICA, i dati relativi a queste interazioni
potranno essere letti dagli Accordi di Servizio immagazzinati nei registri SICA ed
accessibili anche essi attraverso Web Services.
In questo caso quando viene chiamato il client per effettuare la richiesta Applicativa, il
risultato dell’interazione è quello visibile in Figura 39.
135
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Figura 39: Output sull’Application Server (caso Messaggio Singlo)
Come si può vedere dall’output che si verifica sul server, la PDD controlla i valori
relativi a servizio, azione, profilo di collaborazione ed i dati relativi al destinatario, in
particolare l’indirizzo telematico.
In questo caso, essendo l’indirizzo telematico relativo all’application server locale il
servizio viene chiamato sulla stessa PDD e in output si vede il risultato della chiamata
al metodo pigro del servizio pigro (vale a dire la stampa sullo standard output
dell’application server con scritto “chiamato il metodo pigro”) , se il servizio
risiedesse su un Dominio differente dal localhost la PDD effettuerebbe la chiamata alla
PDD dell’altro Dominio che si occuperebbe di invocare il servizio erogatore.
136
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
4.3.2 Comunicazione sincrona
Il secondo caso preso in esame è quello della comunicazione di tipo Sincrono; viene
cioè evocato un Servizio Applicativo su un Dominio e si attende una risposta da parte
dell’Amministrazione evocatrice.
È un caso abbastanza complesso ed è la base della comunicazione tra Web Services più
articolati. Infatti scomponendo anche i Web Services a comunicazione asincrona, che
apparentemente molto complessi, questi si possono vedere come combinazioni di
servizi a comunicazione Sincrona con aggiunta del sistema di gestione dei tracciamenti
e del campo RiferimentoMessaggio.
Al fine di rendere al lettore l’idea di un servizio sincrono viene presentato un esempio
di caso reale che si potrebbe verificare quando il SPCoop sarà fruibile agli utenti di
tutte le Amministrazioni ed è auspicabile anche ai cittadini comuni.
Si può immaginare il caso nel quale un cittadino cambi la residenza: la nuova
Amministrazione Comunale di appartenenza si troverà nella situazione di avere un
cittadino del quale non conosce i dati anagrafici.
Se l’Amministrazione Comunale, dove il cittadino era precedentemente residente ha un
buon sistema informativo, probabilmente i dati del cittadino sono fruibili tramite un
Web Service, e quindi la nuova Amministrazione Comunale può accedere a questi dati
fruendo il Servizio tramite il Sistema Pubblico di Cooperazione sulla PDD del Dominio
in cui risiede. Quest’ultima cercherà l’Accordo di Servizio tra le due Amministrazioni
Comunali sul SICA e da lì estrarrà i dati che servono per la comunicazione.
Invocherà il Servizio Applicativo sulla PDD del Dominio erogante e rimarrà in attesa
del Messaggio Applicativo di risposta vista la possibilità di ricevere i dati in maniera
Sincrona.
137
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Di seguito viene presentato un esempio di implementazione di comunicazione Sincrona
tra PDD in Java.
Come negli altri casi, la PDD si troverà a dover gestire delle Buste di e-Government per
veicolare i dati, questa volta ci sarà una Busta di richiesta ed una di risposta che viene
mostrata qui di seguito per dare la possibilità al lettore di capire a che tipo di
interazione ci si trova di fronte. Quella che segue è la busta tipica della richiesta di tipo
Sincrono:
<eGov_IT:Intestazione
xmlns=http://www.cnipa.it/schemas/2003/eGovIT/Busta1_0/
SOAP_ENV:actor="http://www.cnipa.it/eGov_it/portadominio"
SOAP_ENV:mustUnderstand="1">
<eGov_IT:Mittente>
<eGov_IT:IdentificativoParte tipo="CodicePA">
ParteA
</eGov_IT:IdentificativoParte>
</eGov_IT:Mittente>
ParteB
EGOV_IT_ServizioSincrono
NomeServizio
</eGov_IT:Servizio>
<eGov_IT:Azione>
NomeAzione
</eGov_IT:Azione>
<eGov_IT:Messaggio>
ParteA_ANGPD_0000630_2003-06-05_15:58
2003-06-05T17:58:10
<eGov_IT:Scadenza>
2003-06-10T17:58:20
138
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
</eGov_IT:Scadenza>
<eGov_IT:ListaTrasmissioni>
<eGov_IT:Trasmissione>
<eGov_IT:Origine>
<eGov_IT:IdentificativoParte tipo=" CodicePA"
indirizzoTelematico="http://137.5.3.11/pddo/servlet/soapsrv">ParteA
</eGov_IT:Origine>
<eGov_IT:Destinazione>
indirizzoTelematico="http://158.0.1.21/pddo/servlet/soapsrv"> ParteB
</eGov_IT:Destinazione>
<eGov_IT:OraRegistrazione tempo="EGOV_IT_SPC">2003-0605T17:58:10</eGov_IT:OraRegistrazione>
</eGov_IT:Trasmissione>
</eGov_IT:ListaTrasmissioni>
</SOAP_ENV:Header>
Come si può vedere la Busta è abbastanza simile a quella per una richiesta di tipo
messaggio
singolo,
i
campi
che
più
la
caratterizzano
sono
ProfiloCollaborazione. ProfiloCollaborazione indica all’interfaccia
delegata della PDD fruitrice di non chiudere la comunicazione appena la richiesta è
inviata alla PDD erogatrice ma di attendere che arrivi un Messaggio SPCoop di risposta
contenente i dati desiderati.
Servizio e Azione sono altri elementi fondamentali che identificano il servizio da
invocare sulla PDD remota e l’azione che il servizio deve svolgere.
Nell’esempio che esamineremo, il sistema chiamerà il servizio calculator che,
come azione, dovrà svolgere una somma.
Qui di seguito è mostrata la Busta di e-Gov tipica di una risposta Sincrona:
<eGov_IT:Intestazione
xmlns="http://www.cnipa.it/schemas/2003/eGovIT/Busta1_0/"
139
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
SOAP_ENV:actor=http://www.cnipa.it/eGov_it/portadominio
SOAP_ENV:mustUnderstand="1">
<eGov_IT:Mittente>
ParteB
</eGov_IT:Mittente>
ParteA
NomeServizio
</eGov_IT:Servizio>
<eGov_IT:Azione>
NomeAzione
</eGov_IT:Azione>
<eGov_IT:Messaggio>
ParteB_ANGPA_0123670_2003-06-05_17:58
2003-06-05T17:58:11
<eGov_IT:RiferimentoMessaggio>
ParteA_ANGPD_0000630_2003-06-05_17:58
</eGov_IT:RiferimentoMessaggio>
<eGov_IT:Origine>
indirizzoTelematico="http:// 158.0.1.21/pddo/servlet/soapsrv">
ParteB
</eGov_IT:Origine>
indirizzoTelematico="http:// 137.5.3.11/pddo/servlet/soapsrv">
140
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
ParteA
2003-06-05T17:58:11
</SOAP_ENV:Header>
Nell’altro caso, quello della comunicazione a messaggio singolo, non esiste nemmeno
la busta di risposta, non esistendo la risposta.
È
interessante
notare
che
nella
busta
di
risposta
è
il
campo
ProfiloCollaborazione che descrive all’interfaccia applicativa della PDD
fruitrice che il messaggio è di tipo Sincrono, ma più interessante è il campo
RiferimentoMessaggio che indica alla PDD che messaggio si riferisce alla
risposta, notare che ha lo stesso valore di Identificatore della Busta di richiesta.
Altri elementi fondamentali sono Servizio e Azione che identificano il servizio
invocato sulla PDD erogatrice e l’azione che il servizio ha eseguito.
Come
avveniva
per
il
caso
del
messaggio
singolo
anche
in
questo
ProfiloCollaborazione succede che le Buste di e-Government siano trasportate
all’interno degli Header SOAP (SOAP_ENV:Header).
La gestione degli header viene effettuata allo stesso modo del caso precedente, anche
qui infatti vengono utilizzate le API fornite dal tool-kit AXIS.
MessageFactory mf = MessageFactory.newInstance();
SOAPMessage smsg = mf.createMessage( new MimeHeaders(),
new ByteArrayInputStream(str.getBytes()));
SOAPPart sp = smsg.getSOAPPart();
SOAPEnvelope se = (SOAPEnvelope)sp.getEnvelope();
SOAPHeader sh = se.getHeader();
141
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
String intestazione ="";
Iterator headers = sh.extractAllHeaderElements();
while (headers.hasNext())
{
SOAPHeaderElement he = (SOAPHeaderElement)headers.next();
intestazione = intestazione + DOM2Writer.nodeToString(he, true);
}
attraverso queste poche istruzioni viene letto il contenuto dell’header SOAP e messo
all’interno di una stringa di testo.
Le richieste che arrivano alla Porta, sia all’interfaccia delegata sia all’interfaccia
applicativa, sono richieste SOAP che rispettano il protocollo SOAP1.1; essendo la PDD
implementata come un sevizio web.
Visto che la busta di e-Gov è racchiusa nell’Header si prende la parte header ed viene
estratta la Busta. Ciò avviene nel ciclo while.
Viene poi istanziata una classe intestazione e la stringa XML estratta dall’header viene
deserializzata all’interno dell’istanza:
Intestazione intes = new IntestazioneImpl();
intes = unmarshallIntestazione(isource);
Si testa poi l’elemento che contiene il dato sul profilo di collaborazione per accertarsi
che sia a scambio di messaggi Sincrono:
else if(intes.getIntestazioneMessaggio().getProfiloCollaborazione().getValue()
.equals("EGOV_IT_ServizioSincrono")){
//
VIENE GESTITA LA COMUNICAZIONE SINCRONA
La PDD effettua poi il controllo sul servizio che si vuole fruire, controllando l’elemento
Servizio delle classi sulle quali è stata deserializzata la stringa XML:
142
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
if(intes.getIntestazioneMessaggio().getServizio().getValue().equals("calculator")){
Si controlla anche che l’operazione che deve essere chiamata remotamente sia una delle
operazioni del servizio:
if (!(method.equals("add") || method.equals("subtract"))) {
System.err.println("no such method");
Viene poi istanziato il servizio, la chiamata al servizio stesso e vengono eseguite le
operazioni di assegnazione dei parametri alla chiamata.
Qui di seguito è riportato il codice che effettua queste operazioni:
Service
service = new Service();
Call
call
= (Call) service.createCall();
call.setTargetEndpointAddress( new java.net.URL(endpoint) );
call.setOperationName( method );
call.addParameter( "op1", XMLType.XSD_INT, ParameterMode.IN );
call.addParameter( "op2", XMLType.XSD_INT, ParameterMode.IN );
call.setReturnType( XMLType.XSD_INT );
Nell’operazione successiva viene effettuata l’invocazione della chiamata che fa
eseguire il servizio richiesto.
Integer ret = (Integer) call.invoke( new Object [] { i1, i2 });
La risposta applicativa viene di nuovo inserita dentro i campi di una nuova classe
messaggio e viene inviata una Busta alla PDD remota che contiene nel SOAP body i
dati di risultato dell’invocazione del servizio.
In verità ai fini della PDD non è di nessuna rilevanza il fatto che il dato venga
trasportato o meno, rilevante è invece che il messaggio venga veicolato indietro per
mezzo di una Busta che sia conforme alle le specifiche CNIPA.
143
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Utilizzando i metodi set che ci si è costruiti con il tool utilizzato per generare le classi
vengono settati i vari campi della Busta (quelli più rilevanti ai fini della comunicazione
sincrona).
Il messaggio viene rinviato al mittente veicolato dalla nuova Busta che è mostrata qui
di seguito:
<?xml version='1.0' encoding='UTF-8'?>
<eGov_IT:Intestazione SOAP_ENV:mustUnderstand="false"
SOAP_ENV:actor=http://www.cnipa.it/eGov_it/portadominio
xmlns:eGov_IT=http://www.cnipa.it/schemas/2003/eGovIT/Busta1_0/
xmlns:SOAP_ENV="http://schemas.xmlsoap.org/soap/envelope/">
<eGov_IT:Mittente>
<eGov_IT:IdentificativoParte
indirizzoTelematico=http://localhost:8080/axis/services/
tipo="CodicePA">
ParteA
</eGov_IT:Mittente>
indirizzoTelematico="http://localhost:8080/axis/services/"
tipo="CodicePA">
ParteB
<eGov_IT:Servizio tipo="TEST">calculator</eGov_IT:Servizio>
<eGov_IT:Azione>add:1:2</eGov_IT:Azione>
<eGov_IT:Messaggio>
<eGov_IT:Identificatore>ParteA_ANGPD_0_2007-01-14_07:21</eGov_IT:Identificatore>
<eGov_IT:OraRegistrazione>2007-01-14T19:21:15.713+01:00
<eGov_IT:RiferimentoMessaggio>ParteA_ANGPD_0000630_2003-06-05_15:58
</eGov_IT:RiferimentoMessaggio>
<eGov_IT:Scadenza>2003-06-10T17:58:20Z</eGov_IT:Scadenza>
<eGov_IT:ProfiloTrasmissione
confermaRicezione="false"
inoltro="EGOV_IT_PIUDIUNAVOLTA"/>
144
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
<eGov_IT:Origine>
indirizzoTelematico="http://localhost:8080/axis/services/" tipo="
CodicePA">ParteA</eGov_IT:IdentificativoParte>
</eGov_IT:Origine>
indirizzoTelematico="http://localhost:8080/axis/services/" tipo="
CodicePA">ParteB</eGov_IT:IdentificativoParte>
<eGov_IT:OraRegistrazione tempo="EGOV_IT_SPC">2003-0605T17:58:10Z</eGov_IT:OraRegistrazione>
Importante è osservare come il campo riferimento messaggio faccia riferimento al
messaggio arrivato alla PDD come richiesta e l’identificatore faccia riferimento ad un
altro messaggio.
Si noti che la PDD che fa queste operazioni è sempre la stessa ma basterebbe fare una
implementazione su un’altra macchina per ottenere lo stesso risultato. Qui purtroppo
non è semplice far vedere lo scambio di messaggi che si ha tra differenti interfacce
della PDD perché i riferimenti che sono nella busta a proposito di domini o
amministrazioni sono sempre uguali, essendo sempre la stessa PDD a fare tutto.
4.3.3 Comunicazione asincrona
Altro profilo di collaborazione è quello asincrono. Simmetrico o Asimmetrico che sia si
può vedere come una combinazione di servizi di tipo a messaggio singolo o sincroni.
145
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Come è stato precedentemente osservato, la comunicazione asincrona si differenzia in
due tipi: simmetrico ed asimmetrico si consultino le pagine precedenti per le differenze
che caratterizzano i due tipi di comunicazione.
Nell’ambiente di interazione che si andrà a delineare quando il SPCoop sarà messo in
opera, la maggior parte dei servizi inizialmente saranno di questo tipo.
Si immagini il caso di una richiesta effettuata da una Amministrazione per un dato ad
una altra Amministrazione il cui sistema informativo non permette una interazione
Sincrona, vale a dire il caso in cui un operatore dovrà cercare il dato in un archivio
cartaceo e poi inviare la risposta applicativa tramite il SPCoop.
Questa eventualità può essere esplicativa sia del caso simmetrico che asimmetrico. La
differenza sta nella modalità di consegna della risposta; se l’amministrazione erogatrice
contatta il fruitore nel momento in cui ha la risposta, si è di fronte al caso di
comunicazione
Sincrona
altrimenti,
se
è
il
fruitore
che
deve
contattare
l’Amministrazione erogatrice e prendere il dato che è stato posto accessibile via
SPCoop, si è di fronte ad uno scambio di messaggi Asincrono Asimmetrico.
La comunicazione asincrona deve gestire Buste di e-Government simili a quelle viste
sopra per i casi Sincrono e a Messaggio singolo.
Per la struttura delle buste scambiate si rimanda alle specifiche CNIPA relative alla
Busta di e-Gov. Cercando di non essere prolissi ma comunque, volendo dare al lettore
la possibilità di comprendere, si può dire che ci sono quattro interazioni tra PDD in
caso di comunicazione Asincrona.
Nel caso di comunicazione Simmetrica si ha questo flusso di Buste tra le due
amministrazioni, il fruitore effettua la richiesta, l’erogatore invia un messaggio di
ricezione della richiesta e, quando la risposta è pronta, l’erogatore invia la risposta
mentre il fruitore, alla ricezione, invia un messaggio di ricevuta della risposta.
146
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Nel caso Asimmetrico, il flusso di Buste è il seguente: il fruitore effettua la richiesta,
l’erogatore invia un messaggio di ricezione della richiesta, successivamente il fruitore
invia richieste sullo stato di evasione della richiesta sempre tramite una Busta di e-Gov
e l’erogatore invia messaggi sullo stato, se non ha ancora la risposta, altrimenti invia la
risposta.
Aspetto
caratterizzante
delle
richieste
di
tipo
Asincrono
che
è
il
campo
può
EGOV_IT_ServizioAsincronoSimmetrico
essere
o
EGOV_IT_ServizioAsincronoAsimmetrico a seconda che il profilo di
collaborazione sia di tipo Simmetrico o Asimmetrico.
Da notare sono anche i campi Identificatore e RiferimentoMessaggio e
Collaborazione che fanno in modo che i messaggi siano tracciabili e che le PDD
riescano a capire a chi fa riferimento un messaggio di risposta o un messaggio di
polling sullo stato del servizio richiesto.
I campi Identificatore e RiferimentoMessaggio vengono utilizzati nella
stessa maniera del caso Sincrono, il campo Collaborazione invece è quel campo
che caratterizza a quale richiesta fa riferimento lo scambio di messaggi effettuato.
Qui di seguito vengono mostrati degli spezzono di codice XML per mostrare come i
campi facciano riferimento gli uni agli altri.
Il caso che si vede è quello della comunicazione Asincrona Simmetrica che è
esplicativa anche per il caso Asincrono Asimmetrico.
Viene qui riportato lo spaccato di codice relativo alla richiesta.
<eGov_IT:ProfiloCollaborazione servizioCorrelato="NomeServizioRicezioneRisposte"
tipo="URL">EGOV_IT_ServizioAsincronoSimmetrico</eGov_IT:ProfiloCollaborazione>
<Collaborazione>ParteA_ANGPD_0000630_2003-06-05_17:58</Collaborazione>
<eGov_IT:Servizio tipo="TEST">NomeServizio</eGov_IT:Servizio>
<eGov_IT:Azione>NomeAzione</eGov_IT:Azione>
<eGov_IT:Messaggio>
<eGov_IT:OraRegistrazione tempo="EGOV_IT_SPC">2003-06-05T17:58:00</eGov_IT:OraRegistrazione>
147
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
<Scadenza>2003-06-10T18:00:00</Scadenza>
si vede poi il codice che arriva come ricevuta della richiesta di cui sopra.
<eGov_IT:ProfiloCollaborazione>EGOV_IT_ServizioAsincronoSimmetrico</eGov_IT:ProfiloCollaborazione>
<eGov_IT:Servizio tipo="TEST">NomeServizio</eGov_IT:Servizio>
<eGov_IT:Messaggio>
<eGov_IT:Identificatore>ParteB_ANGPA_0123670_2003-06-05_17:58</eGov_IT:Identificatore>
<RiferimentoMessaggio>ParteA_ANGPD_0000630_2003-06-05_17:58</RiferimentoMessaggio>
Poi si ha la risposta alla richiesta;
<eGov_IT:Servizio tipo="TEST">NomeServizioRicezioneRisposte</eGov_IT:Servizio>
<eGov_IT:Messaggio>
<eGov_IT:Identificatore>ParteB_ANGPA_0123671_2003-06-05_17:59</eGov_IT:Identificatore>
<RiferimentoMessaggio>ParteA_ANGPD_0000630_2003-06-05_17:58</RiferimentoMessaggio>
e finalmente la ricevuta della risposta alla richiesta;
<eGov_IT:Servizio tipo="TEST">NomeServizioRicezioneRisposte</eGov_IT:Servizio>
<eGov_IT:Messaggio>
<RiferimentoMessaggio>ParteB_ANGPA_0123671_2003-06-05_17:59</RiferimentoMessaggio>
148
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Notare che il campo Collaborazione non varia mai per tutta l’interazione tra le
porte, mentre i campi RiferimentoMessaggio e Identificatore variano
come quando si è in presenza di comunicazioni Sincrone.
Per questo la comunicazione asincrona si può vedere come una combinazione di
comunicazioni Sincrone.
La differenza sta nel fatto che i messaggi devono essere tracciati in modo che si possa
impostare il campo Collaborazione con valori consistenti.
Questo si può eseguire in diversi modi; la maniera più semplice è probabilmente quella
di utilizzare dei DBMS per la gestione delle tracciature, dai quali attingere i valori degli
identificativi delle collaborazioni per l’invio consistente di messaggi.
In questo lavoro la comunicazione asincrona non è stata implementata, infatti questa
operazione non era necessaria per provare che i concetti dai quali si è partiti per la
realizzazione della PDD, siano validi per lo sviluppo di un sistema che fornisca le
caratteristiche di interoperabilità richieste dalle specifiche italiane in primis e poi da
quelle europee.
4.4
Problemi e soluzioni
Questa sezione riassume ciò che è stato descritto precedentemente; si parlerà di
argomenti che non erano di interesse specifico delle sezioni precedenti e che non sono
state trattate per mantenere l’attenzione del lettore su quella che era la logica di
implementazione della PDD.
Non saranno ripetuti gli stessi concetti visti precedentemente; qui tratteremo ad un
livello differente alcune tematiche di tipo puramente pratico che hanno causato dei
problemi non difficili da risolvere ma comunque interessanti per un lettore che cerchi
delle risposte a questi problemi.
149
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Fondamentale al fine di lavorare in maniera veloce e pratica era avere un ambiente di
sviluppo che permettesse di sviluppare, schierare e testare servizi in maniera rapida e
deterministica.
Per realizzare questo ambiente è stato individuato un valido strumento in eclipse che è
un software per fare editing di documenti in Java in maniera veloce ed assistita, inoltre
in eclipse c’è un debugger, elemento fondamentale per lo sviluppo di sistemi così
articolati, un tool di compilazione molto potente, che permette di compiere operazioni
come lo schieramento dei servizi direttamente sull’Application Server.
Inoltre eclipse offre la possibilità di includere librerie nel codice senza dover
modificare il classpath della propria macchina, tutte le operazioni avvengono in
maniera molto veloce ed intuitiva.
Per la configurazione dell’ambiente di test è stato scritto un file di deploy per
pubblicare i servizi che venivano sviluppati sul Server. Si è poi impostato eclipse per
processare questo file quando viene effettuata una compilazione del codice Java che
implementa la PDD.
Qui di seguito è mostrato uno stralcio del file di cui sopra:
<deployment xmlns="http://xml.apache.org/axis/wsdd/"
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
<service name="porta" provider="java:RPC">
<parameter name="className" value="porta.Write"/>
<parameter name="allowedMethods" value="porta"/>
<parameter name="scope" value="Request"/>
</service>
<service name="calculator" provider="java:RPC">
<parameter name="className" value="testClasses.Calculator"/>
<parameter name="allowedMethods" value="*"/>
</service>
<service name="pigro" provider="java:RPC">
<parameter name="className" value="testClasses.OneWay"/>
<parameter name="allowedMethods" value="*"/>
150
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
</service>
</deployment>
Si può osservare come vengano pubblicati sull’Application Server i servizi relativi a
porta e servizi di test.
Per impostare eclipse in maniera che esegua il deploy, si devono impostare come
parametri
di
configurazione
main
class
org.apache.axis.client.AdminClient e come argomenti il nome del file di
deploy.
Figura 40: Configurazione di eclipse per il deploy automatico
in questo modo dopo aver compilato l’unica cosa da fare sarà copiare i files .class che si
vuole che siano sull’Application Server per implementare i nostri servizi, a meno che
non si stia sviluppando direttamente dentro l’Application Server, e riavviare il server in
modo che possa processare i files giusti.
La serializzazione e la deserializzazione di stringhe XML, richiedevano l’utilizzo di
istruzioni molto ripetitive.
151
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Si è perciò deciso di includere le operazioni di serializzazione e deserializzazione in
due funzioni specifiche.
Qui di seguito è mostrato il codice:
public static Intestazione unmarshallIntestazione(InputSource pSource)
throwsJAXBException {
Intestazione retVal = new IntestazioneImpl();
JAXBContext context =
JAXBContext.newInstance("it.cnipa.www.schemas._003.egovit.busta1_0");
Unmarshaller unmarshaller = context.createUnmarshaller();
retVal =(Intestazione) unmarshaller.unmarshal(pSource);
return retVal;
}
public static String marshallIntestazione(Intestazione intestazione)
throws JAXBException {
StringWriter sw = new StringWriter();
JAXBContext context =
JAXBContext.newInstance("it.cnipa.www.schemas._003.egovit.busta1_0");
Marshaller marshaller = context.createMarshaller();
marshaller.marshal(intestazione, sw);
return sw.toString();
}
È facile dedurre che, basta passare una istanza della classe intestazione per avere una
stringa XML con la classe serializzata e basta passare la stringa XML in formato
InputSource per avere la stringa deserializzata in una instanza di classe
Intestazione.
Un altro problema che è emerso durante il lavoro, è che per assegnare valori alla classe
Intestazione spesso, sopratutto noi casi in cui il valore è molto innestato nella
struttura si devono scrivere linee di codice molto lunghe ed impegnative, che spesso
portano lo sviluppatore a compiere errori e a perdere molto tempo per implementare
funzioni molto semplici.
Un esempio di queste operazioni può essere
intesRet.getIntestazioneMessaggio().getMessaggio().setRiferimentoMessaggio(intes.getInte
stazioneMessaggio().getMessaggio().getIdentificatore());
152
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Nel caso più semplice di una operazione di lettura o nel caso di operazioni di scrittura
ci si trova di fronte a dover scrivere linee di codice come questa:
intesRet.getIntestazioneMessaggio().getMessaggio().setIdentificatore(ammCode+"_"+portaCo
de+"_"+numProg+"_"+now );
tale operazione di set in verità non è così impegnativa visto che il tipo di dato da
settare è una stringa, se il tipo di dato fosse differente, come un campo date-time o
qualsiasi altro tipo di dato più complesso di una semplice stringa, le operazioni da
compiere sarebbero molteplici.
Per ovviare a questo problema si è pensato di sviluppare una classe per effettuare
queste scritture, una sorta di facade che permetta di effettuare una get o una set
semplicemente istanziando la classe ed utilizzando i metodi che si occupano delle
operazioni di lettura e scrittura dei valori delle classi che implementano la Busta di eGov.
La facade non è stata implementata, poiché lo scopo del progetto non era implementare
una vera e propria PDD totalmente funzionante ed ottimizzata.
L’obbiettivo di questo lavoro era quello di provare che i concetti alla base di questa
progettazione rappresentano una via valida per fornire interoperabilità alla Pubblica
Amministrazione italiana.
153
Tesi di Laurea
Conclusioni e sviluppi futuri
Vittorio Ottaviani
_______________________________________________________________________
5 Conclusioni e sviluppi futuri
5.1
Conclusioni
Scopo del lavoro era realizzare una “proof of concept” di una Porta di Dominio basata
su strumenti open source.
L’intento era dimostrare che questo elemento fondamentale per il Sistema Pubblico di
Cooperazione fosse realizzabile in ambiente open source.
Nell’ambito di questo lavoro è stata realizzata una PDD dimostrativa che permette la
fruizione e l’erogazione di alcuni servizi di test.
Dei quattro profili di collaborazione previsti dalle specifiche CNIPA ne sono stati
realizzati due; sulla base di questo lavoro, i due profili collaborativi non implementati
potranno essere facilmente sviluppati in lavori successivi, in considerazione del fatto
che tali profili di collaborazione, cioè quelli asincroni, sono una estensione di quelli
implementati.
Si è, dunque, dimostrato che in ambito Open Source è possibile realizzare Servizi Web
che svolgano le funzioni di una Porta di Dominio, vale a dire:
•
Gestione di una Busta di e-Government come quella definita nelle specifiche
CNIPA,
•
Gestione delle tracciature che si devono svolgere in un sistema come il SPCoop,
•
Gestione della Busta SOAP, protocollo che veicola la busta di e-Government.
È inoltre importante sottolineare il positivo riscontro delle scelte effettuate riguardo agli
strumenti utilizzando (vedi §4.2.5), in particolare:
154
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
•
Tomcat: che si è rivelato estremamente robusto e di supporto per lo sviluppo e
la gestione di jsp e di applet java.
•
Axis: rivelatosi fondamentale nella gestione del protocollo SOAP e dunque di
parte della Busta di e-gov; Axis può fornire un importante aiuto anche in visione
futura quando dovrà essere stilato l’AS, visto che una delle funzionalità di Axis
è quella di generare automaticamente il WSDL che descrive il servizio.
•
Jaxb: in particolare Jaxme, serie di librerie che si sono rivelate estremamente
utili per gestire in maniera rapida e trasparente stringhe XML e dunque la parte
di estensione della Busta di e-gov rispetto alla busta SOAP.
Sul lato strettamente pratico lo stesso Eclipse si è rivelato un valido ambiente di
sviluppo, viste le ottime funzionalità di supporto alla scrittura di codice, di debug, e di
gestione dei Web Services in fase di rilascio sull’Application Server.
L’utilizzo di strumenti Open Source sembra fondamentale per lo sviluppo di sistemi
interoperabili, vista la necessità dell’utilizzo di standard consolidati ed affermati.
Il lavoro da fare per giungere ad una vera implementazione di riferimento (reference
implementation) è ancora molto, ma i risultati ottenuti in questo lavoro possono essere
di indicazione anche in tal senso.
In conclusione si può affermare che gli obbiettivi che ci si era preposti sono stati
raggiunti con risultati più che soddisfacenti.
Nella prossima sezione saranno proposti possibili sviluppi futuri del progetto SPCoop.
5.2
Sviluppi futuri
Nell’ambito delle attività su SPCoop il CNIPA ha avviato una serie di collaborazioni
con Università ed Enti di ricerca al fine di promuovere il modello anche attraverso
155
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
collaborazioni specifiche (stage, tesi di laurea e di dottorato) di cui questo lavoro
rappresenta un primo risultato.
Questa collaborzione vedrà l’Università come uno dei soggetti validatori di modelli ed
eccellenze, ed il CNIPA come promotore di nuovi temi nell’ambito ICT sui quali fare
ricerca.
Sono inoltre stati attivati dei finanziamenti per le regioni al fine di permettere il
potenziamento dei sistemi informativi e di attivare nelle stesse regioni lo sviluppo di
progetti di cooperazione applicativa.
Esistono esperienze di successo, in ambito di cooperazione applicativa, che sono già
state fatte in Toscana, Emilia, Campania e nella provincia autonoma di Trento.
Sarebbe, quindi, auspicabile che al CNIPA, in ambito di cooperazione applicativa, fosse
affidato il ruolo di:
•
promuovere la cooperazione applicativa;
•
organizzare una serie di collaborazioni con il mondo della ricerca;
•
sviluppare una implementazione di riferimento di una PDD;
•
definire una “road-map” per l’evoluzione del modello SPCoop.
Attualmente in ambito SPCoop e più in generale nell’ambito della cooperazione
applicativa in CNIPA i temi di maggiore interesse sono:
•
la definizione di standard, linee guida, e best practices per la definizione e
gestione dei Service Level Agreement (SLA);
•
lo studio di metodologie e modelli per la definizione di Ontologie e
l’applicazione di tecnologie per la “semantizzazione” del SPCoop;
156
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
•
la definizione di metodologie e standard per la codifica e la gestione
dell’Accordo di Servizio.
Inoltre, il CNIPA, in collaborazione con le Università, ha intenzione di lanciare il
progetto sperimentale SPCoop Labs, che ha come idea generale quella di istituire
all’interno di Università e centri di ricerca dei laboratori che si occupano di fare ricerca
sui temi attinenti SPCoop.
Altro ambito interessante per il CNIPA e per l’Università è quello dello studio e del
miglioramento dell’Identity Management,in particolare per gli aspetti relativi
all’accesso sicuro ai servizi in rete.
Dal lato Università, in particolare il Dipartimento di Informatica Sistemi e Produzioni
(DISP) della Facoltà di Ingegneria dell’Università di Roma “Tor Vergata”, si è vista la
disponibilità ad approfondire alcuni dei temi di cooperazione applicativa sopra citati,
quali:
•
lo studio degli SLA;
•
la applicazione di metodologie e tecnologie di sicurezza ai sistemi sviluppati;
•
lo studio di Identity Management;
•
la collaborazione per lo sviluppo della gestione degli eventi.
Presso il CNIPA sono attualmente in corso di svolgimento altre due tesi riguardanti la
Porta di Dominio e l’Accordo di Servizio.
Come è stato gia detto in tutta Europa stanno nascendo progetti che si pongono come
obbiettivo quello definire frameworks di interoperabilità per le Pubbliche
Amministrazioni.
157
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
In Italia molte aziende private ed Amministrazioni Pubbliche, centrali e locali, stanno
iniziando ad interessarsi allo sviluppo di applicazioni interoperabili secondo il modello
SPCoop.
Basti pensare a progetti di Pota di Dominio come OpenPDD e OpenSPCoop [29] [30],
o le implementazioni di operatori di mercato come Microsoft, IBM, Oracle ed altri.
Anche all’interno della Pubblica Amministrazione ci sono implementazioni di PDD,
quali ad esempio l’implementazione di PDD sviluppata dal Ministero del Tesoro.
In tale ambito, il bisogno di uno sviluppo collaborativo tra Amministrazioni Locali e
operatori di mercato spinge verso l’istituzione di una community di sviluppo, sotto il
coordinamento del CNIPA, per la realizzazione di una reference-implementation. Tale
progetto potrebbe vedere coinvolte anche le università ed enti di ricerca per gli aspetti
avanzati.
In ultimo, sono in via di definizione presso il CNIPA aggiornamenti alle specifiche
della Busta di e-Gov, dunque il presente lavoro dovrà essere rivisto al fine di gestire tali
aggiornamenti.
5.3
Community di Sviluppo
L’idea di sviluppare una community di sviluppo nasce dalla necessità di avere un
sistema che nasca come risultato della collaborazione delle diverse parti in causa nello
sviluppo, in un mondo open source, che sia il più possibile aperto agli input che
vengono dall’esterno e che sia adatto a accettare gli input di nuove tecnologie più
moderne.
Le varie parti in causa nello sviluppo saranno tutti i possibili Stakeholder che possono
venire in mente, come “Vendors”, Amministrazioni Pubbliche, istituzioni private che
158
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
usufruiranno dei servizi, cittadini comuni, Università, mondo della ricerca o qualsiasi
sviluppatore che sia interessato a collaborare con un progetto di tale importanza, anche
sociale per il nostro paese e per la Comunità europea.
Per input che vengono dall’esterno si possono citare la nascita di nuovi protocolli, lo
sviluppo di nuove tecnologie etc.
È fondamentale infatti che il SPCoop sia il più possibile all’avanguardia per offrire al
cittadino il miglior servizio possibile a livello di velocità, sicurezza affidabilità e
disponibilità.
Questo spinge a sviluppare un modello collaborativo che permetta ad un pubblico così
eterogeneo di poter scambiare idee ed indicare vie percorribili nella maniera più snella
possibile.
L'idea consiste nel creare una community sul genere di quella fornita agli sviluppatori
di MySql, dove viene reso possibile il confronto tra gli sviluppatori tramite diversi
canali.
Questi canali sono:
•
Forum dove ogni utente o sviluppatore, in relazione al forum con cui si
interagisce, possa sollevare i propri dubbi o problemi affinchè gli altri possano
consigliare soluzioni o fornire aiuto.
•
Mailing lists che forniranno gli stessi servizi del forum solo con la differenza di
avere comodamente le mail sempre disponibili senza necessita di essere
connessi alla rete tutte le volte che si ha bisogno di un'informazione.
•
Blog che avrà le stesse funzionalità degli altri due servizi offerti solo con
metodologie differenti, non sarà più un punto dove richiedere aiuto, ma bensì
dove fornirlo, ogni utente potrà infatti scrivere come ha risolto gli eventuali
159
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
problemi riscontrati per dare la possibilità agli altri di usufruire dell'esperienza
acquisita non solo dall'utente ma da tutta la comunità.
•
Canale irc dove gli utenti potranno scambiarsi feedback e trovare aiuto in tempo
reale tra gli altri sviluppatori della community.
•
Sistema CVS che permetterà di avere un controllo sulle versioni del software
che la community sta sviluppando, consentendo il download agli utenti della
versione stabile ed agli sviluppatori delle varie versioni “beta” dei sorgenti da
poter modificare per aggiungere servizi e funzionalità al sistema.
•
Una Wiki dove tutti coloro che vogliono possano immettere e fruire notizie
come viene fatto per wikipedia.
I vari servizi saranno mirati alle differenti tipologie di utenza, sono infatti contemplati
diversi tipi di utenti: utilizzatore, sviluppatore, sviluppatore CNIPA, amministratore, e
altri tipi da definire secondo le necessità future.
Ogni tipologia di utente ha diverse caratterizzazioni nei servizi che verranno offerti, nel
dettaglio le tipologie saranno strutturate in questa maniera:
•
utilizzatore: ha la possibilità di scaricare le versioni stabili del software, i
manuali d'uso, la documentazione e le varie ed eventuali licenze, inoltre per
questa tipologia di utente ciascuno dei servizi accennati sopra, ad esclusione del
CVS al quale non avrà accesso, verrà implementato in maniera da rendere il più
semplice possibile l'utilizzo degli stessi.
160
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
o
Una sotto-tipologia di utilizzatore è quello non registrato che può
accedere ai servizi per gli utilizzatori senza possibilità di scrittura
(lasciare messaggi etc...).
•
Sviluppatore: ha la possibilità di scaricare le versioni stabili del software, i
manuali d'uso, la documentazione e le varie ed eventuali licenze, come
l'utilizzatore inoltre per questa tipologia di utente sarà possibile scaricare i
sorgenti del software utilizzando il sistema CVS, gli altri servizi potranno essere
acceduti allo stesso modo dell'utilizzatore, con la possibilità però di avere una
“corsia preferenziale” per servizi dedicati allo sviluppo, come canali irc mailing
lists e forums dedicati.
•
Sviluppatore CNIPA: questo tipo di utente ha un ruolo fondamentale, infatti
sono gli sviluppatori CNIPA a dare le linee guida del progetto e a coordinare gli
altri sviluppatori della community; questa tipologia di utente gode dello stesso
tipo di servizi di uno Sviluppatore, in più collabora attivamente in CNIPA
partecipando alle decisioni che vengono prese sulle vie che il progetto deve
intraprendere.
•
Amministratore: ha la possibilità di usufruire di tutti i servizi forniti, inoltre ha
la responsabilità di gestore del CVS, e dei vari canali di comunicazione tra gli
altri utenti. Decide quando è il momento di effettuare un nuovo rilascio di una
versione in collaborazione con gli sviluppatori e svolge funzione di controllo
sugli utenti. Non è detto che debba essere unico ma la figura dell'amministratore
può essere coperta da un team di persone.
Allo stato attuale sono stati istituiti due servizi per permettere alle
persone
interessate
di
interagire
per
scambiare
notizie
o
suggerimenti. Sono infatti stati posti in essere un Forum [39] ed
161
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
una Wiki [40], inoltre sono stati fatti precedentemente a questo
lavoro degli studi per istituire una community e si
giunti alla
soluzione di utilizzare un Project Manager.
Sono stati presi in considerazione differenti prodotti open source
come phprojekt [41], dotproject [42], netoffice [43], gforge [44] ed
altri.
I pi
adatti alle necessit
di sviluppo della community che si
intende realizzare si sono rivelati phproject e gforge; tra i due la
scelta
ricaduta su gforge, questa
attualmente in CNIPA gforge viene gi
stata fatta valutando che
utilizzato per la gestione
della community dell Osservatorio Open Source.
Sembra più economico, dunque, sviluppare elementi dello stesso tipo utilizzando gli
stessi prodotti, in maniera tale da facilitare i compiti di configurazione,
personalizzazione e gestione del team che se ne occuperà.
162
Tesi di Laurea
Bibliografia
Vittorio Ottaviani
_______________________________________________________________________
Bibliografia
Decreti legge
[1]
Decreto legislativo n. 42 del 28 febbraio 2005 Istituzione del Sistema
Pubblico di Connettività e della rete internazionale della Pubblica
Amministrazione, a norma dell'articolo 10, della legge 29 luglio 2003, n. 229,
Gazzetta ufficiale n.73, 30 marzo 2005
http://www.cnipa.gov.it/site/_files/SPC.pdf
[2]
D.Lgs. 7 marzo 2005, n. 82, pubblicato in G.U. del 16 maggio 2005, n. 112 S.O. n. 93 “Codice dell’amministrazione digitale”, aggiornato dal D.Lgs. n.
159 del 4 aprile 2006 pubblicato in G.U. del 29 aprile 2006, n. 99 – S.O. n.
105 "Disposizioni integrative e correttive al decreto legislativo 7 marzo 2005,
n. 82 recante codice dell’amministrazione digitale"
http://www.cnipa.gov.it/site/_files/Codice%20Amministrazione%20Digitale_0
2.pdf
[3]
Legge n. 59 del 15 marzo 1997 Delega al Governo per il conferimento di
funzioni e compiti alle regioni ed enti locali, per la riforma della Pubblica
Amministrazione e per la semplificazione amministrativa, Gazzetta Ufficiale
n. 63 del 17 marzo 1997.
http://www.parlamento.it/leggi/97059l.htm
Documenti rilasciati dal CNIPA
[4]
Gruppo di Lavoro SPC, Sistema Pubblico di Connettività:Scenario
introduttivo, CNIPA, 07 Aprile 2004.
163
Tesi di Laurea
Bibliografia
Vittorio Ottaviani
_______________________________________________________________________
http://www.cnipa.gov.it/site/_files/4.SPC,Scenario%20introduttivo,QS,3.2.pdf
[5]
Gruppo di lavoro per i Servizi di interoperabilità, Sistema Pubblico di
Cooperazione: Architettura, CNIPA, 25 Novembre 2004.
http://www.cnipa.gov.it/site/_files/SPCoop-Architettura_v1.0_20041125_.pdf
[6]
Gruppo di Lavoro SPCoop, Sistema Pubblico di Cooperazione: Accordo di
Servizio, CNIPA, 14 Ottobre 2005.
http://www.cnipa.gov.it/site/_files/SPCoopAccordoServizio_v1.0_20051014.pdf
[7]
Gruppo di Lavoro SPCoop, Sistema Pubblico di Cooperazione: Busta di EGOV, CNIPA, 14 Ottobre 2005.
http://www.cnipa.gov.it/site/_files/SPCoop-Busta%20eGov_v1.1_20051014.pdf
[8]
Gruppo di Lavoro SPCoop, Sistema Pubblico di Cooperazione: Convenzioni
di Nomenclatura e Semantica, CNIPA, 14 ottobre 2005.
http://www.cnipa.gov.it/site/_files/SPCoopNomenclaturaSemantica_v1.0_20051014.pdf
[9]
Gruppo di Lavoro SPCoop, Sistema Pubblico di Cooperazione: Esercizio e
Gestione, CNIPA, 14 Ottobre 2005.
http://www.cnipa.gov.it/site/_files/SPCoopEsercizioGestione_v1.0_20051014.pdf
[10]
Gruppo di lavoro per i Servizi di interoperabilità, cooperazione applicativa ed
accesso del Sistema Pubblico di Connettività e Cooperazione, Sistema
Pubblico di Cooperazione: Organizzazione, CNIPA, 25 Novembre 2005.
164
Tesi di Laurea
Bibliografia
Vittorio Ottaviani
_______________________________________________________________________
http://www.cnipa.gov.it/site/_files/SPCoopOrganizzazione_v1.0_20041125_.pdf
[11]
Gruppo di Lavoro SPCoop, Sistema Pubblico di Cooperazione: Porta di
Dominio, CNIPA, 14 Ottobre 2005.
http://www.cnipa.gov.it/site/_files/SPCoop-PortaDominio_v1.0_20051014.pdf
[12]
Gruppo di Lavoro SPCoop, Sistema Pubblico di Cooperazione: Quadro
Tecnico d’Insieme, CNIPA, 14 Ottobre 2005.
http://www.cnipa.gov.it/site/_files/SPCoopQuadroInsieme_v1%200_20051014.pdf
[13]
Gruppo di Lavoro SPCoop, Sistema Pubblico di Cooperazione: Servizi di
Registro, CNIPA, 14 Ottobre 2005.
http://www.cnipa.gov.it/site/_files/SPCoopServiziRegistro_v1.0_20051014.pdf
[14]
Gruppo di Lavoro SPCoop, Sistema Pubblico di Cooperazione: Servizi di
Sicurezza, CNIPA, 14 Ottobre 2005.
http://www.cnipa.gov.it/site/_files/SPCoopServiziSicurezza_v1.0_20051014.pdf
[15]
Gruppo di Lavoro SPCoop, Sistema Pubblico di Cooperazione: Termini e
Definizioni, CNIPA, 14 Ottobre 2005.
http://www.cnipa.gov.it/site/_files/SPCoopTerminiDefinizioni_v1.0_20051014.pdf
Documenti incontrati sul WEB
165
Tesi di Laurea
Bibliografia
Vittorio Ottaviani
_______________________________________________________________________
[16]
IDABC, presentazione del progetto
http://ec.europa.eu/idabc/en/chapter/5883
[17]
EIF, European Interoperability Framework for pan-European eGovernment
services, Novembre 2004
[18]
IDABC, Open Source Observatory
http://www.cnipa.gov.it/site/_files/SPCoopNomenclaturaSemantica_v1.0_20051014.pdf
[19]
IDABC, E-Government news
[20]
Bundesministerium des innern, Standards und Architekturen für EGovernment
http://www.kbst.bund.de/saga
[21]
KBSt unit at the Federal Ministry of the Interior,Standards and Architectures
for eGovernment Applications version 3.0, KBSt publication, ottobre 2006
http://www.kbst.bund.de/cln_047/nn_945224/SharedDocs/Anlagenkbst/Saga/standards-and-Architectures-for-_20e-Government-applicationsversion-3__0-pdf,templateId=raw,property=publicationFile.pdf/standardsand-Architectures-for-%20e-Government-applications-version-3_0-pdf.pdf
[22]
Wikipedia English, Service Oriented Architecture
http://en.wikipedia.org/wiki/Service-oriented_architecture
[23]
Wikipedia Italiano, Service Oriented Architecture
http://it.wikipedia.org/wiki/Service-oriented_architecture
166
Tesi di Laurea
Bibliografia
Vittorio Ottaviani
_______________________________________________________________________
[24]
Csaba Krasznay Budapest University of Technology and Economics Centre of
Information
Technology
Hungary,
Hungarian
Electronic
Public
Administration Interoperability Framework (MEKIK) – Technical Standards
Catalogue, Observatory on interoperable eGovernment services (E-GOVinterop’05 annual conference 23-24 febraio2005 Geneva Switzerland)
http://egovinterop.eupm.net/cdrom/pages/presentations/6b3.ppt
[26]
Zsolt Sikolya, Péter Risztics, Hungarian Electronic Public Administration
Interoperability Framework (MEKIK) – Technical Standards Catalogue
http://www.krasznay.hu/presentation/egovinterop_krasznay.pdf
[27]
e-Government Interoperability Framework Version 6.1, 18 Marzo 2005
http://www.govtalk.gov.uk/documents/eGIF%20v6_1(1).pdf
[28]
Wikipedia English, e-GIF
http://en.wikipedia.org/wiki/E-GIF
[29]
A. Poli, OpenSPCoop: un’implementazione della Specifica di Cooperazione
Applicativa per la Pubblica Amministrazione Italiana, UNIVERSITÀ DI
PISA Facoltà di Scienze Matematiche, Fisiche e Naturali Corso di Laurea
Specialistica in Tecnologie Informatiche, 2005.
http://www.openspcoop.org/openspcoop/download/tesi/TesiAndreaPoli.pdf
[30]
R. Barsacchi, Progettazione di un framework Open Source per la
cooperazione applicativa nella Pubblica Amministrazione, UNIVERSITÀ DI
PISA Facoltà di Scienze Matematiche, Fisiche e Naturali Corso di Laurea
Specialistica in Tecnologie Informatiche, 2005.
http://www.openspcoop.org/openspcoop/download/tesi/TesiRuggeroBarsacchi
.pdf
167
Tesi di Laurea
Bibliografia
Vittorio Ottaviani
_______________________________________________________________________
[31]
Sistema Pubblico di Connettività, pagina introduttiva.
http://www.cnipa.gov.it/site/itIT/In_primo_piano/Sistema_Pubblico_di_Connettivit%c3%a0_(SPC)/
[32]
Servizi di interoperabilità evoluta e cooperazione applicativa, pagina
introduttiva.
http://www.cnipa.gov.it/site/itIT/In_primo_piano/Sistema_Pubblico_di_Connettivit%c3%a0_(SPC)/Servizi_
di_interoperabilit%c3%a0_evoluta_e_cooperazione_applicativa/
[33]
Apache Software Foundation, AXIS documentation users & developers.
http://ws.apache.org/axis/java/index.html
[34]
Sun Developer Network, Java Architecture for XML Binding (JAXB).
http://java.sun.com/webservices/jaxb/
[35]
Jochen Wiedmann, The JAXME 2 Manual, Apache Software Foundation,
2004.
http://ws.apache.org/jaxme/manual/index.html
[36]
Apache Software Foundation, Apache Tomcat Documentation
http://tomcat.apache.org/tomcat-6.0-doc/index.html
[37]
Wikipedia Italia, Web Service.
http://it.wikipedia.org/wiki/Web_service
[38]
Apache Software Foundation, Apache Ant 1.7.0 Manual
http://ant.apache.org/manual/
168
Tesi di Laurea
Bibliografia
Vittorio Ottaviani
_______________________________________________________________________
[39]
pagina principale del forum del SPC
http://forumspc.cnipa.it/forum/
[40]
pagina principale del wiki SPC
http://wikispcoop.cnipa.it/
[41]
pagina principale di phproject
http://www.phprojekt.com/
[42]
pagina principale di dotproject
http://www.dotproject.net/
[43]
pagina principale di netoffice
http://netoffice.sourceforge.net/modules/news/
[44]
pagina principale di gforge
http://gforge.org/
Documenti W3C
[45]
E. Christensen, F. Curbera, G. Meredith, S. Weerawarena, Web Services
Description Language (WSDL) 1.1, W3C, 15 Marzo 2001
http://www.w3.org/TR/wsdl
[46]
D. Box, D. Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. F.
Nielsen, S. Thatte, D. Winer, Simple Object Access Protocol (SOAP)1.1,
W3C, 8 Maggio 2000.
http://www.w3.org/TR/2000/NOTE-SOAP-20000508/
169
Tesi di Laurea
Bibliografia
Vittorio Ottaviani
_______________________________________________________________________
[47]
M. Gudgin, M. Hadley, N. Mendelsohn, J. J. Moreau, H. F. Nielsen, Simple
Object Access Protocol (SOAP)1.2, W3C, 24 Giugno 2003.
http://www.w3.org/TR/2003/REC-soap12-part1-20030624/
[48]
L. Clement, A. Hately, C. von Riegen, T. Rogers, UDDI Version 3.0.2, UDDI
Spec Technical Committee Draft, 19 ottobre2004.
http://uddi.org/pubs/uddi-v3.0.2-20041019.htm
[49]
K. Lawrence, C. Kaler, Web Services Security: SOAP Message Security 1.1,
OASIS Standard Specification, 1 febbraio 2006.
http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-specos-SOAPMessageSecurity.pdf
[50]
K. Iwasa, Web Services Reliable Messaging TC WS-Reliability 1.1, OASIS
Standard Specification, 15 novembre 2004.
http://docs.oasis-open.org/wsrm/ws-reliability/v1.1/wsrm-ws_reliability-1.1spec-os.pdf
[51]
D.L. McGuinness, F. van Harmelen, OWL Web Ontology Language
Overview, W3C Recommendation, 10 febbraio 2004
http://www.w3.org/TR/owl-features/
Libri di testo consultati
[52]
C. F. Goldfarb, P. Prescod, XML, Mc. Graw Hill, Febbraio 1999.
[53]
P. Krutchen, The Rational Unified Process: An Introduction, AddisonWesley, 2000.
170
Tesi di Laurea
Bibliografia
Vittorio Ottaviani
_______________________________________________________________________
[54]
G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modeling Language User
Guide, Addison-Wesley.
[55]
M. Page-Jones, Progettazione OO con UML, Apogeo, 2002.
[56]
H. Schildt, Java 2 la guida completa 4°edizione, Mc Graw Hill, 2001.
171
Tesi di Laurea
Vittorio Ottaviani
_______________________________________________________________________
Indice analitico delle figure
Figura 1: Possibile architettura di una SOA (fonte: Wikipedia)...................................... 9
Figura 2: Paradigma Find-Bind-Execute ....................................................................... 13
Figura 3: Architettura del Sistema SAGA [21].............................................................. 14
Figura 4: Pila SPC.......................................................................................................... 16
Figura 5: Esempio di una QXN del Sistema Pubblico di Connetività........................... 20
Figura 6: Modello Architetturale del SPCoop ............................................................... 29
Figura 7: Architettura dei servizi SICA ......................................................................... 32
Figura 8: Esempio di comunicazione tra porte .............................................................. 33
Figura 9: Modalità di Erogazione di un Servizio........................................................... 38
Figura 10 : Struttura completa di un Accordo di Servizio ............................................. 42
Figura 11: Busta SOAP.................................................................................................. 44
Figura 12: Intestazione................................................................................................... 46
Figura 13: IntestazioneMessaggio ................................................................................. 47
Figura 14: Comunicazione tra Porte di Dominio........................................................... 52
Figura 15: Interazione tra Registro Generale e Registri Secondari ............................... 56
Figura 16: Porta di Dominio come Strato Protocollare ................................................. 60
Figura 17: Porta di Dominio come Proxy Applicativo .................................................. 62
Figura 18: Comunicazione Messaggio Singolo ............................................................. 63
Figura 19: Comunicazione Sincrona.............................................................................. 63
Figura 20: Comunicazione Asincrona Simmetrica ........................................................ 64
Figura 21: Comunicazione Asincrona Asimmetrica...................................................... 65
Figura 22: Vista generale degli Use Case ...................................................................... 67
Figura 23: Use Case Trasmetti Messaggio .................................................................... 68
Figura 24: Use Case Ricevi Messaggio ......................................................................... 69
Figura 25: Use Case Gestione Tracciamenti.................................................................. 71
Figura 26: Use Case Gestione Diagnostici .................................................................... 72
Figura 27: Sequence diagram del caso di comunicazione a messaggio singolo
(trasmissione)......................................................................................................... 74
Figura 28: Sequence diagram del caso di comunicazione a messaggio singolo
(ricezione) .............................................................................................................. 76
Figura 29: Sequence diagram del caso di comunicazione sincrona (trasmissione) ....... 78
Figura 30: Sequence diagram del caso di comunicazione sincrona (ricezione) ............ 81
Figura 31: Sequence diagram del caso di comunicazione asincrona simmetrica
(trasmissione)......................................................................................................... 83
Figura 32: Sequence diagram del caso di comunicazione asincrona simmetrica
(ricezione) .............................................................................................................. 85
172
Tesi di Laurea
Indice analitico delle figure
Vittorio Ottaviani
_______________________________________________________________________
Figura 33: Sequence diagram del caso di comunicazione asincrona asimmetrica
(trasmissione)......................................................................................................... 87
Figura 34: Sequence diagram del caso di comunicazione asincrona asimmetrica
(ricezione) .............................................................................................................. 91
Figura 35: Architettura della Porta di Dominio ........................................................... 109
Figura 36: Strumenti utilizzati per realizzare l’architettura della Porta di Dominio ... 111
Figura 37: Schema di funzionamento di JAXME........................................................ 115
Figura 38: Schema di funzionamento del processo di serializzazione/deserializzazione
.............................................................................................................................. 116
Figura 39: Output sull’Application Server (caso Messaggio Singlo).......................... 136
Figura 40: Configurazione di eclipse per il deploy automatico.................................. 151
173
Tesi di Laurea
Glossario
Vittorio Ottaviani
_______________________________________________________________________
Glossario
I. ACoop Accordo di Cooperazione.
II. AS Accordo di Servizio.
III. Accordo di Cooperazione Un Accordo di Cooperazione è la specifica dei
servizi applicativi, composti e coordinati, offerti da un Dominio di
Cooperazione (per dettagli, vedi documenti QUADRO D’INSIEME e
ACCORDO DI SERVIZIO).
IV. Accordo di servizio Definizione delle funzionalità, interfacce, requisiti di
sicurezza e di qualità di uno o più servizi applicativi che vengono scambiati tra
due amministrazioni pubbliche (per dettagli, vedi documenti QUADRO
D’INSIEME e ACCORDO DI SERVIZIO).
V. Applicazione
Interdominio Applicazione Informatica che si basa su
programmi che operano in domini diversi.
VI. Attori dell’Interazione Ruoli di erogazione (erogatore) e fruizione (fruitore) di
uno o più servizi applicativi.. Sono di norma costituiti da applicazioni
informatiche ad hoc.
VII. Autenticazione Operazione mediante cui è possibile verificare l’attendibilità di
un identificativo, riferito ad una persona o ad un sistema elaborativo, associato
ad una transazione o ad un messaggio. L’autenticazione è il mezzo attraverso
cui il destinatario di una transazione o di un messaggio può decidere se accettare
o meno tale transazione.
VIII. Autorizzazione Operazione con cui un dominio di sicurezza decide se accettare
o meno la richiesta di attivazione di una determinata operazione informatica
proveniente da un messaggio o una transazione.
IX. Busta di eGov Protocollo applicativo, specificatamente progettato per SPCoop,
con cui i servizi applicativi sono invocabili remotamente: è una estensione dello
standard SOAP, necessaria al fine di supportare la sicurezza point-to-point,
174
Tesi di Laurea
Glossario
Vittorio Ottaviani
_______________________________________________________________________
l’affidabilità della trasmissione e la tracciatura di tutte le comunicazioni (aspetti
avanzati non ancora standardizzati).
X. Catalogo degli Schemi/Ontologie Il Catalogo degli Schemi/Ontologie è il
componente software che offre funzionalità per “ragionare” sulla semantica dei
servizi e delle informazioni da essi veicolati, ai fini della individuazione dei
servizi migliori candidati all’erogazione delle prestazioni richieste. Funge,
quindi, da struttura di memorizzazione delle ontologie e degli schemi
concettuali, offrendo le funzionalità di registrazione, accesso, aggiornamento,
cancellazione, ricerca e ragionamento su di essi.
XI. Contratto di Servizio Vedi Accordo di Servizio.
XII. Cooperazione applicativa Condizione per cui è possibile rendere disponibili
servizi informatici utilizzando le funzioni di due o più applicazioni progettate
per erogare servizi singolarmente.
XIII. DC Dominio di Cooperazione.
XIV. Dominio di Cooperazione Insieme di amministrazioni che cooperano per
l’automazione di un insieme di procedimenti amministrativi. Vedi DOMINIO
(Glossario).
XV. Dominio di Gestione Insieme di sistemi elaborativi, delle applicazioni e delle
procedure che vengono gestiti da una stessa organizzazione. Vedi DOMINIO
(Glossario).
XVI. Dominio dei Servizi Applicativi Insieme dei servizi applicativi erogati dalla
singola amministrazione in ambito SPCoop. Vedi DOMINIO (Glossario).
XVII. Dominio di Sicurezza Insieme di sistemi elaborativi, delle applicazioni e delle
procedure le cui regole di sicurezza ricadono sotto la responsabilità di una stessa
organizzazione.
XVIII. DSA Dominio dei Servizi Applicativi.
XIX. Erogatore Attore dell’interazione tra servizi applicativi: fornisce informazioni a
chi le richiede, ovvero ad un attore richiedente che di norma è il Fruitore.
XX. Fruitore Attore dell’interazione tra servizi applicativi: richiede informazioni ad
un secondo attore, il quale a fronte di interazione con i propri sistemi legacy,
175
Tesi di Laurea
Glossario
Vittorio Ottaviani
_______________________________________________________________________
eroga (Erogatore) successivamente il servizio richiesto all’attore richiedente, il
quale dunque fruisce del servizio (Fruitore).
XXI. ICP Infrastruttura a Chiave Pubblica. Vedi PKI (Glossario).
XXII. ICP SICA Servizi SICA di infrastruttura a chiave pubblica.
XXIII. Identificazione Operazione che consiste nell’associare ad una transazione o ad
un messaggio un identificativo attribuibile alla persona o al sistema elaborativo
che ha originato la transazione o il messaggio.
XXIV. Incapsulamento Vedi WRAPPING.
XXV. Indice della PA Nell'IndicePA è descritta la struttura organizzativa di ciascuna
amministrazione accreditata, con l'articolazione gerarchica delle varie unità o
uffici. Per ciascuna unità sono disponibili gli indirizzi delle caselle di Posta
Elettronica Certificata (P.E.C.) attive e di eventuali servizi applicativi resi
disponibili on-line. L'IndicePA costituisce, quindi, un punto di riferimento per
l'individuazione e l'accesso alle strutture organizzative e ai servizi telematici
offerti dalla Pubblica Amministrazione centrale e locale. Nell'IndicePA sono,
inoltre, pubblicate tutte le informazioni necessarie per lo scambio di messaggi di
posta elettronica attraverso le caselle istituzionali associate ai sistemi di
protocollo informatico. (Vedi http://www.indicepa.gov.it/).
XXVI. Indice dei Soggetti Insieme di funzionalità necessarie a gestire la “rubrica”
degli operatori della PA. Oltre ad offrire funzionalità di registrazione, accesso,
aggiornamento, cancellazione e ricerca delle informazioni relative agli operatori
(ad es., nome, cognome, riferimenti telefonici ed e-mail, funzioni,
responsabilità, mansioni, etc.), una funzionalità fondamentale offerta da questo
componente infrastrutturale è la gestione dell’identità elettronica del soggetto
(identity management), che è necessaria per poter poi costruire appropriate
politiche di sicurezza (in particolare autenticazione ed autorizzazione) per
l’accesso ai servizi applicativi.
XXVII. Infrastruttura unitaria di Servizi di Interoperabilità Cooperazione e
Accesso Insieme di risorse e di strumenti che abilitano la cooperazione tra
domini diversi rendendo disponibili servizi applicativi comuni (Vedi SICA).
176
Tesi di Laurea
Glossario
Vittorio Ottaviani
_______________________________________________________________________
XXVIII. Indirizzo di Risorsa Vedi URI (Glossario).
XXIX. Interoperabilità Capacità di una applicazione di sfruttare le funzioni di un’altra
applicazione; si dice che A e B interoperano se A è in grado di utilizzare le
funzioni di B e viceversa.
XXX. Messaggio Applicativo Contenuto informativo per erogazione di un servizio
applicativo, che viene scambiato tramite Busta di eGov tra le Porte di Dominio
dei due attori dell’interazione (Erogatore e Fruitore).
XXXI. Ontologia Descrive la semantica dei servizi e delle informazioni da essi
veicolati, ovvero la tipologia di informazioni che il servizio è in grado di
veicolare. Consente di compiere operazioni di “ragionamento” (semi)automatico sulla base di tali informazioni.
XXXII. PD Porta di Dominio.
XXXIII. Porta di dominio La porta di dominio rappresenta un elemento concettuale che
ha la funzione di proxy per l’accesso alle risorse applicative del dominio. Fa
parte del modello organizzativo di SPCoop e, come tale, trova naturalmente
posto nella progettazione concettuale piuttosto che in quella logica o fisica. La
PD può essere ricoprire due ruoli:

Porta Applicativa: Ruolo assunto da una porta di dominio di SPCoop
nell’ambito di un episodio di collaborazione applicativa. Assume tale ruolo
la porta di dominio che, a seguito della ricezione di un messaggio di
richiesta proveniente da un’altra porta di dominio (porta delegata) invia al
mittente un messaggio di risposta.

Porta Delegata: Ruolo assunto da una porta di dominio di SPCoop
nell’ambito di un episodio di collaborazione applicativa. Assume tale ruolo
la porta di dominio che origina un messaggio di richiesta (di servizio)
destinato ad un’altra porta di dominio (porta applicativa).
(per dettagli, vedi documento PORTA DI DOMINIO).
XXXIV. Processo Insieme di attività tra loro correlate, finalizzate al raggiungimento di
un obiettivo predefinito.
177
Tesi di Laurea
Glossario
Vittorio Ottaviani
_______________________________________________________________________
XXXV. Profilo di Accesso Insieme di informazioni che qualificano il soggetto (persona
o sistema elaborativo) che ha dato origine ad un messaggio o ad una
transazione. Il profilo di accesso ha la finalità di fornire le informazioni
necessarie per il processo di autorizzazione.
XXXVI. Registro SICA Servizi SICA di Registrazione e Ricerca. Vedi SICA.
XXXVII. Relazione di servizio Relazione che lega due attori dell’interazione, all’interno
della quale uno di loro assume il ruolo di erogatore e l’altro di fruitore.
XXXVIII. Riconoscimento (Vedi anche Identificazione) Attività che consente di
determinare l’identità di un soggetto.
XXXIX. Rubrica della PA Directory dei dipendenti della PA Centrale. Primo embrione
di un sistema di Identity Management.
XL. RUPA Rete Unitaria della Pubblica Amministrazione.
XLI. Semantica dei Servizi e delle Informazioni Vedi Ontologia.
XLII. Servizi Asincroni Modalità di erogazione dei servizi applicativi tra le porte di
dominio delle amministrazioni, secondo il sistema di coordinamento e gestione
proprio dio SPCoop (per dettagli, vedi documento ESERCIZIO E GESTIONE).
XLIII. Servizi di Registro I Servizi di Registro sono una delle componenti dei Servizi
Infrastrutturali SICA in cui gli Accordi di Servizio (e di Cooperazione) vengono
registrati e mantenuti (a meno della loro componente semantica). Costituiscono,
di fatto, la base di dati della cooperazione. Offrono funzionalità per la
registrazione, l’accesso, l’aggiornamento, la cancellazione e la ricerca degli
Accordi di Servizio (e di Cooperazione). (per dettagli, vedi documenti
QUADRO D’INSIEME e SERVIZI DI REGISTRO).
XLIV. Servizi Sincroni Modalità di erogazione dei servizi applicativi tra le porte di
dominio delle amministrazioni, secondo il sistema di coordinamento e gestione
proprio di SPCoop (per dettagli, vedi documento ESERCIZIO E GESTIONE).
XLV. Servizi di Interoperabilità, Cooperazione ed Accesso

Servizi di rete, erogati con livello di qualità predefinito in termini di
sicurezza, disponibilità ed affidabilità, per l’integrazione di sistemi e servizi
informativi eterogenei per la realizzazione di servizi applicativi compositi.
178
Tesi di Laurea
Glossario
Vittorio Ottaviani
_______________________________________________________________________

Sviluppo di applicazioni distribuite basate sull’interazione di servizi di rete
con livelli di qualità, sicurezza ed affidabilità predefiniti.

Ricerca ed accesso a servizi di rete erogati da diversi soggetti per la
realizzazione di servizi integrati e compositi a valore aggiunto (per dettagli,
vedi documenti QUADRO D’INSIEME e SERVIZI DI REGISTRO).
XLVI. SICA Vedi Servizi di Interoperabilità, Cooperazione ed Accesso.
XLVII. SICA generale Servizi di Registro SICA a livello centrale (per dettagli, vedi
documenti QUADRO D’INSIEME e SERVIZI DI REGISTRO).
XLVIII. SICA secondari Servizi di Registro SICA a livello locale (per dettagli, vedi
documenti QUADRO D’INSIEME e SERVIZI DI REGISTRO).
XLIX. Sistema Pubblico di Connettività e Cooperazione Il Sistema Pubblico di
Connettività e Cooperazione, evoluzione della RUPA, il cui obbiettivo è
promuovere l’interazione tra le reti regionali, territoriali e delle P.A. centrali,
per conseguire economie di scala nell’utilizzo dei servizi di rete, assicurando
l’interoperabilità e standard comuni di funzionalità e sicurezza. Decreto
Legislativo 28 febbraio 2005, n. 42, pubblicato nella Gazzetta Ufficiale della
Repubblica Italiana – Serie Generale - del 30 marzo 2005, n. 73.
L. SPC Sistema Pubblico di Connettività e Cooperazione.
LI. SPConn Sistema Pubblico di Connettività: sottosistema del SPC, che
comprende i servizi di connettività ed interoperabilità di base.
LII. SPCoop Sistema Pubblico di Cooperazione: sottosistema del SPC che
comprende i sistemi di interoperabilità avanzata e di cooperazione applicativa.
LIII. Transazione Insieme di messaggi correlati che svolgono un’operazione
elementare unitaria che mantiene la consistenza della base informativa.
LIV. Wrapping Insieme di attività di predisposizione delle applicazioni legacy in
uso, al fine di renderle accessibili da parte di servizi applicativi sviluppati ad es.
con tecnologie open e standard di mercato tipo Web Services.
Il presente glossario è un estratto da [15] con il gentile permesso del Gruppo di
Lavoro SPCoop.
179