Una Rich Internet Application per l'annotazione
 semantica degli Accordi di Servizio nel Sistema
           Pubblico di Co...
Indice Generale


Indice generale
Premessa...................................................................................
4.2. Software a supporto dell'implementazione........................................................105
        4.2.1. AP...
Premessa



Premessa
      Il presente lavoro è frutto della collaborazione tra il Centro Nazionale per
l'Informatica nell...
Premessa

l'estensione di un object model preesistente, noto come SAWSDL4J, con un pacchetto
software aggiuntivo, da un la...
Premessa

tipologie di risorse prese in esame in corso di progettazione, fornendo per ciascuna di
esse opportune motivazio...
1.Introduzione al contesto di riferimento



1. Introduzione al contesto di riferimento
      La IEEE definisce l'interope...
1.Introduzione al contesto di riferimento

servizi e rendere efficiente l’azione amministrativa, contenendone nel contempo...
1.Introduzione al contesto di riferimento

anche economica, nell'utilizzo dei servizi di interoperabilità e cooperazione a...
1.Introduzione al contesto di riferimento

pubblico di connettività10 (brevemente le “Regole tecniche”). Queste sono state...
1.Introduzione al contesto di riferimento

          meccanismi per la connettività ed il trasporto sia tra diverse ammini...
1.Introduzione al contesto di riferimento




  Figura 1: Pila architetturale del Sistema Pubblico di Connettività (fonte:...
1.Introduzione al contesto di riferimento

in ordine da BT-Albacom, Wind e Telecom Italia. Questi quattro operatori hanno
...
1.Introduzione al contesto di riferimento

da opportuni sistemi crittografici.


1.2.2. Il livello di interoperabilità e c...
1.Introduzione al contesto di riferimento

         Nel Sistema Pubblico di Connettività e Cooperazione, la messa a dispos...
1.Introduzione al contesto di riferimento

       interpretazione delle loro utilità e del significato dell'informazione v...
1.Introduzione al contesto di riferimento

opportuna, si anticipa che esso è stato impiegato in maniera estesa nel definir...
1.Introduzione al contesto di riferimento

prestazioni di servizio. La tipologia di coordinamento seguita da ciascun servi...
1.Introduzione al contesto di riferimento

                       la risposta. La ricezione della risposta ha come effetto...
1.Introduzione al contesto di riferimento




     Figura 4: Esempio di Servizio di tipo Richiesta/Risposta (fonte: [ABFM+...
1.Introduzione al contesto di riferimento

Dominio Applicativo

      Per       dominio applicativo si intende “l'insieme ...
1.Introduzione al contesto di riferimento

        I soggetti amministrativi che rientrano in quest'ottica hanno la possib...
1.Introduzione al contesto di riferimento

astrazione. Fino alla versione 1.1, SOAP era acronimo di Simple Object Access
P...
1.Introduzione al contesto di riferimento

          esterne, interagiscano con un'interfaccia uniforme;


     •    il ra...
1.Introduzione al contesto di riferimento

          del messaggio da parte delle Porte di Dominio in termini di affidabil...
1.Introduzione al contesto di riferimento

1.2.2.2 Porta di Dominio

       L'unico metodo previsto perché un dominio appl...
1.Introduzione al contesto di riferimento

            tenuta a tracciare permanentemente tutte le sue attività.

        ...
1.Introduzione al contesto di riferimento

           in modalità testo mediante messaggi di comando.

       •   Consolle...
1.Introduzione al contesto di riferimento

test riguardano sia il ruolo di erogatore che quello di fruitore di una PdD. La...
1.Introduzione al contesto di riferimento

all'implementazione del servizio vero e proprio, inclusa la sua ubicazione. Ess...
1.Introduzione al contesto di riferimento

     1. Servizi mono-erogatore/mono-fruitore, in cui ciascuno dei sistemi eroga...
1.Introduzione al contesto di riferimento

formalizzano la loro volontà (o l'obbligo per legge) di associarsi, costituendo...
1.Introduzione al contesto di riferimento

         Un Accordo di Servizio Composto è invece una specializzazione di AdS c...
1.Introduzione al contesto di riferimento

flusso informativo e per massimizzare l'efficienza dello scambio di informazion...
1.Introduzione al contesto di riferimento

     •   Il Servizio di Indice dei Soggetti offre un insieme di funzionalità ne...
1.Introduzione al contesto di riferimento




     Figura 6: Servizi Infrastrutturali di Interoperabilità, Cooperazione ed...
2.La semantica per l'interoperabilità dei servizi in SPCoop



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

titolari di un indirizzo, fra le persone fisiche, le società ...
2.La semantica per l'interoperabilità dei servizi in SPCoop

lo stato dell'arte non si è rivelato sufficiente e che hanno ...
2.La semantica per l'interoperabilità dei servizi in SPCoop

computazionali e non al campo di studio della filosofia.

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

su costrutti che esulano dallo scope dei linguaggi logici, pe...
2.La semantica per l'interoperabilità dei servizi in SPCoop

condivide alcuni aspetti delle ontologie fondazionali è il da...
2.La semantica per l'interoperabilità dei servizi in SPCoop

         Il data model di RDF è astratto, pertanto prescinde ...
2.La semantica per l'interoperabilità dei servizi in SPCoop

intende non uno, ma una famiglia di linguaggi di rappresentaz...
2.La semantica per l'interoperabilità dei servizi in SPCoop

          discende dallo stretto legame che ha con i costrutt...
2.La semantica per l'interoperabilità dei servizi in SPCoop

sulla natura delle risorse: due tipologie omologabili, che qu...
2.La semantica per l'interoperabilità dei servizi in SPCoop

        sono essi stessi estensione di una classe;

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

     2. equivalenza (owl:equivalentClass): afferma che un des...
2.La semantica per l'interoperabilità dei servizi in SPCoop

        owl:InverseFunctionalProperty.


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



2.2. Analisi dell'Accordo di Servizio

      L'Accordo di S...
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Tesi_Adamou
Upcoming SlideShare
Loading in...5
×

Tesi_Adamou

1,763

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,763
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
39
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Tesi_Adamou"

  1. 1. 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
  2. 2. 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
  3. 3. 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
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. 1.Introduzione al contesto di riferimento 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
  9. 9. 1.Introduzione al contesto di riferimento 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. 7 [DL4205], articolo 6. 8 [DL4205], articolo 13. 9 [DL8205], articoli 72-87. 9
  10. 10. 1.Introduzione al contesto di riferimento 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
  11. 11. 1.Introduzione al contesto di riferimento 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
  12. 12. 1.Introduzione al contesto di riferimento 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
  13. 13. 1.Introduzione al contesto di riferimento 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
  14. 14. 1.Introduzione al contesto di riferimento 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
  15. 15. 1.Introduzione al contesto di riferimento 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
  16. 16. 1.Introduzione al contesto di riferimento 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
  17. 17. 1.Introduzione al contesto di riferimento 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
  18. 18. 1.Introduzione al contesto di riferimento 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
  19. 19. 1.Introduzione al contesto di riferimento 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
  20. 20. 1.Introduzione al contesto di riferimento 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
  21. 21. 1.Introduzione al contesto di riferimento 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
  22. 22. 1.Introduzione al contesto di riferimento 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
  23. 23. 1.Introduzione al contesto di riferimento 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
  24. 24. 1.Introduzione al contesto di riferimento 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
  25. 25. 1.Introduzione al contesto di riferimento 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
  26. 26. 1.Introduzione al contesto di riferimento 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
  27. 27. 1.Introduzione al contesto di riferimento 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
  28. 28. 1.Introduzione al contesto di riferimento 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
  29. 29. 1.Introduzione al contesto di riferimento 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
  30. 30. 1.Introduzione al contesto di riferimento 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
  31. 31. 1.Introduzione al contesto di riferimento 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
  32. 32. 1.Introduzione al contesto di riferimento 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
  33. 33. 1.Introduzione al contesto di riferimento 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
  34. 34. 1.Introduzione al contesto di riferimento 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
  35. 35. 1.Introduzione al contesto di riferimento • 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
  36. 36. 1.Introduzione al contesto di riferimento 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
  37. 37. 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
  38. 38. 2.La semantica per l'interoperabilità dei servizi in SPCoop 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
  39. 39. 2.La semantica per l'interoperabilità dei servizi in SPCoop 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
  40. 40. 2.La semantica per l'interoperabilità dei servizi in SPCoop 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
  41. 41. 2.La semantica per l'interoperabilità dei servizi in SPCoop 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
  42. 42. 2.La semantica per l'interoperabilità dei servizi in SPCoop 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
  43. 43. 2.La semantica per l'interoperabilità dei servizi in SPCoop 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
  44. 44. 2.La semantica per l'interoperabilità dei servizi in SPCoop 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
  45. 45. 2.La semantica per l'interoperabilità dei servizi in SPCoop 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
  46. 46. 2.La semantica per l'interoperabilità dei servizi in SPCoop 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
  47. 47. 2.La semantica per l'interoperabilità dei servizi in SPCoop 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
  48. 48. 2.La semantica per l'interoperabilità dei servizi in SPCoop 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
  49. 49. 2.La semantica per l'interoperabilità dei servizi in SPCoop 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
  50. 50. 2.La semantica per l'interoperabilità dei servizi in SPCoop 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

×