Tesi_Adamou

Una Rich Internet Application per l'annotazione
semantica degli Accordi di Servizio nel Sistema
Pubblico di Cooperazione

Facoltà di Scienze Matematiche, Fisiche e Naturali
Corso di laurea quinquennale in Informatica

Candidato

Alessandro Adamou
Matricola 691636

Relatore Correlatori

Prof. Giancarlo Bongiovanni Dott. Stefano Fuligni

Dott. Aldo Gangemi

Anno Accademico 2007/2008

Indice Generale

Indice generale
Premessa..........................................................................................................................4
1. Introduzione al contesto di riferimento.....................................................................7
1.1. Il Centro Nazionale per l'Informatica nella Pubblica Amministrazione................7
1.2. Il Sistema Pubblico di Connettività e Cooperazione (SPC)...................................8
1.2.1. Il livello di connettività................................................................................12
1.2.2. Il livello di interoperabilità e cooperazione..................................................14
2. La semantica per l'interoperabilità dei servizi in SPCoop....................................37
2.1. Nozioni fondamentali e strumenti per la semantica.............................................39
2.1.1. Le ontologie computazionali........................................................................39
2.1.2. Strumenti formali per le ontologie: Resource Description Framework
(RDF), RDF Schema e Web Ontology Language (OWL).....................................42
2.2. Analisi dell'Accordo di Servizio..........................................................................50
2.2.1. Ciclo di vita dell'Accordo di Servizio..........................................................50
2.2.2. Struttura dell'Accordo di Servizio................................................................52
2.3. Il ruolo del Catalogo Schemi ed Ontologie in SPCoop.......................................58
2.4. Annotazione semantica di un Accordo di Servizio e di uno schema XML
concettuale..................................................................................................................59
2.4.1. La specifica SAWSDL per l'annotazione dell'Accordo di Servizio.............60
2.4.2. Riferimenti semantici in SPCoop.................................................................64
2.5. Criticità e problematiche nel supporto all'annotazione semantica in SPCoop.....68
3. La soluzione proposta................................................................................................74
3.1. Analisi e definizione dei requisiti funzionali.......................................................74
3.1.1. Modello dell'utente.......................................................................................76
3.1.2. Casi d'uso.....................................................................................................81
3.1.3. Modello delle componenti............................................................................86
3.2. Progettazione dell'interfaccia utente....................................................................91
4. Sviluppo ed implementazione: SAscha..................................................................100
4.1. Risorse e strumenti utilizzati..............................................................................101

2

4.2. Software a supporto dell'implementazione........................................................105
4.2.1. API grafiche per AJAX..............................................................................107
4.2.2. Librerie per il supporto WSDL...................................................................111
4.2.3. Librerie per il supporto all'estensione SAWSDL.......................................115
4.2.4. Librerie per la gestione delle ontologie......................................................125
4.3. Estensione della libreria SAWSDL4J................................................................127
4.3.1. Attuali limitazioni.......................................................................................127
4.3.2. Supporto per schemi XML stand-alone: il plugin SAXSD4J....................129
4.3.3. Integrazione delle funzionalità incomplete................................................135
4.4. L'applicativo SAscha.........................................................................................140
4.4.1. Architettura fisica dell'implementazione....................................................140
4.4.2. SIOM: un object model intermedio per il passaggio di risorse fra client e
server....................................................................................................................141
4.4.3. L'interfaccia di servlet................................................................................150
4.4.4. Motori applicativi server-side....................................................................153
4.4.5. Implementazione dell'interfaccia utente.....................................................156
4.5. Testing................................................................................................................160
4.5.1. Compatibilità cross-browser......................................................................161
4.5.2. Il caso di studio del progetto ICAR............................................................163
4.5.3. Casi di test..................................................................................................166
5. Conclusioni e sviluppi futuri...................................................................................170
Bibliografia..................................................................................................................173

3

Premessa

Premessa
Il presente lavoro è frutto della collaborazione tra il Centro Nazionale per
l'Informatica nella Pubblica Amministrazione [CNIPA] e il Dipartimento di Informatica
degli Studi di Roma “La Sapienza” [DI-UR1] sul tema dell'interoperabilità e della
cooperazione applicativa nella Pubblica Amministrazione (PA) italiana. In particolare,
viene affrontato uno dei campi applicativi di maggiore interesse presente e futuro: il
framework denominato Sistema Pubblico di Cooperazione (SPCoop), un'infrastruttura
avviata a divenire entro breve il backbone per l'interoperabilità telematica fra i domini
della PA.

Questa tesi si pone l'obiettivo di fornire un contributo, sotto forma di strumento
software, a supporto della partecipazione attiva ad SPCoop da parte delle
Amministrazioni che vi aderiscono. Tale obiettivo ha implicato ulteriori requisiti che
questo strumento ha dovuto soddisfare rispetto ad analoghi strumenti, anche open-
source, presenti oggi sul mercato: in particolare la semplificazione, l'adattamento alle
particolari esigenze di SPCoop e l'indipendenza dalle diverse piattaforme informatiche.

Scopo principale della tesi è dunque la progettazione e lo sviluppo di
un'applicazione web altamente interattiva a supporto del processo di annotazione
semantica dei servizi erogati in SPCoop. Questo obiettivo è emerso nel corso dello
studio degli standard e delle tecnologie che concorrono al modello SPCoop, a seguito
dell'analisi delle connotazioni semantiche del sistema, svolta in collaborazione, oltre che
con il CNIPA, con il Consiglio Nazionale delle Ricerche, in particolare l'Istituto di
Scienze e Tecnologie della Cognizione [ISTC]. La soluzione applicativa sviluppata ai
fini della tesi, ancorché concepita in seno a questa particolare architettura, ha
prospettive di estensibilità tali da renderla, nel corso di eventuali futuri sviluppi, uno
strumento general-purpose a sostegno della gestione dei cosiddetti Web Service
semantici.

Un obiettivo secondario, emerso in corso di sviluppo del progetto, è stato

4

Premessa

l'estensione di un object model preesistente, noto come SAWSDL4J, con un pacchetto
software aggiuntivo, da un lato per soddisfare un particolare requisito di SPCoop e
dall'altro per sopperire alle lacune della libreria in questione.

Il presente lavoro si articola in cinque capitoli. Il primo introduce il lettore allo
scenario delle architetture orientate ai servizi (SOA) e dei Web Service, con riferimento
al loro impiego nella Pubblica Amministrazione italiana ed in particolare al Sistema
Pubblico di Connettività e Cooperazione (SPC) ed al framework SPCoop, di cui si
illustrano i componenti infrastrutturali alla base.

Il secondo capitolo è dedicato al problema dell'integrazione fra i servizi della PA e
il contesto del web semantico, ed è accompagnato da un'analisi approfondita di uno
degli elementi infrastrutturali di SPCoop, l'Accordo di Servizio. Tale analisi, dapprima
prettamente strutturale, si focalizza sulle convenzioni adottate per l'estensione di questo
oggetto con metadati che descrivono il significato delle informazioni veicolate dai
servizi. Segue una descrizione delle modalità e dei processi di annotazione semantica
dei servizi erogati in SPCoop. Sono infine esaminati i relativi standard definiti dal
CNIPA sulla base delle raccomandazioni del World Wide Web Consortium (W3C), di
cui viene individuato il set minimale utile in ambito SPCoop.

Il terzo capitolo è dedicato alla progettazione di un sistema che soddisfi i requisiti
di essenzialità ed integrazione con i servizi infrastrutturali di SPCoop, per supportare in
dettaglio i processi di annotazione semantica descritti nel capitolo precedente. La
progettazione riguarderà in particolar modo l'accoppiamento debole fra logica
applicativa ed interfaccia, nonché la modellazione di quest'ultima sulla base di un
determinato paradigma dell'utente.

Il quarto capitolo si concentra sullo sviluppo dell'applicativo SASCHA, uno
strumento basato su web a supporto dell'annotazione semantica degli Accordi di
Servizio. Sono altresì descritte le attività di progettazione e sviluppo complementari, tra
cui l'estensione della libreria SAWSDL4J. Si presenta una panoramica delle varie

5

Premessa

tipologie di risorse prese in esame in corso di progettazione, fornendo per ciascuna di
esse opportune motivazioni in merito alla loro adozione o meno per il presente progetto.
Queste risorse comprendono sia l'ambiente di sviluppo scelto, dall'hardware fino agli
strumenti per redigere questa tesi, sia le API (Application Programming Interface)
utilizzate per rispondere ai requisiti di progetto dell'applicazione. Il capitolo si conclude
con l'esposizione delle attività di collaudo, svolte sia sul piano tecnico che in relazione
ad un caso di studio con esempi sia di Accordi di Servizio che di modelli semantici da
impiegare per annotarli.

Per concludere, nell'ultimo capitolo vengono proposte le conclusioni tratte da
questa esperienza e le possibili direttrici di sviluppo, con prospettive di estensibilità
dell'applicativo SASCHA, sia per una più netta integrazione con i servizi di SPCoop che
per una migrazione verso un modello di sviluppo compatibile con i mondi aperti dei
Web Service e del web semantico.

6

1.Introduzione al contesto di riferimento

1. Introduzione al contesto di riferimento
La IEEE definisce l'interoperabilità come “la capacità di due o più sistemi o
componenti di scambiare informazioni ed utilizzare le informazioni che sono state
scambiate” [IEEE91]. L'interoperabilità è uno dei temi di maggior rilievo in un contesto
quale è quello dell'adozione, in tutto il mondo, di forme di eGovernment, ossia l'uso di
tecnologie dell'informazione e della comunicazione (ICT) come piattaforma per la
fornitura di servizi, scambio di informazioni e svolgimento di transazioni da e verso il
cittadino e le amministrazioni [Bro03][JaiSha07]. Vista dalla prospettiva
dell'eGovernment, questa definizione si traduce nella capacità di fornire ed utilizzare i
servizi della Pubblica Amministrazione, assicurando una coerente interpretazione dei
dati in un ambito inerentemente eterogeneo, ad esempio in termini di standard, di
categorizzazione e, in contesti di interoperabilità internazionale, di barriere linguistiche.

La necessità di interpretare automaticamente e con un sufficiente grado di
accuratezza il significato delle informazioni scambiate e dei servizi utilizzati viene
definita interoperabilità semantica [SWZK06]. Il Sistema Pubblico di Connettività e
Cooperazione (spesso citato come Sistema Pubblico di Connettività, SPC) [CNIPA04]
rappresenta la risposta italiana a tali esigenze, a fronte di un crescente fenomeno di
decentramento delle competenze rivolto verso forme di federalismo che hanno come
riferimento le regioni e le autonomie locali del nostro Paese.

1.1. Il Centro Nazionale per l'Informatica nella Pubblica
Amministrazione

Operante presso la Presidenza del Consiglio dei Ministri “con autonomia tecnica,
funzionale, amministrativa, contabile e finanziaria e con indipendenza di giudizio”1 , il
Centro Nazionale per l'Informatica nella Pubblica Amministrazione (CNIPA)2 è l'organo
preposto a supportare l'utilizzo efficace delle tecnologie dell'informazione e delle
comunicazioni nelle Pubbliche Amministrazioni (PPAA) per ottimizzare la qualità dei
1 D.L.vo 30 giugno 2003, n. 196, art. 176 comma 3
2 http://www.cnipa.gov.it

7


servizi e rendere efficiente l’azione amministrativa, contenendone nel contempo i costi.
Il CNIPA nasce nel 2004 dalla fusione di due precedenti organismi: l’Autorità per
l’Informatica nella Pubblica Amministrazione ed il Centro tecnico per la Rete Unificata
della Pubblica Amministrazione (RUPA)3. Quest'ultima, in esercizio tra il 2000 e il
2007, è stata la prima esperienza di infrastruttura condivisa nell'ambito della PA italiana,
ed ha costituito il primo stadio evolutivo del SPC.

A partire dal 2003, su incarico del Ministero per la Pubblica Amministrazione e
l'Innovazione [MPAI], il CNIPA ha svolto attività di studio e definizione degli standard
dell'infrastruttura di interoperabilità che avrebbe rappresentato la naturale evoluzione
della RUPA. Un importante passo di questo processo è rappresentato dal decreto
legislativo del 28 febbraio 2005 n. 42 (brevemente il Decreto 42-2005) [DL4205], che
istituisce e disciplina il Sistema Pubblico di Connettività. Tale decreto conferisce anche
al CNIPA il compito di seguire attivamente e in maniera continuativa la costituzione e
l'evoluzione del SPC. In particolare, al CNIPA è affidato il compito di gestire le “risorse
condivise del SPC e le strutture operative preposte al controllo e supervisione delle
stesse” e “la progettazione, la realizzazione, la gestione e l'evoluzione del SPC” 4.

1.2. Il Sistema Pubblico di Connettività e Cooperazione (SPC)

SPC è definito come “l'insieme di infrastrutture tecnologiche e di regole tecniche,
per lo sviluppo, la condivisione, l'integrazione e la diffusione del patrimonio
informativo e dei dati della pubblica amministrazione, necessarie per assicurare
l'interoperabilità di base ed evoluta e la cooperazione applicativa dei sistemi
informatici e dei flussi informativi, garantendo la sicurezza, la riservatezza delle
informazioni, nonché la salvaguardia e l'autonomia del patrimonio informativo di
ciascuna pubblica amministrazione”5. La realizzazione del SPC avviene nel rispetto di
principi fra i quali l'architettura federata e non gerarchica del sistema e l'efficienza,

3 http://www.cnipa.gov.it/site/it-it/Attivit
%C3%A0/Sistema_Pubblico_di_Connettivit%C3%A0_(SPC)/RUPA/
4 [DL4205], articolo 10.
5 [DL4205], articolo 2 comma 2.

8


anche economica, nell'utilizzo dei servizi di interoperabilità e cooperazione applicativa6.

Il SPC ha la finalità di mettere a disposizione delle PPAA centrali e locali un
insieme di servizi di connettività che sia condiviso e scalabile nei livelli di sicurezza e di
qualità del servizio e di funzionalità. Su questi servizi di connettività si poggia
un'infrastruttura di interscambio che consenta l'interoperabilità di tutte le reti delle
PPAA esistenti, garantendo l'interazione delle amministrazioni con altri soggetti, fra cui
cittadini ed enti privati7.

Successivamente il Decreto 42-2005, pur senza entrare nel merito delle
caratteristiche tecniche del SPC, definisce l'ambito di responsabilità delle singole
amministrazioni che vi partecipano, elenca i requisiti necessari affinché un soggetto
possa qualificarsi come fornitore di servizi ed istituisce un organismo, la Commissione
di Coordinamento del SPC, che promuova la cooperazione applicativa nella Pubblica
Amministrazione, verifichi la qualità dei servizi erogati ed approvi le modalità operative
degli stessi. Inoltre, il Decreto dà le prime disposizioni in materia di migrazione dalla
RUPA al SPC8.

Alcune importanti linee guida in materia di gestione, trasmissione, accesso e
conservazione dell'informazione supportata dalle tecnologie dell'informazione e della
comunicazione sono state raccolte nel “Codice dell'amministrazione digitale” (di
seguito il “Codice”) [DL8205]. Il Codice ha varato norme in materia di procedimento
amministrativo informatico, uso della posta elettronica certificata (PEC), attività di
certificazione della firma digitale e dematerializzazione dei documenti delle Pubbliche
Amministrazioni. Fra queste norme sono riportate, al Capo VIII, le stesse disposizioni
di cui al Decreto 42-20059.

L'articolo 71 del Codice stabilisce che, entro nove mesi dalla sua entrata in vigore,
siano adottate le Regole tecniche e di sicurezza per il funzionamento del sistema
6 [DL4205], articolo 2 comma 3.
9 [DL8205], articoli 72-87.

9


pubblico di connettività10 (brevemente le “Regole tecniche”). Queste sono state
approvate e rese pubbliche con il Decreto del Presidente del Consiglio dei Ministri del 1
aprile 2008 [DPCM08] ed hanno rappresentato un passo fondamentale dell'evoluzione
del SPC. Applicando le definizioni di cui al Codice, tali Regole tecniche entrano, per la
prima volta nel contesto normativo, nel merito degli standard e delle tecnologie da
adottare nella definizione delle infrastrutture e dei servizi del Sistema Pubblico di
Connettività. Dato che si entrerà nel dettaglio delle varie disposizioni e definizioni in
sede di analisi delle componenti d'interesse di SPC, ci si limita qui a riassumere le
finalità e i punti ritenuti salienti di questo decreto.

Sinteticamente, le Regole tecniche:

● ribadiscono le finalità del SPC, ridefiniscono ruoli e responsabilità delle
amministrazioni che vi partecipano e stabiliscono un modello federato di mutua
e paritetica collaborazione;

● espongono l'architettura del SPC stratificata come segue: (i) un livello di
interconnessione e comunicazione tra più amministrazioni e all'interno di una
stessa amministrazione, basato sul protocollo IP; (ii) un livello di interoperabilità
evoluta e cooperazione applicativa tra le amministrazioni aderenti al SPC;
(iii) il livello dei servizi applicativi messi a disposizione attraverso il SPC. Sono
dettagliate anche le componenti logiche e infrastrutturali del sistema;

● danno le definizioni di tutte le fondamentali componenti architetturali del SPC;
definizioni che saranno più volte assunte come punto di riferimento nel corso di
questo capitolo;

● dispongono le caratteristiche di sicurezza e i servizi infrastrutturali (SICA) per
l'erogazione e la fruizione dei servizi applicativi;

● forniscono le specifiche per la realizzazione dei servizi SPC, tra cui: (i) i

10 [DL8205], articolo 71 comma 1-bis.

10


meccanismi per la connettività ed il trasporto sia tra diverse amministrazioni che
tra diverse sedi della stessa amministrazione; (ii) l'integrazione tra i processi di
soggetti amministrativi omologhi organizzati in domini applicativi; (iii)
l'adesione alle raccomandazioni del W3C per gli standard da impiegare nel
processo cooperativo; (iv) le finalità dei servizi infrastrutturali di cooperazione
applicativa (SICA), tra cui la gestione degli Accordi di Servizio, il supporto per
l'integrazione semantica dei servizi, la gestione dei certificati e delle identità
digitali e il testing di conformità delle Porte di Dominio;

● definiscono le modalità di certificazione e monitoraggio dei servizi e di
qualificazione delle componenti infrastrutturali del SPC.

Come illustrato in seguito dalle stesse Regole tecniche, SPC è strutturato su due
livelli infrastrutturali, che costituiscono la base su cui si poggia un terzo livello, quello
dei servizi applicativi resi disponibili dai soggetti amministrativi che vi aderiscono.
Questi due strati sono:

● un livello di interconnessione tra più amministrazioni e all'interno di una stessa
amministrazione, che è in sostanza un'implementazione dedicata dello stack
TCP/IP, dal livello fisico sino ai servizi di connettività over IP, che risponda a
determinate esigenze di affidabilità e sicurezza. Questo livello è comunemente
detto Sistema Pubblico di Connettività ed abbreviato esso stesso come SPC;
tuttavia, per disambiguare questa definizione da quella dell'infrastruttura nel suo
complesso, vi si farà riferimento nel seguito con la sigla SPConn;

● un livello di interoperabilità e cooperazione, che espone a sua volta servizi a
livello applicativo specializzati, i quali coordinano la circolazione di dati e la
fornitura dei servizi delle singole PPAA. Questo livello costituisce il Sistema
Pubblico di Cooperazione (SPCoop) e l'informazione veicolata in esso si poggia
sui servizi di trasporto di SPConn.

11


Figura 1: Pila architetturale del Sistema Pubblico di Connettività (fonte: [CNIPA])
Dal punto di vista della sicurezza, infine, si precisa che non sono definite due
distinte componenti, una per ciascun livello del SPC: la componente di sicurezza del
sistema è unica e trasversale ad entrambi i livelli e fa sì che SPC venga visto come un
dominio trusted, cioè affidabile, a sua volta costituito da una federazione di domini
trusted fondata su relazioni di tipo fiduciario tra più amministrazioni. Alcune misure
organizzative per la garanzia della sicurezza, in termini di protezione dei dati, di
veridicità e di non ripudio, sono: la gestione federata delle identità digitali e la
qualificazione delle Porte di Dominio. La Porta di Dominio è una delle componenti
architetturali di SPCoop e sarà meglio definita nel seguito.

1.2.1. Il livello di connettività

Al fine di soddisfare i requisiti di affidabilità e sicurezza del SPC, tutto e solo il
traffico generato dalle amministrazioni che vi aderiscono è convogliato in una rete
dedicata, i cui carrier sono fornitori di connettività a livello nazionale e regionale che
hanno ottenuto l'iscrizione agli elenchi qualificati del SPC sulla base di adeguati
requisiti tecnici e commerciali. Il primo bando di gara per la fornitura di tali servizi,
conclusosi nel 2006, ha visto al primo posto il Raggruppamento Fastweb-EDS, seguito

12


in ordine da BT-Albacom, Wind e Telecom Italia. Questi quattro operatori hanno
costituito la QNX-SCPA11, una Società Consortile per Azioni finalizzata alla
realizzazione, gestione ed evoluzione della Qualified eXchange Network (QXN)
[Ros03]. Quest'ultima è la rete dedicata che, per mezzo di un'opportuna topologia
distribuita, interconnette le reti dei diversi operatori con tutte le PPAA italiane. Scopo
della costituzione di tale società è garantire alle amministrazioni aderenti condizioni sia
di compatibilità ed interoperabilità che di uniformità delle condizioni economiche.

La QXN è una rete interamente basata su protocollo IP che deve supportare una
pluralità di tipologie di traffico tra le PPAA italiane (ad esempio VoIP [Jac06] e SOAP
over HTTP/HTTPS [BEKL+00]). È geograficamente distribuita su nodi dislocati presso
i principali NAP (Neutral Access Point) italiani, fra loro interconnessi con circuiti ad
alta affidabilità che scalano tra 100Mb/s e 1Gb/s. I livelli di servizio garantiti
prevedono: (i) disponibilità = 99,99%; (ii) tempo di attraversamento della rete (One-
Way Delay) ≤ 20 ms; (iii) percentuale di perdita di pacchetti (Packet Loss) ≤ 0,05%.

Figura 2: Esempio di collegamenti in una QXN (fonte: [CNIPA04], p. 23)
Si è previsto, a discrezione delle singole amministrazioni e solamente in casi di
necessità, che sia consentito lo scambio di informazioni, sia tra più amministrazioni che
all'interno di una stessa, per mezzo di reti private virtuali (VPN) [GLHA+00] supportate

11 http://www.qxn-scpa.it

13


da opportuni sistemi crittografici.

1.2.2. Il livello di interoperabilità e cooperazione

Assodata a questo punto la disponibilità di un'infrastruttura di connettività
affidabile, sicura ed efficiente, quale è la QXN, si ha la necessità di configurare due
ambiti applicativi omogenei:

1. un ambito di cooperazione ad uso delle amministrazioni che partecipano ad
SPCoop, interagendo per mezzo di servizi applicativi che seguono determinate
modalità standard. Tali soggetti amministrativi dovranno, per l'erogazione e la
fruizione di detti servizi, concordarne i termini concettuali, logici ed
implementativi per mezzo di una convenzione anch'essa standardizzata.

2. un ambito che comprende servizi generali di infrastruttura per la cooperazione
applicativa, non afferenti ad un particolare soggetto amministrativo che
partecipa al sistema. Il fine di questi servizi è di supportare e coordinare
l’interazione fra i servizi applicativi definiti dalle Amministrazioni.

Figura 3: Schema di integrazione in SPCoop dei servizi applicativi (SA)
attraverso le Porte di Dominio (PD) (fonte: [CNIPA])

14


Nel Sistema Pubblico di Connettività e Cooperazione, la messa a disposizione di
questi ambiti applicativi è garantita dalla cosiddetta extranet applicativa che costituisce
il suo secondo sottosistema di massima, SPCoop, il quale rappresenta l'ambito del
presente lavoro. L'architettura flessibile di SPCoop si configura essenzialmente come
una SOA (Service-Oriented Architecture), ossia come un metodo di integrazione fra
sistemi le cui funzionalità sono raggruppate in unità distinte dette servizi interoperabili,
secondo i principi dei processi aziendali [NewLom05]. Di seguito sono elencati i
principi-guida che accomunano SPCoop e le SOA, principi dei quali troveremo poi
ampio riscontro in sede di analisi delle componenti standard definite in ambito SPC:

● accoppiamento debole tra le funzionalità esposte e le tecnologie con cui sono
realizzate (che possono comprendere, tra le altre, sistemi operativi, linguaggi di
programmazione e sistemi software per il dispiegamento delle funzionalità);

● riuso, mediante l'isolamento delle componenti logiche fondamentali da quelle
implementative, al fine di reimpiegarle successivamente sia per versioni
successive di uno stesso servizio, sia per specializzarle a fronte di una pluralità
di soggetti candidati ad erogare o fruire di quel servizio;

● contrattazione, nel senso che i servizi in questa architettura aderiscono ad un
accordo di comunicazione (che comprende, ma non coincide con il protocollo
applicativo di rete utilizzato) definito collettivamente da uno o più documenti
che descrivono il servizio;

● composizionalità, in forza della quale è possibile coordinare ed assemblare
collezioni di servizi allo scopo di formare servizi composti;

● incapsulamento: discende dal principio dell'accoppiamento debole e si riferisce
al consolidamento di applicazioni e funzionalità, spesso non ideate
originariamente per funzionare in una SOA, affinché si integrino in servizi;

● individuabilità, vale a dire la facoltà di reperire servizi in base ad una corretta

15


interpretazione delle loro utilità e del significato dell'informazione veicolata da
essi. I servizi devono essere integrati con delle forme di metadati tramite le quali
possono essere efficacemente interpretati e reperiti [RobPis05]. Nel contesto dei
Web Service, il protocollo utilizzato per la discovery dei servizi si fonda su
registri basati su XML, detti Universal Description, Discovery and Integration
(UDDI) [CHRR04] anche se, come vedremo, questo standard non è che la base
di partenza per la gestione dei servizi in SPCoop.

Il Sistema Pubblico di Cooperazione introduce una serie di tecnologie e standard,
in parte appositamente definiti dal CNIPA, per garantire la realizzazione di questi
principi funzionali.

Fra le possibili tecnologie per l'implementazione di una SOA, lo standard di
riferimento per SPCoop è quello dei già citati Web Service. Nel Web Service Glossary
[HaaBro04], il World Wide Web Consortium (W3C)12 ne dà la seguente definizione:

“Un Web Service è un sistema software progettato per supportare
l'interazione tra più macchine all'interno di una rete. Esso ha un'interfaccia
descritta in un formato interpretabile automaticamente (nello specifico
WSDL). Gli altri sistemi interagiscono con il Web Service nelle modalità
indicate dalla sua descrizione utilizzando messaggi SOAP, i quali
tipicamente viaggiano su HTTP sotto forma di XML unito ad altri standard
relativi ai Web Service”.

Questa definizione mette in scena un attore molto importante ai fini di questa tesi,
vale a dire il linguaggio WSDL (Web Service Definition Language)13. Si tratta di un
dialetto di XML usato per esporre un servizio applicativo specificando la
denominazione delle operazioni che lo compongono e dei messaggi che esse scambiano,
oltre agli standard adottati per l’implementazione del servizio. Mentre l'analisi di questo
standard, d'obbligo nel corso del presente studio, verrà affrontata in una sede più
12 http://www.w3.org
13 Si veda il Web Services Description Working Group, http://www.w3.org/2002/ws/desc

16


opportuna, si anticipa che esso è stato impiegato in maniera estesa nel definire più di un
aspetto dei servizi applicativi in SPCoop.

Lo scambio di messaggi, nel rispetto dei canoni dei Web Service e delle
convenzioni stabilite in linguaggio WSDL [CCMW01], che avviene tra due sistemi
coinvolti nell'esecuzione di un servizio, detti rispettivamente erogatore e fruitore,
costituisce di fatto l'unica forma ammissibile del flusso informativo di un servizio
SPCoop. È bene, a questo punto, definire una tassonomia sia dei servizi dal punto di
vista dell'ordine dei messaggi che scambiano, sia delle modalità di scambio dei
messaggi stessi dal punto di vista della loro natura transazionale.

I tipi di scambio elementare di messaggi, definiti nella documentazione di
riferimento di SPCoop [BFMT05a] sono tre:

• messaggio senza replica: un sistema mittente invia un messaggio a un sistema
destinatario. Come si vedrà, ciascun sistema può indifferentemente, a seconda
dei casi, coincidere con l'erogatore o il fruitore del servizio;

• messaggio/replica sincroni: un sistema detto richiedente trasmette un messaggio
sincrono a un sistema detto rispondente e si mette in attesa (non necessariamente
bloccante) della replica sincrona. Successivamente il rispondente trasmette una
replica sincrona al richiedente correlata logicamente con il messaggio;

• messaggio/replica asincroni: un sistema detto richiedente trasmette un
messaggio asincrono (cioè senza attesa di risposta) a un sistema detto
rispondente. Il rispondente trasmette in seguito una replica asincrona al
richiedente correlata logicamente con il messaggio ricevuto. La correlazione a
livello logico tra messaggio e replica asincroni è rappresentata esplicitamente
dall’inserzione nella replica di un identificatore di correlazione.

Questi tipi elementari di scambio di messaggi, ed essi soltanto, identificano le possibili
modalità di utilizzazione del servizio, ovvero gli scenari di coordinamento delle

17


prestazioni di servizio. La tipologia di coordinamento seguita da ciascun servizio sarà
indicata, mediante un'opportuna nomenclatura, nei documenti in linguaggio WSDL che
descrivono il servizio stesso. Sono previsti in tutto quattro tipi di scenari elementari di
coordinamento:

• Richiesta senza risposta: il fruitore trasmette all’erogatore un
messaggio contenente una richiesta di prestazione e continua il
trattamento. Tale scenario può essere implementato utilizzando
come tipo di interazione il messaggio senza replica.

• Richiesta/risposta: il fruitore trasmette all’erogatore un messaggio
contenente una richiesta di prestazione di servizio. L’erogatore
esegue il trattamento di erogazione della prestazione e trasmette un
messaggio di risposta contenente il resoconto di erogazione e
eventualmente i dati la cui fornitura è parte della prestazione. Le
modalità dell’interazione (dal punto di vista del fruitore) che
implementano lo scenario di richiesta/risposta possono essere sia
sincrone che asincrone:

o Richiesta/risposta sincrone: il sistema fruitore prepara e
emette il messaggio di richiesta della prestazione e blocca la
sua linea di esecuzione in attesa della risposta. Alla
ricezione della risposta, la linea di esecuzione del fruitore
riprende. Lo scenario richiesta/risposta sincrone può essere
implementato direttamente utilizzando uno scambio
elementare di tipo messaggio/replica sincroni.

o Richiesta/risposta asincrone: il fruitore del servizio prepara
la richiesta di prestazione, la trasmette all’erogatore e
continua l’esecuzione. La richiesta viene trasmessa al
sistema erogatore che esegue i trattamenti, prepara e emette

18


la risposta. La ricezione della risposta ha come effetto
presso il fruitore l’avvio di una linea di esecuzione
indipendente che esegue i trattamenti conseguenti alla
ricezione della risposta. Può essere implementato utilizzando
lo scambio elementare di tipo messaggio/replica asincroni.
L’identificatore di correlazione messaggio/replica può essere
utilizzato come identificatore di correlazione
richiesta/risposta.

• Notifica senza risposta: l’erogatore del servizio trasmette di sua
iniziativa un messaggio di notificazione al fruitore (che può
contenente il resoconto di un trattamento effettuato o la notifica di
un evento). Tale scenario può essere implementato usando uno
scambio elementare di tipo messaggio senza replica.

• Notifica/risposta: l’erogatore trasmette un messaggio di
notificazione e successivamente il fruitore trasmette un messaggio di
risposta. Può essere implementata con modalità sincrona o
asincrona e quindi essere implementato rispettivamente dallo
scambio elementare messaggio/replica sincrono o asincrono.14

Prima di inquadrare le categorie fondamentali degli elementi architetturali di
SPCoop e di entrare nel dettaglio di ciascuno di essi, è utile fornire alcune indicazioni
intuitive sulla loro funzione nel ciclo operativo del sistema. Innanzitutto, un esempio di
comunicazione fra un sistema erogatore e uno fruitore di un determinato servizio è
esplicitato in figura 4.

14 [BFMT05a] sezione “Concetti di Base”, pp. 9-10

19


Figura 4: Esempio di Servizio di tipo Richiesta/Risposta (fonte: [ABFM+05])

La lettura dello scenario illustrato da questo esempio è la seguente: un sistema
fruitore, appartenente ad un certo dominio applicativo15, deve utilizzare un servizio
applicativo di tipo richiesta/risposta (si tralasciano al momento i dettagli sulla sincronia)
esposto da un altro dominio applicativo, quello del sistema erogatore. La natura della
conversazione, i nomi dei messaggi scambiati e altre informazioni sono contenute in un
oggetto chiamato Accordo di Servizio, definito apposta per questa coppia <erogatore,
fruitore>. Questi messaggi, veicolati attraverso l'infrastruttura di connettività di SPC,
sono serializzati secondo un protocollo detto Busta eGov e scambiati fra gli endpoint dei
due domini amministrativi, detti Porte di Dominio.

Con questo schema è stata introdotta una prima terminologia che mette in
evidenza gli elementi fondamentali del Sistema Pubblico di Cooperazione: il Dominio
di servizi applicativi, (o Dominio Applicativo) la Busta eGov, la Porta di Dominio e
l'Accordo di Servizio per quanto riguarda l'ambito di cooperazione descritto nel cappello
di questa sezione. Nell'ambito dei servizi infrastrutturali sarà introdotto ora un ulteriore
termine: i Servizi di Interoperabilità, Cooperazione ed Accesso (SICA). Tutti questi
elementi saranno ora dettagliati uno per uno, sia sul piano tecnico che su quello
normativo/istituzionale, con particolare riferimento alle Regole Tecniche per il Sistema
Pubblico di Connettività16.

15 [DPCM08], articolo 1, comma 1, lettera k.
16 v. definizioni in [DPCM08], articolo 1.

20


Dominio Applicativo

Per dominio applicativo si intende “l'insieme delle risorse (infrastrutture,
hardware, software, procedure, dati, servizi) e delle politiche che ricadono sotto la
responsabilità di una specifica organizzazione”17. La definizione di un dominio per
ciascuna amministrazione garantisce il principio dell'autonomia dei soggetti
amministrativi nelle fasi di progettazione, realizzazione e gestione dei servizi
applicativi. Il fatto che questi domini siano definiti in corrispondenza di ciascuna
amministrazione che aderisce ad SPC non deve indurre a credere che l'unica possibile
tipologia di servizi sia quella le cui parti siano esattamente due distinti soggetti
amministrativi. Al contrario, molti procedimenti e compiti istituzionali sovente
prevedono il concorso dell’azione di più soggetti. Scenari di questo genere, che in
un'ottica di decentramento amministrativo verso le Regioni e gli Enti locali si fanno nel
tempo più frequenti, sono stati classificati in due principali tipologie:

• procedimenti inter-amministrativi, nei quali più amministrazioni
concorrono, con compiti diversi, al conseguimento di un risultato
complessivo, riconducibile ad uno o più servizi integrati erogati sia
a fruitori esterni alla PA (ad es. Sportello unico alle imprese,
Sportello unico per l’immigrazione, ecc.) che a fruitori interni alla
PA. Questo tipo di procedimenti è incentrato sulla amministrazione
che eroga il servizio integrato finale;

• procedimenti di razionalizzazione, coordinamento e controllo, in cui
è individuato normativamente un soggetto vigilante e/o di
regolazione, a livello centrale o territoriale (ad es. Regioni,
Province, ecc.), mentre le funzioni amministrative sono attribuite a
soggetti periferici, tipicamente enti locali (ad es. Anagrafi, Catasto,
Demanio…) che erogano sul territorio una stessa gamma di
servizi.18
17 [DPCM08], articolo 1, comma 1, lettera k.
18 [BFMT05a], sezione “Dominio di Cooperazione, Accordo di Cooperazione e relazioni con l’Accordo
di Servizio ”, p. 54

21


I soggetti amministrativi che rientrano in quest'ottica hanno la possibilità di
costituire un ulteriore soggetto organizzativo di SPCoop, detto dominio di cooperazione
[BFMT05a]. In un siffatto dominio, i servizi erogati nascono da un procedimento di
integrazione e composizione dei servizi offerti dai singoli domini applicativi (in
applicazione del principio di composizionalità delle SOA). Tale procedimento è regolato
in maniera invisibile al di fuori del dominio di cooperazione, e si basa su accordi
specifici tra le parti in causa. Questa trasparenza è anche garantita dal fatto che, al
momento del dispiegamento di un servizio composto, l'amministrazione responsabile
della pubblicazione dello stesso sulla sua Porta di Dominio è sempre e comunque una
sola. Tale PA, detta soggetto coordinatore responsabile, ha l'obiettivo di coordinare i
compiti di ciascun partecipante ed assicurare l'efficacia tecnico-organizzativa del
procedimento cooperativo. Il soggetto coordinatore responsabile è solitamente
individuato da una norma di legge che specifica i ruoli dei soggetti coinvolti e indica
quello con responsabilità di coordinamento o di vigilanza. Altrimenti, le parti in causa
devono concordare una delega ad un soggetto coordinatore appositamente eletto, per
mezzo di un'opportuna procedura tra soggetti paritetici che può anche essere mutuata
dalla teoria degli algoritmi di consenso distribuito. Anche se sarà questo soggetto ad
esporre il servizio sulla sua Porta di Dominio, vige comunque il principio di
responsabilità dell'azione amministrativa del singolo procedimento; pertanto, ciascuna
sua parte è associata al soggetto pubblico che istituzionalmente ne ha la responsabilità.

1.2.2.1 Busta eGov

Definita dalle Regole Tecniche come il “protocollo di comunicazione tra
servizi applicativi basato sullo standard SOAP”19, la Busta eGov [GMRF+05b] è di
fatto un'estensione della versione 1.1 di questo protocollo [BEKL+00]. Nato nel 1998,
SOAP è diventato de facto il successore dello standard XML-RPC20 per lo scambio di
messaggi basati su XML, poggiandosi solitamente su HTTP o HTTPS, ed è la base della
pila protocollare dei Web Service, su cui possono essere costruiti arbitrari strati di

19 [DPCM08], articolo 1, comma 1, lettera gg.
20 http://www.xmlrpc.org

22


astrazione. Fino alla versione 1.1, SOAP era acronimo di Simple Object Access
Protocol, ma questa lettura della sigla è stata abbandonata con l'avvento della versione
1.2 [GHMM+07], in quanto ritenuta fuorviante per via di accostamenti spesso erronei
alle SOA, con le quali non è concettualmente legato. Con questa base di partenza, e
nonostante il peso delle ridondanze nella sintassi XML, SOAP presenta innegabili
vantaggi di semplicità, di indipendenza dalle piattaforme e dai linguaggi di
programmazione, di versatilità (si può ad esempio convogliare il traffico SOAP su
SMTP anziché HTTP) e di facile utilizzo in presenza di proxy o di firewall, anche se
questo significa dover ricorrere a costosi processi di stateful packet inspection nei casi
in cui si voglia bloccare questo tipo di traffico.

La necessità di estendere le caratteristiche dello standard internazionale della
SOAP envelope discende dai particolari obiettivi del piano d'azione di eGovernment in
Italia, il quale prevede che le informazioni necessarie alla gestione del servizio siano
uniformate per rispondere ai requisiti di SPCoop in materia di sicurezza ed affidabilità,
preservando nel contempo l'autonomia di ciascuna amministrazione nella definizione
del proprio contenuto applicativo [DL8205]. Ne discende che gli emendamenti proposti
per la Busta eGov intervengono esclusivamente sull'elemento soap11env:Header
(laddove il prefisso soap11env è da considerarsi legato al namespace
“http://schemas.xmlsoap.org/soap/envelope/”) che fornisce l'intestazione di un
messaggio SOAP, conservando invece la struttura del payload applicativo di un
messaggio, il soap11env:Body. I particolari requisiti che lo header, ossia l'intestazione21
della Busta eGov, deve soddisfare sono quelli del livello di messaging delle Porte di
Dominio:

• la gestione degli scambi di informazioni in maniera indipendente dalla logica
applicativa che la implementa;

• la garanzia che le Amministrazioni, sia fra di loro che, eventualmente, con entità
21 Benché il termine header possa agevolmente tradursi in “intestazione”, al fine di evitare confusione
con un suo sottoelemento definito per la Busta eGov e denominato Intestazione, si continuerà a
fare riferimento all'elemento soap11env:Header con il termine anglosassone.

23


esterne, interagiscano con un'interfaccia uniforme;

• il raggiungimento di predeterminati livelli di servizio in termini, ad esempio, di
affidabilità e sicurezza.

La struttura dello header di una busta eGov che soddisfi i predetti requisiti, tenendo
conto della presenza o meno di allegati, è schematizzata in figura 5.

Figura 5: Busta eGov senza allegati (a) e con allegati (b) (fonte: [GMRF+05b])

I due elementi fondamentali dello header della Busta eGov sono i seguenti:

● l’elemento Intestazione che contiene “le informazioni relative al trattamento

24


del messaggio da parte delle Porte di Dominio in termini di affidabilità,
tracciamento, indirizzamento, ecc.”22 Tutti gli elementi non-standard definiti
appositamente per la Busta eGov sono qui contenuti e di seguito brevemente
elencati:

○ 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.23

● l’elemento Wsse:Security, contenente un blocco conforme alle specifiche del
protocollo di comunicazione WS-Security [NKMH06], rilasciato come OASIS
open standard24. Questo elemento può comparire in una Busta zero o più volte e
può contenere più blocchi di firma digitale secondo le specifiche XML-Signature
[ERSH+08]. Può essere usato per garantire la provenienza del messaggio.

È fatto obbligo, in presenza di contenuto applicativo allegato al messaggio SOAP
(vale a dire quando tale contenuto non è formalizzato in XML nel SOAP body), che esso
sia codificato nel rispetto degli standard MIME [Gra93]. In questo caso l’elemento
Descrizione conterrà il manifesto dei riferimenti agli allegati, nel rispetto delle
specifiche SOAP 1.1. with Attachments [BTN00].

22 [GMRF+05b], p. 17
23 [GMRF+05b], p. 18-19
24 http://www.oasis-open.org

25


1.2.2.2 Porta di Dominio

L'unico metodo previsto perché un dominio applicativo possa integrarsi in
SPCoop è che esso esponga una particolare interfaccia applicativa detta Porta di
Dominio (brevemente PdD) [GMRF+05a]. Le Regole Tecniche la definiscono infatti
come “unico componente architetturale del SPC attraverso il quale si accede al
dominio applicativo dell'Amministrazione per l'utilizzo dei servizi applicativi”25. La
PdD è essenzialmente un proxy che si fa carico di tutto il traffico su Busta eGov
riguardante il dominio che la espone, e di fatto costituisce l'unica possibile tipologia
logica degli estremi di uno scambio di informazioni per mezzo di servizi SPCoop. Di
fatto, tutti i servizi erogati da un determinato dominio applicativo vengono esposti e
pubblicati sulla sua PdD, affinché essa possa fungere da nodo di scambio di messaggi
applicativi per ciascun servizio che tale dominio eroga o del quale deve fruire. Questo
non significa che l'implementazione dei servizi erogati sia effettivamente disponibile
sulla PdD stessa; al contrario, sarà frequente uno scenario in cui ad essa sia delegato il
solo compito di instradare (dispatch) messaggi applicativi e, in alcuni casi, di effettuare
la serializzazione (marshalling) e la deserializzazione (unmarshalling) di messaggi
codificati come Busta eGov, il cui contenuto applicativo viene in realtà gestito da
opportuni sistemi software che possono o meno risiedere sulla stessa piattaforma della
PdD.

Queste le funzionalità infrastrutturali che possono (e in alcuni casi devono) essere
implementate da una Porta di Dominio:

1. Funzionalità di base

• Gestione Busta eGov. Comprende tutte le attività (conversione di formato,
implementazione degli algoritmi per gestire il protocollo) relative alla
gestione della componente Intestazione dello header di una Busta eGov.

• Gestione Tracciatura. Si tratta della funzionalità di logging della PdD, che è

25 [DPCM08], articolo 1, comma 1, lettera z.

26


tenuta a tracciare permanentemente tutte le sue attività.

• Gestione Diagnostici. La PdD deve poter inviare e gestire i messaggi di
diagnostica che riportano tutte le anomalie riscontrate nella gestione del
flusso informativo.

• Gestione SOAP with Attachments. Conformità alle specifiche SOAP 1.1–
Attachment.

• Gestione modalità consegna affidabile. Implementazione del meccanismo di
consegna affidabile mediante la gestione, utilizzando un algoritmo a finestra
di trasmissione, di un elemento opzionale della Busta chiamato Profilo
Trasmissione.

2. Gestione della Sicurezza

• Tutti i meccanismi di gestione della sicurezza devono essere implementati in
accordo alle raccomandazioni WS-I Basic Security Profile versione 1.0
[MGMB07]:

• Sicurezza di base SSL. Gestione della modalità di comunicazione a mezzo
HTTP con canale sicuro (HTTPS). Consente la garanzia e la confidenzialità
dello scambio tra gli endpoint di un servizio.

• Sicurezza avanzata Wsse: Security. Gestione della firma dei dati, di tipo
XML Signature, che garantisce la fonte di provenienza del messaggio,
mantenendone il valore anche in scenari di multicasting o di attraversamento
di nodi intermedi.

3. Consolle di Monitoraggio

• Consolle base. Terminale per la configurazione della porta e la gestione del
tracciamento e della diagnostica. Deve consentire come minimo la gestione

27


in modalità testo mediante messaggi di comando.

• Consolle evoluta. Consolle in modalità grafica interattiva (GUI) con
funzionalità evoluta di navigazione dei log e della diagnostica.

Le Porte di Dominio sono state classificate in due tipologie, a seconda di quali
delle funzionalità sopraelencate siano effettivamente implementate. Tale classificazione
è riportata nella tabella che segue:

Funzionalità Porta Applicativa Porta Applicativa
Light Advanced
Gestione Busta eGov sì sì
Gestione Tracciatura sì sì
Gestione Diagnostici sì sì
Gestione SOAP with Attachments sì sì
Gestione modalità consegna affidabile sì sì
Sicurezza di Base SSL sì sì
Sicurezza avanzata Wsse: Security no sì
Consolle base sì non richiesta
Consolle evoluta no sì
Tabella 1: Funzionalità previste per ciascuna tipologia di Porta di Dominio

La facoltà di una PdD di firmare la Busta eGov relativa ai servizi che espone è
sottesa al conferimento di opportuna certificazione digitale. Il processo che porta a tale
certificazione è la qualificazione della Pubblica Amministrazione presso SPCoop, che
prevede uno step in cui la Porta di Dominio viene accreditata presso il sistema, previa
richiesta da parte di un soggetto con ruolo di Amministratore della Porta di Dominio.
Per essere accreditata, una PdD deve sostenere un test di qualificazione nei confronti di
un'altra PdD di riferimento esposta dal CNIPA. Tale test prevede l'esecuzione di un
servizio infrastrutturale composto di una serie di operazioni che verificano che lo
header della busta eGov sia correttamente gestito dalla PdD in esame, ovviamente a
seconda della tipologia della Porta stessa con riferimento a caratteristiche di sicurezza. I

28


test riguardano sia il ruolo di erogatore che quello di fruitore di una PdD. La
qualificazione è un processo obbligatorio perché la PdD sia abilitata ad operare in
SPCoop, poiché comporta il rilascio del certificato digitale necessario alla mutua
identificazione dei soggetti nel sistema.

1.2.2.3 Accordo di Servizio e Accordo di Cooperazione

Le Regole Tecniche definiscono l’Accordo di Servizio (brevemente AdS)
[BFMT05a] come "la convenzione tra erogatore e fruitore del servizio applicativo,
redatta in formato XML e resa pubblica attraverso le infrastrutture condivise del SPC,
che descrive l’oggetto del servizio e le relative modalità di erogazione e fruizione"26.
Questa definizione normativa, ancorché imprecisa dal punto di vista delle specifiche
formali e tecnologiche (come vedremo, sono alcune parti dell'AdS ad essere rese in
XML, e non l'AdS stesso), illustra in maniera esauriente il ruolo e le finalità di queste
componenti di SPCoop.

Si può dire che l'AdS è la componente infrastrutturale di SPCoop che fa sì che
venga soddisfatto il principio di contrattazione delle SOA in forza del quale, lo
ricordiamo, erogatore e fruitore comunicano aderendo ad una predeterminata
convenzione, che può essere redatta dal soggetto erogatore ovvero da terze parti. L'AdS,
che implementa tale convenzione nel framework in esame, consiste di fatto in un
fascicolo, opportunamente archiviato, contenente una serie di documenti redatti in
specifiche formali per il loro trattamento automatico, opzionalmente corredati di
documenti non formalizzati, per esempio a supporto dell'interpretazione del servizio da
parte di un agente umano. Si richiede, a livello sia tecnico che normativo, che un AdS
contenga, in opportune codifiche XML, le seguenti informazioni relative al servizio cui
fa riferimento: (i) l'insieme di operazioni supportate dal servizio, compreso l'ordine, le
tipologie e i nomi dei messaggi scambiati da esse; (ii) le specifiche dei livelli di
sicurezza e di qualità del servizio; (iii) i riferimenti a modelli concettuali che descrivono
il significato delle informazioni trattate; (iv) vincoli tecnologici relativi

26 [DPCM08], articolo 1, comma 1, lettera x.

29


all'implementazione del servizio vero e proprio, inclusa la sua ubicazione. Essendo
l'Accordo di Servizio un elemento fondamentale per il presente studio, tutti questi
aspetti verranno elaborati in dettaglio nel prossimo capitolo.

L'Accordo di Servizio è il prodotto finale del processo organizzativo che definisce
l'erogazione di un servizio in funzione dei suoi attori e del servizio stesso: si può
rappresentare questo processo con una funzione:

servdef: S × PA × PA → ADS

dove S è l'insieme dei servizi disponibili, PA quello dei sistemi partecipanti ad SPCoop
(alias Pubbliche Amministrazioni) e ADS quello degli Accordi di Servizio.

Un Accordo di Servizio completo in tutte le sue parti si forma di due componenti,
dette rispettivamente parte comune e parte specifica. Questa divisione è stata effettuata
con la prospettiva, da un lato, di favorire il riuso di quelle componenti che possono
concorrere alla definizione di più servizi; dall’altro, di minimizzare gli elementi
ridondanti nel caso di servizi definiti fra più di due soggetti. Negli scenari pratici, è
spesso possibile definire elementi comuni fra più accordi di servizio, specialmente dal
punto di vista concettuale e logico, pertanto lo scopo di una parte comune è di fornire
una base per gli accordi che definiscono servizi simili tra loro. La parte specifica di un
AdS può allora essere vista come una specializzazione della parte comune, nel senso
che aggrega tutte quelle caratteristiche strettamente dipendenti dalla coppia <erogatore,
fruitore>, con particolare riferimento alle specifiche dell’implementazione del servizio.

Per meglio comprendere questa distinzione, i servizi sono stati classificati, con
riferimento alla portata della loro erogazione/fruizione, in quattro tipologie. È
importante precisare che, in ciascuna di esse, la parte comune di un AdS è unica, e che
gli ambiti di responsabilità inquadrati sono indipendenti dalle modalità del processo, sia
esso unilaterale o concordato, di definizione del servizio che ha portato alla creazione
dell'Accordo27:
27 Per i dettagli si rimanda a [BFMT05a], pp. 12-15

30


1. Servizi mono-erogatore/mono-fruitore, in cui ciascuno dei sistemi erogatore e
fruitore è unico, indipendente e responsabile per il rispetto dei termini dell'AdS
dalla propria parte. In questo caso si ha un'unica parte specifica.

2. Servizi mono-erogatore/multi-fruitore, destinati alla fruizione di una classe di m
sistemi fruitori indipendenti, per ciascuno dei quali è definita una parte specifica.

3. Servizi multi-erogatore/mono-fruitore, erogati da n sistemi indipendenti (per
ciascuno dei quali è definita una parte specifica) ma destinati alla fruizione da
parte di un solo sistema. La gestione del ciclo di vita dell’Accordo, tuttavia, è
affidata sempre ad un unico soggetto, eventualmente terzo rispetto agli erogatori
ed al fruitore, a cui viene delegato il compito.

4. Servizi multi-erogatore/multi-fruitore, in cui i sistemi erogatori e fruitori possono
essere organizzati in una matrice n × m, portando a n · m parti specifiche. La
gestione del ciclo di vita segue gli stessi criteri dei servizi multi-erogatore/mono-
fruitore.

La divisione in parte comune e parte specifica è perfettamente compatibile con il
caso di definizione unilaterale di un Accordo di Servizio da parte di un singolo
erogatore: in questo scenario (applicabile sia quando il fruitore è unico che quando ve
ne sono due o più), il soggetto erogatore definisce la parte comune e una sorta di
template della parte specifica, ovvero una parte specifica non concordata e definita
dall'erogatore, completa in tutte le sue parti, ma priva di esplicita indicazione del
fruitore; sulla base di questa verrà istanziata la parte specifica vera e propria, nel
momento in cui il fruitore (dopo un'eventuale fase di negoziazione delle caratteristiche
col soggetto erogatore) decida di farla propria per poter utilizzare il servizio.

Benché un Accordo di Servizio descriva astrattamente una collaborazione fra due
soggetti, l'erogatore e il fruitore, ciascuno responsabile per i servizi offerti dal proprio
Dominio, in realtà molti procedimenti amministrativi sono il frutto del concorso
all'azione amministrativa di più soggetti. Come già anticipato, in simili scenari le PPAA

31


formalizzano la loro volontà (o l'obbligo per legge) di associarsi, costituendo un
Dominio di Cooperazione. Rimane a questo punto da definire come possa una
situazione di azione di governo collettiva conciliarsi con il paradigma uno-a-uno
formalizzato nell'Accordo di Servizio.

Come per i Domini di responsabilità delle singole amministrazioni, anche un
Dominio di Cooperazione è visto come un erogatore di servizi, con la differenza che tali
servizi esposti all'esterno sono il frutto di un procedimento coordinato di integrazione e
composizione dei servizi offerti dai singoli domini (servizi componenti) e sono perciò
detti servizi composti.

Un Accordo di Cooperazione (brevemente AdC) descrive l'insieme degli Accordi
di Servizio definiti per i servizi composti, detti pertanto Accordi di Servizio Composti. Si
tratta, in sintesi, della specifica dei servizi applicativi offerti da un Dominio di
Cooperazione. Gli elementi fondamentali che caratterizzano l’erogazione di servizi
applicativi da parte di un Dominio di Cooperazione sono, oltre ai servizi componenti e
composti, anche la specifica delle modalità secondo cui sono coordinati i servizi
componenti (che può essere definita in ottica di orchestrazione o di coreografia) per
formare ciascun servizio composto28.

Un Accordo di Cooperazione non è un insieme di Accordi di Servizio, né
tantomeno una sottospecie di tale Accordo. Si tratta di una componente basata su di una
specifica ben definita, che prevede l'inclusione dei seguenti elementi:

• un documento istitutivo, redatto in linguaggio naturale, che descrive le finalità e
la ragion d'essere di questo Dominio di Cooperazione, citandone eventuali
riferimenti in campo normativo o istituzionale;

• un insieme di liste di riferimenti ad Accordi di Servizio Composti, cioè gli AdS
dei servizi composti, che descrivono i servizi applicativi erogati dal Dominio di
Cooperazione:
28 Per approfondimenti, vedere [BFMT05a], pp. 55-57

32


Un Accordo di Servizio Composto è invece una specializzazione di AdS che
rappresenta un servizio derivante dalla composizione di un insieme di servizi
componenti. Queste le sue componenti:

• la parte comune dell’Accordo di Servizio Composto stesso, redatta come le parti
comuni di tutti gli AdS;

• la parte specifica, che in questo caso contiene i riferimenti ad uno o più Accordi
di Servizio che rappresentano i servizi componenti;

• il documento di coreografia degli AdS Componenti, redatto in WS-BPEL
[JEAA+07], un linguaggio basato su XML che si utilizza per descrivere
formalmente i processi aziendali, al fine di modularizzarli e suddividerne i
compiti fra attori diversi.

• altri documenti descrittivi non formali.

Si ricorda, infine, che l'Accordo di Cooperazione, così come tutto il procedimento
che porta alla sua costituzione, non ha visibilità al di fuori del Dominio di Cooperazione
cui fa riferimento. I servizi composti offerti dal Dominio sono esposti, attraverso la sua
Porta di Dominio, da quel soggetto amministrativo che funge da vigilante o
coordinatore del processo di composizione dei servizi. Tale esposizione avviene tramite
la pubblicazione di Accordi di Servizio del tutto analoghi a quelli definiti per due
soggetti amministrativi semplici. Un Accordo di Cooperazione sarà allora completo di
un insieme di riferimenti ordinati agli AdS che descrivono questi servizi composti.

1.2.2.4 Servizi Infrastrutturali di Interoperabilità, Cooperazione ed
Accesso

Si è detto, all'inizio di questa sezione, che per poter operare a livello di servizi
applicativi in SPCoop è necessario che si configuri un ambito applicativo nel quale
vengono forniti i servizi generali di infrastruttura necessari per il coordinamento del

33


flusso informativo e per massimizzare l'efficienza dello scambio di informazioni. I
Servizi di Interoperabilità, Cooperazione ed Accesso (brevemente SICA o “servizi
SICA”) sono stati concepiti in risposta a questa esigenza.

Le Regole Tecniche definiscono i SICA come “l'insieme delle regole, dei servizi e
delle infrastrutture condivise che abilitano l'interoperabilità e la cooperazione
applicativa fra le Amministrazioni e l'accesso ai servizi applicativi da queste
sviluppati e resi disponibili sul SPC”29. Dunque non si tratta di un insieme di soli servizi
applicativi in senso stretto, ma di un aggregato di differenti elementi, alcuni di carattere
documentale ed altri sotto forma di veri e propri componenti software. La
documentazione comprende, ad esempio, linee-guida per la redazione degli Accordi di
Servizio, la specifica delle naming conventions adottate e la specifica dei requisiti di
sicurezza. Quanto ai componenti software, essi sono raggruppati in una serie di servizi,
schematizzati in figura 6:

● I Servizi di Registro SICA [BFMT05b] offrono funzionalità per la registrazione,
l’accesso, l’aggiornamento, la cancellazione e la ricerca degli Accordi di
Servizio e di Cooperazione. Possono essere visti come la base di dati di tali
Accordi, si basano su di un'ampia estensione dello standard UDDI e sono
organizzati in modo distribuito attraverso un’architettura con replicazione
dell’informazione.

• Il Catalogo Schemi e Ontologie (brevemente “il Catalogo”) [BFMT05c], su cui
si tornerà nel prossimo capitolo per chiarirne il fondamentale ruolo nel contesto
applicativo d'interesse, è un servizio SICA che nasce dall'esigenza di sostenere il
principio di individuabilità delle SOA. Si tratta di un repository che raccoglie i
modelli concettuali con i quali è possibile descrivere i servizi applicativi e sui
quali è possibile “ragionare” con strumenti semiautomatici per l'individuazione
dei servizi stessi. Si può dire, pertanto, che esso sia la base di conoscenza
dell'intero Sistema Pubblico di Cooperazione.

29 [DPCM08], articolo 1, comma 1, lettera r.

34


• Il Servizio di Indice dei Soggetti offre un insieme di funzionalità necessarie a
gestire la rubrica degli operatori ed utenti della Pubblica Amministrazione.

• I Servizi di Sicurezza Interna SICA [BTBF+05], come si può intuire dal nome,
riguardano l'applicazione delle fondamentali politiche di sicurezza dei dati e
delle loro trasmissioni in di SPCoop, con riferimento tanto ai servizi applicativi
messi a disposizione dalle Amministrazioni partecipanti, quanto agli stessi
servizi infrastrutturali SICA.

• Il Servizio di Certificazione ed il Servizio di Gestione Federata delle Identità
Digitali, a supporto delle procedure di identity management ed access
management previste dal Sistema.

• I Servizi di Supporto alla qualificazione delle Porte di Dominio e del Registro
SICA Secondario sono finalizzati all'abilitazione dei soggetti amministrativi che
intendano operare in SPCoop. I Registri SICA Secondari sono replicazioni di un
sottoinsieme del Registro SICA Generale e possono essere acceduti, sia in
ricerca che in scrittura, in luogo di quest'ultimo. Pertanto è necessaria una
procedura di abilitazione anche dei soggetti che intendano fornire tale servizio.

• I Servizi di Supporto al Monitoraggio e Gestione consistono in un insieme di
sistemi software finalizzati al controllo e alla gestione di tutti i parametri relativi
agli aspetti applicativi del traffico in SPCoop.

35


Figura 6: Servizi Infrastrutturali di Interoperabilità, Cooperazione ed Accesso

Avendo definito lo scenario della cooperazione applicativa nella PA italiana e
delineato le sue principali componenti infrastrutturali, si può ora entrare nel merito degli
aspetti su cui ci si è concentrati nel corso dell'esperienza: l'analisi dell'Accordo di
Servizio dal punto di vista sia concettuale che strutturale e l'individuazione dei
meccanismi previsti per arricchirlo di valore semantico a supporto dell'individuabilità.

36

2.La semantica per l'interoperabilità dei servizi in SPCoop

2. La semantica per l'interoperabilità dei servizi in
SPCoop
Come per tutte le architetture orientate ai servizi, la possibilità di far operare tra
loro dei sistemi informativi potenzialmente eterogenei in un mondo di entità e processi
limitatamente aperto (nel senso i suoi abitanti non fanno parte di un insieme
predeterminato) è un elemento cruciale in SPCoop. In termini pratici, questa facoltà si
traduce nella necessità di assicurare che i dati veicolati dai messaggi siano interpretati
da erogatori e fruitori (o potenziali tali) in modo da denotare le stesse entità, proprietà e
relazioni del mondo della Pubblica Amministrazione italiana [CorRe08]. Si deve cioè
consentire ai soggetti del sistema di “ragionare” sul significato dei servizi resi
disponibili nella PA. Le regole e metodologie a supporto di questi processi di
ragionamento costituiscono il livello semantico di un'architettura orientata ai servizi.

Un prerequisito per la definizione del livello semantico di SPCoop può essere
quello di garantire la coerenza dei tipi di dati scambiati dai servizi: non sarebbe sensato
che ogni partecipante ridefinisse concetti di uso frequente nel contesto della PA (si pensi
ad esempio al concetto di “indirizzo”), quando sarebbe possibile definirli una tantum,
almeno sul piano strutturale, in uno schema concettuale condiviso. Questo
permetterebbe anche di ovviare al problema di rappresentazioni non omogenee di uno
stesso concetto. Nell'esempio dell'indirizzo, ogni soggetto amministrativo può creare un
oggetto di questo tipo concatenando in maniera diversa gli elementi che lo
compongono; per mezzo di uno schema concettuale comune, tutti i soggetti
conserverebbero la libertà di costruire un'istanza di “indirizzo” seguendo i propri criteri,
ma con la certezza di estrarne gli elementi costitutivi (nome o ragione sociale,
provincia, codice di avviamento postale, etc...) secondo un modello conosciuto da più
enti [PisTra08].

Pur avvalendosi di schemi concettuali condivisi, tuttavia, permane il problema di
contestualizzare i tipi di dato scambiati dai servizi rispetto al dominio che li mette a
disposizione. Uno schema concettuale non ci può dire, ad esempio, quali tipologie di

37


titolari di un indirizzo, fra le persone fisiche, le società e gli enti pubblici, hanno un
nome piuttosto che una ragione sociale, oppure che un contratto di lavoro non può
essere titolare di un indirizzo. Un metodo per superare questi ostacoli può essere di
descrivere una concettualizzazione dei domini applicativi tramite ontologie.

La disponibilità di schemi concettuali ed ontologie sottostanti i servizi apre le
porte ad una serie di potenziali vantaggi nel modello di cooperazione:

• reperimento di servizi che siano d'interesse per un determinato contesto, con
benefici sia nella qualità dei servizi che nell'immediatezza di reperimento degli
stessi;

• riuso di concetti o di interi modelli preesistenti, possibilmente anche ottenuti
attraverso un processo concordato tra differenti organizzazioni che hanno
standardizzato i concetti in essi descritti. Questo favorirebbe una riduzione del
costo d'ingresso nel modello di cooperazione per le piccole organizzazioni;

• favorire e promuovere un processo di standardizzazione graduale dei servizi
stessi. [Akk07]

Nel corso di questo capitolo saranno delineati i tratti di come questo livello
semantico sia reso nel Sistema Pubblico di Cooperazione. Da principio viene effettuata
una descrizione sintetica di cosa si intende per “ontologia” in scienza dell'informazione,
e di quali sono i metodi per formalizzarla che sono impiegati in SPCoop.
Successivamente viene effettuata un'analisi puntuale, dal punto di vista del ciclo di vita
e della struttura, di quell'elemento fondamentale di SPCoop che è l'Accordo di Servizio,
poiché esso è origine di tutti i collegamenti tra il livello semantico e quello dei servizi
applicativi. Si esamina poi in maggior dettaglio il ruolo del Catalogo Schemi ed
Ontologie, che è il servizio SICA delegato a mantenere l'intera base di conoscenza della
PA. Sono infine esposte le modalità previste in SPCoop per effettuare i collegamenti
semantici fra AdS e Catalogo, con riferimento anche a quei requisiti speciali per i quali

38


lo stato dell'arte non si è rivelato sufficiente e che hanno portato alla definizione della
soluzione proposta dal presente progetto.

2.1. Nozioni fondamentali e strumenti per la semantica

Il processo di definizione di un livello semantico, come è stato definito all'inizio
di questo capitolo, consiste essenzialmente nella formalizzazione di un modello nel
quale includere qualsiasi cosa che possa essere inserita in un vocabolario di dati allo
scopo di caratterizzare un determinato contesto (come in questo caso un servizio, o la
Pubblica Amministrazione). In altre parole, questo livello comprende oggetti, proprietà,
eventi, stati e qualsiasi altra cosa che sia concepibile, esprimibile e scambiabile
attraverso una rete di comunicazione [VetLen08]. Poiché tale modello è completo anche
delle relazioni, opportunamente formalizzate, che intercorrono fra questi elementi, si
può individuare un parallelismo fra il livello semantico così descritto e un classico
dizionario monolingue, nel quale il significato di un concetto indicato da un certo
termine viene espresso, seppur in linguaggio naturale, secondo le relazioni che esso ha
con altri concetti, inclusi elementi tipici dei Tesauri, quali sinonimi e antonimi.

2.1.1. Le ontologie computazionali

Alla base delle tecnologie semantiche, siano esse applicate all'intelligenza
artificiale, alla bioinformatica o al web, può sempre essere inquadrato il problema di
rappresentare la conoscenza del mondo a cui tali tecnologie si applicano, o di parte di
esso. Nel campo dell'ingegneria della conoscenza, una rappresentazione formale di
quanto esiste (nel senso che è il valore di una variabile vincolata) in un determinato
dominio e delle relazioni che intercorrono tra queste entità sono le ontologie
computazionali, comunemente dette ontologie. Il nome dato a queste famiglie di
rappresentazioni formali è solo parzialmente legato a quella branca fondamentale della
filosofia, l'ontologia per l'appunto, che studia le categorie dell'essere [Gan08]. Nel
seguito, salvo eccezioni opportunamente puntualizzate, il termine “ontologia” è da
intendersi, anche al singolare, come un riferimento al dominio delle ontologie

39


computazionali e non al campo di studio della filosofia.

In scienza dell'informazione, quando si parla di ontologie si fa riferimento ad una
collezione di “oggetti logico-formali” il cui fine ultimo è di identificare e descrivere,
nell'ambito di un sistema informativo, non tanto delle categorie concettuali, quanto
piuttosto gli oggetti che vi appartengono. Un'ontologia può essere un prodotto del
processo di progettazione e sviluppo di un sistema software, quindi un artefatto, come
lo sono ad esempio i casi d'uso, e come tale ha una struttura complessa, un ciclo di vita
delle buone pratiche e dei pattern di progettazione, come avviene nel campo
dell'ingegneria del software e dei processi aziendali [Gan08].

Queste collezioni di concetti e delle loro relazioni sono formalmente espresse
tramite una semantica formale, più comunemente quella delle teorie assiomatiche,
mediante le quali si fissa un insieme di proposizioni, gli assiomi per l'appunto,
che permettono di caratterizzare meglio l’interpretazione dei termini o predicati. I
linguaggi della logica utilizzati per la rappresentazione delle ontologie, più
frequentemente la logica del primo ordine e la logica descrittiva, individuano il limite
dell'espressività e della decidibilità delle conclusioni che si vogliono trarre da esse. Non
si entrerà del dettaglio di tali limiti di espressività, preferendo rimandare una trattazione
più esauriente al momento in cui saranno definiti i linguaggi formali il cui utilizzo è
previsto nel Sistema Pubblico di Cooperazione. Ci si limita ad anticipare che questi
linguaggi formali devono poter codificare i seguenti costrutti: (i) costanti predicative
unarie (chiamate di solito classi, o tipi); (ii) costanti individuali (chiamate di solito
individui o istanze); (iii) costanti predicative relazionali (relazioni, proprietà, attributi,
associazioni, slot), usate per mettere in relazione tra loro sia intere categorie di individui
che gli individui stessi; (iv) assiomi sulle classi (chiamati variamente vincoli, restrizioni,
regole), che a loro volta usano un insieme ristretto di operatori logici, fra cui operatori
booleani, quantificatori ed insiemi [Gan08].

Idealmente, un'ontologia ben formata contiene molte altre informazioni che
possono essere rese per mezzo di metadati o annotazioni. Queste informazioni si basano

40


su costrutti che esulano dallo scope dei linguaggi logici, pertanto sono molto più utili
alla progettazione e concettualizzazione delle ontologie che non ad agenti software
automatici, detti ragionatori, finalizzati a derivare conclusioni a partire dalle asserzioni
di un insieme di ontologie.

L'ambito applicativo della semantica dei domini rappresentata con le ontologie è
sterminato. In linea generale, le ontologie computazionali possono entrare in gioco in
qualunque contesto ove si pongano problemi di comunicazione fra più attori, dove per
attore si intende sia un agente vero e proprio, sia un elemento passivo come una
sorgente di informazioni. Sul piano applicativo, sono già moltissimi i servizi informativi
o basati sull'uso di sistemi informativi che fanno affidamento alle ontologie per favorire
l'efficienza, il risparmio di risorse e l'operatività: oltre ovviamente ai campi
dell'eGovernment e dei Web Service, anche l'indicizzazione e l'estrazione di
informazioni da documenti, l'interrogazione o il merging di basi di dati eterogenee, la
condivisione di dati scientifici, il commercio elettronico e il social networking sono solo
alcuni dei campi d'impiego di strategie operative basate su ontologie. Dal punto di vista
del contenuto, si fanno sempre più frequenti i gruppi di lavoro finalizzati alla
produzione di ontologie di riferimento per particolari domini, fra i quali si possono
citare Gene Ontology30 per la biologia molecolare, RosettaNet31 per l'elettronica e
Agrovoc32 per l'agricoltura. Parallelamente, uno dei campi di studio dell'ontology
engineering è la creazione di modelli che sappiano descrivere concetti generali che
siano gli stessi in tutti i domini. Esempi di queste ontologie, delle fondazionali o upper
ontologies, sono: Basic Formal Ontology (BFO)33, General Formal Ontology (GFO)34,
Suggested Upper Merged Ontology (SUMO)35 e Descriptive Ontology for Linguistic
and Cognitive Engineering (DOLCE)36. Altra importante risorsa semantica che

30 http://www.geneontology.org
31 http://www.rosettanet.org
32 http://www.fao.org/aims/ag_intro.htm
33 http://www.ifomis.org/bfo
34 http://www.onto-med.de/ontologies/gfo
35 http://www.ontologyportal.org
36 http://www.loa-cnr.it/DOLCE.html

41


condivide alcuni aspetti delle ontologie fondazionali è il database lessicale WordNet37,
nato come network semantico basato su principi di psicolinguistica e oggi assurto a vero
e proprio dizionario monolingue inglese. Nel campo dei Web Service, due dei progetti
meglio conosciuti per concettualizzarne lo scambio di informazioni sono le ontologie
Web Service Modeling Ontology (WSMO)38 e OWL-S (evoluzione di DAML-S)
[MBHL+04].

Nel seguito saranno esposti i più noti formalismi utilizzati nella creazione e
gestione delle ontologie, di cui alcuni saranno poi adottati nella definizione del layer
semantico di SPCoop: in particolare RDF per la codifica della conoscenza ed OWL per
l'authoring di ontologie.

2.1.2. Strumenti formali per le ontologie: Resource Description
Framework (RDF), RDF Schema e Web Ontology Language
(OWL)

Originariamente progettato come un data model per la rappresentazione di
metadati, RDF (acronimo per Resource Description Framework) [LasSwi99] è una
famiglia di specifiche del W3C che, nel periodo dal 1999 al 2004, si sono consolidate in
un linguaggio general-purpose per la rappresentazione delle informazioni sul web. Il
data model di RDF si basa sull'idea che le risorse descritte abbiano delle proprietà,
ciascuna con un valore, e che queste risorse possano essere descritte per mezzo di
asserzioni, o statement, che ne specifichino le proprietà e i rispettivi valori. I membri di
un tale statement sono descritti in RDF seguendo una particolare terminologia mutuata
da una metafora linguistica comune: un'espressione in RDF è una tripla soggetto-
predicato-oggetto, dove soggetto e predicato sono risorse, che possono essere
identificate ciascuna da un Uniform Resource Locator (URI), mentre l'oggetto può
essere una risorsa, una costante (o letterale) o a sua volta una tripla RDF. Una risorsa
può essere anonima, nel qual caso è detta blank node.

37 http://wordnet.princeton.edu
38 http://www.wsmo.org

42


Il data model di RDF è astratto, pertanto prescinde dal formalismo usato per
serializzarlo. Tuttavia, mentre da un lato è comune (anche per la rappresentazione di
ontologie) l'impiego di una sintassi XML appositamente definita, è anche utile pensare
ad un insieme di statement come ad un grafo i cui nodi sono i soggetti ed oggetti e per
ogni statement vi è un arco tra soggetto ed oggetto, etichettato con l'identificatore della
proprietà.

RDF Schema (o RDFS) [BriGuh04] è un linguaggio che è stato pensato per
strutturare le risorse RDF a fini di porre le basi per la descrizione di ontologie (o
vocabolari RDF). Le sue componenti principali, che ritroveremo successivamente in
tema di linguaggio OWL, sono:

● rdfs:class per dichiarare che una risorsa rappresenta il tipo (o la classe) di
un'altra risorsa;

● rdfs:subClassOf per dichiarare gerarchie di classi;

● rdfs:domain, dichiarato per una proprietà, indica la classe a cui appartengono i
soggetti di tutte le triple che hanno questa proprietà come predicato;

● rdfs:range, dichiarato per una proprietà, indica la classe o il tipo di dato
primitivo a cui appartengono gli oggetti di tutte le triple che hanno questa
proprietà come predicato;

Mentre RDFS rappresenta una valida base di partenza per la formalizzazione di
modelli semantici, esso si rivela limitato ed insufficiente a garantire determinati trade-
off di espressività e computabilità. Ad esempio, non è possibile rappresentare assiomi
sulle classi come l'equivalenza o la disgiunzione, poiché l'unica relazione
rappresentabile è quella di tipo “is-a” (tramite assiomi detti di sussunzione). La
descrizione del superamento di queste limitazioni è affidata alla prossima sezione.

Ad oggi, per Web Ontology Language (abbreviato come OWL) [DSBH+04] si

43


intende non uno, ma una famiglia di linguaggi di rappresentazione della conoscenza per
l'authoring di ontologie. Divenuto W3C Recommendation il 10 febbraio 2004, OWL si
fonda sulla messa a disposizione delle risorse del web in maniera tale da renderle
accessibili da processi automatici o semi-automatici. La rappresentazione si basa
sull'assunto di operare in un contesto di mondo aperto: da un lato, mettendo in relazione
due o più ontologie, è resa possibile la raccolta di informazioni da fonti distribuite;
dall'altro, in ogni dominio è possibile estendere un qualsiasi concetto, anche non
definito nel dominio stesso, e tali emendamenti non possono annullarne altri, neanche in
un contesto a rischio di contraddittorietà. Questa caratteristica, mutuata dalla natura
inerentemente distribuita del web semantico, prende il nome di monotonia. Inoltre, sotto
questo assunto del mondo aperto (che si pone, ad esempio, in contrasto con gran parte
della teoria delle basi di dati relazionali), se non è possibile dimostrare, con la
conoscenza a nostra disposizione, che un'asserzione sia vera, non possiamo per questo
trarre la conclusione che essa sia falsa. Facendo un parallelo con la teoria della
concorrenza, come è necessario prevedere meccanismi per la prevenzione e la
risoluzione dei deadlock, così chi progetta ontologie o strumenti che operano con esse
deve tenere in conto i casi di informazioni contraddittorie ed adottare opportune
strategie risolutive.

Allo stato attuale della specifica, OWL si compone di tre varianti, classificate in
base alla loro potenza espressiva. Ciascun sottolinguaggio estende il suo predecessore
più semplice sul piano sintattico:

● OWL-Lite mette a disposizione dell'utente una gerarchia delle classi e una serie
di vincoli elementari. Ad esempio, pur supportando vincoli di cardinalità,
consente per tali vincoli soltanto valori in {0,1}.

● OWL-DL comprende tutti i costrutti del linguaggio OWL per garantire la
massima espressività, ma vi pone alcune restrizioni per garantire la completezza
computazionale (cioè che ogni conclusione in OWL-DL sia calcolabile) e la
decidibilità (ovvero che ogni computazione di una conclusione termini). Il nome

44


discende dallo stretto legame che ha con i costrutti della logica descrittiva,
disciplina per la rappresentazione strutturata della conoscenza in un dominio
applicativo, che di fatto costituisce la base di OWL.

● OWL-Full fu progettato per compatibilità con RDFS, ed è inteso per
massimizzare l'espressività mantenendo la libertà sintattica di RDF. È
improbabile che un sistema software con supporto per il ragionamento su
ontologie possa mai supportare completamente OWL Full.

L'espressività richiesta dal processo di modellazione dei domini applicativi in
SPCoop è tale per cui il set di costrutti messi a disposizione da OWL-Lite non è
sufficiente per rappresentare il patrimonio di conoscenza della Pubblica
Amministrazione. Si assume pertanto che la semantica dei domini SPCoop possa, e in
parte debba essere espressa per mezzo dei costrutti della logica descrittiva. Questo può
essere interpretato come l'affermazione che la base di conoscenza del Catalogo Schemi
ed Ontologie sia rappresentata in OWL-DL, ma essendo al vaglio l'approvazione da
parte del gruppo di lavoro OWL di una specifica (denominata OWL 1.1) modellata sui
costrutti maggiormente utilizzati nel campo dell'ontology engineering, questa
distinzione in tre varietà è prossima a cadere. Nel seguito ci limiteremo, perciò, a
parlare di linguaggio OWL, sottintendendo però che ci si concentrerà nell'ambito dei
costrutti entro la logica descrittiva.

È un errore pensare ad OWL come ad un dialetto di XML, anche perché lo stesso
linguaggio XML (peraltro in più di una variante) rappresenta solo alcune delle possibili
sintassi alternative per serializzare un'ontologia: linguaggi non basati su XML che si
utilizzano nella rappresentazione di un'ontologia sono KRSS2, N-Triple e Turtle
[Bec04] (le ultime due basate sulla c.d. Notazione 3 [Ber98], che è un formato di
serializzazione per RDF non basato su XML). Un'ontologia in OWL può essere vista
come un grafo RDF, ovvero come un insieme di triple <soggetto, predicato, oggetto> i
cui membri rappresentano risorse. Ciascuna tripla indica un'espressione nel linguaggio
RDF, cioè uno statement. Questa rappresentazione fornisce già le prime indicazioni

45


sulla natura delle risorse: due tipologie omologabili, che qualificano soggetto e oggetto
di una tripla (i vertici del grafo) e una che qualifica i predicati (gli archi del grafo). Una
delle finalità del presente progetto, che ha condizionato la scelta del motore OWL da
impiegare nell'applicazione, è proprio l'astrazione rispetto alla particolare
rappresentazione di un'ontologia messa a disposizione per l'annotazione di un Accordo
di Servizio. Nell'analizzare quali entità esposte da OWL sono identificabili nel processo
di annotazione semantica, non si effettuerà accoppiamento stretto fra tali entità e tag
XML, salvo talvolta ricorrere alla rappresentazione di concetti per mezzo della più
conosciuta sintassi RDF/XML.

La maggior parte degli elementi di un'ontologia OWL riguarda classi, proprietà,
istanze di classi e relazioni fra queste istanze.

Le classi forniscono un meccanismo di astrazione per il raggruppamento di risorse
con caratteristiche simili. Come si vedrà, larga parte del potere espressivo delle
ontologie viene dalla capacità di ragionare su questi costrutti. Ogni classe in OWL è
associata ad un insieme di individui, detto estensione della classe. Gli elementi di
un'estensione sono detti istanze della classe. A questa descrizione, detta per l'appunto
estensionale, è affiancata una definizione intensionale, correlata al concetto sottostante
definito dalla classe stessa. Pertanto, due classi possono avere la stessa estensione pur
continuando a differire tra di loro.

OWL ammette sei diverse modalità per definire una classe, dette descrittori di
classe (class descriptions):

1. la dichiarazione esplicita per mezzo di un identificatore;

2. un'enumerazione esaustiva di individui, che definisce estensionalmente una
nuova classe;

3. una particolare restrizione su una proprietà (vedere seguito). Tutti gli individui
che soddisfano questa restrizione (ad esempio vincoli di valori o di cardinalità)

46


sono essi stessi estensione di una classe;

4. l'intersezione di due o più descrittori;

5. l'unione di due o più descrittori;

6. il complemento di un descrittore;

Questa tassonomia pone una prima importantissima questione in merito
all'impiego di classi in un'annotazione di tipo sawsdl:modelReference: si ha cioè che
soltanto le classi del primo tipo sono provviste di un identificatore, nel caso specifico un
riferimento di tipo URI. Le classi definite in tutti gli altri modi sono anonime, definite
ponendo dei vincoli sull'estensione di un'altra classe, e non c'è modo di identificarle con
un meccanismo che riconduca ad un semplice riferimento, garantendone in ogni
momento il mapping univoco verso quel particolare descrittore.

Un altro metodo per definire classi in OWL si basa proprio sui suddetti descrittori:
questi sono gli elementi che si utilizzano per definire altre classi mediante quelli che
sono noti come assiomi di classe. Il più elementare assioma di classe è un descrittore del
tipo 1 sopracitato. Con un piccolo abuso di notazione, è di seguito reso in RDF/XML un
esempio di assioma di classe di questo tipo:

<owl:Class rdf:ID="Servizio"/>

Un assioma di questo tipo definisce correttamente i servizi, ma ci dice ben poco
sulle loro caratteristiche. Tipicamente, gli assiomi di classe contengono componenti
aggiuntive che dichiarano condizioni necessarie e/o sufficienti per l'appartenenza ad una
classe. I costrutti sintattici che consentono di combinare descrittori di classi per formare
assiomi sono tre:

1. sottoclasse (rdfs:subClassOf): consente di asserire che l'estensione di un
descrittore di classe è un sottoinsieme dell'estensione di un altro descrittore di
classe;

47


2. equivalenza (owl:equivalentClass): afferma che un descrittore ha esattamente
la stessa estensione di classe di un altro descrittore;

3. disgiunzione (owl:disjointWith): afferma che l'estensione di un descrittore di
classe non ha membri in comune con l'estensione di classe di un altro
descrittore.

Le proprietà in OWL sono distinte in due principali categorie:

● Object properties, per mettere in correlazione individui con individui. Proprietà
di questo tipo sono istanze della classe OWL predefinita owl:ObjectProperty.

● Datatype properties, per mettere in correlazione individui con valori di tipi di
dato. Proprietà di questo tipo sono istanze della classe OWL predefinita
owl:DatatypeProperty.

Riprendendo l'esempio precedente dei rapporti di lavoro, definiamo ora una nuova
proprietà, con la restrizione che il suo codominio debba essere un insieme di individui:

<owl:ObjectProperty rdf:ID="espone"/>

Avendo definito una proprietà di nome espone con la sopracitata restrizione, non
si sa ancora nulla, tuttavia, di quali debbano essere gli individui che ne compongono il
codominio. Come per le classi, OWL definisce dei costrutti per descrivere
caratteristiche aggiuntive delle proprietà, e che si combinano fra loro per formare i
cosiddetti assiomi di proprietà. Questi costrutti sono:

1. Costrutti di tipo RDF Schema: rdfs:subPropertyOf, rdfs:domain (dominio) e
rdfs:range (codominio).

2. Relazioni con altre proprietà: owl:equivalentProperty e owl:inverseOf.

3. Vincoli globali di cardinalità: owl:FunctionalProperty e

48


owl:InverseFunctionalProperty.

4. Caratteristiche logiche delle proprietà: owl:SymmetricProperty e
owl:TransitiveProperty.

Per ragioni di spazio, si rimandano ai riferimenti del W3C per OWL [DSBH+04] i
dettagli di questi costrutti sintattici, il cui significato si presta comunque all'intuizione a
partire dai loro nomi. Aggiungiamo infine che i tre costrutti di OWL usati per formare
assiomi di classe (sottoclasse, equivalenza e disgiunzione) sono tre proprietà aventi
descrittori di classe sia come dominio che come codominio.

Gli individui, infine, rappresentano istanze di classi e sono la componente
basilare di un'ontologia. Non è necessario, in senso stretto, includere alcun individuo
nella definizione di un'ontologia, ma è bene tener presente che una delle finalità
fondamentali delle ontologie è la categorizzazione di oggetti, anche se non sono definiti
esplicitamente come parte del modello (cosa possibile visto che, data la natura
distribuita del web semantico, è sempre possibile istanziare una classe anche
trasversalmente a domini applicativi diversi).

Per definire un individuo, è sufficiente dichiararlo come membro di una classe
tramite un assioma di istanza, che in RDF/XML sarebbe:

<Servizio rdf:ID="ServizioIndiceSoggetti" />

Un'importante considerazione riguarda la questione della dicotomia fra le
relazioni di sottoclasse e di istanza. Nell'esempio di cui sopra, come è stato possibile
determinare che ServizioIndiceSoggetti indicasse un particolare servizio piuttosto
che una sottoclasse di servizi? Nella pratica, questa scelta è arbitraria e costituisce uno
dei capisaldi dell'ingegneria della conoscenza.

49


2.2. Analisi dell'Accordo di Servizio

L'Accordo di Servizio è il prodotto finale di quel processo organizzativo che è la
definizione di un servizio in SPCoop. Nell'ottica di voler lasciare a ciascun soggetto
amministrativo partecipante la libertà di apportare aggiornamenti e modifiche, anche sui
piani concettuale e logico, ai servizi erogati da esso anche successivamente alla loro
pubblicazione, si è reso fondamentale un supporto al versioning dei servizi. Questo si
traduce a sua volta nella definizione di versioni diverse dei corrispondenti Accordi di
Servizio, i quali dovranno necessariamente differire anche a livello di parte comune.

2.2.1. Ciclo di vita dell'Accordo di Servizio

Ciascuna versione di un servizio segue un ciclo di vita autonomo, e così l'AdS
corrispondente. Questo ciclo di vita è suddiviso nelle sei fasi illustrate in Tabella 239.

Fase Descrizione
Fase 1. Il servizio viene ideato e formalizzato nella parte comune e in una
Definizione o più parti specifiche, a seconda della tipologia del servizio. Due
dell’Accordo di sono i possibili approcci che può seguire il processo di
Servizio definizione:

1. Approccio unilaterale. La parte comune viene concepita
unilateralmente dal soggetto erogatore, o da un soggetto
delegato. Le parti specifiche possono seguire l’approccio
unilaterale o l’approccio concordato definito al punto 2.

2. Approccio concordato. La definizione dell’Accordo di
Servizio, nelle sue parti comune e specifica, è negoziata in
modo congiunto dall'erogatore e dal fruitore (o da loro
rappresentanti).

39 [BFMT05a], sezione “Ciclo di Vita dell’Accordo di Servizio”, pp. 15-17

50

Tesi_Adamou

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (7)

Semelhante a Tesi_Adamou

Semelhante a Tesi_Adamou (20)

Mais de tutorialsruby

Mais de tutorialsruby (20)

Último

Último (9)

Tesi_Adamou