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 Prof. Giancarlo Bongiovanni

Correlatori Dott. Stefano Fuligni

Dott. Aldo Gangemi

Anno Accademico 2007/2008

Indice Generale

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

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

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 opensource, presenti oggi sul mercato: in particolare la semplificazione, l'adattamento alle particolari esigenze di SPCoop e l'indipendenza dalle diverse piattaforme informatiche. Scopo principale della tesi dunque la progettazione e lo sviluppo di un'applicazione web altamente interattiva a supporto del processo di annotazione semantica dei servizi erogati in SPCoop. Questo obiettivo emerso nel corso dello studio degli standard e delle tecnologie che concorrono al modello SPCoop, a seguito dell'analisi delle connotazioni semantiche del sistema, svolta in collaborazione, oltre che con il CNIPA, con il Consiglio Nazionale delle Ricerche, in particolare l'Istituto di Scienze e Tecnologie della Cognizione [ISTC]. La soluzione applicativa sviluppata ai fini della tesi, ancorch concepita in seno a questa particolare architettura, ha prospettive di estensibilit tali da renderla, nel corso di eventuali futuri sviluppi, uno strumento general-purpose a sostegno della gestione dei cosiddetti Web Service semantici. Un obiettivo secondario, emerso in corso di sviluppo del progetto, stato 4

Premessa l'estensione di un object model preesistente, noto come SAWSDL4J, con un pacchetto software aggiuntivo, da un lato per soddisfare un particolare requisito di SPCoop e dall'altro per sopperire alle lacune della libreria in questione. Il presente lavoro si articola in cinque capitoli. Il primo introduce il lettore allo scenario delle architetture orientate ai servizi (SOA) e dei Web Service, con riferimento al loro impiego nella Pubblica Amministrazione italiana ed in particolare al Sistema Pubblico di Connettivit e Cooperazione (SPC) ed al framework SPCoop, di cui si illustrano i componenti infrastrutturali alla base. Il secondo capitolo dedicato al problema dell'integrazione fra i servizi della PA e il contesto del web semantico, ed accompagnato da un'analisi approfondita di uno degli elementi infrastrutturali di SPCoop, l'Accordo di Servizio. Tale analisi, dapprima prettamente strutturale, si focalizza sulle convenzioni adottate per l'estensione di questo oggetto con metadati che descrivono il significato delle informazioni veicolate dai servizi. Segue una descrizione delle modalit e dei processi di annotazione semantica dei servizi erogati in SPCoop. Sono infine esaminati i relativi standard definiti dal CNIPA sulla base delle raccomandazioni del World Wide Web Consortium (W3C), di cui viene individuato il set minimale utile in ambito SPCoop. Il terzo capitolo dedicato alla progettazione di un sistema che soddisfi i requisiti di essenzialit ed integrazione con i servizi infrastrutturali di SPCoop, per supportare in dettaglio i processi di annotazione semantica descritti nel capitolo precedente. La progettazione riguarder in particolar modo l'accoppiamento debole fra logica applicativa ed interfaccia, nonch la modellazione di quest'ultima sulla base di un determinato paradigma dell'utente. Il quarto capitolo si concentra sullo sviluppo dell'applicativo SASCHA, uno strumento basato su web a supporto dell'annotazione semantica degli Accordi di Servizio. Sono altres descritte le attivit di progettazione e sviluppo complementari, tra cui l'estensione della libreria SAWSDL4J. Si presenta una panoramica delle varie 5

Premessa tipologie di risorse prese in esame in corso di progettazione, fornendo per ciascuna di esse opportune motivazioni in merito alla loro adozione o meno per il presente progetto. Queste risorse comprendono sia l'ambiente di sviluppo scelto, dall'hardware fino agli strumenti per redigere questa tesi, sia le API (Application Programming Interface) utilizzate per rispondere ai requisiti di progetto dell'applicazione. Il capitolo si conclude con l'esposizione delle attivit di collaudo, svolte sia sul piano tecnico che in relazione ad un caso di studio con esempi sia di Accordi di Servizio che di modelli semantici da impiegare per annotarli. Per concludere, nell'ultimo capitolo vengono proposte le conclusioni tratte da questa esperienza e le possibili direttrici di sviluppo, con prospettive di estensibilit dell'applicativo SASCHA, sia per una pi netta integrazione con i servizi di SPCoop che per una migrazione verso un modello di sviluppo compatibile con i mondi aperti dei Web Service e del web semantico.

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 giudizio1 , 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

1.Introduzione al contesto di riferimento servizi e rendere efficiente lazione amministrativa, contenendone nel contempo i costi. Il CNIPA nasce nel 2004 dalla fusione di due precedenti organismi: lAutorit per lInformatica 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 amministrazione5. 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.

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 7 8 9 [DL4205], articolo 2 comma 3. [DL4205], articolo 6. [DL4205], articolo 13. [DL8205], articoli 72-87.

1.Introduzione al contesto di riferimento pubblico di connettivit10 (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

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

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

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 (OneWay 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

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 linterazione 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

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

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 limplementazione 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

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 dallinserzione 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

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 allerogatore 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 allerogatore un messaggio contenente una richiesta di prestazione di servizio. Lerogatore 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 dellinterazione (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 allerogatore e continua lesecuzione. La richiesta viene trasmessa al sistema erogatore che esegue i trattamenti, prepara e emette

18

1.Introduzione al contesto di riferimento la risposta. La ricezione della risposta ha come effetto presso il fruitore lavvio 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. Lidentificatore di correlazione messaggio/replica pu essere utilizzato come identificatore di correlazione richiesta/risposta. Notifica senza risposta: lerogatore 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: lerogatore 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

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 Connettivit16.

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

20

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 organizzazione17. 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 dellazione 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 limmigrazione, 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 lAccordo di Servizio , p. 54

21

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 SOAP19, 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

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

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:

lelemento Intestazione che contiene le informazioni relative al trattamento

24

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 dellinterazione 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 dellelemento Intestazione del messaggio.23

lelemento 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 lelemento
Descrizione

conterr il manifesto dei riferimenti agli allegati, nel rispetto delle

specifiche SOAP 1.1. with Attachments [BTN00].

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

25

1.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 applicativi25. 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

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

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 Gestione Busta eGov Gestione Tracciatura Gestione Diagnostici Gestione SOAP with Attachments Gestione modalit consegna affidabile Sicurezza di Base SSL Sicurezza avanzata Wsse: Security Consolle base Consolle evoluta Porta Applicativa Light s s s s s s no s no Porta Applicativa Advanced s s s s s s s non richiesta 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

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 lAccordo 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 loggetto 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

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

30

1.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 dellAccordo, 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/monofruitore. 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

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 lerogazione 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

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 dellAccordo 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

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 SPC29. 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, laccesso, laggiornamento, 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 unarchitettura con replicazione dellinformazione.

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

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

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

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

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

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

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 linterpretazione 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

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 31 32 33 34 35 36

http://www.geneontology.org http://www.rosettanet.org http://www.fao.org/aims/ag_intro.htm http://www.ifomis.org/bfo http://www.onto-med.de/ontologies/gfo http://www.ontologyportal.org http://www.loa-cnr.it/DOLCE.html

41

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 soggettopredicato-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

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 rdfs:domain,

per dichiarare gerarchie di classi;

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 tradeoff 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

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

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

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

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

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 48 globali di cardinalit:

owl:FunctionalProperty

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

owl:InverseFunctionalProperty.

4. Caratteristiche

logiche

delle

propriet:

owl:SymmetricProperty

owl:TransitiveProperty.

Per ragioni di spazio, si rimandano ai riferimenti del W3C per OWL [DSBH+04] i dettagli di questi costrutti sintattici, il cui significato si presta comunque all'intuizione a partire dai loro nomi. Aggiungiamo infine che i tre costrutti di OWL usati per formare assiomi di classe (sottoclasse, equivalenza e disgiunzione) sono tre propriet aventi descrittori di classe sia come dominio che come codominio. Gli individui, infine, rappresentano istanze di classi e sono la componente basilare di un'ontologia. Non necessario, in senso stretto, includere alcun individuo nella definizione di un'ontologia, ma bene tener presente che una delle finalit fondamentali delle ontologie la categorizzazione di oggetti, anche se non sono definiti esplicitamente come parte del modello (cosa possibile visto che, data la natura distribuita del web semantico, sempre possibile istanziare una classe anche trasversalmente a domini applicativi diversi). Per definire un individuo, sufficiente dichiararlo come membro di una classe tramite un assioma di istanza, che in RDF/XML sarebbe:
<Servizio rdf:ID="ServizioIndiceSoggetti" />

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

49

2.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 Fase 1. Definizione dellAccordo di Servizio Descrizione Il servizio viene ideato e formalizzato nella parte comune e in una o pi parti specifiche, a seconda della tipologia del servizio. Due sono i possibili approcci che pu seguire il processo di definizione: 1. Approccio unilaterale. La parte comune viene concepita unilateralmente dal soggetto erogatore, o da un soggetto delegato. Le parti specifiche possono seguire lapproccio unilaterale o lapproccio concordato definito al punto 2. 2. Approccio concordato. La definizione dellAccordo 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 dellAccordo di Servizio, pp. 15-17

50

2.La semantica per l'interoperabilit dei servizi in SPCoop Fase 2. Pubblicazione dellAccordo di Servizio sul Servizio di Registro SICA. registrazione dei titolari dei sistemi erogatore e fruitore, registrazione della parte comune, registrazione di tutte le parti specifiche, da cui discende anche l'obbligo di registrare i porti di accesso dei relativi sistemi, qualificando le Porte di Dominio presso SPCoop. Fase 3. Implementazione del servizio. I titolari dei sistemi erogatori e fruitori implementano rispettivamente lerogazione e la fruizione del servizio in conformit con lAccordo di Servizio. Questa fase pu essere parallela, o anche precedente la pubblicazione sul SICA Fase 4. Presentazione del servizio su SPCoop. Fase 5. Erogazione/fruizi one del servizio su SPCoop. Fase 6. Dismissione dellAccordo di Servizio e del servizio. La fase di dismissione prevede la sottrazione (della versione) del servizio da SPCoop, dopo annuncio preventivo ai titolari dei sistemi fruitori. Tabella 2: Ciclo di vita di un servizio e del relativo Accordo di Servizio 51 Il servizio erogato in conformit con lAccordo di Servizio. La fase di erogazione/fruizione comprende attivit di logging e pu comprendere attivit di monitoraggio definite nellAdS ed effettuate dai soggetti designati da detto accordo. Questa fase prevede larchiviazione (della versione) del servizio, del suo AdS e dei giornali di tracciatura.. I titolari dei sistemi erogatori e fruitori presentano i componenti software che realizzano il servizio sulla rete, ovvero li mettono in esercizio sulla Porta di Dominio. La registrazione del servizio, obbligatoria in SPCoop comprende le seguenti attivit da effettuare presso i Servizi di Registro SICA:

2.La semantica per l'interoperabilit dei servizi in SPCoop ammesso che in un dato istante possa essere erogato ed utilizzato uno stesso servizio in pi versioni differenti, purch per ciascuna versione sia registrato un corrispondente Accordo di Servizio e che questo non sia stato nel frattempo dismesso. Da questa suddivisione in sei fasi e dal forte supporto al versioning emerge un'importante caratteristica del ciclo di vita di un Accordo di Servizio, vale a dire che questo, in una stessa versione, non pu subire emendamenti in fasi successive alla sua pubblicazione, pertanto la fase 1 (definizione dell'AdS) l'unica in cui sia possibile il processo di annotazione semantica. Questa osservazione fondamentale per identificare determinati vincoli operativi inerenti il processo di annotazione: per ogni versione del servizio, questo processo viene effettuato una tantum, quindi se la base di conoscenza del dominio applicativo (formalizzata, come vedremo, in ontologie) sottoposta ad aggiornamento, manutenzione o fine-tuning, tali modifiche non si rifletteranno nei corrispondenti riferimenti semantici dell'Accordo, salvo dismetterne questa versione e definirne una successiva. infatti sconsigliabile, in quanto potenzialmente fuorviante, mantenere due versioni dello stesso AdS che differiscono solo per l'aspetto semantico, poich una delle due sar necessariamente obsoleta rispetto al modello semantico del Dominio.

2.2.2. Struttura dell'Accordo di Servizio

La composizione dell'Accordo di Servizio descritta e disciplinata dalle Regole tecniche40, le quali stabiliscono che siano compresi: (i) l'interfaccia del servizio, cio l'insieme delle operazioni che espone; (ii) gli endpoint preso cui tale servizio accessibile; (iii) il protocollo di conversazione; (iv) la semantica del servizio e delle informazioni trattate; (v) i livelli di servizio e le caratteristiche di sicurezza. In particolare, i primi due elementi sono obbligatori e formalizzati in WSDL (Web Services Description Language). Queste caratteristiche possono essere identificate come i termini di un servizio
40 [DPCM08], articolo 20, commi 8 e 9.

52

2.La semantica per l'interoperabilit dei servizi in SPCoop applicativo in SPCoop. LAccordo di Servizio pu pertanto essere descritto come un aggregato di documenti che descrivono questi termini per una determinata istanza di un servizio applicativo. Possiamo inizialmente ripartire tali documenti in due macroinsiemi:

una specifica per limplementazione dei sistemi erogatore e fruitore: utilizzata dai progettisti e dagli ambienti di sviluppo nelle fasi di implementazione dei sistemi erogatore e fruitore;

un riferimento per lesecuzione e la gestione dei sistemi erogatore e fruitore: utilizzato dai sistemi di gestione dellesecuzione nelloperativit dei sistemi. bene precisare da subito che un Accordo di Servizio, pur essendo strutturato in

una bipartizione di tale insieme di documenti, non formalizzato in maniera tale da rispecchiare la divisione nei due insiemi sopra descritti, poich la composizione delle sue parti funzione solamente della natura dei sistemi erogatore e fruitore del servizio. anche possibile classificare le componenti dellAccordo di Servizio sulla base del loro grado di formalit, nel qual caso si possono distinguere, a prescindere dalla loro distribuzione tra le parti comune e specifica, due componenti, una formale e una semiformale, di seguito riassunte:

Specifica formale Comprende la specifica delle interfacce del servizio (inclusi i riferimenti a modelli che descrivano la semantica delle informazioni veicolate), delle conversazioni da esso supportate, dei livelli di qualit del servizio e delle caratteristiche di sicurezza. Lalto grado di formalit consiste nel fatto che tutti i documenti di questa specifica sono resi in unopportuna sintassi basata su XML. Se ne presentano gli esempi pi comuni:

WSDL (Web Service Description Language) versione 1.1 per la specifica delle interfacce del servizio [CCMW01];

53

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

XSD (XML Schema Definition) per schemi concettuali o definitori dei tipi di dato veicolati dai messaggi scambiati [FalWal04];

WSLA (Web Service Level Agreement) versione 1.0 [LKDK+03] e WSAgreement versione 1.0 [ACDK+07] per descrivere i livelli di qualit del servizio;

WSBL (Web Service Behavior Language), uno standard appositamente definito per SPCoop che specifica le conversazioni supportate [BFMT05a].

Specifica semiformale Sostanzialmente lo stesso insieme della specifica formale, solamente reso in formati diversi e non strettamente regolamentati in SPCoop. Pu includere documenti in linguaggio naturale al fine di facilitare la comprensione umana della natura del servizio. Documenti HTML o diagrammi UML delle classi, di sequenza o di stato sono alcuni dei possibili formati che possono far parte di questa specifica.

Le seguenti sottosezioni descriveranno in maggior dettaglio la struttura di un Accordo di Servizio in termini delle sue componenti di base descritte nel precedente capitolo e schematizzate in figura 7, la Parte Comune e la Parte Specifica [BFMT05a].
2.2.2.1 Composizione della Parte Comune

La parte comune dellAdS si compone di tre elementi, ciascuno consistente di uno o pi elementi della specifica formale ed opzionalmente da quella semiformale. Tali elementi sono: la Specifica dellInterfaccia, la Specifica delle Conversazioni ed il Riferimento alla Semantica dellInformazione Veicolata.

54

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

Figura 7: Esempio di struttura della Parte Comune di un Accordo di Servizio (fonte: [DanSal08b])

la Specifica dellInterfaccia formalizzata in una rappresentazione su due livelli di astrazione, uno dei quali si differenzia in relazione allerogatore e al fruitore. Essa consiste in tre documenti, tutti resi nel linguaggio WSDL versione 1.1. Nello specifico, essi sono: (i) WS_Concettuale,
WS_ErogatoreLogico,

la descrizione

dellinterfaccia del servizio a livello di scenario di coordinamento; (ii) che descrive la parte di competenza dellerogatore in ma per la parte di competenza del fruitore. termini di scambio elementare di messaggi; (iii) WS_FruitoreLogico, analogo a
WS_ErogatoreLogico,

Questi tre documenti rappresentano la specifica astratta del servizio, pertanto sono scevri di informazioni relative allimplementazione dello stesso e rappresentano per questo una componente dellAdS potenzialmente riusabile. Nei termini del linguaggio WSDL 1.1, questo significa che gli unici costrutti di primo livello (vale a dire figli dellelemento radice) ammissibili sono import,
types, message

e portType. Altri costrutti quali binding e service non

compaiono, in quanto descrivono aspetti implementativi del servizio (ad esempio binding o URI fisico ove reperire limplementazione) che dipendono

55

2.La semantica per l'interoperabilit dei servizi in SPCoop strettamente dalla coppia <erogatore, fruitore> e vanno quindi dettagliati nella parte specifica.

la Specifica delle Conversazioni descrive, in maniera compatta, tutte le conversazioni supportate dal servizio. Come per la specifica dellinterfaccia, anche questa presenta tre documenti che descrivono le conversazioni rispettivamente a livello concettuale, logico lato erogatore e logico lato fruitore. Il formalismo adottato per questi documenti un dialetto di XML appositamente definito per SPCoop, noto come WSBL (Web Service Behavior Language), che rappresenta la Macchina a Stati Finiti che descrive le conversazioni.

il Riferimento alla Semantica dellInformazione Veicolata consiste in uno strato di integrazione con la Specifica dell'Interfaccia, che la arricchisce di potenza semantica per mezzo di riferimenti a determinate entit di un modello che definisce la semantica dellinformazione veicolata dal servizio. Nel modello di cooperazione prevista la nozione di semantica dei servizi, la quale formalizzata nel servizio SICA di Catalogo Schemi ed Ontologie. Non incoraggiata la definizione di modelli semantici che siano inclusi direttamente nell'Accordo di Servizio.

2.2.2.2 Composizione della Parte Specifica

La parte specifica di un AdS comprende tutti quei documenti finalizzati alla definizione dei livelli implementativi, delle caratteristiche di sicurezza e dei livelli di qualit del servizio. Le componenti, formali o meno, di questa parte dell'AdS sono elencate di seguito:

56

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

Figura 8: Esempio di struttura della Parte Specifica di un Accordo di Servizio (fonte: [DanSal08b])

La Specifica dei Porti di Accesso descrive gli aspetti di livello fisico del servizio e si compone di due documenti WSDL (uno per lerogatore ed uno per il fruitore) analoghi a quelli che descrivono l'AdS sul piano logico nella parte comune, ma completi dei costrutti binding e service. Pu essere considerata la Specifica dellInterfaccia della parte specifica di un AdS. Si ricorda, a tale proposito, che la base per limplementazione di un servizio in SPCoop rappresentata dalla Busta eGov, il che pone determinate restrizioni in termini dei possibili binding fra interfaccia ed implementazione.

la Specifica dei Livelli di Servizio definisce i livelli e le caratteristiche di prestazioni concordate tra erogatore e fruitore, ed il modo di valutarli e misurarli. Tale specifica alla base della valutazione, durante lesercizio e la gestione, delladerenza ai livelli garantiti. Si tratta di una specifica opzionale, cos come non vi obbligo di renderla formale o meno. Pu essere espressa in

57

2.La semantica per l'interoperabilit dei servizi in SPCoop un documento in testo libero ovvero in uno dei linguaggi XML proposti allo scopo, quali WSLA (Web Service Level Agreement, v. 1.0) o WS-Agreement (v. 1.1). La specifica, sia essa formalizzata o meno, deve definire sia le componenti necessarie a definire gli SLA, che gli SLA veri e propri per la sua coppia <erogatore, fruitore>; di qui la pertinenza alla parte specifica dellAdS.

la Specifica delle Caratteristiche di Sicurezza, infine, descrive le caratteristiche di sicurezza supportate e richieste dal servizio.

2.3. Il ruolo del Catalogo Schemi ed Ontologie in SPCoop

In linea di principio, un soggetto titolare di un Dominio di Amministrazione potrebbe, in corso di definizione di un servizio e del relativo Accordo, includere nello stesso della documentazione, che pu essere non formalizzata oppure espressa in OWL e XSD, che qualifichi e descriva il contesto applicativo. Un approccio del genere, tuttavia, porrebbe una serie di limitazioni alle potenzialit offerte dalle ontologie e dagli XML Schema. In primo luogo, essendo la semantica del servizio confinata all'interno della descrizione dello stesso, sarebbe reso impossibile il riuso di concetti assimilabili ai modelli semantici che descrivono altri domini. In secondo luogo non sarebbe favorita l'efficienza del reperimento di servizi interessanti, poich sarebbe impossibile, per un soggetto che volesse ricercare servizi per mezzo di query semantiche, derivare i parametri d'interrogazione per un contesto di riferimento chiuso. Ragioni come queste hanno motivato la scelta, in fase di definizione del modello di SPCoop, di far confluire tutta la conoscenza formalizzata per le Pubbliche Amministrazioni partecipanti in un repository centralizzato ed aperto alla consultazione da parte di tutti i soggetti abilitati ad operare in SPCoop [ABFM+05]. Questo repository accessibile tramite i servizi SICA di Catalogo Schemi ed Ontologie [BFMT05c], gi introdotti nel precedente capitolo. Il Catalogo un componente software che offre funzionalit per: 58 memorizzare ontologie e schemi concettuali, ai quali si presume facciano

2.La semantica per l'interoperabilit dei servizi in SPCoop riferimento gli Accordi di Servizio definiti per i servizi che si appoggiano su questi schemi ed ontologie per la definizione del dominio applicativo e dei dati veicolati; gestire il ciclo di vita degli oggetti memorizzati, ovvero funzionalit di navigazione, modifica, creazione ed estensione di ontologie e schemi concettuali, nonch di trasformazione tra di essi (se possibile); interrogare il Catalogo stesso e ragionare sugli elementi in esso contenuti (ossia derivare le conseguenze logiche dei fatti in essi asseriti), a fini di scoperta dei servizi candidati alla fruizione. Come per tutti i SICA, il Catalogo integrato sul piano architetturale nel sistema di cooperazione, pertanto tutte le sue funzionalit vengono esposte come Web Service. Tuttavia, anche previsto che le funzionalit di consultazione per lutente generico e le funzioni di utilit per utenti interni responsabili di gestione, monitoraggio e sicurezza siano esposte sotto forma di interfaccia web, accessibile mediante web browser.

2.4. Annotazione semantica di un Accordo di Servizio e di uno schema XML concettuale

Nel descrivere la struttura dell'Accordo di Servizio si puntualizzato che, delle sue due componenti, soltanto la parte comune foriera di riferimenti alla semantica, cio ad un insieme di entit che qualificano il servizio esposto sulla base del significato delle informazioni che esso veicola. Sul piano concettuale, questo significa introdurre un nuovo meta-livello in cima allo strato prettamente infrastrutturale del Web Service. Nella pratica, la definizione di questo strato pu senz'altro comprendere l'inclusione di ulteriore documentazione all'interno della componente non formalizzata dell'AS, ma questa pratica, da sola, non fornirebbe adeguato supporto a procedimenti semiautomatici per la pubblicazione, composizione, discovery o esecuzione del servizio. Formalmente, la modalit prediletta per definire questo layer semantico consiste nell'annotazione dei documenti che compongono la specifica formale della parte 59

2.La semantica per l'interoperabilit dei servizi in SPCoop comune [VetLen08]. Annotare semanticamente una risorsa pu essere visto come la definizione di una o pi asserzioni che rappresentano il raccordo tra elementi di quella risorsa e membri di una base di conoscenza. L'architettura di SPCoop prende spunto da questa intuizione e stabilisce che il dominio di tali annotazioni semantiche siano i documenti WSDL e XSD che fanno parte della specifica delle interfacce della parte comune. Il formalismo proposto per la definizione di queste annotazioni lo standard SAWSDL (Semantic Annotations for WSDL and XML Schema), divenuto W3C Recommendation nell'agosto 2007 [FarLau07], che ad oggi rappresenta una delle pi robuste convenzioni in materia di Semantic Web Service [Akk07]. Il linguaggio SAWSDL consta di una serie di estensioni per la sintassi standard WSDL, applicabili senza necessit di alterare informazioni preesistenti sul documento. Queste estensioni sono definite in due modalit diverse per garantire la retrocompatibilit con la versione 1.1 della specifica WSDL, con particolare riguardo alle restrizioni sulla grammatica e ai costrutti utilizzati per definire i messaggi scambiati dai servizi.

2.4.1. La specifica SAWSDL per l'annotazione dell'Accordo di Servizio

La specifica SAWSDL stabilisce due tipologie di annotazione semantica di documenti WSDL e XSD: (i) l'attributo sawsdl:modelReference e (ii) la coppia di attributi sawsdl:liftingSchemaMapping e sawsdl: loweringSchemaMapping, dove il prefisso
sawsdl

da

considerarsi

legato

al

namespace

http://www.w3.org/ns/sawsdl. Le finalit di queste estensioni sono illustrate di seguito:

l'attributo modelReference utilizzato per associare gli elementi di un documento WSDL o XSD con uno o pi concetti in un determinato modello semantico;

gli attributi liftingSchemaMapping e loweringSchemaMapping sono indicati

60

2.La semantica per l'interoperabilit dei servizi in SPCoop per problematiche successive all'individuazione di un servizio (post-discovery) e servono ad effettuare trasformazioni di dati da strutture XML verso un modello semantico e viceversa. Si utilizzano, ad esempio, a supporto di operazioni di matching, per far fronte al problema di input e output strutturati in maniera non conforme al modello semantico. Si tratta di un'estensione pensata apposta per gli elementi di tipo XML Schema, poich essi vengono utilizzati per descrivere i tipi di dato convogliati nel flusso informativo dei sevizi. Il modello SPCoop prevede che ogni singolo dominio amministrativo sia responsabile della definizione di un'ontologia, detta per l'appunto ontologia di dominio, che descriva almeno i servizi esposti dal dominio stesso. Ci non significa che l'ontologia di dominio debba necessariamente essere autocontenuta, cio che gli assiomi che ne fanno parte coinvolgano esclusivamente entit definite nell'ontologia stessa; anzi auspicabile il contrario, vale a dire che le ontologie di dominio costituiscano solo l'ultimo livello di una struttura stratificata in base al livello di astrazione delle sue entit, e che favorisca il riuso delle componenti pi astratte, situate ai livelli pi bassi di questa struttura. Il contesto per il riuso dei modelli semantici fondamentali garantito dall'accesso al servizio di Catalogo Schemi ed Ontologie. Poich la responsabilit di definire l'ontologia di dominio ricade sullo stesso soggetto che ne espone i servizi, si pu assumere che non si ponga il problema di omologare tipi di dato discordi rispetto al modello semantico di riferimento. Pertanto, nel seguito della presente trattazione si far esclusivo riferimento all'utilizzo dell'attributo sawsdl:modelReference, che costituir anche il punto cardine dell'applicativo oggetto della tesi. Il seguente frammento di codice XML, estratto dallo Schema XML che descrive la sintassi SAWSDL, descrive l'attributo modelReference:
<xs:attribute name="modelReference" type="listOfAnyURI" /> <xs:simpleType name="listOfAnyURI"> <xs:list itemType="xs:anyURI"/> </xs:simpleType>

61

2.La semantica per l'interoperabilit dei servizi in SPCoop Dunque l'attributo modelReference ammette come valore un insieme di identificatori URI in numero maggiore o uguale a zero, separati da spazi. Ciascuno di questi URI punta ad un determinato concetto in un modello semantico ed ha lo scopo di fornire un valore aggiunto per interpretare il significato del costrutto che annotato. necessaria a questo punto una precisazione: il fatto che un URI punti ad un determinato concetto non implica la risolubilit di tale URI in una risorsa fisicamente disponibile sul web. Si tratta semplicemente di un meccanismo per identificare in maniera univoca una certa entit ed inquadrarne il dominio di appartenenza, ma che non fornisce un metodo per accedere concretamente ad un documento che qualifichi il modello semantico cui associata a tale entit. In altre parole, SAWSDL non definisce alcun metodo per dereferenziare un model reference, bench sia preferibile che esso si risolva in un documento contenente la definizione del concetto stesso. Nel contesto di SPCoop, i servizi di Catalogo Schemi ed Ontologie permettono di superare questo ostacolo, poich il Catalogo mantiene e gestisce in maniera trasparente il mapping tra URI logici ed URL fisici presso cui reperire i documenti che formalizzano il relativo modello (che possono essere ontologie OWL cos come XML Schema o persino diagrammi UML delle classi). Pertanto possibile fruire di un servizio SICA che implementi un caso d'uso nel quale l'utente ricerchi il documento che definisce un'entit semantica a partire da un identificatore della stessa. Riguardo l'ammissibilit di annotazioni multiple per uno stesso costrutto WSDL o XSD, esplicitate da un insieme di URI di cardinalit maggiore di uno, secondo la specifica SAWSDL si intende che tutte le annotazioni si applichino in contemporanea. Al di l di questo, non definita nessun'altra relazione logica fra di esse. Una possibilit che, per favorire l'interoperabilit fra diversi sistemi, queste annotazioni identifichino lo stesso concetto espresso in diversi linguaggi di rappresentazione della semantica.
2.4.1.1 L'annotazione di descrittori WSDL 1.1 via model reference

Di seguito sono esposti i dettagli dei vari elementi di WSDL versione 1.1 che

62

2.La semantica per l'interoperabilit dei servizi in SPCoop supportano l'annotazione semantica tramite model reference, come da specifiche W3C. Tutti gli elementi sottoelencati si assumono essere legati rispettivamente con il namespace http://schemas.xmlsoap.org/wsdl/. In linea teorica, gli elementi di WSDL 1.1 che possono essere estesi con l'attributo aggiuntivo modelReference sono: part, portType e operation. Sono tuttavia necessarie alcune considerazioni aggiuntive in merito a ciascuna tipologia di elemento. Un portType pu essere annotato per categorizzarlo rispetto a qualche modello, o per specificarne aspetti comportamentali. importante per notare che l'attributo
modelReference

non si propaga ad eventuali portType che estendono quello annotato,

mentre si applica implicitamente agli elementi di tipo port che lo istanziano (e che saranno indicati nella parte specifica dell'Accordo di Servizio). Quanto ad operation, SAWSDL prevede l'estensibilit di questo elemento; tuttavia la specifica WSDL 1.1 pone una restrizione secondo cui esso non ammette attributi aggiuntivi al di fuori di quelli indicati nella specifica WSDL. Per annotare un'operazione in WSDL 1.1 bisogna annidare in esso un ulteriore elemento figlio
<sawsdl:attrExtensions>, sawsdl:modelReference. attrExtensions

sua

volta

provvisto

dell'attributo

fondamentale ricordare, a questo proposito, che l'elemento

non deve essere utilizzato per quei tag per cui sia gi prevista

l'estensione per mezzo di attributi. Elementi di tipo part possono solamente trovarsi annidati in altri di tipo message. In WSDL 2.0 questa particolare sintassi stata poi abbandonata, e i messaggi vengono esplicitati come nodi XML Schema di tipo element. Non prevedono invece annotazione semantica gli elementi binding, service e
port,

poich fanno riferimento all'implementazione dei servizi e peraltro rimangono di

esclusiva competenza delle parti specifiche degli Accordi di Servizio (le quali, lo si ricorda, non prevedono alcuna definizione del livello semantico). 63

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

2.4.1.2 L'annotazione di schemi XSD via model reference

Gli elementi degli schemi XSD i cui attributi possono essere estesi con
modelReference

sono: simpleType, complexType, attribute ed element. Le

modalit di annotazione sono identiche per tutti i tipi di elemento, che possono essere estesi con l'attributo aggiuntivo modelReference. Nel caso in cui si annotino elementi di tipo simpleType o complexType, si deve intendere che tali annotazioni si propaghino a tutte le componenti XSD che dichiarino attributi o elementi il cui tipo quello del simpleType o del complexType annotato. Nel caso, inoltre, di dichiarazioni di complexType (che rappresentano tipi di dato composti o sottoposti a vincoli strutturali), la specifica SAWSDL definisce due modalit per annotare semanticamente questi tipi: (i) una detta top-level, in cui l'attributo
modelReference

appeso alla dichiarazione del complexType e (ii) una modalit

bottom-level, ovvero scendendo al livello dei suoi membri e annotando le corrispondenti dichiarazioni di attributo o di elemento. Le annotazioni effettuate nelle due diverse modalit non sono mutuamente esclusive e sono da considerarsi indipendenti l'una dall'altra: in altre parole, non definita una regola per cui le annotazioni top-level debbano propagarsi ai membri del tipo composto, anche se la libera interpretazione delle annotazioni pu stabilire altrimenti.

2.4.2. Riferimenti semantici in SPCoop

Si affermato nella sezione precedente che in SAWSDL non viene fatta alcuna assunzione sul formalismo utilizzato per la rappresentazione della conoscenza cui fanno riferimento le annotazioni di un WSDL o XSD. L'unico requisito che le primitive di questa base di conoscenza siano individualmente e univocamente identificabili per mezzo di Uniform Resource Identifier (URI) [Ber05]. Ci si pu quindi interrogare su quali delle forme di rappresentazione della conoscenza esistenti abbiano sufficiente potere espressivo da poter essere efficacemente impiegate nel Sistema Pubblico di Cooperazione.

64

2.La semantica per l'interoperabilit dei servizi in SPCoop Le specifiche SPCoop emesse nel 2005 inquadrano XML Schema (XSD), RDF Schema (RDFS) e Web Ontology Language (OWL) quali linguaggi adeguati a modellare la conoscenza associata al dominio della Pubblica Amministrazione. I documenti che utilizzano i costrutti dei linguaggi sopra elencati, redatti in un'opportuna sintassi, sono parte di un repository, il Catalogo Schemi e Ontologie, che si integra con il Registro SICA Generale per fornire supporto, a livello sia di categorie concettuali che di entit concrete, al modello di dati di SPCoop. previsto dalle specifiche del W3C che i riferimenti semantici possano puntare ad elementi all'interno del documento WSDL stesso, nel caso in cui esso venga esteso con un modello semantico embedded, ad esempio per mezzo della sintassi RDF/XML. Questa possibilit non stata presa in considerazione ai fini di SPCoop, in quanto parso naturale, in fase di definizione, disaccoppiare le due componenti del modello logico nelle quali la semantica dei servizi viene rispettivamente definita e riferita, convogliando quindi l'intera base di conoscenza all'interno del Catalogo Schemi ed Ontologie [BFMT05c].
2.4.2.1 Ontologie di dominio

Le ontologie, intese come rappresentazioni formali di un insieme di concetti relativi ad un particolare dominio, costituiscono quella parte della base di conoscenza della PA su cui si focalizza la sperimentazione oggetto di questa tesi. Non obiettivo del presente studio trattare i metodi e criteri per definire e valutare una buona ontologia. Tuttavia, utile fornire un esempio di possibili strategie e buone pratiche applicabili al contesto della PA italiana. Per fare questo ci si rif a quanto accennato in sede di definizione di che cosa sia un'ontologia computazionale. stata fatta menzione dell'esistenza di numerosi gruppi di lavoro che si sono costituiti per formalizzare in ontologie di riferimento l'insieme delle conoscenze di precisi domini applicativi. Questo un approccio possibile, e generalmente incoraggiato, anche nel contesto della Pubblica Amministrazione e porta alla definizione delle cosiddette ontologie di dominio.

65

2.La semantica per l'interoperabilit dei servizi in SPCoop In primo luogo si pu asserire che i processi di definizione delle ontologie di dominio e degli Accordi di Servizio siano indipendenti fra loro, sia concettualmente che sulla linea temporale. Allo stesso tempo, non esclusa una strategia bottom-up per la definizione di ontologie che parta direttamente da quei concetti che ruotano attorno all'Accordo di Servizio, sino a catalogare e strutturare i concetti propri del dominio applicativo. Questa pratica consente di minimizzare il rischio di concludere il processo di definizione avendo formalizzato un'ontologia di livello troppo alto per essere referenziata in maniera precisa ed esaustiva dai servizi che ne faranno uso [GanPre06]. Una strategia basata su questi principi quella adottata per definire l'insieme di ontologie del caso di studio preso in esame per questa tesi, vale a dire il progetto di Interoperabilit e Cooperazione Applicativa tra le Regioni (ICAR)41. In esso si partiti dagli aspetti rappresentativi di un servizio applicativo in SPCoop, per poi suddividerli in dati, processi e servizi veri e propri e costruire delle ontologie parziali sottese a questi: lontologia dei dati scambiati nellambito del dominio di cooperazione (che rappresenta l'ontologia di dominio vera e propria) consente di dare la definizione formale del significato di questi dati e quindi consente di specificarne linterpretazione autentica; lontologia dei servizi consente di generalizzare linsieme degli stessi rispetto a opportune classi di servizio sul cui significato non ci sono ambiguit; infine lontologia dei processi mira a generalizzare linsieme degli stessi rispetto ad opportune classi di processo non ambigue.42
2.4.2.2 Raccordo tra OWL e riferimenti in SAWSDL

L'unico requisito formale per annotare semanticamente un documento secondo la specifica SAWSDL che i concetti semantici cui si fa riferimento siano identificabili tramite URI. Questo requisito soddisfatto da tutti i concetti in OWL espressi tramite assiomi che dichiarano propriet, individui e classi non anonime, dichiarate cio esplicitandone un riferimento per mezzo di attributi RDF quali rdf:ID o rdf:about. Questi due attributi si differenziano nel fatto che ammettono come valore,
41 http://www.progettoicar.it/home.aspx 42 [VetLen08], p. 150

66

2.La semantica per l'interoperabilit dei servizi in SPCoop rispettivamente, un valido name token XML e un URI (quest'ultimo anche espresso in sintassi abbreviata per mezzo di nomi qualificati, o QName [Wal04]). La certezza di poter ricondurre questi identificatori a degli URI come richiesto dalla specifica data dalla necessit di risolvere possibili ambiguit fornendo precise indicazioni sul dominio dei termini utilizzati. Per fare questo, si include una componente standard delle ontologie che, indipendentemente dal formalismo con cui esse sono rese, un insieme di dichiarazioni di namespace XML. Il seguente esempio, basato nuovamente sulla sintassi RDF/XML, illustra quanto spiegato:
<rdf:RDF xml:base xmlns xmlns:co xmlns:ads xmlns:owl xmlns:rdf xmlns:rdfs xmlns:xsd = = = = = = = = "http://progettoicar.it/2008/06/owl/co" "http://progettoicar.it/2008/06/owl/co#" "http://progettoicar.it/2008/06/owl/co#" "http://www.lego-lab.it/icar/ads#" "http://www.w3.org/2002/07/owl#" "http://www.w3.org/1999/02/22-rdf-syntax-ns#" "http://www.w3.org/2000/01/rdf-schema#" "http://www.w3.org/2001/XMLSchema#">

Per prima si pu notare una dichiarazione standard di base URI in XML, che fornisce un riferimento generale per l'ontologia. In mancanza di tale dichiarazione, o se non ci si trova in un contesto XML-based, possibile servirsi dell'attributo rdf:about nello header dell'ontologia. da notare che l'URI fisico ove reperire il documento un base URI ammissibile ma non necessario. La seconda e terza dichiarazione identificano il namespace associato con questa ontologia. La seconda indica il namespace di default: ogni nome qualificato senza prefisso fa riferimento all'ontologia corrente; la terza lega il namespace dell'ontologia con il prefisso co. La quarta dichiarazione lega il prefisso ads ad un altro namespace, con la previsione di far riferimento a concetti dell'ontologia con quel namespace. La quinta assegna il prefisso convenzionale al vocabolario OWL (che comprende vari costrutti tra i quali la classe base owl:Thing, di cui ogni altra sottoclasse). Le ultime tre dichiarazioni sono dovute alla dipendenza di OWL da costrutti definiti in RDF e RDF Schema, nonch da datatype di XML Schema. 67

2.La semantica per l'interoperabilit dei servizi in SPCoop Stabilito quali sono i possibili concetti di un'ontologia che si possono isolare per un loro impiego nelle annotazioni semantiche di Accordi di Servizio, nei capitoli successivi si descriveranno le strade intraprese per presentare tali concetti all'utente finale. bene precisare che questi concetti, presi tutti insieme al di fuori del contesto creato dagli assiomi che li riguardano, non sono sufficienti per dare all'utente un adeguato supporto alle decisioni nella scelta dei concetti che meglio rispecchiano il significato delle informazioni veicolate dai servizi. Sar opportuno, in sede di progettazione e sviluppo dell'interfaccia utente, valutare a quali costrutti non critici (ad esempio specificazioni di dominio e range, classi disgiunte o equivalenti) dare opportuna forma grafica. Nel procedimento si terr conto sia delle best practices di presentazione delle ontologie, nella letteratura come nelle esistenti applicazioni, sia delle possibilit e dei limiti di un contesto come quello delle Rich Internet Applications [All02].

2.5. Criticit e problematiche nel supporto all'annotazione semantica in SPCoop

Prima di affrontare la descrizione dello stato dell'arte in materia di strumenti a supporto dell'annotazione semantica secondo lo standard SAWSDL, utile riassumere alcuni requisiti fondamentali per la sua messa in pratica in SPCoop: 1. Ogni titolare di un Dominio che intenda definire un servizio deve, in fase di definizione del relativo Accordo, poter annotare i documenti WSDL nella specifica delle interfacce della sua parte comune. 2. La specifica di annotazione richiesta l'attributo modelReference cos come applicabile alla versione 1.1 dello standard WSDL. 3. La fonte delle annotazioni, vale a dire le entit cui fa riferimento il valore di
modelReference,

devono essere concetti non anonimi definiti in ontologie

correntemente registrate presso il Catalogo Schemi ed Ontologie.

68

2.La semantica per l'interoperabilit dei servizi in SPCoop 4. Deve essere possibile annotare, sempre nel rispetto delle specifiche SAWSDL, anche documenti di tipo XML Schema (XSD), sia che si trovino nella parte comune di un AdS per specificarne i tipi di dato, sia che si tratti di schemi concettuali registrati nel Catalogo Schemi ed Ontologie. Aver focalizzato su questi punti utile per l'estrazione di determinati criteri valutativi di merito, che sono stati poi impiegati per suffragare la tesi di inadeguatezza delle applicazioni esistenti per l'annotazione semantica in SPCoop. Dal punto 1 emerge la necessit di uno strumento che sia disponibile a tutte le Amministrazioni partecipanti, in ogni momento e da ogni localit. L'eterogeneit dei domini della PA italiana, di cui necessario tenere conto in virt dei processi di decentramento amministrativo e di delega delle modalit interne di esercizio delle funzioni, porta a due importanti conclusioni: la prima che si ritiene necessaria l'indipendenza dalla piattaforma hardware e software, poich non ne definita una di riferimento per tutti i soggetti della PA. stabilito che ognuno di essi avr accesso ad un applicativo, il client SICA, tramite il quale usufruire, nei prescritti limiti e privilegi, dei Servizi Infrastrutturali per la Cooperazione e l'Accesso [BFMT05b]; tuttavia questo strumento client non adibito a supportare attivamente le annotazioni SAWSDL. L'altra conclusione che, mentre ragionevole assumere che i soggetti cui demandato il compito di definire gli AdS siano esperti del dominio applicativo in cui operano, non si ha per la garanzia che essi siano ontology engineers, n che abbiano nozioni specifiche in materia di web semantico. Ne discende che semplicit dell'interfaccia, indipendenza dalla piattaforma ed ampia disponibilit saranno tre criteri su cui si fonder la nostra valutazione degli applicativi esistenti. I punti 2 e 4 sono alla base di importanti considerazioni di carattere tecnico: per essere utile nel contesto di SPCoop, uno strumento di annotazione deve supportare completamente WSDL versione 1.1 e consentire anche di annotare documenti XSD indipendenti, ossia che abbiano una dignit propria nel sistema, a prescindere dall'esistenza o meno di descrittori WSDL che li importino per definire i tipi dei propri dati. 69

2.La semantica per l'interoperabilit dei servizi in SPCoop Dal punto 3, infine, emerge l'esigenza di impedire all'utente, in corso di annotazione, di compiere errori grossolani che possono spaziare dall'aggiunta di annotazioni che non siano URI ben formati o che non identifichino concetti estratti da un'ontologia del Catalogo, al tentativo di compiere operazioni non conformi alla specifica SAWSDL, fino addirittura a modifiche che possano rompere la sintassi XML del documento. La strategia per ovviare a queste eventualit inequivocabilmente quella di celare all'utente finale la complessit derivante dai formalismi di XML e/o di altri linguaggi usati per rappresentare le ontologie (KRSS2, Turtle, etc.), nonch di URI correttamente definiti. Si rende pertanto obbligatorio presentare all'utente queste risorse in una forma conveniente che resista a tentativi di effettuare azioni improprie, seguendo quindi il paradigma di interfaccia WYSIWYM (What You See Is What You Mean, vale a dire che la manipolazione delle risorse deve essere strutturata concentrandosi sul loro significato anzich sull'estetica, come invece avviene in WYSIWYG [Pow00]). Un'altra conseguenza del punto 3 che la capacit di verificare in tempo reale la corrispondenza fra entit del Catalogo Schemi ed Ontologie e gli URI utilizzati per l'annotazione, siano essi definiti dall'utente o preesistenti, rappresenta un fattore significativo. Trattandosi di un aspetto strettamente legato all'architettura di interoperabilit presa in esame, non stato preso in considerazione nel valutare l'attuale offerta applicativa. Per questa ragione, e perch al momento del presente studio il servizio di Catalogo non risulta ancora disponibile, questo requisito stato classificato come opzionale anche a fronte delle funzionalit richieste per l'applicazione oggetto della tesi. Tuttavia, il supporto a questa caratteristica diviene imperativo nel momento in cui si intenda consentire l'annotazione anche a mezzo di un'interfaccia text-editor. Le soluzioni disponibili, estratte dal rapporto W3C sulle attuali implementazioni SAWSDL, sono state valutate con riferimento ai criteri sopra descritti. In tutti i casi si tratta di applicazioni che per l'interfaccia si basano sul framework dell'ambiente di sviluppo Eclipse43 e sono di seguito elencate:

43 http://www.eclipse.org

70

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

Semantic Tools for Web Services44 un insieme di plugin per Eclipse che si basano su annotazioni semantiche WSDL-S per il matching, la composizione e la scoperta di Web Service.

Radiant45 un plugin Eclipse che mira a fornire un'interfaccia grafica userfriendly per l'annotazione semantica secondo le specifiche WSDL-S e SAWSDL.

WSMO Studio46 un ambiente open source di modellazione di Web Service e processi aziendali semantici, basato sulla gi citata ontologia di riferimento WSMO. Tutte queste proposte di soluzione si sono rivelate inadeguate alle necessit di

SPCoop in base ai sopracitati criteri. In particolare, non stato possibile prendere in considerazione la prima proposta che, pur vantando il supporto esclusivamente per WSDL 1.1, si concentra unicamente sullo standard Web Service Semantics (WSDL-S), sviluppato da IBM e il laboratorio LSDIS [AFMN+05], che rappresenta il progenitore di SAWSDL. Per quanto concerne gli altri due candidati, se ne sintetizza la valutazione nella Tabella 3. In termini di supporto a WSDL 1.1, nessuno dei due candidati si dimostrato in grado di gestire in maniera soddisfacente l'elemento attrExtensions, utilizzato per annotare operazioni. Di fatto, questo elemento di estensibilit supportato attivamente solo da Radiant; tuttavia, in sede di testing emerso che tale elemento non correttamente gestito, poich ad annotazioni multiple corrisposta la proliferazione di nodi di tipo attrExtensions, ciascuno con un unico URI come valore dell'attributo
modelReference,

con un concreto rischio di ridondanze fra tali URI, ritenute non

significative nella specifica SAWSDL.

44 http://www.alphaworks.ibm.com/tech/wssem 45 http://lsdis.cs.uga.edu/projects/meteor-s/downloads/index.php?page=1 46 http://www.wsmostudio.org

71

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

Autori Piattaforme supportate Supporto per WSDL 1.1

WSMO Studio
WSMO Working Group limitato (solo elementi comuni
con WSDL 2.0)

LSDIS limitato (solo elementi comuni

con WSDL 2.0 pi l'elemento attrExtensions)

Linux, Mac OS X, Windows Linux, Mac OS X, Windows

Supporto per XSD stand-alone Gestione dipendenze ontologie Visualizzazione strutturata di ontologie Visualizzazione strutturata di WSDL/XSD Paradigma di interazione fail-safe

s limitata s s s

no limitata s s s

Tabella 3: Comparazione fra applicazioni SAWSDL esistenti Dal punto di vista dell'interfaccia, l'esperienza si rilevata pi soddisfacente in corso di utilizzo di WSMO Studio, soprattutto per via dell'intuitiva rappresentazione ad albero di un documento WSDL che si differenzia notevolmente nel rendering dei vari costrutti supportati, inclusi gli elementi di tipo XML Schema (che tuttavia sono ammessi solo in un documento WSDL). Positivo anche il modello seguito per la presentazione delle ontologie, improntato sulla gerarchia delle classi arricchita con i nodi delle loro istanze, con propriet ed assiomi al seguito. Quanto a Radiant, la sua maggiore flessibilit in termini di supporto a WSDL e XSD inficiata da un'interfaccia utente di scarsa risposta e da una rappresentazione poco intuitiva dei documenti da annotare. Al contrario, la presentazione delle ontologie beneficia di una separazione strutturata delle categorie di concetti, per cui individui e propriet compaiono nei confini delle loro relazioni con le classi (i cosiddetti slot) visualizzate in forma gerarchica. La carenza di un appropriato supporto all'integrazione di documenti WSDL 1.1 e XSD con riferimenti semantici estrapolati da una o pi ontologie stata alla base della necessit di disporre di uno strumento ad hoc, che conservasse le qualit dello stato dell'arte in termini di interazione dell'utente finale, ma che al tempo stesso integrasse le 72

2.La semantica per l'interoperabilit dei servizi in SPCoop funzionalit richieste e rendesse le risorse accessibili per mezzo di azioni utente essenziali. In aggiunta a tali necessit, si pensato di dare a questa applicazione un valore aggiunto derivante dalla sua disponibilit in veste di Rich Internet Application (RIA), quindi come uno strumento fruibile sul web in qualsiasi momento, che un soggetto amministrativo possa mettere a disposizione come servizio aggiuntivo a quanti gi ne esistono a supporto dei servizi infrastrutturali SICA e degli strumenti necessari all'authoring degli Accordi di Servizio.

73

3.La soluzione proposta

3. La soluzione proposta
I punti critici esposti alla fine del precedente capitolo, particolarmente in relazione alla carenza di un'offerta applicativa che soddisfacesse tutti i requisiti, sia funzionali che di user-friendliness, hanno determinato l'obiettivo di offrire una soluzione alternativa e sempre disponibile che potesse integrarsi con il core business delle PPAA centrali e locali. Tale soluzione, che nel prossimo capitolo trover applicazione nel pacchetto software SASCHA e nelle sue dipendenze, stata progettata nell'ottica di focalizzarsi sugli obiettivi dell'utente finale in rapporto a quelle che sono le abilit che possiamo ragionevolmente assumere che egli possieda. Il capitolo si articoler lungo due direttrici di progettazione: la prima riguarda il design della soluzione e parte da una modellazione della classe di utenza sulla base degli obiettivi, dei ruoli e delle abilit, per poi proseguire con l'analisi dei casi d'uso e con la delineazione di massima dell'architettura modulare dell'applicazione; la seconda si concentrer esclusivamente sulla modellazione usage-centered dell'interfaccia grafica, che in questo contesto di Rich Internet Application [All02] destinata ad un bacino d'utenza eterogeneo, rappresenta un fattore di particolare criticit. importante precisare che il presente capitolo non esaurisce tutte le fasi di progettazione della soluzione, poich molto dipender dalle singole scelte implementative effettuate, per le quali si rimanda al prossimo capitolo. Le fasi di progettazione e sviluppo, infatti, si sono svolte non in un processo seriale, ma in una continua iterazione di emendamenti e approssimazioni successive, di pari passo con le scelte d'implementazione e con l'arricchimento dell'esperienza soggettiva acquisita nelle materie d'interesse.

3.1. Analisi e definizione dei requisiti funzionali

Innanzitutto di fondamentale importanza dichiarare l'obiettivo del progetto, inteso in senso stretto come lo stato finale atteso per le risorse coinvolte nel flusso 74

3.La soluzione proposta operativo dell'applicazione. A partire dalla precondizione che si abbia, annotata o meno, la specifica formale della parte comune di un Accordo di Servizio, possiamo porre la postcondizione che la stessa specifica formale si trovi in uno stato in cui: 1. tutti i documenti di tipo WSDL [CCMW01] o XSD [FalWal04] che compongono la specifica presentino elementi annotati secondo lo standard SAWSDL [FarLau07], per mezzo dell'attributo qualificato identificato come http://www.w3.org/ns/sawsdl/modelReference, in numero maggiore o uguale a zero; 2. tutte le annotazioni, oltre ad essere corrette in termini di rispetto della specifica SAWSDL, si compongono di soli URI riconducibili ad entit effettivamente registrate presso il Catalogo Schemi ed Ontologie [DanSal08a]; 3. opzionalmente, uno o pi nodi del documenti WSDL o XSD siano documentati in linguaggio naturale mediante gli elementi wsdl:documentation e
xsd:documentation,

annidati all'interno del nodo stesso e contenenti una loro

descrizione in testo libero. Si pu osservare che le propriet 1 e 3 della postcondizione possono essere entrambe soddisfatte fornendo un'implementazione dei linguaggi standard adottati per la specifica formale della parte comune di un Accordo di Servizio, nello specifico WSDL 1.1, XSD e l'estensione SAWSDL applicata ad entrambi i formati. Per quanto riguarda la seconda propriet, perch essa sia soddisfatta richiesto l'intervento di un attore esterno, il Servizio di Catalogo Schemi ed Ontologie. Esso deve mettere a disposizione, previa ricerca o esplicita richiesta, l'intera base di conoscenza registrata in SPCoop, sia come origine dei possibili valori per le annotazioni dell'AdS, sia come termine di riscontro per verificare che un AdS gi annotato non abbia riferimenti orfani, per i quali il concetto corrispondente stato ricollocato o non esiste pi. Nel periodo di tempo in cui stato svolto il presente studio, tale servizio non era disponibile, n sarebbe stato possibile utilizzarlo in veste di soggetto della PA accreditato presso SPCoop. Per questa 75

3.La soluzione proposta ragione, in fase di progettazione stata inclusa l'eventualit di poter accedere ad ontologie sia locali che disponibili sul web.

3.1.1. Modello dell'utente

In ragione dei requisiti e delle finalit dichiarate per il progetto, importante delineare le caratteristiche fondamentali attese dall'utente finale dell'applicazione, al fine di modellarlo sulla base del ruolo, degli obiettivi e delle nozioni che lo contraddistinguono. Come vedremo, alcune di queste caratteristiche discendono intrinsecamente dalle finalit del progetto stesso, mentre altre si possono desumere dal contesto applicativo. Bench i canoni del linguaggio UML affrontino la problematica della modellazione dell'utente dal punto di vista dei casi d'uso, le particolari restrizioni poste dal contesto di riferimento (interattivit ricca e nel contempo estremamente semplificata, deployment come strumento disponibile sul web, etc.) rendono necessaria un'analisi preliminare, a seguito della quale gli elementi inquadrati come obiettivi utente saranno scomposti in task che identificheranno i casi d'uso. Volendo formalizzare gli obiettivi dell'utente, necessario partire dalla finalit dell'applicazione, cos com' stata delineata all'inizio del capitolo. Questa pu essere scomposta in due sotto-obiettivi (o subgoal) fondamentali: 1. Il rispetto puntuale della specifica SAWSDL nel processo di annotazione: pur avendo ventilato l'ipotesi di effettuare annotazioni non normative di elementi WSDL tra cui binding e port, anche vero che tali elementi sono confinati entro la specifica delle interfacce nella parte specifica dell'AdS, la quale non destinata a convogliare riferimenti alla semantica. Fra i criteri con cui pu essere valutato il grado di soddisfazione di questo obiettivo, sono in evidenza: (i) l'impedimento, a livello di interfaccia utente, di annotare elementi che istanziano costrutti che non ammettono model reference, e le misure per le quali l'utente non sia indotto ad effettuare tali annotazioni errate; (ii) l'assenza di ridondanze 76

3.La soluzione proposta nel valore dell'annotazione per uno stesso elemento; (iii) la garanzia che gli elementi di un'annotazione siano URI sintatticamente validi, o in alternativa, che siano QName [Wal04] il cui prefisso correttamente legato ad un namespace. 2. La risolubilit delle annotazioni, ovvero l'effettiva corrispondenza fra ciascun membro del layer semantico ed uno e un solo concetto descritto in almeno un modello del Catalogo Schemi ed Ontologie. Mentre SAWSDL non richiede, ma implicitamente assume, che i riferimenti di tipo model reference possano ricondurre a concetti effettivamente formalizzati, prerogativa esplicita di SPCoop che i riferimenti alla semantica di un Accordo di Servizio siano coerenti con la base di conoscenza rappresentata dal Catalogo. Si danno due criteri con i quali possibile misurare la rispondenza a questo requisito: (i) la possibilit di passare, con una semplice azione d'interfaccia, a visualizzare rapidamente il modello semantico in cui dichiarato un particolare concetto o namespace; (ii) la differente rappresentazione di riferimenti orfani rispetto a quelli correttamente risolti. Si prevede che queste funzionalit siano garantite dal servizio di Catalogo, che potr essere interrogato per risolvere il mapping fra URI logici e indirizzi fisici. In assenza di disponibilit del servizio, il codominio del mapping saranno le ontologie locali e remote messe a disposizione dall'utente. Si premette al processo di modellazione che l'utente finale sia un soggetto che opera per conto di un organo della Pubblica Amministrazione italiana centrale o locale, che partecipa al Sistema Pubblico di Connettivit per conto di un dominio che eroga o fruisce di servizi applicativi. Non si tratta, quindi, di un soggetto cui demandata la gestione di servizi SICA o comunque di componenti infrastrutturali di SPCoop. Proprio questa distribuzione della classe di utenza, potenzialmente disomogenea sul fronte delle nozioni di partenza, ha fatto s che la progettazione si orientasse verso l'essenzialit e la semplificazione. possibile, ma non garantito, che l'utente finale abbia avuto un ruolo attivo nella definizione dell'ontologia del dominio applicativo presso cui opera. Tuttavia, anche possibile che non si tratti neppure di un ontology engineer, o comunque di un esperto di modellazione della conoscenza. Fra le possibili ragioni 77

3.La soluzione proposta perch questo si verifichi, se ne indicano le due pi probabili: 1. Nel ciclo di vita di un servizio, la fase precedente la pubblicazione del relativo Accordo di Servizio l'unica in cui entra in gioco l'operazione di annotazione semantica. Ci significa che essa indipendente dalla fase in cui stata definita e registrata l'ontologia di dominio (salvo ovviamente che essa debba precedere la fase di annotazione), pertanto la possibilit che i due task siano stati affidati a diversi soggetti da considerare. 2. Nel caso di un Accordo di Servizio Composto, esso pu essere definito e pubblicato da un soggetto esterno al dominio che ha costituito il relativo Accordo di Cooperazione. Questo soggetto esterno pu non avere avuto alcun ruolo nella definizione delle ontologie dei domini coinvolti. Si elencano ora le tipiche nozioni minime di partenza, organizzate in due categorie di massima, che si ritiene di poter assumere per l'end-user di riferimento:

Nozioni di modellazione:

Paradigma entit-relazione [Che76]. Analisi del flusso informativo (ad es. flow chart, UML sequence diagram [Amb04]).

Modellazione per mezzo di UML class diagram [Amb04]. Analisi dei requisiti di un servizio applicativo, sia in fase di discovery che di deployment.

Capacit di interpretazione dei casi d'uso.

Requisiti di dominio:

78

3.La soluzione proposta

Conoscenza della natura, sul piano semantico, dei servizi applicativi erogati dal soggetto della PA cui fa capo.

Analisi qualitativa dei servizi applicativi di cui fruisce, o dovrebbe poter fruire il soggetto della PA cui fa capo.

Padronanza della struttura e delle finalit dell'entit Accordo di Servizio. Accesso a quella parte del patrimonio documentale che consente di determinare le necessit, in termini di servizi richiesti, del dominio applicativo.

Le nozioni che sono state raggruppate fra quelle di modellazione costituiscono un insieme minimale di skills tale da sopperire ad un'eventuale carenza di conoscenze in campo di ingegneria e tecnologie della conoscenza, garantendo nel contempo un'interpretazione adeguata ed esaustiva delle ontologie di dominio. Assumendo che l'utente abbia delle qualifiche in termini di modellazione strutturata via diagrammi delle classi UML, si pu pensare di presentare un set di ontologie di riferimento con una vista strutturata, il cui scheletro una gerarchia delle classi membro. Il modo in cui sar articolata questa vista sar oggetto della fase di progettazione dell'interfaccia. Richiedendo nozioni di analisi che seguano il paradigma entit-relazione, si ha una base sufficientemente solida per dare forma agli assiomi che specificano le relazioni tra concetti, con particolare riferimento a quelli che coinvolgono propriet di oggetti e di datatype. Altre conoscenze, fra cui la modellazione ed analisi del flusso informativo, dei requisiti e dei connotati semantici di servizi applicativi (particolarmente quelli che il suo dominio applicativo intende esporre o utilizzare), sono necessarie per gli aspetti decisionali e di valutazione nel corso di utilizzo dell'applicazione. In altre parole, ovvio che l'utente debba poter entrare nel merito del significato dei servizi dei quali intende annotare gli Accordi e che sappia inquadrare le componenti, se non implementative, perlomeno concettuali e logiche dei documenti XML che compongono la parte comune di un Accordo di Servizio. La padronanza del linguaggio XML vero e 79

3.La soluzione proposta proprio non una prerogativa del progetto, in quanto esso finalizzato all'astrazione di oggetti formalmente rappresentati in questo linguaggio, esonerando l'utente dalla conoscenza dei relativi dialetti. Tutte queste considerazioni sono riassunte in un particolare diagramma delle classi UML applicato alla modellazione dell'utente, ispirato a [CheYus08].

Figura 9: Diagramma del modello utente Sulla base della distribuzione delle suddette nozioni, nonch dell'unica fase del ciclo di vita in cui entrano in gioco, stato identificato un unico possibile ruolo dell'utente. stato assegnato a tale ruolo il titolo di deployer, ossia di responsabile per il 80

3.La soluzione proposta dispiegamento del servizio e la pubblicazione del relativo Accordo. L'ambito di responsabilit di questo ruolo pu essere l'intera fase di definizione dell'Accordo di Servizio, come anche soltanto la fase di integrazione di esso con la componente semantica prima della pubblicazione: questo lasciato all'arbitrio di ciascun soggetto amministrativo.

3.1.2. Casi d'uso

Si prima stabilito che gli utenti dell'applicazione, in base agli obiettivi che si prefiggono e all'unicit della fase del ciclo di vita di un AdS in cui prevista l'annotazione semantica, possono essere classificati in un'unica tipologia. Si avr pertanto che, nei casi d'uso modellati di seguito, esister un solo attore umano, per chiarezza denominato Gestore Dominio PA. Altri soggetti che sono stati inquadrati come attori sono tutti quelli che possono essere interrogati in una qualche fase di esecuzione di un caso d'uso, quindi il Servizio di Catalogo Schemi ed Ontologie, il Servizio di Registro SICA , il web nel suo complesso ed il file system locale. Per facilitarne la lettura, il diagramma complessivo dei casi d'uso stato scomposto in una serie di moduli, ciascuno centrato su uno dei sottosistemi identificati dai casi d'uso di massima. Come punto di partenza stato isolato in figura 10 un caso d'uso che pu essere identificato con la seconda fase del ciclo di vita di un servizio applicativo in SPCoop: la pubblicazione sul Registro SICA del relativo Accordo di Servizio. chiaro che questo caso d'uso non pu prescindere dalla compilazione dell'AdS stesso, nella fase di definizione del servizio. Tuttavia, poich si tratta di due fasi ben distinte del ciclo di vita, i relativi casi d'uso sono presentati separatamente.

81

3.La soluzione proposta

Figura 10: Caso d'uso "Pubblica Accordo di Servizio" Si assumer che l'attore Gestore Dominio PA faccia parte del dominio responsabile della compilazione della parte comune, o perch titolare del servizio o perch delegato tale in uno scenario multi-erogatore. Alcuni dettagli sulla compilazione dell'AdS che non coinvolgono strettamente il processo di annotazione, fra cui la compilazione della parte specifica e la stesura dei WSBL per la specifica delle conversazioni, saranno per semplicit tralasciati e indicati con casi d'uso generici. I casi d'uso di cui si rimandano i dettagli a diagrammi successivi saranno indicati in colore scuro. La compilazione dell'Accordo di Servizio pu essere vista come il concorso dei due procedimenti di assemblaggio della parte comune e di quella specifica. Entrando nel dettaglio della prima, se ne mettono in evidenza gli aspetti formali quali la compilazione della specifica delle interfacce (nei linguaggi WSDL e XSD), delle conversazioni (in linguaggio WSBL) e dei riferimenti alla semantica dell'informazione veicolata (mediante annotazione della specifica delle interfacce). Questo scenario schematizzato in figura 11, ma nel seguito non si entrer nel merito n della formalizzazione delle interfacce e delle conversazioni, n della compilazione della parte specifica di un AdS.

82

3.La soluzione proposta

Figura 11: Caso d'uso "Compila Accordo di Servizio" Il processo di annotazione semantica della parte comune prevede che siano resi disponibili sul file system tutti i documenti che lo comporranno, inclusi quelli formalizzati in XML, tra i quali descrittori WSDL e schemi XSD. Questi documenti possono a loro volta contenere direttive d'importazione, eventualmente ricorsive, di altri schemi XSD disponibili localmente o anche in rete. In questo caso devono essere caricati anche questi schemi importati. In figura 12 sono evidenziate tutte queste caratteristiche, oltre ad essere anticipati i casi d'uso di estrazione di concetti da un'ontologia e di annotazione di un'entit. In questa fase non vengono dettagliate le modalit di annotazione, n la natura dei suoi destinatari, per il momento indicati semplicemente come entit. Cos facendo, questo schema rimane valido anche nel caso in cui vengano in futuro adottate modalit di annotazione diverse da quelle previste da SAWSDL.

83

3.La soluzione proposta

Figura 12: Caso d'uso "Annota Parte Comune" Nello scenario attuale, mostrato in figura 13, con Annota Entit si denota una generalizzazione dei casi d'uso secondo i quali viene annotato semanticamente un documento WSDL o uno XSD. La relazione fra questi casi d'uso mostrata in figura 13. I casi d'uso Modifica Model Reference e Modifica Documentation si riferiscono alle due modalit con cui si intende consentire all'utente di annotare: il primo riguarda la modalit standard specificata da SAWSDL, mentre il secondo permette di effettuare annotazioni in testo libero mediante elementi aggiuntivi, recanti il nome
documentation,

messi a disposizione sia da WSDL che da XSD. Ricordiamo che in

questo scenario non previsto il ricorso all'annotazione di XML Schema per mezzo di schema mapping. La presenza di URI da utilizzare come model reference indissolubilmente legata alla disponibilit di un'ontologia che fornisca i necessari concetti del dominio applicativo di questa PA o di altri concetti utili. Questa l'ontologia attiva, cos detta in quanto espressamente richiesta dall'utente, anche se nella realt il sistema potrebbe presentargli un insieme di ontologie, incluse quelle eventualmente importate da quella attiva. 84

3.La soluzione proposta

Figura 13: Caso d'uso "Annota Entit" Come ovvio, una volta che questa risorsa sia stata annotata in maniera soddisfacente, essa andr salvata. Ci reso possibile solo sul file system locale. Per ultimo, il caso d'uso Estrai Concetti da Ontologia viene esploso nelle componenti, mostrate in figura 14, che descrivono in che modo tali risorse possano essere ottenute. Teoricamente, l'unico metodo per avere a disposizione le ontologie di SPCoop quello di interrogare il Catalogo Schemi ed Ontologie, usufruendo dei servizi che questo mette a disposizione. Tuttavia, non essendo stato possibile accedere a tali servizi nel periodo di questo studio, stata messa a disposizione una strada alternativa che consenta di caricare ontologie o da un URI fisico oppure dal proprio file system locale. Come per i documenti WSDL o XSD, se l'ontologia attiva ha delle dipendenze, anche ricorsive, il sistema tenter di caricare anche queste.

85

3.La soluzione proposta

Figura 14: Caso d'uso "Estrai Concetti da Ontologia"

3.1.3. Modello delle componenti

Date le prospettive di estensibilit del progetto, la modularit della soluzione proposta una prerogativa imprescindibile. Dovr in futuro essere possibile, ad esempio, integrarla con ulteriori moduli per l'invocazione di Web Service per l'accesso al Catalogo Schemi e Ontologie, nonch al Registro SICA Generale, quando i relativi servizi saranno disponibili. I dettagli di queste prospettive di sviluppo saranno meglio discussi nell'ultimo capitolo. Una chiave di lettura del principio di modularit riguarda molto da vicino l'architettura applicativa rispetto al paradigma di sviluppo adottato. La scelta di sviluppare un'applicazione web, o pi precisamente una Rich Internet Application, ha una serie di implicazioni che possono essere sfruttate a beneficio sia dello sviluppatore che dell'utente finale. Prima di tutto, cruciale la scelta di come distribuire il carico applicativo fra il sistema che utilizza il servizio (client) e quello che lo fornisce (server). 86

3.La soluzione proposta La scelta di concentrare la maggior parte della logica applicativa su di un unico modulo eseguito in locale (quello che in letteratura noto come thick client) certamente una strada percorribile, ma a fronte degli ovvi vantaggi di flessibilit, possibilit di lavorare offline e maggiore indipendenza dall'architettura server (che a seconda dei casi pu anche essere uno svantaggio) bisogna rilevare una serie di punti critici che ne fanno una scelta non adatta a tutti gli scenari applicativi, tanto meno a questo: 1. Le risorse disponibili sui sistemi utente possono essere inadeguate ad un carico computazionale che comprenda l'interpretazione di WSDL, XSD e OWL, nonch attivit di ragionamento sulle ontologie, soprattutto se il client sviluppato per piattaforme non ottimizzate, come spesso il caso di JavaScript. 2. La logica applicativa di questo progetto si basa fortemente sul parsing e sull'interpretazione di particolari linguaggi logici e di markup, per i quali la stragrande maggioranza di API in circolazione scritta in Java. Volendo impiegare queste librerie, si sarebbe vincolati allo sviluppo del client come applet Java. 3. In caso vengano effettuati aggiornamenti all'implementazione della logica applicativa sottostante, sarebbe concreto il rischio che tali aggiornamenti non si riflettessero su tutte le occorrenze di utilizzo dell'applicazione; in particolare se il client fosse abilitato ad operare offline, allora potrebbero sorgere problemi di compatibilit fra versioni datate dell'applicazione. 4. Nel ciclo operativo di questo strumento in SPCoop si prevede che esso usufruisca di servizi SICA, ad esempio per il reperimento delle ontologie di dominio. Se la logica applicativa distribuita fra tutti i sistemi client, ognuno di essi deve definire i termini di utilizzo di tali servizi, redigendone gli Accordi e abilitando la propria Porta di Dominio ad utilizzarli. Al contrario, se la logica applicativa centralizzata, soltanto i domini applicativi che espongono questo strumento come servizio sul web devono farsi carico di questo onere, svolgendo 87

3.La soluzione proposta quindi una funzione di proxy. Per queste ragioni si optato per un'architettura applicativa nella quale interfaccia utente e business logic siano disaccoppiate, salvo disporre di uno strato intermedio di comunicazione rispetto al quale esse dovranno ovviamente essere standardizzate. chiaro che questo strato di comunicazione avr un suo costo in termini di traffico di rete, ma si ritiene di poter trascurare tale costo in rapporto ai livelli di qualit del servizio garantiti in SPC (si veda in proposito il capitolo 1) e alla quantit di sessioni utente contemporanee previste per questo servizio. Lo strumento verrebbe dunque composto dei seguenti sottosistemi:

Un backend deputato alla gestione della logica applicativa che governa i dati d'interesse, traducendo l'input dell'utente in azioni concrete come la costruzione di documenti SAWSDL, la validazione di documenti WSDL, XSD e OWL, il reperimento e l'aggiornamento di detti documenti.

Una componente di frontend, che implementi l'interfaccia utente vera e propria, orientata al paradigma WYSIWYM [Pow00] in modo da esonerare l'utente dal conoscere i sopraelencati linguaggi. Una peculiarit che emerge da questa scomposizione concerne il grado di

compenetrazione dei due sottosistemi in termini di capacit di interpretare i formalismi usati per rappresentare le varie tipologie di documento. In linea di principio, la logica interna della componente di interfaccia utente non dovrebbe entrare nel merito dei linguaggi in cui sono rappresentate le risorse coinvolte: in termini colloquiali, il frontend non deve parlare n WSDL, n XSD, n OWL e in teoria nemmeno XML, bench, come si vedr in seguito, sia prevista una deroga su quest'ultimo punto. L'interfaccia, infatti, deve limitarsi a presentare all'utente solo il risultato delle operazioni di parsing, interpretazione e ragionamento effettuate a priori sulle risorse richieste. Ovviamente il livello di comunicazione dovr essere sufficientemente dettagliato da consentire all'interfaccia di strutturare l'informazione in maniera coerente 88

3.La soluzione proposta con i dati d'origine, perci in corso di sviluppo si adotter una nomenclatura che rispecchi quella del modello di partenza. Ad esempio, un oggetto del modello intermedio che rappresenta una classe in OWL verr denominato come classe anche se il suo livello di dettaglio riguarda solo un sottoinsieme delle caratteristiche che denotano una classe. In nome della modularit, si altres scelto di raffinare la granularit dell'approccio anche in relazione al backend, utilizzando come criterio non solo i ruoli (fonte o destinatario dell'annotazione semantica), ma anche le tipologie di risorsa impiegate nel flusso informativo dell'applicazione. Da un lato sono stati individuati dei moduli che rappresentino le interfacce esposte verso il frontend, al fine di servire le richieste di caricamento delle risorse e di eventuale salvataggio delle stesse, senza entrare nel merito del linguaggio in cui sono rappresentate; dall'altro, si provveduto ad isolare ulteriori moduli logici, ciascuno finalizzato all'interpretazione di un determinato linguaggio. Sintetizzando, sono state formalizzate due possibili tipologie di moduli:

una per le interfacce di servizio remoto che mettono le risorse a disposizione del client. Sono stati individuati due possibili moduli: Servizi Ontologia e Servizi Entit Annotabili;

un'altra per i moduli finalizzati all'interpretazione di tali risorse nel linguaggio in cui sono rappresentate, che frequentemente chiameremo motori, o engine. In base ai linguaggi in questione, ne sono stati individuati tre: Motore WSDL, Motore Schema e Motore Ontologia. Le modalit con cui questi moduli interagiscono sino a comporre un'architettura

applicativa consistente sono schematizzate nei diagrammi UML delle componenti [Amb04] riportati nelle figure 15 e 16.

89

3.La soluzione proposta

Figura 15: Diagramma delle componenti del frontend

Figura 16: Diagramma delle componenti del backend Si pu evincere dalla lettura di questi diagrammi che la macro-componente locale e quella remota si interfacciano per mezzo di un nodo che stato denominato Remote Procedure Call (RPC). Questo perch si prevede che il layer di trasporto, a prescindere 90

3.La soluzione proposta dalla sua particolare implementazione, segua in ogni caso questo modello di comunicazione inter-processo [Mar99] nel quale vengano messe in comune solo le specifiche logiche delle procedure previste, senza che le loro implementazioni giacciano nello spazio d'indirizzamento dei processi che le invocano. Per poter usufruire di questo canale di trasporto, sar necessario che frontend e backend si accordino sulla rappresentazione dei dati in transito, che nella quasi totalit dei casi saranno informazioni sui documenti aperti. Questo significa disporre di un modello di rappresentazione intermedio che, nella prospettiva di evitare che la componente locale debba effettuare il parsing dei documenti veri e propri, sar diverso dal formato di rappresentazione originario. Di qui la necessit di avere degli interpreti lato client che si pongano a met fra il modello intermedio e l'utente. Il sottosistema del backend che comprende i gi citati motori quello destinato ad ospitare i veri e propri parser e validatori di WSDL, XML Schema, RDF e OWL. Ad essi spetta il compito di effettuare le conversioni tra il modello originario e quello intermedio, presentandone il risultato al sottosistema dei servizi, il quale espone verso l'esterno le funzionalit di questi motori, dalla lettura di una risorsa sino alla scrittura di un file WSDL o XSD annotato (anche dal file system locale per mezzo di servizi di upload/download).

3.2. Progettazione dell'interfaccia utente

L'aver optato per la creazione di una RIA, quindi di uno strumento fruibile per mezzo di web browser, offre numerose opportunit, ma allo stesso tempo pone altrettanto numerose limitazioni. Se da un lato si trae vantaggio dalla familiarit dell'utente con uno strumento come il web, visto al suo attuale stadio evolutivo come veicolo di servizi, dall'altro necessario misurarsi con le sue limitazioni intrinseche, sia a livello di risorse che di funzionalit. Esempi di queste limitazioni includono l'efficienza del motore JavaScript e il suo rendimento rispetto alla processing power a disposizione; fenomeni di caching e supporto ridotto per lo stato d'esecuzione dovuto alla natura stateless del protocollo HTTP; limitati metodi di accesso al file system.

91

3.La soluzione proposta Alcune di queste limitazioni possono essere risolte facendo ricorso a componenti software esterni: ad esempio applet Flash47 o Java48 possono consentire di accedere al file system in maniera pi articolata. Tuttavia, bisogna far presente che uno degli obiettivi secondari del progetto quello di limitare, se non addirittura escludere il ricorso a strumenti disponibili lato client, al di fuori di un browser web con supporto per AJAX [Gar05]. Il problema di estendere il livello d'interazione mediante ricorso a tali strumenti potr comunque essere affrontato in sviluppi successivi. Le propriet dell'interfaccia utente dell'applicazione proposta come soluzione discendono sia dalla natura delle funzionalit previste, ovvero di uno strumento per l'annotazione comparata di due tipologie di documento con elementi da una terza tipologia, sia dall'insieme dei vantaggi e delle restrizioni del suo essere presentato come un'applicazione web. Tali propriet sono riassunte in una serie di requisiti, di seguito enunciati, che tale interfaccia deve soddisfare: 1. Perspective unificata. Il processo di annotazione semantica di un documento WSDL o di un XML Schema prevede una valutazione di merito, da parte dell'utente, su quanto i concetti espressi in un'ontologia siano adeguati per caratterizzare il servizio esposto dal suo dominio. Questo significa consentire all'utente di poter effettuare una comparazione, a livello concettuale, delle due risorse necessarie ad eseguire l'operazione, minimizzando il costo dei cambi di contesto in termini sia temporali che di attenzione dell'utente. Per fare questo, sia l'ontologia (o l'insieme di ontologie) che il documento da annotare devono essere presentati contemporaneamente su di un'unica vista, come del resto accade sia in WSMO Studio49 che in Radiant50. Il termine perspective, ben noto agli utenti e agli sviluppatori di plugin per Eclipse51, determina l'insieme delle viste e delle azioni utente rese disponibili in
47 48 49 50 51
http://www.adobe.com/products/flash/about/ http://java.sun.com/docs/books/tutorial/deployment/applet/ http://www.wsmostudio.org http://lsdis.cs.uga.edu/projects/meteor-s/downloads/index.php?page=1 http://www.eclipse.org

92

3.La soluzione proposta una finestra e fornisce meccanismi di filtraggio ed interazione orientata al compito dell'utente. 2. Pluralit di rappresentazioni di uno stesso documento. Per ogni tipologia di risorsa, all'utente dovrebbe essere data facolt di scegliere tra pi modalit di rappresentazione, differenziate in base al grado di conoscenza che pu avere della struttura e della sintassi sottostante. Dovrebbero essere garantite perlomeno tre modalit: una strutturata (alberi, grafi, etc.), una piatta o semi-strutturata (ad esempio tabelle o liste con ordinamento parziale) ed una del codice sorgente. Almeno due di queste modalit dovrebbero essere interagibili, ovvero abilitate all'esecuzione delle azioni utente necessarie per l'annotazione. 3. Compatibilit fra le rappresentazioni. Anche se le risorse fonte e destinatario sono concettualmente molto diverse, il fatto che siano messe in relazione fra loro dal processo di annotazione implica che esse debbano essere presentate secondo delle metafore visive con un adeguato grado di similarit. Ad esempio, effettuare un'operazione del genere tramite drag-&-drop dei nodi di un albero su di un grafo sparso pu sembrare innaturale, perci sarebbe opportuno replicare le stesse modalit di rappresentazione per entrambi i ruoli di fonte e destinatario. 4. Feedback non modale. Mentre nelle classiche applicazioni desktop talvolta accettabile che situazioni di errore o anomalie di altro tipo vengano notificate da elementi d'interfaccia che richiedono che l'utente interagisca con essi prima di proseguire con le sue operazioni, questo un comportamento generalmente inaspettato nell'interazione con pagine web. Si richiede pertanto che eventuali anomalie o situazioni di errore vengano notificate all'utente con sistemi evidenti ma il meno possibile intrusivi, affinch si possa proseguire l'attivit, eventualmente prendendo in carico o ignorando l'evento notificato. Le modalit di notifica dipenderanno dai widget messi a disposizione dalle librerie grafiche scelte.

93

3.La soluzione proposta 5. Filtraggio. Questo requisito ha una duplice valenza: da un lato va conferita all'utente la facolt di personalizzare, entro certi limiti, il livello di dettaglio della rappresentazione delle risorse; dall'altro, si vuole disporre di un layout flessibile, cosicch l'utente sia libero di espandere o collassare i pannelli recanti informazioni non essenziali (ad esempio la navigazione di schemi e ontologie, le opzioni o i messaggi di sistema). Il filtraggio sar disponibile in forme e limiti tali da non depauperare la potenza espressiva delle metafore di rappresentazione. Diversamente da come avviene per il design dell'architettura applicativa, non esiste ancora uno standard universalmente riconosciuto di linguaggio di modellazione per progettare interfacce grafiche. Ai fini del presente lavoro, si tratto spunto da UMLi [PinPat03], una delle pi accreditate proposte di linguaggio per la modellazione delle interfacce utente. Si tratta di una proposta dell'Universit di Manchester sin dal 1998 per estendere UML con una nuova tipologia di diagramma e un insieme di nuovi costruttori per diagrammi di attivit per modellare gli aspetti comportamentali delle interfacce. Per modellare l'unica perspective prevista per l'applicazione ci si serviti del modello UMLi, la cui applicazione rappresentata nel diagramma in figura 17. Se ne elenca rapidamente la legenda [PinPat00] per chi non avesse familiarit con UMLi:

i displayer sono componenti dell'interfaccia utente che hanno il compito di mostrare informazioni all'utente in una qualche forma grafica (che pu essere anche semplice testo). Sono indicati con triangoli con un vertice rivolto verso l'alto;

gli inputter hanno il compito di catturare l'informazione sottoposta dall'utente. Questa non comprende quelle azioni di interfaccia mirate a invocare l'invio delle informazioni stesse, quanto piuttosto quei dati che contribuiscono al payload applicativo vero e proprio. Sono indicati con triangoli con un vertice rivolto verso il basso;

gli editor, che sono contemporaneamente inputter e displayer, sono indicati con

94

3.La soluzione proposta una losanga;

gli action invoker, indicati con delle frecce, rappresentano i segnaposti di quegli oggetti tramite i quali l'utente pu generare eventi di interfaccia. Non specificato, a questo livello, se tali oggetti siano pulsanti, checkbox, radio button, etc.

i container possono contenere, in qualsiasi numero, tutti i segnaposti per widget elencati sinora, compresi altri container. Non detto, pur essendo auspicabile, che la relazione di contenimento si rifletta in senso stretto sul layout dell'interfaccia.

Il free container, uno per ogni diagramma, rappresenta la vista principale proposta all'utente, ed delimitato da una linea tratteggiata. Si ricorda che la disposizione degli elementi in un diagramma di interfaccia UMLi

non necessariamente indicativa di come tali elementi saranno effettivamente disposti nel layout, n della quantit di spazio che occuperanno, n del modo in cui verranno resi in forma grafica (cio di quali siano i widget corrispondenti). Tuttavia, i container sono stati disposti ed organizzati in maniera da indicare, a grandi linee, come la perspective sar realizzata.

95

3.La soluzione proposta

Figura 17: Diagramma UMLi dell'interfaccia utente Da una lettura di questo diagramma si pu gi evincere come siano soddisfatte alcune delle propriet elencate. gi evidente la compresenza delle due viste, su ciascuna delle quali sono presentate ontologie o documenti WSDL/XSD. Entrambe queste viste offrono tre diverse modalit di rappresentazione (Albero, Lista Nodi e Codice), nel cui dettaglio per il momento non si entrer, ma dal cui nome si pu facilmente intuire il senso. Il passaggio tra le modalit sar garantito dal Selettore Modalit, un oggetto che, a fronte di un'azione dell'utente, generer un evento di interfaccia. Per entrambe le viste si prevede anche la gestione di un evento Ricarica, utile se, ad esempio, stato alterato il set di ontologie su cui il motore semantico dovr ragionare. Le due viste si differenziano nelle modalit di gestione dell'input utente: mentre nella vista delle ontologie consentita solamente la selezione di concetti idonei all'operazione di annotazione, nella vista WSDL/XSD viene effettuata l'operazione vera e propria, e i suoi effetti dovrebbero riflettersi in tempo reale sulla struttura del documento, nonch sul codice. Sono pertanto presenti due editor, uno per l'annotazione tramite attributo modelReference ed uno per l'annotazione in testo libero tramite

96

3.La soluzione proposta l'elemento documentation. Le azioni di caricamento e salvataggio delle risorse sono raggruppate nel Menu Container. Le funzioni dei suoi action invoker Carica WSDL, Carica XSD, Carica Ontologia e Salva WSDL/XSD sono facilmente intuibili, anche se a questo livello non viene ancora effettuata alcuna distinzione fra il caricamento di un'ontologia da un URI remoto piuttosto che dal file system. Il contenitore Info UI segue una logica simile a quella delle viste sulle risorse, con la differenza che i tre displayer in esso contenuti sono semanticamente distinti, nel senso che denotano risorse s correlate ma pur sempre di diversa natura:

Diagnostica generalmente impiegata per una notifica non intrusiva degli eventi, siano essi anomalie o errori fatali. Non si tratta propriamente di un log, in quanto si intende utilizzarla solo per i messaggi di interesse per l'utente finale.

Slots Concetti una sezione riservata ai dettagli delle relazioni che un certo concetto messo in evidenza ha con altri concetti nel set di ontologie preso in esame.

Mappa Ontologie tiene traccia di tutte le ontologie che sono state richieste, o direttamente dall'utente o perch importate, dall'inizio della sessione utente. Questa vista ospiter informazioni fra cui lo stato di risoluzione, lo URI fisico (che pu essere stato reimpostato a mano dall'utente) e la sua relazione con l'ontologia attiva. Gli ultimi due container, infine, forniscono supporto per input accessori.

Navigazione offre gli strumenti per accedere a singoli documenti WSDL o XSD a partire da un'opportuna struttura gerarchica, che pu essere basata sulla relazione di importazione fra schemi, ma pu anche essere la directory di un Accordo di Servizio. La vista Opzioni riguarder principalmente impostazioni di filtraggio della rappresentazione, come indicato dal requisito numero 5; ad esempio, l'utente avr la 97

3.La soluzione proposta facolt di richiedere che sia visualizzata solamente l'ontologia attiva, piuttosto che l'intera chiusura delle sue importazioni. Nel concludere, ci si sofferma brevemente sulla caratterizzazione delle rappresentazioni strutturate che si adotteranno sia per le entit annotabili che per le ontologie, pur con criteri completamente diversi tra loro. La rappresentazione degli schemi XSD la pi semplice, in quanto rispecchia esattamente la gerarchia degli elementi di tipo all, attribute, choice, complexType,
element, sequence

e simpleType nel corrispondente albero DOM, avente come radice

un elemento di tipo schema. La rappresentazione di un documento WSDL tale che si abbia: 1. la radice, corrispondente a wsdl:definition; 2. per ogni elemento di tipo xsd:schema, il l'albero corrispondente appeso come figlio di primo livello; 3. un nodo figlio di primo livello per ciascun elemento di tipo wsdl:message, ciascuno con un nodo figlio per ogni elemento wsdl:part annidato; 4. un nodo figlio di primo livello per ciascun elemento di tipo wsdl:portType, ognuno con un nodo figlio per ogni elemento wsdl:operation annidato. Ogni nodo rappresentante un elemento di tipo operation ha una sequenza ordinata di figli, uno per ogni sottoelemento di tipo input, output e fault, nell'ordine in cui sono dichiarati. 5. Per ogni attributo di tipo sawsdl:modelReference, il nodo corrispondente all'elemento titolare ha un nodo figlio per ogni URI che compone il valore dell'attributo, detto nodo di annotazione. Se tale elemento di tipo
sawsdl:attrExtensions,

il nodo di annotazione appeso all'elemento padre di

98

3.La soluzione proposta tipo operation. Questi nodi sono sempre elencati come i primi figli di ciascun nodo titolare dell'attributo. Infine, la rappresentazione ad albero di un'ontologia costruita secondo i seguenti postulati, dove si assume che ad ogni named entity E sia associato un nodo NE: 1. il nodo Nthing corrispondente alla classe owl:Thing sempre la radice dell'albero; 2. per ogni coppia di classi C1 e C2 tali che esista un assioma o un'inferenza che asserisca che C1 sottoclasse diretta di C2, si ha che NC1 figlio di NC2; 3. per ogni individuo I1 istanza della classe meno generale C1, si ha che NI1 figlio di NC1; 4. per ogni propriet (sia object property che datatype property) P1 tale che la classe C1 un termine dell'espressione del dominio di P1, si ha che NP1 figlio di NC1. Mentre le prime tre regole ricalcano da vicino le modalit di rappresentazione dei pi comuni editor di ontologie, la quarta il risultato di un trade-off fra la necessit di rappresentare pi concetti possibili entro la stessa struttura ed il rischio di avere alberi sparsi e con molti nodi ripetuti. La scelta di limitarsi ai soli assiomi di dominio (poich il codominio delle datatype property coinvolge solamente dei letterali) parsa un giusto compromesso che includesse gran parte delle propriet dichiarate in un'ontologia.

99

4.Sviluppo ed implementazione: SAscha

4. Sviluppo ed implementazione: SASCHA

Quanto stato teorizzato nel secondo capitolo e progettato nel terzo trova applicazione pratica in un apposito strumento software sviluppato a supporto del Sistema Pubblico di Cooperazione [ABFM+05], ma con il potenziale per un vero e proprio asset per l'annotazione semantica di Web Service in tutti i contesti [New02]. L'applicativo SASCHA rappresenta il prodotto finale concreto dell'attivit di tesi, ma come vedremo, esso ha generato un altro sottoprodotto che potr rappresentare un contributo alla comunit di sviluppo di Web Service semantici [KotVit06]. Come apparir chiaro dalla sezione Analisi e scelta del software a supporto dell'implementazione, vi una discreta disponibilit di prodotti software per gli standard adottati e proposti per la rappresentazione di Accordi di Servizio ed ontologie. Si osserva che essi sono quasi per intero scritti in linguaggio Java, con riferimento sia agli strumenti per l'utente finale (molti dei quali basati sul framework messo a disposizione dall'ambiente di sviluppo Eclipse52, compresi i gi citati Radiant53 e WSMO Studio54), sia alle librerie a supporto dello sviluppo di applicazioni di terze parti. perci risultato naturale ricorrere a questa piattaforma ampiamente diffusa, la cui natura di linguaggio orientato agli oggetti favorisce la pratica di rappresentare elementi dei linguaggi di interesse in apposite tassonomie, ricalcando il paradigma dell'object model [Fow96]. Inoltre, gi l'API standard di Java dispone nativamente di classi per la costruzione di e l'accesso ad alberi DOM, l'interpretazione del linguaggio XML e la formalizzazione di URI in forma di nomi qualificati, o QName [Wal04], grazie ai quali ogni namespace pu essere mappato su di un prefisso. La scelta di tecnologie improntate sul modello AJAX (Asynchronous JavaScript And XML) [Gar05] stata dettata principalmente dallo stato di immaturit di gran parte

52 http://www.eclipse.org 53 http://lsdis.cs.uga.edu/projects/meteor-s/downloads/index.php?page=1 54 http://www.wsmostudio.org

100

4.Sviluppo ed implementazione: SAscha delle tecnologie concorrenti presenti sul mercato: JavaFX55, sviluppata da Sun56, pur apparendo oggi come una delle piattaforme pi promettenti per lo sviluppo di RIA, manca ancora di una release stabile pubblica; Microsoft Silverlight57 fu rilasciato solo pochi mesi prima della fase di progettazione di questo applicativo e a tutt'oggi manca di un completo supporto cross-platform, non essendo ancora compatibile con Linux n con il browser Opera; OpenLaszlo58, bench attivamente sviluppato sin dal 2000, soffre di una diffusione relativamente scarsa e della dipendenza da un linguaggio di programmazione ad-hoc chiamato LZX; infine Adobe Flex59, insieme di tecnologie di sviluppo RIA basate su Flash, probabilmente l'unica piattaforma proprietaria sufficientemente matura, ma allo stesso tempo eredita i punti critici che caratterizzano Flash, fra cui accessibilit, compatibilit con sistemi diversi da Windows a 32 bit e limitata indicizzazione dei dati binari.

4.1. Risorse e strumenti utilizzati

In questa sezione viene effettuata una breve panoramica delle tecnologie utilizzate a supporto di tutte le fasi del ciclo di vita del presente lavoro. Queste sono riassunte in tabella 4, con la riserva di giustificare successivamente le pi importanti scelte effettuate. Il ricorso a tecnologie di virtualizzazione come quelle offerte da VMware60 dovuto a due principali ragioni: in primo luogo pratiche, poich tali tecnologie hanno permesso di condensare l'intero ambiente di sviluppo in un unico nucleo completo e portabile; in secondo luogo, perch ha consentito di simulare un approccio client-server analogo al tipico scenario applicativo atteso per l'impiego dello strumento software sviluppato per questa tesi.

55 56 57 58 59 60

http://javafx.com http://www.sun.com/software/javafx http://silverlight.net http://www.openlaszlo.org http://www.adobe.com/products/flex http://www.vmware.com

101

4.Sviluppo ed implementazione: SAscha La pluralit di web browser adottati nel corso della sperimentazione trova giustificazione nelle evidenti discrepanze fra di essi, sia per le loro modalit di generazione ed interpretazione del Document Object Model (DOM)61 di una pagina web, sia per l'efficienza e le funzionalit dei motori JavaScript. Poich parte di questi browser, nello specifico IE7, Chrome e Safari, non disponibile in forma nativa per Linux (salvo ricorrere a wrapper come Wine62), si rivelato imperativo disporre sia di Windows che di Linux come sistemi operativi host su cui far girare il frontend. Hardware Piattaforma di virtualizzazione Sistemi Operativi host Sistemi Operativi guest Java Virtual Machine e kit di sviluppo Ambiente di sviluppo integrato (IDE) Servlet Container Editor di ontologie x86_64 multicore, 2048+ MB VMware Server63 Linux Fedora 864 Windows XP SP3 Windows XP SP2 Sun JDK SE65 1.6.0 con aggiornamenti Eclipse Europa (3.3) Ganymede (3.4) Apache Tomcat66 5.5 NeOn Toolkit67 1.0 1.2 Protg68 4.0beta Altova SemanticWorks 200869 70 Swoop71 2.3beta4 Strumenti di test e debugging FireBug72 GWT73 hosted-mode browser

61 Si vedano a tale proposito i rapporti tecnici sul Document Object Model del World Wide Web Consortium presso http://www.w3.org/DOM/DOMTR 62 http://www.winehq.org 63 http://www.vmware.com/products/server 64 Kernel 2.6.23-2.6.26 con window manager GNOME, testato con e senza estensione OpenGL compiz. 65 http://java.sun.com/javase/ 66 http://tomcat.apache.org 67 http://www.neon-toolkit.org 68 http://protege.stanford.edu 69 http://altova.com/products/semanticworks/semantic_web_rdf_owl_editor.html 70 Versione trial, in prova per 30 giorni. 71 http://code.google.com/p/swoop 72 http://getfirebug.com 73 http://code.google.com/webtoolkit

102

4.Sviluppo ed implementazione: SAscha Web Browser Google Chrome74 0.2 Mozilla Firefox75 2.x 3.x Microsoft Internet Explorer76 7 Opera77 9.5 9.61 Apple Safari78 3.1.2 Editor XML, HTML, CSS, batch, etc. Authoring di documentazione e grafica Notepad++79 (Windows) gedit80 (Linux) Dia81 0.96 GIMP82 2.4 Inkscape83 0.46 LyX84 1.52 OpenOffice85 2.3 2.4 Editor UML Papyrus86 1.10 StarUML87 5.0 Tabella 4: Risorse a supporto dello sviluppo La scelta di Apache Tomcat come servlet engine, di per s arbitraria, stata dettata da fattori soggettivi e da una ricerca della massima compatibilit con il metodo proposto dal Google Web Toolkit per il debugging, che sar esaminato tra breve. infine opportuno soffermarsi brevemente sul tema degli strumenti di editing delle ontologie. vero che l'applicazione delle teorie di ontology enginnering
74 75 76 77 78 79 80 81 82 83 84 85 86 87
http://www.google.com/chrome http://www.mozilla.com/en-US/firefox/ http://www.microsoft.com/windows/products/winfamily/ie http://www.opera.com http://www.apple.com/safari http://notepad-plus.sourceforge.net http://www.gnome.org/projects/gedit/ http://dia-installer.de/index_en.html http://www.gimp.org http://www.inkscape.org http://www.lyx.org http://www.openoffice.org http://www.papyrusuml.org http://staruml.sourceforge.net

103

4.Sviluppo ed implementazione: SAscha [UscGru96] per la creazione, gestione e valutazione di ontologie non rientra negli scopi di questo progetto. Tuttavia, l'adozione di questi strumenti in pi varianti ha una duplice valenza: da un lato, essi hanno fornito utilissimi spunti per modellare una metafora di rappresentazione delle ontologie immediata ma completa; dall'altro, sono stati impiegati nella generazione dei casi di test, vale a dire ontologie dalla complessit generalmente ridotta, ma strutturate su diversi livelli di espressivit. Questo stato richiesto per verificare che SASCHA non solo interpretasse correttamente i costrutti sintattici del linguaggio OWL, ma sapesse anche derivare tutte le conclusioni e i fatti rilevanti per supportare l'annotazione semantica di documenti WSDL e XSD. Descriviamo rapidamente gli strumenti esaminati:

Protg sia uno strumento per l'authoring di ontologie che un sistema di acquisizione della conoscenza. Si tratta di un vero e proprio framework open source estensibile, basato su Swing e sviluppato dall'Universit di Stanford88, e la sua estensione Protg-OWL89 probabilmente l'editor di ontologie pi utilizzato al momento, con oltre 107.000 utenti registrati nell'ottobre 2008.

Swoop uno strumento per la creazione, la modifica e il debugging di ontologie OWL. Originariamente sviluppato dal laboratorio MIND90 dell'Universit del Maryland, oggi divenuto open source e mantenuto su Google Code. Ad oggi, Swoop ancora non supporta le sintassi di OWL basate sulla Notazione 3 [Ber98].

NeOn Toolkit, come il nome pu suggerire, un vero e proprio ambiente di ontology engineering. Parte del progetto di ricerca paneuropeo quadriennale NeOn91 sulla gestione del ciclo di vita della conoscenza, questo framework offre supporto alla navigazione e all'editing di ontologie basate su OWL, RDF(S) e FLogic. basato su Eclipse e vanta una quantit considerevole di estensioni, anche commerciali.

88 89 90 91

http://www.stanford.edu http://protege.stanford.edu/overview/protege-owl.html http://mindlab.umd.edu http://www.neon-project.org

104

4.Sviluppo ed implementazione: SAscha

Semantic Works l'unica applicazione commerciale che sia stata esaminata nel corso della sperimentazione. Si tratta di un editor visuale sviluppato da Altova92, che supporta OWL e RDF(S) e consente la conversione da e verso RDF/XML e N-Triple. L'applicazione stata provata per il periodo di 30 giorni consentito dalla licenza trial. stato posto in secondo piano il problema della scelta delle librerie da impiegare

come componenti del software vero e proprio, poich la loro analisi e scelta dipesa da fattori profondamente diversi tra loro e dai criteri utilizzati per la scelta delle risorse a supporto. Questo tema sar trattato in dettaglio nella prossima sezione.

4.2. Software a supporto dell'implementazione

Per stabilire fino a che profondit implementare il servizio di annotazione in tutte le sue parti, sembrato opportuno sondare lo stato dell'arte e l'esperienza delle comunit di sviluppo sia di piattaforme AJAX che di Web Service semantici e non. Parte di questo studio gi stata affrontata in sede di analisi dello stato dell'arte in materia di strumenti SAWSDL [FarLau07] per l'utente finale, poich alcuni di questi (in particolare WSMO Studio) riusano implementazioni di riferimento per standard quali WSDL, XML Schema e SAWSDL. utile dare sin da subito la definizione di object model, che in questa trattazione non da intendersi in senso classico, cio come la notazione utilizzata per rappresentare gli oggetti in un dato linguaggio di programmazione. Nell'accezione corrente, mutuata da [Fow96], un object model un'interfaccia object-oriented verso un dato servizio o sistema, cio una collezione di tipi di dato attraverso i quali un programma pu esaminare e manipolare specifiche parti del suo ambiente di esecuzione. Un esempio molto comune il gi citato Document Object Model (DOM) che si utilizza, ad esempio, per rappresentare una pagina web in un browser, affinch uno script possa manipolarla.
92 http://altova.com

105

4.Sviluppo ed implementazione: SAscha L'analisi dello stato dell'arte, dal quale sono stati poi estratti elementi di rilievo da impiegare in questo progetto, stata effettuata puntualmente per ciascuno standard o paradigma che si intenda seguire in sede di sviluppo. importante osservare, a tal fine, che la scelta delle librerie per il supporto ai formati delle entit annotabili stata del tutto indipendente dalla scelta delle implementazioni di OWL. In tabella 5, le implementazioni adottate per questo progetto sono indicate in grassetto e corsivo. Standard Grafica e trasporto per AJAX WSDL XML Schema (XSD) SAWSDL OWL Implementazioni Google Web Toolkit93, Ext GWT94, GWT-Ext95, Tatami96, SmartClient97, JSON98 WSDL4J99, Woden100 W3C DOM101 Woden4SAWSDL102, WSMO4J Grounding API103, SAWSDL4J104 Jena105, RACER112 Tabella 5: Panoramica delle implementazioni Java delle tecnologie adottate OWL API106, Manchester FaCT++110, OWL107, Hoolet111, KAON2108, Pellet109,

93 http://code.google.com/webtoolkit 94 http://extjs.com/products/gxt/ 95 http://code.google.com/p/gwt-ext 96 http://code.google.com/p/tatami 97 http://www.smartclient.com 98 http://www.json.org 99 http://sourceforge.net/projects/wsdl4j 100 http://ws.apache.org/woden 101 Disponibile in Java SE 1.6 102 http://lsdis.cs.uga.edu/projects/meteor-s/opensource/woden4sawsdl 103 http://wsmo4j.sourceforge.net 104 http://knoesis.wright.edu/opensource/sawsdl4j 105 http://jena.sourceforge.net 106 http://owlapi.sourceforge.net 107 http://owl.man.ac.uk/api/readme.html 108 http://kaon2.semanticweb.org 109 http://clarkparsia.com/pellet 110 http://owl.man.ac.uk/factplusplus 111 http://owl.man.ac.uk/hoolet 112 http://www.racer-systems.com

106

4.Sviluppo ed implementazione: SAscha

4.2.1. API grafiche per AJAX

4.2.1.1 Google Web Toolkit

Si detto che la scelta di Java come linguaggio di programmazione per il backend stata praticamente d'obbligo, oltre che per la versatilit del linguaggio, soprattutto per l'ampia disponibilit di librerie per la gestione della maggior parte delle tipologie di risorsa che l'applicazione deve gestire. perci parso naturale ricercare piattaforme di sviluppo di Rich Internet Application [All02] che traessero vantaggio dal rigore del linguaggio Java, garantendo nel contempo un grado soddisfacente di potenza espressiva ed efficienza delle interfacce. Google Web Toolkit (GWT) si rivelato essere l'unico framework di sviluppo rilasciato in versione stabile che sembrasse soddisfare queste esigenze. Si tratta di una tecnologia open source che consente lo sviluppo di applicazioni AJAX direttamente in linguaggio Java. disponibile per Linux, Mac OS X e Windows, pur con qualche limitazione per il debugging su sistemi operativi a 64 bit, e pu essere integrato con gli ambienti di sviluppo pi usati (fra cui NetBeans113, JDeveloper114 ed Eclipse) per mezzo di plugin open source di terze parti. Al momento in cui iniziato lo sviluppo del presente progetto, l'ultima versione stabile supportava fino alla versione 1.4 del linguaggio; una versione con supporto per Java 1.5, recante l'innegabile vantaggio di poter parametrizzare raw types come Set, List e Map, divenuta stabile nell'arco del 2008 ed stata adottata in corso d'opera. Le componenti di GWT, a supporto sia dello sviluppo che della messa in opera, sono:

Cross-compiler Java-to-JavaScript, per tradurre esclusivamente il codice lato client in HTML e JavaScript;

GWT Hosted Web Browser, che consente al programmatore di eseguire il codice

113 http://www.netbeans.org 114 http://www.oracle.com/technology/products/jdev/index.html

107

4.Sviluppo ed implementazione: SAscha GWT senza compilarlo n caricarlo su un server: uno strumento di debugging che interpreta direttamente il bytecode Java attraverso la Java Virtual Machine del sistema operativo, senza bisogno di cross-compiling in JavaScript. Questo strumento attualmente disponibile solo per sistemi operativi a 32 bit.

JRE Emulation Library, un'implementazione in JavaScript delle pi comuni componenti della class library standard di Java: quasi tutto il package
java.lang,

gran parte di java.util e alcune classi di java.io e java.sql;

GWT Web UI class library, un widget toolkit come lo sono AWT, Swing e SWT, ma basato su HTML. Mette a disposizione un insieme di oggetti grafici da combinare in interfacce oppure in nuove librerie grafiche. Mettiamo in evidenza alcuni dei vantaggi principali di GWT. In primo luogo, ha

un ampio supporto per i browser pi diffusi, tra cui Mozilla Firefox 3, Microsoft Internet Explorer 7, Opera, Apple Safari e Google Chrome. In secondo luogo, di estrema importanza per questo progetto, GWT fornisce semplici meccanismi per la comunicazione con il backend che implementa la logica applicativa. Infine, grazie anche alla licenza Apache 2.0 [APL20], gode di un'amplissima comunit di sviluppo sia del framework stesso che di librerie di terze parti (di cui, come vedremo, alcune sono state adottate per questo progetto). In base a quanto descritto, il programmatore pu dunque sviluppare l'applicazione client interamente in Java, utilizzando le librerie GWT, eventuali API di terze parti che le estendano e quel sottoinsieme della libreria standard Java reimplementato da GWT (o dalle eventuali librerie di terze parti). In corso di sviluppo, egli pu eseguire test e debugging per mezzo del browser hosted-mode di GWT, se disponibile: tale browser include anche una distribuzione lightweight del motore Tomcat, cos da poter servire anche il backend per testare l'applicazione anche con altri browser. Infine, lo sviluppatore pu compilare i codici client e server separatamente e caricarli sul servlet container di sua preferenza. 108

4.Sviluppo ed implementazione: SAscha La libreria di widget messa a disposizione da GWT molto versatile e vanta una gamma abbastanza ampia di primitive HTML standard e complesse. Tuttavia, molti di questi sono presentati senza parametri di stile impostati, lasciando allo sviluppatore la libert di definire quasi per intero lo stile della propria applicazione, per mezzo sia di opportuni metodi Java che di fogli di stile CSS [BCHW07]. Questo processo pu essere lungo ed inutilmente laborioso, soprattutto per la gestione dell'ereditariet delle classi CSS che pu portare a ridondanze o inconsistenze, perci parso opportuno esaminare soluzioni preesistenti, in particolare librerie grafiche open source che estendano l'API grafica di GWT per un'agevole presentazione delle strutture dati necessarie. Per semplicit, di seguito saranno elencate e descritte solamente le librerie che sono state selezionate.
4.2.1.2 Ext JS e GWT-Ext

Ext, nota anche come ExtJS115, una libreria JavaScript che fa uso di tecniche di AJAX e DHTML [Sha07] per costruire applicazioni web interattive. Questa libreria mette a disposizione alcuni fogli di stile CSS precompilati e widget complessi come tabelle con supporto per l'ordinamento, menu a tendina, alberi e tooltip dinamici. Tuttavia, la licenza d'uso ExtJS ha subito profondi mutamenti fra le sue versioni: fino alla versione 2.0.2, la libreria disponibile sotto licenza LGPL [LGPL30], purch si intenda utilizzarla a fini personali, educativi o comunque non commerciali, oppure in un progetto open source che escluda l'uso di software non open source. D'altro canto, esistono interpretazioni secondo cui le clausole della licenza LGPL annullerebbero tali restrizioni. Versioni successive di ExtJS e della sua implementazione in Java per GWT (ExtGWT) sono rilasciate con duplice licenza commerciale e GPL3. Per via delle controversie sorte sulla licenza di ExtJS, l'ultima versione LGPL rilasciata ha generato numerose fork, una delle quali GWT-Ext. Si tratta di un'implementazione alternativa di ExtJS versione 2.0.2 per Google Web Toolkit, che sostanzialmente un wrapper delle classi JavaScript di ExtJS e pertanto necessita di tale
115 http://extjs.com/products/extjs

109

4.Sviluppo ed implementazione: SAscha libreria a tempo di esecuzione, diversamente da ExtGWT che invece le reimplementa in Java per intero. Pur basandosi su una versione obsoleta di ExtJS, il progetto GWT-Ext ancora in stato di attivo sviluppo e di correzione di bug, bench la sua comunit di sviluppo abbia recentemente espresso interesse ad implementare un altro framework AJAX chiamato SmartClient (che peraltro include il supporto per Web Service basati su WSDL e REST).
4.2.1.3 Tatami

Dojo Toolkit116 un'altra libreria modulare JavaScript a supporto dello sviluppo di Rich Internet Application. A differenza di ExtJS, Dojo non mira a fornire un insieme onnicomprensivo di widget per lo sviluppo dell'intera interfaccia, ma solo un insieme limitato di oggetti con funzionalit avanzate. Fra queste citiamo selettori di data e ora, liste con visualizzazione ad occhio di pesce, un editor di testo (Dijit) e sistemi di notifica non intrusivi (i cosiddetti toaster, che si deciso di impiegare in questo progetto). Anche Dojo rilasciato sotto due licenze: la BSD License [BSDL10] e la Academic Free License [AFL30]. Tatami un progetto mirato alla graduale integrazione del Dojo Toolkit in GWT. La sua pi recente versione stabile (1.1) stata adottata in questo progetto per integrare alcune funzionalit accessorie di interazione, ma al vaglio un suo impiego pi intensivo in future release, specialmente se verr seguito l'approccio di abbandonare GWT-Ext in favore di un'altra libreria grafica attivamente sviluppata.
4.2.1.4 JSON

JSON (JavaScript Object Notation) un formato per la serializzazione e l'interscambio di dati frequentemente usato in applicazioni AJAX, a fianco di XML. facilmente leggibile da agenti umani cos come facilmente generabile ed interpretabile da una macchina a stati. Pur derivando dalla sintassi usata da JavaScript per rappresentare gli oggetti, JSON di fatto indipendente dal linguaggio di
116 http://dojotoolkit.org

110

4.Sviluppo ed implementazione: SAscha programmazione e ne esistono implementazioni per quasi tutti i linguaggi pi conosciuti, inclusi Java, C, C++, C#, Lisp, Haskell, Python, Ruby, Perl, PHP e persino LZX per OpenLaszlo. Si fatto uso della libreria Java di JSON per implementare un formato di scambio di messaggi fra alcune componenti d'interfaccia e del backend (ad esempio per l'upload di ontologie e documenti XML), ma non escluso un futuro passaggio a questo formato per generare una sostanziale parte del traffico client-server.

4.2.2. Librerie per il supporto WSDL

Al di l dell'ampia disponibilit di strumenti end-user per la creazione e gestione di Web Service, particolare attenzione stata rivolta alla ricerca di API Java a supporto dei Web Service basati su WSDL, con un occhio di riguardo per la versione 1.1 dello standard [CCMW01], la quale fa parte delle specifiche WS-I BP 1.1 [BEFG+06] adottate in SPCoop [GMRF+05a]. Sono state prese in esame due proposte di implementazione differenti ma correlate, delle quali una stata poi impiegata per quella parte del backend finalizzata alla gestione, in lettura e scrittura, delle entit annotabili. Entrambi i candidati saranno esaminati nel dettaglio, poich la loro stretta correlazione suggerisce future prospettive per l'impiego di ambedue.
4.2.2.1 WSDL4J

Java APIs for WSDL (JWSDL) [DufFre03] un insieme di API per la rappresentazione di documenti WSDL in Java. Rilasciata nel 2003, questa specifica stata sviluppata da un team di esperti provenienti da Sun, IBM, Oracle, IONA Technologies, Cisco Systems e Fujitsu. JWSDL stata progettata per consentire agli utenti di leggere, modificare, creare e riorganizzare documenti WSDL. La validazione di questi documenti si limita alla correttezza della sintassi, ma in linea di principio JWSDL pu essere impiegata per sviluppare strumenti per la validazione semantica. La validazione anche solo sintattica di documenti XML Schema non prevista, tuttavia sono incluse espressioni che consentano di accedervi a partire da dichiarazioni di tipi di dato in WSDL 111

4.Sviluppo ed implementazione: SAscha (wsdl:types). L'estensione del linguaggio, sia per mezzo di elementi XML che di attributi, interamente supportata da JWSDL. Ci rappresenta, nel caso in esame, un fattore estremamente positivo poich, pur non supportando direttamente l'estensione SAWSDL, questa API mette a disposizione gli strumenti necessari per implementarla on-demand. JWSDL supporta esclusivamente la versione 1.1 del linguaggio, e non ha subito aggiornamenti da quando la versione 2.0 diventata W3C Recommendation, nel giugno 2007. Come si pu vedere dalla tabella 6, esiste una corrispondenza biunivoca tra elementi del linguaggio WSDL 1.1 ed interfacce Java del modello JWSDL. Tali interfacce sono strutturate secondo una gerarchia che ricalca il livello di annidamento dei tag XML, nel senso che, ad esempio, possibile accedere ad un'operazione solamente a partire dal port type che la espone (e infatti gli elementi operation sono annidati all'interno di elementi portType). Elemento WSDL
binding definition fault import input message operation output part port portType service types

Interfaccia JWSDL
javax.wsdl.Binding javax.wsdl.Definition javax.wsdl.Fault javax.wsdl.Import javax.wsdl.Input javax.wsdl.Message javax.wsdl.Operation javax.wsdl.Output javax.wsdl.Part javax.wsdl.Port javax.wsdl.PortType javax.wsdl.Service javax.wsdl.Types

Tabella 6: Corrispondenza fra elementi in WSDL ed interfacce in JWSDL

112

4.Sviluppo ed implementazione: SAscha Oltre a queste, JWSDL espone altre due interfacce provviste di metodi per la serializzazione e deserializzazione di documenti WSDL, estensioni incluse, da e verso XML: WSDLReader e WSDLWriter. L'accesso alle implementazioni di queste due interfacce consentito dai metodi newWSDLReader() e newWSDLWriter() della classe astratta WSDLFactory. Di per s, JWSDL si compone di un insieme di interfacce, classi astratte e classi con metodi statici di utilit. Essa mette dunque a disposizione un object model, ma non ne fornisce un'implementazione concreta. L'implementazione di riferimento per JWSDL rappresentata dalla libreria WSDL4J117, sviluppata da IBM fino al novembre 2006 e rilasciata sotto Common Public License, la licenza open source di IBM [CPL10]. WSDL4J implementa l'intero modello base di JWSDL, pi alcune sue estensioni per l'accesso a XML Schema annidati (che sono invece rappresentati in DOM) e per rappresentare binding di tipo HTTP, MIME e SOAP [ABBD+06]. Per accedere alle classi che implementano l'object model, WSDL4J fornisce una specializzazione di
WSDLFactory

e un'implementazione di WSDLReader e WSDLWriter. La distribuzione di

WSDL4J comprende sia l'ultima versione di JWSDL (inclusa nel package javax.wsdl e suoi discendenti) che l'implementazione stessa (nel package com.ibm.wsdl e suoi discendenti). La coppia JWSDL+WSDL4J si rivelata perfettamente adatta agli scopi del nostro progetto, sia per il supporto della versione richiesta di WSDL che per le possibilit di estendere il linguaggio. Essa risente, purtroppo, di due difetti connessi alle circostanze in cui stata sviluppata: in primo luogo, essendo scritta in Java 1.4, manca del supporto per le Java Generics [Bra04], vale a dire che non possibile parametrizzare tipi come List, Set o Collection. Questo problema pu essere superato, ma richieder un controllo dei tipi pi rigoroso nel codice interno di SASCHA. In secondo luogo, essendo specifica per la versione 1.1 del linguaggio WSDL e non
117 http://sourceforge.net/projects/wsdl4j

113

4.Sviluppo ed implementazione: SAscha avendo prospettive di adeguamento a nuovi standard, questa API sembra giacere su di un binario morto, perci non adatta a progetti a lungo termine. Essa pertanto stata adottata ai fini di questo progetto, ma con la prospettiva di migrare, una volta che abbia raggiunto un grado di maturit sufficiente, a quello che pu essere considerato il suo successore spirituale, descritto di seguito.
4.2.2.2 Woden

Nato a met 2005 in seno allApache Web Service Project118, Woden un progetto mirato allo sviluppo di una libreria Java che consenta la gestione completa di documenti WSDL. Il gruppo di lavoro per questo progetto si compone per oltre due terzi di membri di IBM, avvalendosi, per la restante parte, della collaborazione dellUniversit dellIndiana119 e della Open Source SOA Company (WSO2)120. Mentre non ne esiste ancora una versione stabile, la pi recente release intermedia, al momento della stesura, la 1.0 Milestone 8, rilasciata il 24 aprile 2008. Questa stata anche la versione che ha debuttato ufficialmente come parte dellApache Web Service Project. E espressamente dichiarato nella pagina del progetto che Woden nasce con lintento iniziale di supportare la versione 2.0 della specifica WSDL, con la previsione di sviluppi successivi che integrino versioni passate e future dello standard. Proprio questa limitazione, poi confermata da un esame ravvicinato della libreria dinteresse, ha costituito forte motivo ostativo per ladozione della suddetta allinterno del progetto SASCHA. IBM ha contribuito al progetto con la concessione del codice sorgente di WSDL4J. Diversamente da quest'ultimo, per, Woden non sar un'implementazione di JWSDL (l'object model su cui basato WSDL4J) ma riusa parte del codice e della propriet intellettuale di WSDL4J per sviluppare un processore WSDL 2.0. Nel lungo termine, il progetto Woden potrebbe avvalersi dell'esperienza passata di sviluppo di
118 http://ws.apache.org 119 http://www.indiana.edu 120 http://wso2.com

114

4.Sviluppo ed implementazione: SAscha strumenti per processare WSDL e mettere a disposizione un vero e proprio framework che possa adattarsi a pi versioni del linguaggio senza bisogno di riscrivere il parser. Nella prossima sezione sar esaminata, tra le altre, la libreria Java che estende Woden con il supporto per SAWSDL. Anche se le carenze dell'attuale Milestone rilasciata sono tali da non consentirne l'utilizzo nel nostro progetto, utile prenderla in esame ugualmente, poich potrebbe rappresentare lo step successivo per la creazione di uno strumento a supporto dei Web Service semantici nel loro insieme.

4.2.3. Librerie per il supporto all'estensione SAWSDL

Ferma restando lintenzione di adottare WSDL4J come framework per la gestione dei documenti WSDL che compongono un Accordo di Servizio, ci si posti il problema di affiancare ad esso unestensione che supportasse annotazioni semantiche secondo la specifica SAWSDL. Sulla base del rapporto fornito dal W3C in merito alle esistenti implementazioni della specifica [KBP07], nonch della documentazione per i rispettivi progetti, sono stati individuati tre candidati open source: Woden4SAWSDL, WSMO4J e SAWSDL4J. I principali criteri per valutare la rispondenza alle necessit del progetto sono elencati di seguito: 1. Supporto per documenti WSDL versione 1.1, secondo le specifiche del WS-I Basic Profile 1.1 adottato in SPCoop. 2. Metodi di accesso ai model references di un elemento via operazioni di estrazione, aggiunta e cancellazione. 3. Livello di integrazione con l'object model di WSDL4J. 4. Flessibilit, a fini di estensione per supportare documenti XSD indipendenti. 5. Minimalit, inteso come non appartenenza a framework eccessivamente 115

4.Sviluppo ed implementazione: SAscha complessi. Si anticipa da subito che la scelta definitiva, per quanto non priva di aspetti controversi, ricaduta sulla libreria open-source SAWSDL4J.
4.2.3.1 Woden4SAWSDL

Risulta dalla pagina di Woden che i progetti attualmente noti che ne impieghino lAPI siano: (i) Apache Axis 2, limplementazione Java del principale motore per Web Service impiegato dalla Apache Software Foundation; (ii) Apache ServiceMix, un middleware per infrastrutture dimpresa basato su SOA.; (iii) Woden4SAWSDL, un object model per laccesso a documenti SAWSDL rispondenti ai requisiti di Woden. Ovviamente, il terzo progetto stato quello che ha raccolto la nostra attenzione come candidato allimpiego nel progetto SASCHA. Si pertanto proceduto ad unanalisi qualitativa approfondita di questa libreria. Woden4SAWSDL richiede la libreria WSDL4J come dipendenza a tempo di compilazione; tuttavia, come riscontrato dalla documentazione JavaDoc, le interfacce esposte da questa libreria per rappresentare elementi di una definizione WSDL non estendono n coincidono con quelle di JWSDL. Woden4SAWSDL fa s uso di interfacce per rappresentare elementi del modello delle componenti WSDL, demandando limplementazione dei metodi daccesso a classi specializzate, che vengono istanziate da appositi oggetti di tipo
WSDLFactory

(ad

esempio

l'interfaccia di tipo

org.apache.woden.wsdl20.InterfaceOperation operation).

rappresenta

elementi

Tuttavia, queste interfacce e le classi che le implementano, pur basandosi

sulle corrispettive in JWSDL, non estendono queste ultime, ma sono quasi sempre create ex novo. Questa caratteristica, se da un lato desiderabile perch facilita una migrazione per quanto possibile indolore tra le due API, dallaltro rende pressoch inutile una conoscenza approfondita di WSDL4J. Lesame delle specifiche ha inoltre confermato come, allo stato attuale, 116

4.Sviluppo ed implementazione: SAscha Woden4SAWSDL non supporti le componenti della specifica WSDL 1.1; in particolare, non vengono fornite interfacce per accedere a quelle componenti definite esclusivamente in questa versione della specifica, come ad esempio message e part. Laccesso agli attributi aggiuntivi definiti dalla specifica SAWSDL viene fornito da metodi statici della classe di utilit edu.uga.cs.lsdis.wsdl20.util.SAWSDLUtil. Sfortunatamente, un esame di quest'ultima classe ha riscontrato la completa mancanza, attualmente, di funzioni che permettano allutente di assegnare o modificare annotazioni semantiche alle varie componenti WSDL. Gli unici metodi presenti consentono laccesso a tali annotazioni solamente in lettura, e consistono in varie specializzazioni, per mezzo di overloading, dei metodi getLiftingMapping(), getLoweringMapping() e getModelRef(). Come ovvio, questa carenza ha influito pesantemente sulla scelta finale della API da adottare.
4.2.3.2 WSMO4J

Come per leditor WSMO Studio, il set di librerie WSMO4J fa parte delle implementazioni pi conosciute che fanno capo allontologia di riferimento per i Web Service WSMO, o Web Service Modeling Ontology [KLR05]. WSMO4J consiste in una API, corredata da unimplementazione di riferimento per la costruzione sia di Web Service che di processi aziendali semantici. LAPI fortemente modularizzata e si compone di vari sottoprogetti, fra cui un modulo per la modellazione di coreografie e orchestrazioni, un'implementazione di WS-BPEL [JEAA+07] per definire i processi aziendali basati su Web Service, ed una Grounding API, con supporto per la gestione di descrittori WSDL annotati secondo le specifiche SAWSDL. Quest'ultima stata presa in esame nell'interesse del presente progetto, per valutarne la completezza ed attinenza alle specifiche richieste. La Grounding API inclusa con la distribuzione di WSMO4J si compone di due librerie, grounding-api e grounding-impl, entrambe attualmente alla versione 0.1.0. La prima contiene linsieme di interfacce Java necessarie per la gestione delle 117

4.Sviluppo ed implementazione: SAscha annotazioni semantiche, pi una classe Factory che si occupa di fornire parser e serializzatori da e verso XML, un tipo di evento per indicare laggiunta o rimozione di annotazioni semantiche e una classe di costanti con i nomi locali e i namespace degli attributi SAWSDL, come definiti dalla specifica W3C. La seconda libreria d unimplementazione di riferimento per tutte le interfacce incluse nella grounding-api. Pur basando il proprio object model su interfacce, WSMO4J non estende n utilizza lobject model di WSDL4J. La libreria difatti stand-alone e non ha dipendenze esterne. Il punto daccesso alle annotazioni semantiche di un documento WSDL rappresentato dallinterfaccia org.wsmo.grounding.sawsdl.Grounding, da cui il nome dellAPI, di cui rappresenta il fulcro. Un oggetto di tipo Grounding contiene tutte le annotazioni SAWSDL di un documento WSDL, compresi gli elementi XML Schema inclusi in un elemento wsdl:types. Ciascuna annotazione rappresentata da una specializzazione dellinterfaccia org.wsmo.grounding.sawsdl.ModelRef. Il tipo di questa interfaccia specializzata funzione soltanto del tipo della componente WSDL annotata. Qualunque oggetto di tipo ModelRef registrato con una ed una sola istanza di Grounding e non pu essere condiviso tra pi oggetti. Si osserva che questa interfaccia contiene tutti i metodi per laggiunta, elencazione e rimozione di annotazioni SAWSDL, ad esempio
createAttributeModelRef(), createOperationModelRef()

e listModelRefs().

Sono presenti anche metodi che tengono o meno conto anche delle annotazioni propagate per quegli elementi, come simpleType e complexType di XML Schema, che supportano la propagazione delle annotazioni.
4.2.3.3 SAWSDL4J

Il progetto SAWSDL4J mira alla creazione di un object model semplice ma completo per la gestione di descrittori WSDL con supporto per l'annotazione semantica.

118

4.Sviluppo ed implementazione: SAscha La libreria progettata e sviluppata da Karthik Gomadam del centro Kno.e.sis121 e da Douglas Brewer, Zixin Wu e Ajith Ranabahu del laboratorio LSDIS (Large Scale Distributed Information Systems)122. Lultima versione rilasciata, la Milestone 3, risale a giugno 2007. Questa versione, cos come le precedenti, indicata nella pagina Maven del progetto come una "Early Access Release", lasciando intendere che non tutte le modalit di accesso agli elementi semantici di un documento WSDL potrebbero essere disponibili. Come per Woden4SAWSDL, questa API viene rilasciata sotto licenza Apache 2.0. La principale caratteristica di SAWSDL4J di estendere direttamente lobject model di WSDL4J. I due pacchetti software richiesti da SAWSDL4J a tempo di compilazione sono infatti le distribuzioni di WSDL4J e Jaxen123. La prima dipendenza, gi approfonditamente descritta in precedenza, discende dal fatto che SAWSDL4J espone delle interfacce, oltre alle loro implementazioni, che sono dirette specializzazioni, arricchite di potenziale valore semantico, di interfacce e classi WSDL4J recanti lo stesso nome. Jaxen una libreria open source a supporto del linguaggio Xpath [ClaDer99], adattabile a diversi object model tra cui DOM, XOM, DOM4J e JDOM. Il linguaggio XPath, o XML Path Language, nella recente versione 2.0 [BBCF+07], divenuto una raccomandazione W3C il 23 gennaio 2007. Esso si basa sulla rappresentazione ad albero di un documento XML e ne consente la navigazione, identificandone i nodi per mezzo di espressioni del linguaggio. Nel caso di SAWSDL4J, la necessit di utilizzare un motore XPath nasce dalla dicotomia nella rappresentazione degli elementi di tipo XML Schema (presentati in DOM) rispetto a quelli di tipo WSDL (presentati in JWSDL). Questo significa, in un esempio pratico, che mentre un elemento di tipo
wsdl11:portType

viene astratto dallinterfaccia javax.wsdl.PortType, non esiste

uninterfaccia del genere per xsd:element. Pertanto, se si desidera intervenire su

121 http://knoesis.wright.edu 122 http://lsdis.cs.uga.edu 123 http://jaxen.codehaus.org

119

4.Sviluppo ed implementazione: SAscha elementi di un XML Schema incluso in una specifica WSDL (per esempio aggiungendo, come nel nostro caso, un attributo modelReference), necessario agire direttamente sulla sua rappresentazione DOM. La libreria SAWSDL4J utilizza il linguaggio XPath e la sua implementazione in Jaxen per manipolare direttamente lalbero DOM di un XML Schema. Lestensione di WSDL4J viene effettuata tramite specializzazione sia delle sue interfacce che della loro implementazione di riferimento. Esemplificando, linterfaccia
javax.wsdl.Definition,

che fornisce una rappresentazione di un intero documento estesa in SAWSDL4J dallinterfaccia che integra nella precedente i metodi di

WSDL,

viene

edu.uga.cs.lsdis.sawsdl.Definition,

accesso a versioni specializzate delle varie componenti WSDL di primo livello come
Message

(accessibile per mezzo del metodo getSemanticMessage(QName name)) e (accessibile per mezzo del metodo getSemanticPortType(QName name)).

PortType

Limpostazione di questi elementi nella loro versione specializzata resa possibile tramite overloading dei rispettivi metodi. Naturalmente, il programmatore mantiene la possibilit di accedere alle versioni standard di questi costrutti, eseguendo il casting o invocando i rispettivi metodi di WSDL4J. Lo stesso discorso vale per le classi Java che implementano le suddette interfacce. Resta da definire in che modo sia possibile garantire allutente-programmatore che il parser WSDL utilizzato sia quello fornito da SAWSDL4J, in grado di estrarre correttamente le annotazioni semantiche a partire dalle variabili SAWSDL
modelReference, liftingSchemaMapping, loweringSchemaMapping

dallelemento attrExtensions definito per le operazioni. Allo stesso tempo, si deve garantire che tali annotazioni siano esposte per mezzo di classi ed interfacce specializzate, e che vengano preservate al momento della serializzazione in XML. Questa tecnica di estrema importanza, poich verr sfruttata in seguito nella fase di estensione di questa libreria. SAWSDL4J si avvale di una caratteristica della classe astratta javax.wsdl.factory.WSDLFactory, vale a dire la possibilit di definire a 120

4.Sviluppo ed implementazione: SAscha runtime il tipo della WSDLFactory che viene creata mediante una chiamata al suo metodo statico newInstance(). Questo tipo pu essere impostato tramite il metodo standard Java System.setProperty(String key, String value), dove la chiave (argomento key) la stringa "javax.wsdl.factory.WSDLFactory" e il valore (argomento value) il nome della classe che si vuole utilizzare come implementazione di WSDLFactory. In questo modo, possibile impostare unimplementazione che generi direttamente istanze di WSDLReader, WSDLWriter, Definition ed ExtensionRegistry specializzate in SAWSDL4J. Per ottenere la lista di model reference da un particolare elemento di tipo XSD, necessario conoscere a priori un'espressione XPath che lo identifichi. Tale approccio, se da un lato comporta un minore dispendio di risorse computazionali (considerato che non si possono far assunzioni sulla dimensione dellalbero DOM di un XML Schema), dallaltro solleva due importanti questioni: in primo luogo, noi abbiamo comunque la necessit di rappresentare gli XML Schema attraverso un object model intermedio, vale a dire oggetti serializzabili da passare attraverso le chiamate RPC del Google Web Toolkit (e che vengono successivamente riusati per la rappresentazione ad albero dellinterfaccia utente). Pertanto, si rende necessario costruire a mano questa rappresentazione mediante una visita dellalbero DOM che tenga conto solamente delle componenti XML Schema dinteresse, scartando tutte le altre. In secondo luogo necessario tener conto di un requisito fuori standard dello strumento oggetto della tesi, vale a dire il supporto per lannotazione semantica di schemi XSD stand-alone, non necessariamente referenziati da documenti WSDL o da loro schemi embedded. Questa caratteristica non supportata da nessuna delle API esaminate sinora (mentre supportata da strumenti end-user come Radiant), perci sotto questo punto di vista esse si pongono tutti su un livello paritario. Tuttavia, la modalit di accesso alle annotazioni semantiche di un XML Schema fornita da SAWSDL4J suggerisce un possibile approccio per trattare schemi stand-alone in maniera analoga: possibile estendere lAPI con un plugin che supporti la creazione di unistanza di

121

4.Sviluppo ed implementazione: SAscha

Schema

in SAWSDL4J a partire direttamente da un documento XSD, per poi passarla al

motore SAWSDL dellapplicazione, che la tratta esattamente come le istanze di Schema per schemi importati da WSDL. Ipotizzando che SAWSDL potesse rappresentare la scelta definitiva per lAPI a supporto del progetto (soprattutto in virt del supporto WSDL 1.1 e del fatto che estenda WSDL4J) si proceduto ad una fase ulteriore di testing ed analisi del codice sorgente. Le prime lacune sono emerse proprio nellesecuzione di un programma Java che restituisse i model reference di un documento WSDL annotato appositamente fornito. E stato riscontrato che tale programma non restituiva gli insiemi di URI desiderati, appositamente codificati nel documento WSDL di riferimento. Mentre, come vedremo, questi difetti sono risolvibili intervenendo sulle rispettive classi di costanti e sul parser, stata riscontrata da test successivi la mancata implementazione, nella versione odierna della libreria, di alcune funzionalit essenziali per implementare i casi duso del progetto SASCHA. I pi evidenti sono elencati di seguito e sono limitati allo scope del progetto, escludendo quindi la gestione delle annotazioni di tipo schema mapping: 1. Al momento della scrittura in XML della definizione WSDL annotata, gli eventuali riferimenti aggiunti non vengono correttamente serializzati. In particolare, se lattributo sawsdl:modelReference non gi presente non viene creato, mentre se presente non viene aggiornato il suo valore. 2. Non gestito il caso in cui si rimuova uno pi URI dallinsieme di model reference. Questo implica la mancata rimozione dellattributo quando questo insieme vuoto, cos come dellelemento sawsdl:attrExtensions richiesto per lannotazione semantica di operazioni in WSDL 1.1. Sono stati anche riscontrati casi di model reference duplicate in ragione di questa lacuna. 3. Lindentazione dei tag XML spesso scorretta e non fa uso di tabulazioni.

122

4.Sviluppo ed implementazione: SAscha Inoltre non viene effettuata alcuna formattazione sui nodi di tipo XML Schema, che vengono mantenuti cos come sono, il che pu rappresentare un problema se il documento originale formattato in maniera confusionaria.
4.2.3.4 Riepilogo

I risultati dell'analisi di queste tre tecnologie sono riassunti in tabella 7. Vantaggi Woden4SAWSDL

Svantaggi
previsto, ma attualmente assente

In attivo sviluppo e con Supporto per WSDL 1.1 previsioni di un futuro supporto per vari dialetti di WSDL Ricalca JWSDL da vicino

Accesso alle annotazioni in sola lettura

l'intuitivo object model di Fortemente orientato

all'estensibilit senza per richiedere un intervento diretto sulla core API

WSMO4J Grounding API

Gestione delle annotazioni Mancato SAWSDL in un layer indipendente

supporto

di

WSDL 1.1 Manca di un object model per gli elementi WSDL, pertanto non possibile operare con esso prescindendo da WSDL4J

Completa di tutti i metodi d'accesso alle annotazioni semantiche di un documento WSDL

API molto pi ricca e complessa richiesto progetto ai di quanto fini del

123

4.Sviluppo ed implementazione: SAscha SAWSDL4J

Supporto per WSDL 1.1 Estensibile con

Sviluppo discontinuo XML e la rimozione o modifica di annotazioni non sono implementate Annotazioni XSD gestite in maniera non coerente con quelle di WSDL

Integrazione con WSDL4J La serializzazione verso annotazioni fuori standard

Tabella 7: Comparazione di librerie Java per SAWSDL Bench attivamente sviluppata e con eccellenti prospettive per una successiva adozione in future applicazioni per Web Service semantici, per la gravit delle sue attuali limitazioni, la libreria Woden4SAWSDL non stata ritenuta sufficientemente matura per un immediato impiego allinterno del progetto SASCHA. D'altro canto la WSMO4J Grounding API, pur costituendo solamente una minima parte dellAPI di riferimento di WSMO4J, si rivela un ottimo strumento per la gestione di documenti WSDL 2.0 annotati semanticamente, lasciando al tempo stesso al programmatore la libert di utilizzare qualsiasi altra libreria per disporre di un object model completo per lanalisi dettagliata dei costrutti WSDL standard. Tuttavia, il mancato supporto per WSDL 1.1 ha finito per pregiudicare la candidatura di questa libreria per limpiego come middleware per il supporto semantico in SASCHA. Il fatto che SAWSDL4J estenda lobject model di WDL4J presenta sia aspetti positivi che negativi. Uno degli aspetti controversi l'impossibilit di parametrizzare i tipi generici che utilizza (ad esempio Set o List), che obbliga il programmatore ad eseguire esplicitamente il casting degli inner types, operazione il cui esito corretto non garantito. Tale anomalia definita come unchecked casting. Altro aspetto controverso il modo in cui viene gestito il cosiddetto loose-coupling, o accoppiamento debole, per estendere lAPI di WSDL4J. Il fatto che il programmatore debba, a seconda dei casi, scegliere di utilizzare uninterfaccia standard o quella specializzata per gestire un elemento WSDL, comporta nelle difficolt nel passaggio da una rappresentazione

124

4.Sviluppo ed implementazione: SAscha allaltra. Ad esempio, eseguire il casting da

javax.wsdl.Operation

ad

edu.uga.cs.lsdis.sawsdl.Operation

pu fallire oppure restituire un oggetto le cui

informazioni semantiche sono comunque andate perdute. Tuttavia, la possibilit di definire a runtime la specializzazione di WSDLFactory suggerisce di poter sfruttare questa caratteristica per creare pi WSDLFactory con caratteristiche differenti, ad esempio per colmare le carenze della libreria allo stato attuale senza doverla sovrascrivere, o per serializzare lobject model in codice XML con evidenziamento della sintassi tramite rendering in HTML. Questa caratteristica, unita allinnegabile vantaggio di essere lunica API a supportare la versione 1.1 della specifica WSDL, ha fatto maturare la scelta di adottare questa API, almeno in via provvisoria, con la riserva di estenderla nel corso del progetto, sia per poter disporre delle feature non ancora implementate, sia per accomodare particolari necessit come il supporto per XML Schema stand-alone.

4.2.4. Librerie per la gestione delle ontologie

I campi del web semantico e dell'ingegneria delle ontologie sono stati un terreno molto battuto, negli ultimi anni, per quanto riguarda le implementazioni reali e possibili. Editor, sistemi di Content Management, ragionatori, browser di ontologie, interfacce, generatori di grafi RDF e framework come quelli visti alla fine del capitolo 2 sono solo alcune delle possibili categorie di strumenti che usano o consentono di gestire dati semantici. In questa fase ci si concentrati sulla ricerca ed analisi di librerie d'infrastruttura e ragionatori, con riguardo ai toolkit per OWL sviluppati in Java. Per brevit, saranno descritti nel seguito soltanto gli strumenti adottati.
4.2.4.1 OWL API e ragionatori

Nata originariamente come parte del progetto europeo WonderWeb, la OWL API oggi sviluppata nell'ambito dei progetti CO-ODE e TONES, mirati alla costruzione di infrastrutture, strumenti di authoring di ontologie e tecniche automatiche di ragionamento sulle stesse. Nelle sue versioni pi recenti OWL API focalizza sulla 125

4.Sviluppo ed implementazione: SAscha recente proposta di OWL 2, che raccoglierebbe le precedenti nozioni di OWL-Lite, OWL-DL e OWL-Full. Questa libreria completa di un object model che consiste di interfacce per rappresentare non solo concetti fondamentali in OWL quali classi, propriet ed individui, ma anche espressioni n-arie, restrizioni ed assiomi di ogni tipo (fra i quali possiamo citare dichiarazioni di dominio e range, disgiunzioni, importazioni, sottoclasse, sottopropriet, equivalenza ed annotazioni di entit). Sotto questo aspetto, essa ha sicuramente pi di una similitudine con le API scelte per WSDL. In aggiunta a questo modello, per, OWL API consente anche di processare ogni singolo concetto o assioma per mezzo del pattern Visitor [Mar02], per il quale possono essere implementate delle classi arbitrarie da utilizzare per scorrere ciascun tipo di dato in maniera dedicata. Anche se nel contesto del Sistema Pubblico di Cooperazione ci si aspetta che la conoscenza sia formalizzata prevalentemente in RDF/XML, l'utilizzo di questa libreria permette il supporto per vari sintassi alternative: in particolare, OWL API include parser per i formati RDF/XML, OWL/XML, Turtle e KRSS2. Inoltre, la libreria stand-alone, quindi priva di dipendenze esterne; tuttavia, prevista la sua integrazione con due dei ragionatori pi diffusi, che sono Pellet e FaCT++. Questo reso possibile perch, essendo OWL API finalizzata principalmente alla rappresentazione delle entit dichiarate per un'ontologia, essa mette a disposizione metodi di ragionamento limitati. Ad esempio, se si desidera derivare la gerarchia delle classi di un'ontologia rispetto alla relazione di sottoclasse, si pu utilizzare ToldClassHierarchyReasoner, che cablato dentro ad OWL API ma deriva la gerarchia sulla base delle sole asserzioni esplicitate nell'ontologia. Per derivare l'albero della classi sulla base di inferenze (ad esempio nel caso di classi equivalenti) possibile richiedere l'intervento di un DIGReasoner, che a sua volta si appoggia ad un ragionatore in logica descrittiva. Per quanto riguarda questo secondo caso, l'impiego di Pellet come ragionatore esterno parso pi che sufficiente per gli scopi del progetto. Si tratta di un completo 126

4.Sviluppo ed implementazione: SAscha sistema open source di ragionamento su ontologie con supporto per tutte le varianti di OWL e attualmente in sviluppo continuativo.

4.3. Estensione della libreria SAWSDL4J

Nella sezione dedicata all'analisi di librerie SAWSDL stato affermato che, per le limitazioni presentate in fase di analisi della documentazione e del codice sorgente, l'adozione di SAWSDL4J come API di riferimento per implementare il supporto di questo standard subordinata all'aggiornamento e all'estensione dell'API stessa. Il fine quello di soddisfare non solo i requisiti standard del modello proposto, ma anche quelli espressamente dichiarati per il Sistema Pubblico di Connettivit, che comunque rientrano nella specifica SAWSDL del W3C e sono supportati da alcuni strumenti esistenti fra cui Radiant. Nell'intraprendere questa scelta, il processo di estensione stato svolto su due versanti: il primo rappresentato dall'inclusione, per mezzo di un plugin denominato SAXSDL4J sviluppato allo scopo, del supporto per l'annotazione di schemi XSD standalone; il secondo ha riguardato la riscrittura o l'estensione dei metodi che realizzano funzionalit dichiarate dalle interfacce ma non ancora implementate, oppure implementate in maniera ad oggi non soddisfacente. Questa seconda base di codice stata cablata nell'applicazione principale, ma non si esclude di poterla proporre in veste di contributo al futuro sviluppo di SAWSDL4J.

4.3.1. Attuali limitazioni

L'esecuzione di semplici casi di test, in parallelo con l'esame del codice sorgente di SAWSDL4J, ha fatto emergere come le carenze funzionali di questa libreria, parzialmente esposte in precedenza, siano dovute in parte ad uno stato di sviluppo incompiuto ed in parte ad obsolescenza delle informazioni in essa codificate. Il primo fondamentale sintomo dato dal fatto che l'API, con la sua implementazione di riferimento, non estragga dal codice XML verso l'object model i valori degli attributi 127

4.Sviluppo ed implementazione: SAscha

modelReference

applicati nel rispetto della specifica SAWSDL per WSDL 1.1. Questa

lacuna si scoperto essere dovuta alle seguenti ragioni:

Il namespace utilizzato per la specifica SAWSDL, hard-coded allinterno della classe

edu.uga.cs.lsdis.sawsdl.impl.Constants

con

valore

"http://www.w3.org/2007/01/sawsdl#", deprecato e non corrisponde a quello indicato nella specifica W3C ("http://www.w3.org/ns/sawsdl"), che peraltro utilizzato negli Accordi di Servizio.

Unaltra classe SchemaConstants, che specifica i nomi di tutti gli elementi XML Schema validi, manca di una costante per indicare i nodi di tipo
attribute,

che sono fra quelli che ammettono l'attributo modelReference.

Se la definizione WSDL utilizza un namespace obsoleto per i nodi XML Schema, vale a dire http://www.w3.org/1999/XMLSchema questi nodi sono o http://www.w3.org/2000/10/XMLSchema, scartati

dall'implementazione SAWSDL4J del parser WSDLReader. Questo dovuto al fatto che questi namespace non sono registrati nella classe Constants. Intervenendo sulle classi Constants e SchemaConstants con l'aggiunta o sostituzione delle costanti sopraelencate, si ottengono correttamente tutti gli insiemi di model reference, senza ripetizioni, per tutti gli elementi che di norma li ammettono, compreso il caso di operation, per il quale necessario un elemento annidato
attrExtensions.

Tuttavia, sono emersi progressivamente altri sintomi, di seguito

ricapitolati, man mano che si procedeva con i test servendosi di soluzioni temporanee:

A seguito di una chiamata ai metodi WSDLWriter.writeWSDL(), i cambiamenti apportati agli insiemi di model reference per i vari elementi WSDL e XSD non si riflettono sul corrispondente codice XML.

Il caso di model reference vuoto (ad esempio per cancellazione del valore

128

4.Sviluppo ed implementazione: SAscha precedente) non correttamente gestito, in quanto viene ugualmente serializzato un attributo con valore vuoto quando sarebbe preferibile che non venisse serializzato affatto.

Similmente, l'elemento aggiuntivo attrExtensions non gestito correttamente, in quanto esso non viene eliminato in caso di model reference vuoto.

La gestione di annotazioni per elementi XML Schema, che avviene per mezzo di query XPath, monotona, quando invece dovrebbe consentire la cancellazione di riferimenti preesistenti. Questo comportamento dovuto al fatto che il metodo
Schema.setModelReferences()

implementato come un'iterazione di

chiamate a Schema.addModelReference() per ogni elemento dell'insieme passato come parametro. A sua volta, il metodo addModelReference() si limita a concatenare una nuova stringa a quella gi esistente, il che significa che potranno anche esserci ridondanze tra gli URI che compongono i valori per l'attributo modelReference. Infine, stato riscontrato in SAWSDL4J un difetto ereditario, che il mancato supporto di XML Schema indipendenti caricati singolarmente. Questo discende dal fatto che l'object model JWSDL non tratta documenti di questo tipo, mentre WSDL4J si limita a metterli a disposizione come alberi DOM, senza effettuarne la validazione.

4.3.2. Supporto SAXSD4J

per

schemi

XML stand-alone:

il

plugin

Si precedentemente detto che uno dei requisiti di SPCoop per integrare l'informazione veicolata dai servizi con valore semantico aggiunto la possibilit di utilizzare quella parte della specifica SAWSDL dedicata agli XML Schema (o XSD) per annotare documenti di questo tipo, anche quando il loro ruolo nel sistema non necessariamente dipendente da un descrittore WSDL che li importi. Questa funzionalit stata concertata considerando un ulteriore possibile caso d'uso, nel quale un soggetto di SPCoop, nel definire schemi concettuali da registrare nel Catalogo Schemi ed 129

4.Sviluppo ed implementazione: SAscha Ontologie, intenda integrare questi stessi schemi con riferimenti ad entit di ontologie presenti nel Catalogo stesso. Le classi di SAWSDL4J cui sono delegate la lettura e scrittura di un documento dispongono solo di metodi per deserializzare schemi a partire da un descrittore WSDL che vi faccia riferimento per mezzo del costrutto wsdl:import o di costrutti
xsd:import, xsd:include wsdl:types.

e xsd:redefine di uno schema incluso in un elemento

Non pertanto considerata la lettura e scrittura di documenti XML

Schema indipendenti. Allo stesso modo SAWSDL4J, pur consentendo (almeno a livello di interfaccia) le operazioni di annotazione su singoli elementi XSD, non supera questa limitazione dell'accesso a tali elementi. Per far fronte non solo a questa limitazione, ma anche alle varie lacune presentate dall'implementazione di riferimento nei limiti del supporto XSD, si pensato, anzich di emendare l'ultima versione della libreria, di estenderla per mezzo di un insieme minimo di risorse, proposto come plugin per SAWSDL4J e ribattezzato come SAXSD4J (Semantic Annotations for XML Schema Definitions for Java). Obiettivi di SAXSD4J sono i seguenti:

Fornire delle classi di factory, lettori e scrittori per dare supporto completo alla lettura e scrittura di documenti XSD senza che debbano essere importati transitivamente.

Presentare un'implementazione alternativa per l'interfaccia SAWDL4J estesa

edu.uga.cs.lsdis.sawsdl.extensions.schema.Schema,

per consentire la

gestione puntuale dei model references per un elemento XSD. La corretta gestione degli schema mapping uno dei possibili scenari di sviluppo futuro di questo plugin, ma non essendo richiesta dalle specifiche di SPCoop, essa stata tralasciata ai fini del presente progetto.

130

4.Sviluppo ed implementazione: SAscha

4.3.2.1 Struttura del progetto

A tempo di compilazione, il plugin SAXSD4J dipende dalle librerie WSDL4J, SAWSDL4J e Jaxen. Queste dipendenze discendono dalla necessit, da un lato, di fornire un object model compatibile con quello di SAWSDL4J e dall'altro, di estendere le funzionalit di WSDL4J per il marshalling dall'albero DOM al codice XML e viceversa. Inoltre, per l'individuazione dei nodi da annotare dell'albero DOM di uno schema, si fa uso dello stesso motore XPath usato da SAWSDL4J, vale a dire Jaxen.

Figura 18: Diagramma delle classi di SAXSD4J

131

4.Sviluppo ed implementazione: SAscha Come si vede dal diagramma UML in figura 18, le specifiche della classe astratta
SchemaFactory

e dell'interfaccia SchemaReader sono autoesplicative, e ricalcano da

vicino i loro corrispettivi in WSDL4J WSDLFactory e WSDLReader. Tuttavia, al fine di mettere in evidenza il valore aggiunto da questa implementazione, vale la pena di soffermarsi sulle segnature del metodo readSchema() di SchemaReader, le cui funzionalit vengono riflesse dalla classe SchemaReaderImpl. Tutti questi metodi sono pubblici e restituiscono un oggetto di tipo Schema in SAWSDL4J, quindi completo del supporto per le annotazioni semantiche:

readSchema(String

documentBaseURI,

Document

schemaDocument,

boolean recurseReferences)

assume che l'albero DOM del documento sia

gi stato costruito e abbia schemaDocument come radice. Il metodo verifica che la radice indichi effettivamente un nodo xsd:schema, dopodich ne estrae l'elemento DOM e invoca la lettura dell'albero a partire da esso.

readSchema(String

documentBaseURI,

Element

schemaElement,

boolean recurseReferences)

effettua la visita in pre-ordine dell'albero DOM

a partire dall'elemento schemaElement (che assume essere di tipo xsd:schema). l'unico metodo che esamina ricorsivamente altri schemi referenziati dai costrutti xsd:import, xsd:include e xsd:redefine.

readSchema(String recurseReferences)

schemaURI,

String

contextURI,

boolean

tenta di recuperare un documento XSD dalla locazione

fisica identificata da schemaURI. Se contextURI nullo o la stringa vuota, ci significa che lo schema cercato da considerarsi stand-alone, altrimenti relativo allo schema il cui base URI definito da contextURI. importante notare che questo l'unico metodo ad invocare la costruzione dell'albero DOM del documento.

readSchema(String schemaURI, boolean recurseReferences)

equivale ad

una chiamata al metodo sopra indicato con contextURI = . 132

4.Sviluppo ed implementazione: SAscha Un'opportuna combinazione di chiamate ai sopracitati metodi ci mette a disposizione, mimando il modello di WSDL4J, tutto ci che necessario per la gestione di un documento XSD: un oggetto di tipo Schema nel modello SAWSDL4J, con una via d'accesso al suo albero DOM (tramite il metodo getElement()) che il programmatore pu manipolare a piacimento. Si evidenzia che, mentre ai fini del presente progetto la gestione si limita all'uso di un singolo attributo, il livello di astrazione impiegato consente un accesso general-purpose allo Schema.
4.3.2.2 Un'implementazione alternativa dell'interfaccia Schema

Dopo aver reso possibile la lettura e scrittura di un documento XML Schema stand-alone, occorre far fronte all'assenza di un supporto adeguato all'aggiunta ed impostazione dell'attributo sawsdl:modelReference agli elementi di tale documento. A tal fine si propone un'implementazione per l'interfaccia Schema di SAWSDL4J che estenda quella di riferimento SchemaImpl. Tale implementazione consiste nella classe
saxsd.impl.SchemaImpl. SchemaFactoryImpl

Tutti gli oggetti di tipo Schema che vengono creati da

sono istanze di questa classe.

Di seguito si elencano le funzionalit attese dai metodi di accesso ai model references dell'interfaccia Schema, in particolare come ci si aspetta che essi modifichino lo stato di un oggetto di tipo Schema:

addModelReference(Element ModelReference ref)

startElement,

String

path,

aggiunge il riferimento ref all'insieme di model

references del primo elemento XSD individuato valutando l'espressione XPath

path

a partire dall'elemento DOM startElement. Poich la collezione di model A supporto di questo requisito si fa presente che,

references per un elemento viene trattata come un insieme, necessario evitare ripetizioni. nell'implementazione di riferimento, due oggetti di tipo ModelReference sono uguali se e solo se lo sono i rispettivi URI cui fanno riferimento.

133

4.Sviluppo ed implementazione: SAscha

getModelReferences(Element startElement, String path, Definition def)

restituisce l'insieme di model reference del primo elemento XSD Analizzando il codice sorgente si osservato che l'argomento

individuato valutando l'espressione XPath path a partire dall'elemento DOM

startElement. def

(che indica una definizione WSDL) non concretamente utilizzato per

reperire queste informazioni, trattandosi probabilmente di un segnaposto per un'implementazione futura. Si deciso pertanto di conservare questa segnatura per compatibilit, poich un eventuale valore null per questo argomento non genera eccezioni n inficia l'effettivit del metodo. importante puntualizzare che in questo insieme sono contenuti anche eventuali model references propagati: se l'elemento in esame ha un valore per l'attributo type, saranno inclusi anche i riferimenti del corrispondente simpleType o complexType.

getModelReference(Element startElement, String path, Definition def)

restituisce il primo elemento incontrato iterando sull'insieme restituito da

getModelReferences().

setModelReferences(Element Set<ModelReference> refs)

startElement,

String

path,

assegna refs all'insieme di model references del

primo elemento XSD individuato valutando l'espressione XPath path a partire dall'elemento DOM startElement. Se refs null o l'insieme vuoto, equivale alla rimozione dell'attributo sawsdl:modelReferences per quell'elemento. Si osserva che l'interfaccia Schema estesa da SAWSDL4J non espone metodi per la rimozione di model references. Pertanto necessario emulare questa operazione facendo ricorso al metodo setModelReferences(), che come terzo argomento ricever l'insieme di model references che si intendono conservare. Mentre nella forma originaria l'URI corrispondente all'annotazione da effettuare viene appeso direttamente alla stringa del valore corrente di sawsdl:modelReference (il che comporta un rischio concreto di trovarsi con URI ripetuti), nell'implementazione 134

4.Sviluppo ed implementazione: SAscha SAXSD4J si scelto di estrapolare l'insieme di model references dal valore corrente dell'attributo, per poi serializzarlo in una stringa dopo aver eseguito l'unione di questo insieme con il singleton costituito dal nuovo model reference. da notare che, dovendo in questo caso restringersi all'insieme di URI estrapolato dal valore dell'attributo per un certo elemento, i model references propagati non vengono presi in considerazione. In questo modo si trae vantaggio dalla disponibilit di una struttura dati, quale
java.util.Set,

che non ammette ripetizioni.

L'implementazione di setModelReferences(), che stato invece riscritto da capo, sfrutta questa stessa intuizione, oltre ad interpretare il passaggio di un insieme nullo o vuoto come una richiesta di cancellazione dell'attributo
sawsdl:modelReference.

infine opportuno aggiungere che stato necessario

estendere la classe Constants di SAWSDL4J, sostituendo il valore deprecato della costante NS_URI_SAWSDL con il namespace definitivo stabilito dalla specifica W3C, vale a dire http://www.w3.org/ns/sawsdl.

4.3.3. Integrazione delle funzionalit incomplete

Per quanto riguarda le altre funzionalit di SAWSDL4J che si sono rivelate essere inefficacemente implementate, si optato per includerle in un apposito package del backend di SASCHA, denominato org.example.sascha.server.wsdl.override. Questo package contiene non solo le classi che integrano alcune funzionalit critiche della libreria, ma anche alcune classi specializzate aggiuntive a supporto della generazione di codice XML, a sua volta codificato in HTML. Questa caratteristica in realt un requisito esclusivo dell'applicativo SASCHA per visualizzare nell'interfaccia grafica il codice del documento con evidenziamento della sintassi XML, pertanto se ne rimanda la discussione alla sezione successiva. Gli emendamenti a SAWSDL4J proposti in questa sezione riguardano quasi esclusivamente l'implementazione di riferimento, in quanto la libreria soddisfa appieno i nostri requisiti dal punto di vista delle interfacce esposte, fatta ovvia eccezione per il 135

4.Sviluppo ed implementazione: SAscha supporto di schemi XSD stand-alone, ampiamente discusso nella sezione precedente. In particolare, gli aspetti su cui ci si concentrati sono:

Garantire che si utilizzi come riferimento per le annotazioni SAWSDL il namespace standard indicato dalle specifiche della raccomandazione.

Fornire supporto completo all'estrazione, aggiunta e cancellazione di annotazioni semantiche di tipo model reference per quei costrutti WSDL che li supportano, garantendo nel contempo l'assenza di ridondanze degli URI che compongono il valore di tale attributo.

Dare speciale supporto all'elemento sawsdl:attrExtensions, appositamente definito per il costrutto operation in WSDL 1.1, che non estensibile per mezzo di attributi esterni. In particolare, si deve far s che tale elemento non sia presente se non dotato di almeno un attributo con un valore ammissibile.

Migliorare la resa estetica dei documenti WSDL una volta trasformati in XML, gestendo parametri tra cui la corretta indentazione e l'ordinamento dei namespace dichiarati. Per affrontare tutti questi aspetti, si sfruttata la stessa particolarit di WSDL4J su

cui si basa anche SAWSDL4J, vale a dire l'accoppiamento debole tra l'interfaccia
WSDLFactory

e la sua implementazione. Nel package inclusa, infatti, una

specializzazione di questa classe astratta, denominata WSDLFactoryImpl, che provvede all'istanziazione di implementazioni personalizzate di WSDLReader, WSDLWriter ed
ExtensionRegistry.

Per mezzo di queste classi specializzate possibile impostare un

parametro di sistema, il cui valore viene letto ed utilizzato dal metodo statico
newInstance()

della classe astratta javax.wsdl.factory.WSDLFactory, contenente il

nome della classe da utilizzare come implementazione di riferimento di WSDLFactory. Questa operazione pu essere effettuata in qualsiasi momento, e se ne illustra un esempio nel breve frammento di codice che segue:

136

4.Sviluppo ed implementazione: SAscha

// Si imposta un'implementazione di WSDLFactory che ci // consenta di maneggiare le annotazioni semantiche. System.setProperty("javax.wsdl.factory.WSDLFactory", "org.example.sascha.server.wsdl.override.WSDLFactoryImpl");

Si ricorda che lo scope di queste propriet di sistema, nel nostro caso di un'applicazione web, limitato dalla sessione utente, la quale viene gestita lato server tramite il web container da esso impiegato. Una volta impostata questa propriet, si ha la garanzia che le interfacce delegate alla serializzazione e deserializzazione di documenti e costrutti WSDL saranno istanziate secondo la seguente tabella: Interfaccia JWSDL di riferimento
javax.wsdl.Definition onImpl javax.wsdl.extensions.Extension org.example.sascha.server.wsdl.overri Registry javax.wsdl.xml.WSDLReader javax.wsdl.xml.WSDLWriter de.StandardExtensionRegistry org.example.sascha.server.wsdl.overri de.WSDLReaderImpl org.example.sascha.server.wsdl.overri de.WSDLWriterImpl

Classe di implementazione
edu.uga.cs.lsdis.sawsdl.impl.Definiti

Tabella 8: Mappa delle implementazioni estese Si entrer ora nel dettaglio delle classi di estensione sviluppate per questo progetto, evidenziandone le peculiarit per le quali esse soddisfano i requisiti dell'applicazione principale. La classe javax.wsdl.extensions.ExtensionRegistry, di cui non si finora parlato, ha lo scopo di tenere traccia degli attributi e degli elementi aggiuntivi ammissibili nei processi di serializzazione (o marshalling) e deserializzazione (o unmarshalling) di documenti WSDL da e verso la loro rappresentazione XML. Presso di essa sono registrate sia le classi che implementano le relative estensioni, sia quelle che effettivamente svolgono le operazioni di marshalling e unmarshalling, e che estendono rispettivamente i tipi ExtensionSerializer ed ExtensionDeserializer. La 137 specifica SAWSDL ammette tre attributi (modelReference,

4.Sviluppo ed implementazione: SAscha

liftingSchemaMapping

e loweringSchemaMapping, di cui solo il primo nell'interesse

di questa tesi) ed un elemento aggiuntivo (attrExtensions, definito esclusivamente per il costrutto operation di WSDL 1.1). pertanto necessario registrare presso un apposito ExtensionRegistry tutte le classi necessarie per la corretta interpretazione di questi costrutti aggiuntivi. Poich, tuttavia, l'implementazione fornita da SAWSDL4J si rivelata insufficiente, se ne dovuta scrivere un'estensione da registrare, al posto di quella di default, presso il nostro StandardExtensionRegistry. Le classi AttrExtensionsSerializer e AttrExtensionsImpl, utilizzate per l'estrazione dell'elemento attrExtensions e la sua inclusione nell'object model di SAWSDL4J, sono state estese per i seguenti scopi: 1. Far s che elementi di tipo attrExtensions privi di attributi o con un valore vuoto per modelReference (ad esempio se cancellati dall'utente) non compaiano nel codice XML. 2. Accertarsi che, quando viene creato un oggetto di tipo AttrExtensions, l'attributo modelReference e il suo valore vengano registrati nella mappa attributo valore per questo oggetto se e solo se il suo valore una stringa non vuota. 3. Richiedere che l'elemento stesso e i suoi attributi siano qualificati per mezzo del namespace corretto
http://www.w3.org/ns/sawsdl

anzich

http://www.w3.org/2007/01/sawsdl#.

La finalit di cui al punto 3, che stata espletata estendendo la classe Constants come stato fatto in SAXSD4J, anche alla base della necessit di fornire un'implementazione alternativa per l'interfaccia WSDLReader. Per risolvere il problema del namespace deprecato per le estensioni SAWSDL (che purtroppo hard-coded all'interno della libreria), si reso necessario riscrivere tutti quei metodi per il parsing degli elementi WSDL con supporto per l'annotazione semantica. Il corpo dei metodi in 138

4.Sviluppo ed implementazione: SAscha questione sostanzialmente identico, ma in luogo della vecchia classe Constants viene importata la sua versione estesa con il valore corretto per il namespace SAWSDL e per il qualified name che di esso si compone. Per quanto riguarda la classe WSDLWriterImpl, si puntualizza che gli emendamenti proposti rispetto alla sua versione originale hanno finalit esclusivamente estetiche e sono mirate alla produzione di un documento XML finale per quanto possibile ordinato e di pi facile comprensione umana. Le stesse considerazioni valgono per il metodo marshall() della classe AttrExtensionsSerializer. Non essendo di particolare interesse trascrivere il codice che realizza queste funzionalit, ci limitiamo ad elencare di seguito le modifiche apportate: 1. Garantire la corretta indentazione dei tag XML di apertura e chiusura annidati. La determinazione del livello di indentazione immediata poich l'annidamento predeterminato per tutti i costrutti dichiarati in WSDL. Per quanto riguarda gli elementi di tipo XSD, essi vengono resi (a meno di variazioni nelle loro annotazioni semantiche) esattamente come in origine, a meno che la classe
SchemaSerializerForText

del plugin SAXSD4J sia stata registrata nello

StandardExtensionRegistry.

2. Utilizzare tabulazioni in luogo dei whitespaces per effettuare l'indentazione. 3. Separare con una riga vuota i blocchi di dichiarazioni di types, message,
portType, binding

e service.

4. Mettere in ordine lessicografico i legami prefisso namespace indicati dal prefisso xmlns alla radice del documento. al vaglio, infine, la possibilit di far migrare il package override (meno le classi per il rendering HTML), in un'API separata che possa essere messa a disposizione come patch per SAWSDL4J, con la prospettiva di sottoporla al suo team di sviluppo come contributo ad un'eventuale prossima versione della libreria.

139

4.Sviluppo ed implementazione: SAscha

4.4. L'applicativo SASCHA

La realizzazione finale degli obiettivi indicati nella tesi un'applicazione web sviluppata appositamente e denominata SASCHA, le cui due iniziali possono arbitrariamente stare per Semantic Annotation o Service Agreement. Si tratta di uno strumento fortemente orientato alla modularit, non solo per la divisione di interfaccia utente e logica applicativa in due componenti che possano girare su due distinti sistemi, ma anche per l'accoppiamento debole fra i singoli elementi della logica applicativa delegati ciascuno all'interpretazione di un certo linguaggio formale. Questa linea di condotta ampiamente giustificata dai possibili orizzonti di sviluppo successivo, che nello specifico saranno trattati nell'ultimo capitolo, ma che in generale riguardano non solo l'adozione di future versioni delle librerie utilizzate, ma anche l'eventuale passaggio ad altri object model o l'arricchimento del set di funzionalit dell'applicazione stessa.

4.4.1. Architettura fisica dell'implementazione

Avendo ora a disposizione tutte le API necessarie ad implementare la soluzione proposta nei suoi vari livelli di astrazione e di trasporto, possibile rielaborare quanto descritto nella sezione 86 alla luce dei meccanismi e delle restrizioni che si applicano alle librerie selezionate. L'architettura applicativa si presenta dunque come mostrato in figura 19.

Figura 19: Diagramma dell'architettura fisica di SASCHA 140

4.Sviluppo ed implementazione: SAscha Da questo diagramma si pu comprendere come ciascuna risorsa,

indipendentemente dalla tipologia, attraversi tre stadi di trasformazione. Il primo il formato in cui essa originariamente codificata: nella maggior parte dei casi come dialetto di XML, ma nel caso delle ontologie consentita qualunque altra sintassi supportata da OWL API. Il secondo stadio determinato dalla particolare implementazione selezionata per ciascuna tipologia di risorsa, e corrisponde all'object model esposto da ciascuna libreria, quindi JWSDL per descrittori WSDL, DOM per schemi XSD e OWL API per le ontologie. Le trasformazioni fra questi due stadi sono svolte in maniera opaca da queste API. Il terzo stadio rappresentato da un object model comune su cui possano accordarsi i sistemi frontend e backend, ciascuno tramite le sue interfacce di servizi remoti, per il trasporto dei dati a mezzo RPC. Le trasformazioni fra il secondo ed in terzo stadio sono svolte da quei moduli che sono stati identificati come motori, e che sono modellati attorno alle librerie selezionate. teoricamente possibile mettere a disposizione implementazioni alternative di tali motori, specializzate per API diverse, ma non si esclude che questa architettura fisica possa in futuro evolversi. Le prossime sezioni descriveranno in dettaglio questo ultimo stadio e le sue ragioni ed implicazioni. Essendo ora noto che l'interfaccia utente sar sviluppata con un toolkit che metta a disposizione gli strumenti per gestire eventi asincroni d'interfaccia, come accade per Swing o AWT, si pu anche affermare che la gestione della risposta d'interfaccia alla ricezione delle risorse o a situazioni di errore avverr per mezzo di un analogo sistema di eventi.

4.4.2. SIOM: un object model intermedio per il passaggio di risorse fra client e server
Nell'architettura modulare del Google Web Toolkit il vantaggio di poter disaccoppiare l'implementazione dell'interfaccia utente e quella della logica applicativa, separandoli rispettivamente in un frontend e un backend, comporta un determinato costo implementativo. GWT mette a disposizione due metodologie, entrambe basate su HTTP, 141

4.Sviluppo ed implementazione: SAscha per la comunicazione fra queste due componenti, una lato client ed una lato server. Una, la pi semplice, consiste nell'utilizzo del framework GWT per le chiamate a procedura remota (RPC) in modo da poter invocare delle servlet Java in maniera trasparente, passando oggetti Java a mezzo di chiamate HTTP standard. In alternativa, se richiesto un controllo pi sofisticato sui dati inviati, anche possibile comporre ed inviare delle HTTP request personalizzate per mezzo di classi HTTP messe a disposizione da GWT lato client, con la riserva di gestire le corrispondenti HTTP response per mezzo di classi di utilit per la gestione di XML e JSON, anch'esse disponibili lato client. Nello sviluppo di SASCHA stata impiegata esclusivamente la strategia delle GWT-RPC, non essendoci alcuna prerogativa di gestire a grana fine il traffico HTTP. Per gestire con sicurezza il passaggio di parametri e tipi di ritorno di una chiamata a procedura remota da client a server, GWT richiede che tali tipi siano serializzabili. Il concetto di serializzabilit dei tipi in GWT riprende quello classico di Java che si basa sull'interfaccia standard java.io.Serializable. Tuttavia vi sono profonde differenze, dovute principalmente al fatto che GWT emula solo un insieme ristretto dell'API Java, pertanto usa meccanismi di serializzazione pi semplici e con una semantica meno sofisticata, che sar ora esposta in maggior dettaglio. Per poter essere utilizzato in un'interfaccia di servizio remoto, un tipo deve essere serializzabile nel framework GWT-RPC. Enunciamo di seguito sette postulati che definiscono l'insieme dei tipi di dato serializzabili: 1. Tipi primitivi quali char, byte, short, int, long, boolean, float e double sono serializzabili. 2. I tipi String, Date e i wrapper di tipi primitivi (Character, Byte, Short,
Integer, Long, Boolean, Float,

o Double) sono serializzabili. Le costanti dell'enumerazione sono

3. Un'enumerazione

serializzabile.

serializzate solo nel nome e non nel valore.

142

4.Sviluppo ed implementazione: SAscha 4. Un array di tipi serializzabili serializzabile. 5. Una classe definita dall'utente pu essere resa un tipo serializzabile se risponde a determinati requisiti (vedere nel seguito). 6. Ogni tipo diverso dalla classe Object per cui esista almeno una sottoclasse serializzabile serializzabile. 7. Nessun altro tipo di dato serializzabile. Con riferimento al postulato 5, una classe definita dall'utente deve, per essere serializzabile, soddisfare tutte le seguenti condizioni: i. assegnabile ad almeno una tra le interfacce java.io.Serializable
com.google.gwt.user.client.rpc.IsSerializable, e

o perch la implementa

direttamente oppure perch estende una classe serializzabile. ii. Tutti i suoi campi che non siano dichiarati n final n transient devono essere di tipi serializzabili. iii. O non ha alcun costruttore, o se ne ha, deve esistere almeno il costruttore di default (cio con zero argomenti).124 I vincoli appena illustrati, per quanto ampiamente giustificati da ragioni sia di sicurezza che di efficienza (nel senso che la compilazione deve produrre il minimo codice JavaScript possibile), delineano un'importante restrizione: non possibile passare, tramite chiamate GWT-RPC, le classi e le interfacce definite dagli object model forniti nelle varie API utilizzate per l'interpretazione di ontologie, schemi e descrittori WSDL. Ad esempio, non si pu definire una servlet con un metodo che restituisca direttamente un oggetto di tipo org.semanticweb.owl.model.OWLOntology oppure
javax.wsdl.Definition,

poich questi tipi non rispettano i vincoli di serializzabilit

124 In versioni di GWT precedenti la 1.5 era anche richiesto che il costruttore di default fosse pubblico. Dalla 1.5 in poi non sono pi imposti vincoli di visibilit.

143

4.Sviluppo ed implementazione: SAscha posti da GWT. Per ovviare a questa limitazione richiesto uno sforzo di programmazione ulteriore. La strategia adottata stata quella di scrivere un layer di emulazione di WSDL4J, SAWSDL4J, OWL API e W3C DOM, vale a dire una famiglia di packages composti di classi che mimano, nella struttura, nel contenuto e nei metodi esposti per accedervi, le analoghe interfacce delle librerie corrispondenti, opportunamente tagliate per presentare solo quei dati necessari alla manipolazione lato client (per la presentazione in forma grafica) e lato server (per la scrittura delle annotazioni semantiche). Questo strato di emulazione costituisce un object model intermedio per il passaggio di descrittori WSDL, schemi ed ontologie da e verso l'applicazione client. SIOM (SASCHA Intermediate Object Model) il modello intermedio definito nel precedente paragrafo; il suo codice sorgente interamente incluso nel package
org.example.sascha.client.common.beans

e specializzato per ciascuna tipologia di

risorsa nei suoi pacchetti figli. Come accade in GWT per le interfacce dei servizi remoti, per poter impiegare questi tipi di dato nelle transazioni client-server necessario che tutta questa famiglia di pacchetti sia compilata due volte e con due modalit differenti: come JavaScript, tramite il compilatore GWT, per effettuare le chiamate dall'applicazione client, e come bytecode standard di Java per la gestione da parte delle servlet. La scelta del nome del pacchetto discende dall'analogia fra i requisiti di serializzazione di GWT RPC e le caratteristiche di quelle componenti riusabili del linguaggio Java note come JavaBeans. Entrambe le tipologie di costrutti richiedono l'implementazione di interfacce marker che garantiscano la serializzabilit, e richiedono l'esistenza di un costruttore di default. Inoltre, l'object model intermedio di SASCHA prevede che le propriet di ciascun oggetto che ne fa parte siano accessibili per mezzo di metodi accessori e mutatori (comunemente noti come setter e getter). La naming convention adottata per le classi contenute in questi pacchetti prevede che, qualora esse rappresentino una particolare componente dell'object model originario, 144

4.Sviluppo ed implementazione: SAscha portino il nome di quella componente concatenata alla parola chiave Container.

Figura 20: Class diagram del package radice di SIOM Il package radice contiene tutte quelle classi che rappresentano il vero e proprio payload applicativo passato a mezzo RPC. In particolare, un oggetto di tipo
SAWSDLObject

pu contenere un descrittore WSDL e zero o pi schemi XSD

(ovviamente in forma serializzata), oltre a messaggi di diagnostica e codice XML, eventualmente gi formattato per essere reso in HTML. Similmente, un oggetto di tipo
OntologyResponse

pu contenere, oltre ad un'ontologia (o un insieme di ontologie

dipendenti fra loro), anche il codice XML in cui formalizzata (utile per la visualizzazione in modalit codice) e un messaggio di diagnostica che segnali eventuali anomalie. Inoltre, un oggetto di tipo OntologyResponse pu anche includere una mappa da stringhe in stringhe, che associ un baseURI di un'ontologia all'indirizzo fisico ove reperirla. Questa mappa serve a permettere all'utente di definire nuovi URI fisici per lo scaricamento di ontologie importate transitivamente da quella attiva (eventualmente caricandole a mano). Altri tipi di rilievo sono: la classe QualifiedName e le interfacce 145

4.Sviluppo ed implementazione: SAscha

SAWSDLResourceContainer

e SupportsModelReference; la prima una versione

serializzabile di QName, usata per formalizzare URI suddivisi in namespace e parte locale; la seconda permette di assegnare un tipo comune ai rappresentanti di schemi e descrittori WSDL; la terza, infine, l'analogo di ModelReferenceExtensible in SAWSDL4J e si applica ad elementi dei subpackage wsdl e schema per identificare le categorie estensibili via model reference. Il package ontology mette a disposizione quella parte di object model delegata all'emulazione di OWL API, bench in principio esso sia compatibile con altri modelli, come quello esposto da Jena. Rispetto ad essi, tuttavia, il modello intermedio un sottoinsieme minimale delle inferenze ottenuto ragionando sull'insieme di ontologie di interesse. Nello specifico, gli assiomi non sono codificati come oggetti, se non nella misura in cui sia necessario enunciarli all'utente finale, poich il modello intermedio si concentra sui concetti fondamentali di classe, istanza e propriet (sia di oggetto che di datatype). Il motivo risiede nel fatto che non si richiede all'applicazione client di ragionare sugli assiomi di un'ontologia, per ragioni sia di efficienza che di separazione delle competenze. Di conseguenza, quello che chiamato ontologia nell'object model intermedio in realt parte del risultato di un'attivit di ragionamento su di un insieme di ontologie (che tipicamente consister nella chiusura transitiva delle dipendenze dell'ontologia attiva, cio espressamente richiesta dall'utente).

146

4.Sviluppo ed implementazione: SAscha

Figura 21: Class diagram della porzione di SIOM per ontologie

Un'ontologia rappresentata come un aggregato di tali concetti, rappresentati dalla classe astratta ConceptContainer, che viene estesa come ClassContainer,
DatatypePropertyContainer, ObjectPropertyContainer

e IndividualContainer.

Questi concetti sono raggruppati per tipologia in quattro Map che ne consentono l'accesso diretto a partire dallo URI che li identifica. A sua volta, ciascuno di questi 147

4.Sviluppo ed implementazione: SAscha container portatore di riferimenti ad altri concetti con cui messo in relazione da un assioma delle ontologie su cui stato effettuato il ragionamento. Ad esempio, ciascun
DatatypePropertyContainer

e ObjectPropertyContainer include i riferimenti al

suo dominio e al suo range, mentre ciascun ClassContainer conosce classi equivalenti e disgiunte, sottoclassi ed istanze della classe OWL che rappresenta. In aggiunta a queste mappe, un OntologyContainer mantiene anche un riferimento alla classe radice (che con ogni probabilit sar owl:Thing), necessario per costruire la gerarchia delle classi. Avendo una struttura dati di questo genere, possibile costruire, visitando l'ontologia a partire dalla classe radice, l'albero che comprender, lato client, tutti i nodi di classi, individui e propriet per cui sia dichiarato il dominio. Il modello utilizzato per rappresentare gli XML Schema (XSD) estremamente semplice, in quanto mima la sintassi del linguaggio nei limiti di quegli elementi d'interesse per l'annotazione semantica: esistono dunque classi che rappresentano costrutti quali schema, attribute, element, simpleType, complexType e gli aggregatori all, choice e sequence. Tutte queste classi estendono la classe astratta
SchemaItemContainer,

che caratterizzata dal mantenere una lista di riferimenti ai

suoi discendenti diretti nell'albero DOM del documento. Le classi che rappresentano elementi annotabili, quindi di tipo attribute, element, simpleType e complexType, implementano anche l'interfaccia SupportsModelReference. Inoltre, ad ogni oggetto di tipo SchemaItemContainer corrisponde una stringa del linguaggio XPath, necessaria per identificare i nodi da annotare con l'attributo sawsdl:modelReference. Tutte le espressioni XPath sono preventivamente costruite dallo schema engine con un procedimento arbitrario tale che non esistano due espressioni che risultino in uno stesso elemento di un albero DOM. Questa porzione dell'object model rappresenta schemi sia indipendenti che inclusi in un descrittore WSDL.

148

4.Sviluppo ed implementazione: SAscha

Figura 22: Class diagram della porzione di SIOM per XML Schema Infine, il package wsdl fornisce l'object model per la rappresentazione di documenti in linguaggio WSDL 1.1 e consente di mappare elementi di tipo
definition, types, message, part, portType

ed operation in corrispondenti oggetti

serializzabili, i cui tipi sono tutti raggruppati come estensioni della classe astratta
WSDLItemContainer.

Questo modello strutturalmente simile a quello di WSDL4J (e

di SAWSDL4J, che lo estende), nel senso che sono esplicitate relazioni di contenimento fra elementi che rispecchiano la struttura del documento XML. Ciascun elemento WSDL contiene un insieme di riferimenti ai propri membri: ad esempio, un
MessageContainer

contiene tutti i riferimenti ai PartContainer rappresentanti parti

del corrispondente messaggio, cos come un PortTypeContainer contiene i riferimenti ai corrispondenti OperationContainer. Diversamente da come avviene per le ontologie, questa struttura gerarchica rigida: mentre da un'ontologia possibile accedere direttamente a classi, propriet ed individui, da una definizione WSDL non si pu accedere direttamente ad un'operazione senza aver ottenuto in precedenza un handle sul PortTypeContainer dove essa stata definita.

149

4.Sviluppo ed implementazione: SAscha

Figura 23: Class diagram della porzione di SIOM per WSDL

4.4.3. L'interfaccia di servlet

Innanzitutto da notare che l'API di riferimento del Google Web Toolkit non si limita a coprire il dominio del modulo client per quanto riguarda l'interfaccia utente e i meccanismi per RPC, ma deve anche integrarsi con l'application server per mezzo di un pacchetto chiamato gwt-servlet.jar, da includere tra le dipendenze lato server

150

4.Sviluppo ed implementazione: SAscha copiando il suddetto archivio jar nella directory WEB-INF/lib dell'applicazione
sascha.

Questo necessario perch l'implementazione di GWT per le chiamate a

procedura remota non utilizza esattamente le classiche interfacce Java Servlet, ma una loro particolare estensione chiamata GWT-RPC. La definizione di un'interfaccia GWTRPC prevede che siano definiti i seguenti tipi Java: 1. un'interfaccia che estenda RemoteService ed elenchi i metodi RPC a discrezione del programmatore. Quest'interfaccia condivisa, nel senso che deve essere disponibile per la compilazione sia come bytecode Java lato server che come JavaScript lato client. 2. Una seconda interfaccia che definisca la versione asincrona del servizio di cui al punto precedente. Essa necessaria per implementare la richiesta di servizio lato client, e segue determinate convenzioni per essere legata con la sua versione sincrona. 3. Una classe lato server che estenda RemoteServiceServlet ed implementi l'interfaccia sincrona di cui al punto 1. Tale classe deve poi essere associata ad un percorso virtuale nel file web.xml per il deployment. Sono stati definiti due gruppi di servizi GWT-RPC per operare sulle risorse utilizzate nel ciclo operativo di SASCHA, pi alcuni gruppi aggiuntivi a supporto di operazioni di routine (ad esempio l'aggiornamento in tempo reale del codice XML di un documento) e altre che saranno implementate in futuro. Limitatamente alla sola specifica della versione sincrona, sono di seguito descritte le due interfacce per la comunicazione dei dati di risorsa: 1. OntologyListingService mette a disposizione i metodi di accesso in lettura ad un'ontologia di cui si conosce la collocazione. Tali metodi, che non si esclude possano essere condensati in uno solo in futuro, sono:

fetchLocalOntology().

Restituisce una versione compatibile con SIOM di

151

4.Sviluppo ed implementazione: SAscha un'ontologia che l'utente ha precedentemente caricato sul server dal proprio file system. Se specificato come parametro, il risultato pu comprendere tutta la chiusura transitiva delle ontologie importate;

fetchRemoteOntology().

Funziona come fetchLocalOntology(), con la

differenza che il suo URL fisico viene trattato come assoluto e dereferenziato. Si utilizza per recuperare ontologie non locali;

getCode().

Richiede il codice dell'ultima ontologia attiva memorizzata nella

sessione. Sono supportati tutti i formati per cui sia registrato un parser presso OWL API, fra cui RDF/XML, OWL2/XML, Turtle e KRSS2;

loadOntology().

Funziona

come

fetchLocalOntology(),

con

la

differenza che l'ontologia viene caricata silenziosamente, senza essere convertita in SIOM e restituita. Questo metodo usato per estendere la base di conoscenza su cui il motore OWL dovr ragionare, ad esempio se l'utente carica, oltre all'ontologia attiva, anche le sue dipendenze. 2. WSDLRetrievalService, a dispetto del nome, consente l'accesso sia a descrittori WSDL che a schemi XSD, nei limiti previsti dalla specifica. I metodi di questa interfaccia correntemente impiegati sono:

fetchLocalWSDLData().

Restituisce una versione compatibile con SIOM di

un documento WSDL che l'utente ha precedentemente caricato sul server dal proprio file system. La risoluzione di eventuali dipendenze implicita;

fetchSchemaData().

Restituisce una versione compatibile con SIOM di un

documento XSD che pu essere locale oppure remoto. Anche in questo caso la risoluzione di eventuali dipendenze (per mezzo di direttive di tipo
include, import

o redefine) implicita; Prende in input la

getMergedSAWSDLDocumentLocation().

152

4.Sviluppo ed implementazione: SAscha rappresentazione SIOM di un documento WSDL o XSD annotato, lo serializza in un file XML e ne restituisce il percorso, in modo che il richiedente possa scaricarlo a mezzo di una semplice richiesta HTTP GET. Oltre alle interfacce principali gi citate, ne sono state costruite altre accessorie, elencate brevemente: 3. XMLCodeService utilizzata per serializzare temporaneamente le annotazioni effettuate e richiedere il codice XML aggiornato del documento WSDL e XSD. 4. ServiceAgreementRetrievalService, attualmente non utilizzata, permetter l'estrazione, navigazione e compressione di interi Accordi di Servizio. 5. OntologyUploadServlet e WSDLUploadServlet sono due estensioni di una classe astratta UploadServlet per gestire il caricamento di ontologie e documenti WSDL e XSD dal file system locale. Queste non fanno parte di GWT-RPC, ma sono delle HTTP Servlet standard, che per supportano solo il metodo POST. 6. WSDLDownloadServlet consente di salvare localmente un documento WSDL o XSD annotato. Anche questa una HTTP Servlet standard, ma che implementa solamente il metodo GET.

4.4.4. Motori applicativi server-side

Disponendo ora di un metodo per far viaggiare tra frontend e backend le informazioni che ci interessano riguardo documenti WSDL, schemi ed ontologie, si pone il problema di trasformare questi oggetti dal loro object model originario verso quello intermedio e viceversa. Transizioni di questo genere si verificano ogniqualvolta l'utente sottoponga un comando che preveda il caricamento o salvataggio di una risorsa. L'approccio che stato scelto prevede che l'intero carico computazionale per effettuare tali trasformazioni sia suddiviso fra tre classi lato server, una per ciascuna tipologia di 153

4.Sviluppo ed implementazione: SAscha documento, generalmente denominate motori (o engines):

org.example.sascha.server.ontology.OntologyEngine org.example.sascha.server.schema.SchemaEngine org.example.sascha.server.wsdl.WSDLEngine

Scopo di queste classi di tenere le servlet il pi possibile all'oscuro dei dettagli della specifica adottata per quella tipologia di dato. Questa strategia favorisce il riuso e l'estensione, nonch il passaggio a nuove API in tempi successivi. Ad esempio, dovrebbe essere possibile, in un futuro, optare per il passaggio a Woden o a WSMO Grounding senza dover riscrivere la servlet WSDLServicesImpl, ma ridefinendo solamente i metodi di WSDLEngine. Per come sono organizzati i metodi che espongono, queste classi manifestano una caratteristica comune: per ciascuna di esse il procedimento che porta alla transizione da XML all'object model intermedio di SASCHA si scompone in due fasi distinte ed indipendenti, a ognuna delle quali associato un metodo. Ad esempio, la classe
OntologyEngine

espone due metodi: tenta di caricare

loadOntology(URI uri, boolean forceReload): boolean

un'ontologia risolvendo l'indirizzo fisico uri e ne immagazzina al suo interno la rappresentazione, attualmente secondo l'object model di OWL API. Se l'ontologia gi correntemente immagazzinata e il parametro forceReload falso, il caricamento non viene effettuato nuovamente. da notare che questo metodo non restituisce un oggetto di tipo OWLOntology, ma solamente un booleano che indica se l'operazione ha avuto esito positivo, il che comprende anche il caso in cui non si ricarichi un'ontologia gi immagazzinata. Per ottenere un oggetto di tipo
OWLOntology

bisogner

invocare

il

metodo

getLastLoadedOntology();

154

4.Sviluppo ed implementazione: SAscha

parseOntology(OWLOntology

ontology):

OntologyContainer

effettua il

parsing di un'ontologia gi rappresentata in OWL API e ne restituisce una versione nell'object model intermedio di SASCHA. Nel caso particolare delle ontologie, questo procedimento si avvale di classi specializzate che implementano il pattern visitor e di ragionatori quali Told e Pellet. Analoghi metodi sono definiti anche per gli altri due motori che gestiscono documenti WSDL e XSD e per semplicit non saranno trattati. opportuno tuttavia soffermarsi su WSDLEngine, poich esso ha anche la responsabilit di iniettare nel documento le annotazioni effettuate dall'utente. Come avviene per l'interpretazione, anche questo procedimento si scompone in due parti esplicitate da due classi di metodi:

updateModelReferences()

identifica una famiglia di metodi la cui funzione

di fondere un documento aggiornato dall'utente, rappresentato nell'object model intermedio, con un altro (presumibilmente lo stesso, gi immagazzinato nel backend), rappresentato nell'object model di origine, al fine di produrre un unico oggetto Definition o Schema di SAWSDL4J che includa i model references aggiornati;

writeToFile() e writeToString()

identificano un'altra famiglia di metodi per

la serializzazione in XML di un oggetto Definition o Schema, sia esso annotato o meno. La serializzazione pu avvenire su di un file, che pu essere messo a disposizione dalla servlet perch l'utente possa scaricarlo, ovvero su di una stringa. Questo secondo caso discende da una funzionalit aggiuntiva prevista per gli engine, ossia l'estrazione direttamente del codice originario delle varie risorse, cosicch possa essere presentato all'utente sotto un'opportuna modalit di visualizzazione. Si pu osservare che la classe WSDLEngine responsabile per il merging e la serializzazione sia di documenti WSDL che XSD, mentre SchemaEngine si occupa esclusivamente della deserializzazione di schemi XSD. Questo comportamento, che 155

4.Sviluppo ed implementazione: SAscha discende dalla stretta dipendenza degli uni dagli altri nella definizione dei tipi di dato, potrebbe mutare in successive versioni del programma. Similmente, uno dei possibili scenari di sviluppo prevede che le funzioni che realizzano il passaggio tra i vari object model vengano implementate in due moduli separati per ciascun linguaggio.

4.4.5. Implementazione dell'interfaccia utente

In linea di principio, non obbligatorio implementare l'intera applicazione web in Google Web Toolkit. Il programmatore pu, a sua discrezione, generare codice HTML o di scripting a mano o per mezzo dei tool di sviluppo che preferisce, assegnando nelle pagine un numero arbitrario di slot (ad esempio sotto forma di tag div) nei quali lo script compilato da GWT possa iniettare i widget da esso generati. Nel caso di SASCHA, disponendo di una libreria grafica molto ricca qual GWT-Ext, si preferito affidarsi ad essa per implementare l'intera interfaccia. Questa scelta motivata dal fatto che GWT-Ext gestisce vari aspetti implementativi ricalcando molto da vicino i classici, solidi widget toolkit di Java come AWT o Swing: innanzitutto, i criteri di disposizione degli oggetti grafici in GWT-Ext si basano sulla definizione di layout per ciascun pannello o contenitore, mentre la libreria standard di GWT incorpora un layout predeterminato in ciascuna classe di contenitore; inoltre, il flusso informativo che regola le funzionalit dell'interfaccia governato per mezzo di event handling, vale a dire l'invocazione di subroutine asincrone che reagiscono ad eventi generati da azioni dell'utente. GWT-Ext consente di generare l'intera pagina in Java creando un oggetto di tipo Viewport. Il layer d'interfaccia utente risulta organizzato secondo il diagramma UML delle classi in figura 24, ed implementato interamente nel package
org.example.sascha.client.ui.

156

4.Sviluppo ed implementazione: SAscha

Figura 24: Diagramma UML delle principali classi del package ui La disposizione dei pannelli che compongono l'unica perspective prevista per l'applicazione rispecchia in parte la disposizione dei container del diagramma UMLi [PinPat00] d'interfaccia di cui al capitolo 3. In particolare, ora siamo in grado di dire che essi sono disposti secondo un BorderLayout simile a quello a cui i conoscitori di AWT saranno adusi. Secondo questo layout, i pannelli che rappresentano i container Menu, Navigazione ed Opzioni sono disposti ad ovest e raccolti in un unico pannello che permette di mostrarne uno alla volta per mezzo di un AccordionLayout (layout a 157

4.Sviluppo ed implementazione: SAscha fisarmonica). Nella porzione a sud viene collocato l'insieme di viste rappresentato dal container Info UI; in questo caso, il container implementato come un TabPanel, per consentire la navigazione a schede delle viste Diagnostica, Slots Concetti e Mappa Ontologie. Entrambi questi pannelli sono collassabili ed espandibili, come del resto avviene anche per le applicazioni basate su Eclipse125. La sezione centrale condivisa fra le due viste WSDL/XSD ed Ontologia. Anche queste sono organizzate in due distinti TabPanel che consentono la scelta, per ciascuna vista, di una fra le tre rappresentazioni previste (Albero, Lista Nodi e Codice). Le due principali viste sulle risorse sono implementate in due distinti oggetti, rispettivamente di tipo WSDLPanel ed OntologyPanel. Ciascuno di essi un TabPanel, quindi un contenitore di widget disposti secondo lo stile di uno schedario, tali da essere visibili e selezionabili uno alla volta per mezzo di tab (o linguette). In entrambi i casi, questo TabPanel si compone di tre pannelli, ciascuno contenente una diversa rappresentazione della stessa risorsa caricata (ontologia, descrittore WSDL o schema): 1. Un TreePanel, utilizzato per rappresentare una risorsa in un'opportuna struttura gerarchica: nel caso di documenti WSDL e XSD, questa gerarchia rispecchia a grandi linee l'albero DOM della corrispondente sintassi XML, mentre per le ontologie essa il frutto di un processo di inferenza svolto dal sottostante motore OWL. 2. Un pannello che, a seconda dei casi, sar di tipo WSDLElementStackPanel o
ConceptStackPanel,

e che consiste in un aggregato di tabelle ( GridPanel)

disposte secondo un AccordionLayout. Tali tabelle risultano ordinate per colonne e se ne ha una per ciascuna tipologia di entit che partecipa direttamente al processo di annotazione. Per le ontologie si avranno dunque tabelle per classi, propriet di dati, propriet di oggetti ed individui, mentre per WSDL e schemi si
125 http://www.eclipse.org

158

4.Sviluppo ed implementazione: SAscha avranno tabelle per messaggi, operazioni, tipi di porta, elementi, attributi, tipi semplici e complessi e cos via. 3. Un pannello per la visualizzazione della risorsa in formato testuale. Questo implementato come un SyntaxHighlightPanel per le ontologie, mentre nel caso di WSDL/XSD un semplice Panel HTML, dove l'evidenziamento della sintassi viene effettuato in maniera meno dispendiosa lato server, in quanto il codice viene aggiornato in tempo reale dopo ogni operazione di annotazione. In particolare, i pannelli di tipo 1 e 2 sono attivamente coinvolti nelle operazioni di annotazione semantica. Avendo a disposizione metafore visive esteticamente snelle e allo stesso tempo ricche sul piano dei contenuti, si optato per rendere l'operazione di annotazione secondo il paradigma di drag-&-drop fra i nodi o le righe di tabella di entrambe le sezioni. Questo paradigma valido in una sola direzione, vale a dire dal
TreePanel

o StackPanel della sezione ontologia verso il TreePanel o StackPanel

della sezione WSDL/XSD, e si traduce nell'operazione di concatenazione degli URI indicanti i concetti selezionati nel valore dell'attributo modelReference associato, ove possibile, al drop target. La rimozione di annotazioni avviene attraverso menu di contesto che possono essere invocati da un nodo di annotazione. Come avviene nei widget toolkit standard di Java quali AWT, Swing o SWT, anche in questo caso ci si avvale di tecniche di programmazione governata dagli eventi. In aggiunta agli eventi di interfaccia messi a disposizione da GWT e GWT-Ext, si scelto di impiegare lo stesso paradigma per gestire la reazione ai messaggi scambiati fra client e server. Questa scelta nasce dalla necessit di evitare che i moduli demandati all'invocazione dei servizi remoti (ad esempio per il caricamento di un'ontologia o la scrittura di un documento WSDL annotato), una volta ricevuto il messaggio di callback, debbano essi stessi farsi carico di manipolare l'interfaccia utente (ad esempio appendendo all'OntologyPanel l'albero dell'ontologia appena caricata, o notificando una condizione di errore). Questa condotta, bench semanticamente ammissibile, considerata altamente eterodossa in un contesto di programmazione ad oggetti, perci si 159

4.Sviluppo ed implementazione: SAscha preferito far riferimento al pattern di progetto Mediator [GHJV95]. In base a questo pattern, si indebolisce l'accoppiamento fra le classi per la gestione dello scambio di risorse (OntologyManager e SAWSDLResourceManager) e quelle dell'interfaccia grafica ad esse associate (rispettivamente OntologyPanel e WSDLPanel). Per far questo sono state progettate due nuove interfacce di tipo EventListener:

DocumentListener,

una generica interfaccia per la gestione delle richieste e

delle risposte in merito al caricamento ed alla selezione di documenti di qualsiasi tipo. Essa espone i metodi onOntologyLoaded(), onDefinitionLoaded(),
onSchemaLoaded(), onDocumentSelected(), onSAWSDLObjectLoaded()

doBeforeSAWSDLObjectLoaded(). ErrorListener,

un'interfaccia progettata, a dispetto del nome, anche per la

gestione di anomalie non necessariamente fatali. Essa espone i metodi

onError()

e onReturnCode().

Queste interfacce sono implementate da pi classi lato client, ma in particolar modo da una classe detta UIHandler, che costituisce il mediatore principale del frontend. Questa classe mantiene tutti i riferimenti agli elementi singleton dell'interfaccia utente e tiene traccia di tutti i sottoalberi delle risorse immagazzinate, insieme ai rispettivi baseURI.

4.5. Testing
Verificare che siano soddisfatti i requisiti iniziali ed i casi d'uso implementati dal prodotto finale un elemento quintessenziale dell'ingegneria del software, ma nel caso di un'applicazione web quale SASCHA, questo non sufficiente. Se da un lato, infatti, accertarsi dell'effettivit della soluzione implementata imprescindibile, dall'altro necessario tenere in considerazione che essa si dovr adattare ad una variet di piattaforme che non siamo in grado di quantificare con esattezza, per quanto riguarda le architetture hardware, i sistemi operativi e soprattutto i browser web su cui girer.

160

4.Sviluppo ed implementazione: SAscha Per questo motivo, oltre a verificare requisiti e casi d'uso per mezzo di una serie di casi di test, per chiarezza esposti in linguaggio naturale, stato anche sondato il livello di compatibilit di SASCHA con un insieme di browser che, stando ai rapporti di NetApplications dell'ultimo anno, ricopre all'incirca il 98% di market share. Nel concludere la sezione di testing, si dar una panoramica su di un piccolo gruppo di esempi di Accordi di Servizio ed ontologie dello stesso dominio che hanno costituito il banco di prova di tutta l'attivit di studio, dall'analisi degli standard di SPCoop fino alla fase di verifica, passando per quelle di progettazione e di sviluppo iterativo.

4.5.1. Compatibilit cross-browser

Abbiamo sintetizzato in tabella 9 i risultati dei test di compatibilit fra le varie piattaforme disponibili. Per completezza si indicano di seguito i sistemi operativi sui quali sono stati eseguiti i test:

Mozilla Firefox 2 e Opera sono stati testati sotto Linux Fedora 8 per x86_64 e Windows XP SP2 e SP3 per x86.

Mozilla Firefox 3, Microsoft Internet Explorer 7 e Google Chrome sono stati testati esclusivamente sotto Windows XP SP2 e SP3 per x86.

Apple Safari stato testato sotto Mac OS X 10.4 per x86_64 e Windows XP SP2 e SP3 per x86.

161

4.Sviluppo ed implementazione: SAscha Browser Esecuzione funzionalit di progetto Firefox 2.x Firefox 3.0 corretta corretta Layout interpretazione DOM perfetto perfetto sufficiente buona FireBug segnala errori non fatali negli script di ExtJS Internet Explorer 7 corretta Non gestisce correttamente il delle colonne negli StackPanel Safari 3.1.2 Chrome 0.2 corretta corretta perfetto nel dimensionamento delle finestre Opera 9.x Non supporta perfetto i menu contestuali JavaScript Tabella 9: Risultati dei test cross-browser In linea di massima, si pu dire che SASCHA sia compatibile con tutti i browser testati, nel senso che possibile utilizzare ognuno di essi per soddisfare i requisiti applicativi ed i casi d'uso. L'unica concreta limitazione data da Opera, il cui motore JavaScript, oltre ad essere il meno ottimizzato, non sembra gestire l'evento menu di
126 L'efficienza del motore JavaScript stata riscontrata esclusivamente sotto Windows XP SP3 sulla stessa architettura hardware x86_64 (AMD64 X2 5200+, 4GiB DDR2 800MHz).

Efficienza del JavaScript126

Altro

dell'interfaccia e motore

Buona, eccetto che per il lato client buona Sporadici crash

dimensionamento parsing XML

Qualche problema eccellente

scarsa

Non tratta in maniera corretta i messaggi in formato JSON

162

4.Sviluppo ed implementazione: SAscha contesto (invocato solitamente con la pressione del tasto destro del mouse). Non dunque possibile invocare il menu di contesto personalizzato per la rimozione di annotazioni, pertanto successivi sviluppi dovranno fornire un metodo d'accesso alternativo a quello del menu contestuale.

4.5.2. Il caso di studio del progetto ICAR

Come banco di prova per testare la corretta implementazione delle funzionalit di progetto, stato messo a disposizione un set di Accordi di Servizio annotati, corredato dalla base di conoscenza cui fanno riferimento le annotazioni, che costituisce parte di un pi ampio progetto di cooperazione applicativa tra le Regioni. I casi di test illustrati nella sezione successiva e gli screenshot dell'applicativo SASCHA fanno interamente riferimento a questo particolare caso di studio, in ragione della sua completezza ed attinenza allo scenario di cooperazione applicativa fra le PPAA italiane. Il progetto "Interoperabilit e Cooperazione Applicativa in rete tra le Regioni" (abbreviato ICAR)127 ha l'obiettivo di sviluppare un ambiente di Community Network interregionale, mirato ad abilitare le Regioni a partecipare ad un modello di interoperabilit e cooperazione, nel quale i servizi e le procedure erogati da un dominio applicativo possono richiedere forme di cooperazione fra pi Amministrazioni regionali. Esso coinvolge 16 regioni ed una provincia autonoma nel periodo che va dal marzo 2007 all'aprile 2009, ed cofinanziato dalle Regioni stesse e dal CNIPA per un totale di 24 milioni di euro128. ICAR prevede che si verifichi la consistenza dell'infrastruttura modellata secondo sette domini applicativi (Sanit, Anagrafe, Aree Organizzative Omogenee, Lavoro e servizi per l'impiego, Tassa automobilistica regionale, Osservatorio Interregionale sulla rete distributiva dei carburanti, Sistema interregionale di raccordo con Cinsedo), i quali richiedono cooperazione tra le Amministrazioni regionali. Due di
127 http://www.progettoicar.it/home.aspx 128 Fonte: sito del progetto ICAR, http://www.progettoicar.it/ViewCategory.aspx?
catid=a0180b19c1bc458f8dfaafe603e660aa

163

4.Sviluppo ed implementazione: SAscha questi (AP3 Aree Organizzative Omogenee e AP4 Lavoro e servizi per l'impiego) hanno rappresentato un concreto termine di riscontro per tutte le fasi di studio, progettazione, sviluppo e collaudo del presente lavoro. Il caso di studio AP3 coinvolge Friuli Venezia Giulia, Toscana, Abruzzo, Puglia e Basilicata e si compone di tre attivit a supporto dello scambio di informazioni fra le Regioni. Nella prima di queste attivit, su cui si sono concentrate le nostre verifiche, si definisce il formato di comunicazione a soggetti indeterminati (mediante una pratica nota come pubblicazione per sottoscrizione) delle variazioni intercorse nellIndice della Pubblica Amministrazione (IPA)129 su SICA. Lattivit si limita alla definizione del formato di scambio escludendo dunque la realizzazione del sistema di pubblicazione. Il caso di studio AP4 coinvolge Friuli Venezia Giulia, Piemonte, Liguria, Toscana, Marche e Abruzzo ed finalizzato alla cooperazione applicativa nellambito del sistema informativo lavoro, con particolare riguardo alla sinergia fra l'operato delle Regioni e lazione del Ministero del Lavoro130, che negli ultimi anni ha rilasciato servizi in logica cooperativa come la Borsa Continua Nazionale del Lavoro (BCNL) e le Comunicazioni Obbligatorie (CO) del datore di lavoro. Entrambi questi casi di studio ricoprono l'intero ciclo di formalizzazione della base di conoscenza e definizione dei servizi applicativi erogati da questi domini. Si ricorda che tali domini sono due dei sette elencati all'inizio della sezione, senza alcun riferimento alle competenze delle singole Regioni partecipanti. In particolare, gli obiettivi chiave di questi due casi di studio sono:

la costruzione delle ontologie di dominio per l'Indice PA e il sistema informativo lavoro;

la definizione degli Accordi di Servizio (IPA e servizi documentali per AP3; BCNL, CO e mobilit territoriale dei lavoratori per AP4).

129 http://www.indicepa.gov.it 130 http://www.lavoro.gov.it

164

4.Sviluppo ed implementazione: SAscha Gli AdS e le ontologie sviluppati in questi due domini esemplificano la strategia di progettazione di ICAR e pi in generale della partecipazione ad SPCoop delle Regioni, ed esplorano tutte le opportunit offerte dallinfrastruttura di cooperazione applicativa rilasciata da ICAR allinterno di SPCoop. Anche se i due processi di definizione sono, in generale, del tutto indipendenti, nella strategia adottata in ICAR si configura un accoppiamento stretto fra le entit generate da questi processi. In particolare, la stesura degli Accordi di Servizio viene vista come la definizione del dominio applicativo vero e proprio, mentre definire l'ontologia di riferimento permette di catalogare e strutturare da un punto di vista semantico l'insieme dei riferimenti utilizzati nel contesto del dominio di cooperazione. In questo modo, si riduce il rischio di costruire un modello semantico che, per il suo grado di espressivit, non sia allineato con i concetti del dominio di cooperazione. Per favorire il riuso e l'allineamento dei concetti semantici espressi nelle ontologie dei servizi, finalizzate a categorizzare l'insieme dei servizi erogati dal dominio, esse sono state costruite con un processo verticale articolato su tre livelli: 1. L'ontologia dell'Accordo di Servizio definisce la semantica dell'AdS in ICAR e SPCoop ed un elemento traversale a tutte le ontologie dei servizi erogati in ICAR. In particolare essa esplicita le nozioni fondamentali di Servizio, Operazione, Ruolo e Attore, oltre alle relazioni di base che intercorrono fra di esse. 2. L'ontologia dei servizi generici definisce un insieme di classi di servizio generiche legate alla nozione di servizio definita nell'ontologia fondazionale. Ontologie di questo tipo possono essere riutilizzate per definire servizi afferenti a diversi domini applicativi. 3. L'ontologia del servizio specifico definisce i servizi che sono occorrenze di una o pi classi di servizio generico. Tipicamente, questo l'unico livello in cui vengono dichiarate le istanze delle classi, sia in quanto servizi specifici che in 165

4.Sviluppo ed implementazione: SAscha quanto loro attori. Per i casi di studio presi in esame sono stati definiti quattordici Accordi di Servizio per la Borsa Continua Nazionale del Lavoro, uno per le Comunicazioni Obbligatorie, uno per l'aggiornamento dell'Indice delle PA e tre per i Servizi Documentali. In ciascuno di questi Accordi la definizione dei tipi di dato convogliati nei messaggi applicativi, normalmente inclusa nell'elemento wsdl:types, definita in schemi separati, ad esempio Types.xsd, che sono a loro volta importati dai corrispondenti WSDL concettuali, logici ed implementativi. Quasi tutti gli Accordi sono annotati semanticamente, nella loro parte comune, secondo una precisa strategia. Soltanto il documento WSDL WS_Concettuale della parte comune viene annotato semanticamente. Non vi annotazione al livello degli schemi XSD che definiscono i tipi di dato. L'annotazione vera e propria effettuata solo al livello delle operation dichiarate nel documento, per mezzo dell'attributo modelReference e dell'elemento
attrExtensions.

4.5.3. Casi di test

Questa sezione ristretta alle descrizioni dei casi di test a scatola nera eseguiti sulle funzionalit richieste, vale a dire che essi si basano solamente su input ed output, senza assumere alcuna conoscenza della struttura interna dell'oggetto del test [BCS01]. Per semplicit, nel seguito si assume di disporre ab initio di metodi corretti ed esaustivi per l'interpretazione di ontologie in OWL. Pur costituendo un elemento fondamentale per la generazione del flusso informativo necessario per le operazioni di annotazione semantica, si assunto il buon fine del processo di parsing e di ragionamento sulle ontologie, perch al momento non sono previsti interventi dell'utente volti a modificarle, ed inoltre il loro processamento affidato per intero ad una solida API di terze parti. Fermo restando questo assunto, sono stati individuati nove casi di test positivi, tutti incentrati sulla corretta interpretazione, annotazione semantica e scrittura di documenti WSDL e XSD. 166

4.Sviluppo ed implementazione: SAscha I criteri che configurano ciascun caso di test sono stati indicati secondo uno schema che segue il template della tabella 10. Numero e titolo del caso di test Descrizione Stato iniziale Step di esecuzione Stato finale Descrizione del requisito applicativo. Si tratta della postcondizione che dev'essere soddisfatta dallo stato finale. Stato iniziale in cui si pu ragionevolmente assumere che si trovi il sistema. Individua le precondizioni del caso di test. Sequenza delle azioni eseguite dall'utente a partire dallo stato iniziale sino allo stato in cui si verifica la postcondizione. Stato finale del sistema, con riferimento ai parametri che determinano il soddisfacimento della postcondizione. Tabella 10: Schema di un caso di test Ciascun caso di test ambivalente, nel senso che tratta di meccanismi per processare sia documenti WSDL che schemi XSD, tenendo ovviamente conto, tramite documentazione informale, delle diversit strutturali e delle specificit di ciascuna tipologia di entit annotabile. In tabella 11 sono elencati i titoli dei casi di test, dei cui dettagli si rimanda in allegato A. # 1 2 3 4 5 6 7 8 9 Descrizione Apertura documento senza annotazioni Apertura documento con annotazioni Apertura documento con schemi importati Annotazione documento senza prefisso Annotazione documento con prefisso Annotazione di dipendenze Annotazioni fuori standard Annotazioni ripetute Rimozione di annotazioni Tabella 11: Elenco dei casi di test a scatola nera Negli screenshot in figura da 25 a 29 sono mostrati alcuni esempi di applicazione pratica in SASCHA di questi casi di test, nello specifico eseguiti con Safari. 167

4.Sviluppo ed implementazione: SAscha

Figura 25: Apertura di un descrittore WSDL e di un'ontologia in SASCHA

Figura 26: Apertura di uno schema XSD e di un'ontologia in SASCHA 168

4.Sviluppo ed implementazione: SAscha

Figura 27: Annotazione di un portType con la classe ComunicazioneObbligatoria

Figura 28: Rimozione di un riferimento semantico da un'operazione WSDL

Figura 29: Riscontro nel codice XML delle modifiche alle annotazioni

169

5.Conclusioni e sviluppi futuri

5. Conclusioni e sviluppi futuri

Scopo di questo lavoro stato la progettazione e lo sviluppo di un'applicazione web ad alto grado di interattivit131, denominata SASCHA, per supportare la definizione della semantica dei servizi nell'ambito del framework di interoperabilit della Pubblica Amministrazione italiana SPCoop [ABFM+05]. Le fasi di disegno e sviluppo, svolte in maniera sinergica ed iterativa, sono state precedute dall'analisi delle componenti infrastrutturali del Sistema Pubblico di Connettivit e Cooperazione (SPC) [ABFM+05] e delle regole tecniche che ne disciplinano gli aspetti concettuali, logici ed implementativi. Successivamente, sono state esaminate in dettaglio le modalit di integrazione dei servizi erogati in cooperazione applicativa con metadati che diano connotazione semantica alle informazioni veicolate. Questa analisi ha fatto emergere la numerosit e l'eterogeneit dei potenziali soggetti che possono prendere parte al sistema, siano essi PA centrali che locali. Di qui la necessit di progettare uno strumento fortemente semplificato, scalabile e di immediata disponibilit. La scelta di sviluppare questo strumento sotto forma di Rich Internet Application in AJAX [Gar05] ha arrecato una serie di vantaggi: dalla portabilit alla centralizzazione della logica applicativa, sino alla possibilit di mettere a disposizione questo strumento sotto forma di servizio complementare, in una logica che segue la filosofia di Software as a Service (SaaS) [PLBB+99]. Inoltre, il ricorso a tali tecnologie si gi dimostrato una strategia vincente nel campo del web semantico: basti pensare ad OwlSight132, un browser di ontologie creato dagli autori del ragionatore Pellet133 e sviluppato anch'esso con le medesime tecnologie qui utilizzate. La necessit di fare affidamento a librerie datate o parziali, per gestire l'annotazione semantica secondo lo standard SAWSDL, ha portato alla genesi in corso
131 Si veda a tale proposito la definizione di Rich Internet Application in [All02] 132 http://pellet.owldl.com/owlsight 133 http://clarkparsia.com/pellet

170

5.Conclusioni e sviluppi futuri d'opera di un sottoprodotto dell'applicativo oggetto di questa sperimentazione, vale a dire l'estensione di queste librerie per favorire il loro adattamento al profilo tecnico di SPCoop e consentire il completamento delle funzionalit previste. L'applicativo finale il risultato della convergenza di pi processi concorrenti, che comprendono l'acquisizione progressiva di competenze in materie specifiche ed indipendenti, a partire dalla sintassi del linguaggio XML sino ai campi delle architetture orientate ai servizi e delle ontologie come prominente espressione del web semantico. Al tempo stesso stata sperimentata una tecnica di sviluppo di applicazioni AJAX che sia efficace, efficiente e compatibile con la maggiore quota di mercato dei browser, senza dover rinunciare al rigore e al polimorfismo del gi noto linguaggio Java. Di primaria importanza stata anche l'esperienza acquisita sia esaminando i casi di test utilizzati per il collaudo che utilizzando i pi noti editor di ontologie open source e commerciali, che hanno fornito spunti fondamentali per i paradigmi di visualizzazione delle ontologie, poi applicati anche agli elementi degli Accordi di Servizio. Quanto esposto in questo studio costituisce solo parte del lavoro necessario per giungere ad un completo sistema a supporto dell'annotazione semantica degli Accordi di Servizio in SPCoop. Le maggiori limitazioni discendono sia dallo stato di definizione dei dettagli strutturali delle entit coinvolte che dalla condizione di operativit del sistema stesso. L'accrescimento dell'interesse e della conoscenza in materia di web semantico applicato alle architetture orientate ai servizi costituisce un forte incentivo a proseguire iterativamente lo sviluppo di SASCHA. Ci avverrebbe in un'ottica di utilit per l'intero mondo dei Web Service basati su WSDL, quindi indebolendo lo stretto legame con SPCoop per consentire il supporto ad un ampio spettro di standard e tecnologie relative alle SOA, potenziando nel contempo il motore semantico sottostante. Per favorire l'apertura a varie strade di sviluppo, si prevede il rilascio sotto un'opportuna licenza open-source permissiva, ad esempio LGPL [LGPL30]. Un approccio per perseguire questa finalit pu essere il proseguimento dello sviluppo di SASCHA orientato ad una maggiore integrazione con i servizi infrastrutturali 171

5.Conclusioni e sviluppi futuri di SPCoop, parallelamente ad una diramazione del progetto mirata alla gestione di tutti quegli aspetti funzionali che sono stati posti in secondo piano per ritagliare l'applicazione attorno al framework di interoperabilit della PA italiana. In alternativa si pu estendere l'applicazione per renderla appetibile ad una base di utenza pi estesa, permettendo all'utente finale di personalizzarne il livello di dettaglio e le funzionalit esposte, le quali possono essere implementate come moduli aggiuntivi, o plugin. Entrambi i progetti manterrebbero l'obiettivo fondamentale di abbattere la complessit della logica sottostante, sia in termini di semantica che di Web Service. Alcuni possibili futuri scenari di sviluppo comprendono: la gestione in contemporanea di pi ontologie; l'integrazione di moduli specifici per SPCoop, fra cui la navigazione degli Accordi di Servizio e l'interfacciamento con il Catalogo Schemi ed Ontologie; il supporto per gli schema mapping e per le altre versioni di WSDL, magari migrando su future versioni di progetti come Woden134; il potenziamento dell'interattivit del client, che comprende un eventuale passaggio a nuovi widget toolkit come SmartClient135; il supporto per funzionalit basilari di editing delle ontologie; infine, il supporto alle decisioni in merito alla scelta delle entit in OWL da impiegare per l'annotazione, ad esempio frapponendo, fra un'ontologia e il documento da annotare, un'ontologia mediatrice costruita a partire da un pattern applicato alla struttura del documento WSDL o XSD stesso. In sintesi, il raggiungimento degli obiettivi preposti nel corso dell'esperienza non che il punto di partenza di un percorso evolutivo che, senza perdere di vista gli obiettivi di semplificazione originari, possa coinvolgere sia il sistema di interoperabilit della Pubblica Amministrazione italiana che il mondo delle architetture orientate ai servizi nel suo complesso. Si prevede che un aggiornamento continuativo sui progressi delle tecnologie semantiche e del modo in cui si legano al contesto dei servizi sul web incentiver lo sviluppo di questa applicazione sino a farne un sostanziale contributo a tutto il panorama delle tecnologie per i Web Service semantici.
134 http://ws.apache.org/woden 135 http://www.smartclient.com

172

Bibliografia

Bibliografia
[ABBD+06] : Angelov, D., Ballinger, K., Bukek, R., Davis, D., Ferris, C., Karmarak, A., Liu, C. K., Marsh, J., Mischkinsky, J., Nadalin, A., Schlimmer, J., Yalnalp, ., "WSDL 1.1 Binding Extension for SOAP 1.2", http://www.w3.org/Submission/wsdl11soap12, 2006 [ABFM+05] : Armenia, S., Baldoni, R., Fuligni, S., Mecella, M., Raia, A., Tortorelli, F., Sistema Pubblico di Cooperazione: Quadro Tecnico d'Insieme, http://www.cnipa.gov.it/ site/_files/SPCoop-QuadroInsieme_v1%200_20051014.pdf, CNIPA, 2005 [ACDK+07] : Andrieux, A., Czajkowski, K., Dan, A., Keahey, K., Ludwig, H., Nakata, T., Pruyne, J., Rofrano, J., Tuecke, S., Xu, M., Web Services Agreement Specification (WS-Agreement), Open Grid Forum, 2007 [AFL30] : Academic Free License, version 3.0, Open Source Initiative, http://www.opensource.org/licenses/afl-3.0.php [AFMN+05] : Akkiraju, R., Farrell, J., Miller, J., Nagarajan, M., Schmidth, M., Sheth, A., Verma, K., "Web Service Semantics - WSDL-S", http://www.w3.org/Submission/WSDL-S, 2005 [Akk07] : Akkiraju, R., "Semantic Web Services" in Semantic Web Services: Theory, Tools, and Applications, 2007 [All02] : Allaire, J., Macromedia Flash MX A Next-generation Rich Client, Macromedia, 2002 [Amb04] : Ambler, S. W., The Object Primer: Agile Model Driven Development with UML 2, Cambridge University Press, 2004, ISBN 0-521-54018-6 [APL20] : Apache License, Version 2.0, The Apache Software Foundation, http://www.apache.org/licenses/LICENSE-2.0 [BBCF+07] : Berglund, A., Boag, S., Chamberlin, D., Fernandez, M. F., Kay, M., Robie, J., Simon, J., "XML Path Language (XPath) 2.0", http://www.w3.org/TR/xpath20, 2007 [BCHW07] : Bos, B., elik T., Hickson, I., Wium Lie, H., , "Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification", http://www.w3.org/TR/CSS21, 2007 [BCS01] : British Computer Society - Specialist Interest Group in Software Testing, "Standard for Software Component Testing", 173

Bibliografia http://www.testingstandards.co.uk/BS7925_3_4.zip, 2001 [Bec04] : Beckett, D., "Turtle - Terse RDF Triple Language", http://www.dajobe.org/2004/01/turtle, 2004 [BEFG+06] : Ballinger, K., Ehnebuske, D., Ferris, C., Gudgin, M., Liu, C. K., Nottingham, M., Yendluri, P., "Basic Profile Version 1.1", http://www.ws-i.org/Profiles/ BasicProfile-1.1.html, 2006 [BEKL+00] : Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, N., Nielsen, H., Thatte, S., Winer, D., "Simple Object Access Protocol (SOAP) 1.1", http:// www.w3.org/TR/2000/NOTE-SOAP-20000508, 2000 [Ber05] : Berners-Lee, T., "Uniform Resource Identifier (URI): Generic Syntax", http://tools.ietf.org/html/rfc3986, 2005 [Ber98] : Berners-Lee, T., "Notation 3", http://www.w3.org/DesignIssues/Notation3, 1998 [BFMT05a] : Baldoni, R., Fuligni, S., Mecella, M., Tortorelli, F., Sistema Pubblico di Cooperazione: Accordo di Servizio, http://www.cnipa.gov.it/site/_files/SPCoopAccordoServizio_v1.0_20051014.pdf, CNIPA, 2005 [BFMT05b] : Baldoni, R., Fuligni, S., Mecella, M., Tortorelli, F., Sistema Pubblico di Cooperazione: Servizi di Registro, http://www.cnipa.gov.it/site/_files/SPCoopServiziRegistro_v1.0_20051014.pdf, CNIPA, 2005 [BFMT05c] : Baldoni, R., Fuligni, S., Mecella, M., Tortorelli, F., Sistema Pubblico di Cooperazione: Convenzioni di Nomenclatura e Semantica, http://www.cnipa.gov.it/site/ _files/SPCoop-NomenclaturaSemantica_v1.0_20051014.pdf, CNIPA, 2005 [Bra04] : Bracha, G., Generics in the Java Programming Language, , 2004 [BriGuh04] : Brickley, D., Guha, R. V., "RDF Vocabulary Description Language 1.0: RDF Schema", http://www.w3.org/TR/rdf-schema, 2004 [Bro03] : Mary Maureen Brown, "Electronic Government" in Encyclopedia of Public Administration and Public Policy, Jack Rabin, 2003, ISBN 978-1-4200-5275-6 [BSDL10] : BSD License, Regents of the University of California, http://www.opensource.org/licenses/bsd-license.php [BTBF+05] : Bussotti, U., Terranova, M., Baldoni, R., Fuligni, S., Mecella, M., Tortorelli, F., Sistema Pubblico di Cooperazione: Servizi di Sicurezza, 174

Bibliografia http://www.cnipa.gov.it/site/_files/SPCoop-ServiziSicurezza_v1.0_20051014.pdf, CNIPA, 2005 [BTN00] : Barton, J. Thatte, S., Nielsen, H., "SOAP Messages with Attachments", http://www.w3.org/TR/SOAP-attachments, 2000 [CCMW01] : Christensen, E., Curbera, F., Meredith, G., Weerawarana, S., "Web Services Description Language (WSDL) 1.1", http://www.w3.org/TR/wsdl, 2001 [Che76] : Chen, P., The Entity-Relationship Model - Toward a Unified View of Data, 1976 [CheYus08] : Chessell, M., Yusuf, L., "Modeling Demystified", https://www.ibm.com/developerworks/library/ar-usermod1/, 2008 [CHRR04] : Clement, L., Hately, A., von Riegen, C., Rogers, T., "UDDI Version 3.0.2", http://uddi.org/pubs/uddi_v3.htm, 2004 [ClaDer99] : Clark, J., DeRose, S., "XML Path Language (XPath) Version 1.0", http://www.w3.org/TR/xpath, 1999 [CNIPA04] : Centro Nazionale per l'Informatica nella Pubblica Amministrazione, Quaderno n. 5 - Sistema pubblico di connettivit e cooperazione, 2004 [CorRe08] : Corradini, F., Re, B., "e-Government: Problemi di Interoperabilit Semantica in un Contesto Distribuito" in Le ontologie come infrastruttura concettuale per lo sviluppo dei servizi assistiti da tecnologie semantiche nella Pubblica Amministrazione, 2008 [CPL10] : Common Public License - V1.0, IBM, http://www128.ibm.com/developerworks/library/os-cpl.html [DanSal08a] : Daniele, A., Salvatore, B., Specifiche del Servizio di Catalogo Schemi ed Ontologie, RTI, 2008 [DanSal08b] : Daniele, A., Salvatore, B., Struttura dellAccordo di Servizio e dellAccordo di Cooperazione, RTI, 2008 [DL4205] : Decreto Legislativo 28 febbraio 2005, n.42, recante Istituzione del sistema pubblico di connettivit e della rete internazionale della pubblica amministrazione, a norma dell'articolo 10, della legge 29 luglio 2003, n. 229 (Gazzetta Ufficiale n. 73 del 30 marzo 2005) [DL8205] : Decreto Legislativo 7 marzo 2005, n. 82, recante Codice 175

Bibliografia dell'amministrazione digitale (Gazzetta Ufficiale n. 112 del 16 maggio 2005) [DPCM08] : Decreto del Presidente del Consiglio dei Ministri, 1 aprile 2008, recante Regole tecniche e di sicurezza per il funzionamento del Sistema pubblico di connettivit previste dallarticolo 71, comma 1-bis del decreto legislativo 7 marzo 2005, n. 82, recante il "Codice dellamministrazione digitale" (Gazzetta Ufficiale n. 144 del 21 giugno 2008) [DSBH+04] : Dean, M., Schreiber, G., Bechhofer, S., van Harmelen, F., Hendler, J., Horrocks, I., McGuinness, D. L., Patel-Schneider, P.F., Stein, L. A., "OWL Web Ontology Language Reference", http://www.w3.org/TR/2004/REC-owl-ref-20040210, 2004 [DufFre03] : Duftler, M., Fremantle, P., Java APIs for WSDL, IBM, 2003 [ERSH+08] : Eastlake, D., Reagle, J., Solo, D. Hirsch, F., Roessler, T., Bartel, M., Boyer, J., Fox, B., LaMacchia, B., Simon, E., "XML Signature Syntax and Processing (Second Edition)", http://www.w3.org/TR/xmldsig-core, 2008 [FalWal04] : Fallside, D., Walmsley, P., "XML Schema Part 0: Primer Second Edition", http://www.w3.org/TR/xmlschema-0/, 2004 [FarLau07] : Farrell, J., Lausen, H., "Semantic Annotations for WSDL and XML Schema", http://www.w3.org/TR/sawsdl/, 2007 [Fow96] : Fowler, M., Analysis Patterns: Reusable Object Models, Addison-Wesley, 1996, ISBN 0201895420 [Gan08] : Gangemi, A., "Che cosa sono le ontologie computazionali e come si progettano" in Le ontologie come infrastruttura concettuale per lo sviluppo dei servizi assistiti da tecnologie semantiche nella Pubblica Amministrazione, 2008 [GanPre06] : Gangemi, A., Presutti, V., Ontology Design for Interaction in a Reasonable Enterprise, ISTC-CNR, 2006 [Gar05] : Garrett, J. J., "Ajax: A New Approach to Web Applications", http://www.adaptivepath.com/ideas/essays/archives/000385.php, 2005 [GHJV95] : Gamma, E., Helm, R., Johnson, R., Vlissides, J., Design Patterns: Elements of Reusable Object-Oriented Software., Addison-Wesley, 1995, ISBN 0-20163361-2 [GHMM+07] : Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, J., Nielsen, H., Karmarkar, A., Lafon, Y., "SOAP Version 1.2 Part 1: Messaging Framework (Second 176

Bibliografia Edition)", http://www.w3.org/TR/soap12-part1, 2007 [GLHA+00] : Gleeeson, B., Lin, A., Heinanen J., Armitage, G., Malis, A., A Framework for IP Based Virtual Private Networks, Internet informational RFC 2764, 2000 [GMRF+05a] : Gargiulo, E., Mariotti, E., Raia, A., Fuligni, S., Tortorelli, F., Sistema Pubblico di Cooperazione - Porta di Dominio, http://www.cnipa.gov.it/site/_files/SPCoop-PortaDominio_v1.0_20051014.pdf, CNIPA, 2005 [GMRF+05b] : Gargiulo, E., Mariotti, E., Raia, A., Fuligni, S., Tortorelli, F., Sistema Pubblico di Cooperazione - Busta di eGov, http://www.cnipa.gov.it/site/_files/SPCoopBusta%20e-Gov_v1.1_20051014.pdf, CNIPA, 2005 [Gra93] : Mark Grand, "MIME Overview", http://mgrand.home.mindspring.com/mime.html, 1993 [HaaBro04] : Haas, H., Brow, A., "Web Services Glossary", http://www.w3.org/TR/wsgloss, 2004 [IEEE91] : Institute of Electrical and Electronics Engineers, IEEE standard computer dictionary. A compilation of IEEE standard computer glossaries, Institute of Electrical and Electronics Engineers, 1991 [Jac06] : Jackson, B., "History of VoIP", http://www.utdallas.edu/~bjackson/history.html, 2006 [JaiSha07] : Jain Palvia, S. C., Sharma, S. S., "E-Government and E-Governance: Definitions/Domain Framework and Status around the World" in Foundations of Egovernment, 2007 [JEAA+07] : Jordan, D., Evdemon, J., Alves, A., Arkin, A., Askary, S., Barreto, C., Bloch, B., Curbera, F., Ford, M., Goland, Y., Guzar, A., Kartha, N., Liu, C. K., Khalaf, R., Knig, D., Marin, M., Metha, V., Thatte, S., van der Rijn, D., Yendluri, P., Yiu, A., "Web Services Business Process Execution Language Version 2.0", http://docs.oasisopen.org/wsbpel/2.0/wsbpel-v2.0.pdf, 2007 [KBP07] : Kopecky, J., Bournet, C., Prud'hommeaux, E., "SAWSDL Candidate Recommendation Implementation Report", http://www.w3.org/2002/ws/sawsdl/CR, 2007 [KLR05] : Keller, U., Lausen, H., Roman, D., "Web Service Modeling Ontology (WSMO)", http://www.wsmo.org/TR/d2/v1.2/, 2005

177

Bibliografia [KotVit06] : Kotinurmi, P., Vitvar, T., Web Service Invocation and Interoperation, Knowledge Web Consortium, 2006 [LasSwi99] : Lassila, O., Swick, R. R., "Resource Description Framework(RDF) Model and Syntax Specification", http://www.w3.org/TR/1999/REC-rdf-syntax-19990222, 1999 [LGPL30] : GNU Lesser General Public License, version 3, Free Software Foundation, http://www.gnu.org/copyleft/lesser.html [LKDK+03] : Ludwig, H., Keller, A., Dan, A., King, R. P., Franck, R., "Web Service Level Agreement (WSLA) Language Specification", http://www.research.ibm.com/wsla/WSLASpecV1-20030128.pdf, 2003 [Mar02] : Martin, R. C., "The Visitor Family of Design Patterns" in The Principles, Patterns, and Practices of Agile Software Development, Prentice Hall, 2002, ISBN [Mar99] : Marshall, D., "Remote Procedure Calls (RPC)", http://www.cs.cf.ac.uk/Dave/ C/node33.html, 1999 [MBHL+04] : Martin, B., Burstein, M., Hobbs, J., Lassila, O., McDermott, D., McIlraith, S., Narayanan, S., Paolucci, M., Parsia, B., Payne, T., Sirin, E., Srinivasan, N., Sycara, K., "OWL-S: Semantic Markup for Web Services ", http://www.w3.org/Submission/OWL-S, 2004 [MGMB07] : McIntosh, M., Gudgin, M., Morrison, K. S., Barbir, A., "Basic Security Profile Version 1.0, Final material", http://www.ws-i.org/Profiles/BasicSecurityProfile1.0.html, 2007 [New02] : Newcomer, E., Understanding Web Services: XML, WSDL, SOAP, and UDDI, Addison-Wesley, 2002, ISBN 978-0201750812 [NewLom05] : Newcomer, E., Lomow, G., Understanding SOA with Web Services, Addison-Wesley, 2005, ISBN 0-321-18086-0 [NKMH06] : Nadalin, A., Kaler, C., Monzillo, R., Hallam-Baker, P., "Web Services Security: SOAP Message Security 1.14 (WS-Security 2004)", http://www.oasisopen.org/committees/download.php/16790/wss-v1.1-spec-osSOAPMessageSecurity.pdf, 2006 [PinPat00] : Pinheiro da Silva, P., Paton, N. W., The Unified Modeling Language for Interactive Applications in "Proc. of the 3rd Conf. UML'00, UK", Springer, 2000 [PinPat03] : Pinheiro da Silva, P., Paton, N. W., User Interface Modeling in UMLi in 178

Bibliografia "IEEE Software", IEEE Computer Society, luglio 2003 [PisTra08] : Pistore, M., Trainotti, M., "Annotazione semantica di Servizi Web" in Le ontologie come infrastruttura concettuale per lo sviluppo dei servizi assistiti da tecnologie semantiche nella Pubblica Amministrazione, 2008 [PLBB+99] : Bennett, K., Layzell, P., Budgen, D., Brereton, P., Macaulay, L., Munro, M., "Service-Based Software: The Future for Flexible Software", http://www.bds.ie/Pdf/ ServiceOriented1.pdf, 1999 [Pow00] : Power, R., "WYSIWYM Home Page", http://www.itri.brighton.ac.uk/projects/WYSIWYM/wysiwym.html, 2000 [RobPis05] : Roberti, P., Pistore, M., Theoretical Integration of Web Service Discovery and Composition, Knowledge Web Consortium, 2005 [Ros03] : Rossi, V. et al., Sistema Pubblico di Connettivit - Architettura QXN, CNIPA, 2003 [Sha07] : Shannon, R., "DHTML Explained", http://www.yourhtmlsource.com/javascript/dhtmlexplained.html, 2007 [SWZK06] : Selvage, M. Y., Wolfson, D., Zurek, B., Kahan, E., "Achieve semantic interoperability in a SOA", http://www.ibm.com/developerworks/webservices/library/ws-soa-seminterop.html, 2006 [UscGru96] : Uschold, M., Gruninger, M., Ontologies: Principles, Methods and Applications in "Knowledge Engineering Review", Cambridge Journals, giugno 1996 [VetLen08] : Vetere, G., Lenzerini, M., "Modelli per l'interoperabilit semantica nelle architetture orientate ai servizi" in Le ontologie come infrastruttura concettuale per lo sviluppo dei servizi assistiti da tecnologie semantiche nella Pubblica Amministrazione, 2008 [Wal04] : Walsh, N., "Using Qualified Names (QNames) as Identifiers in XML Content", http://www.w3.org/2001/tag/doc/qnameids.html, 2004

179

Bibliografia

Siti istituzionali
[DI-UR1] : Universit di Roma La Sapienza - Dipartimento di Informatica, http://w3.uniroma1.it/dipinfo [CNIPA] : Centro Nazionale per l'Informatica nella Pubblica Amministrazione, http://www.cnipa.gov.it [MPAI] : Ministero per http://www.funzionepubblica.it la pubblica amministrazione e l'innovazione,

[ISTC] : Consiglio Nazionale delle Ricerche - Istituto di Scienze e Tecnologie della Cognizione, http://www.istc.cnr.it

180

Indice delle figure

Figura 1: Pila architetturale del Sistema Pubblico di Connettivit (fonte: [CNIPA]).....12 Figura 2: Esempio di collegamenti in una QXN (fonte: [CNIPA04], p. 23)...................13 Figura 3: Schema di integrazione in SPCoop dei servizi applicativi (SA) attraverso le Porte di Dominio (PD) (fonte: [CNIPA])........................................................................14 Figura 4: Esempio di Servizio di tipo Richiesta/Risposta (fonte: [ABFM+05]).............20 Figura 5: Busta eGov senza allegati (a) e con allegati (b) (fonte: [GMRF+05b])...........24 Figura 6: Servizi Infrastrutturali di Interoperabilit, Cooperazione ed Accesso.............36 Figura 7: Esempio di struttura della Parte Comune di un Accordo di Servizio (fonte: [DanSal08b])...................................................................................................................55 Figura 8: Esempio di struttura della Parte Specifica di un Accordo di Servizio (fonte: [DanSal08b])...................................................................................................................57 Figura 9: Diagramma del modello utente........................................................................80 Figura 10: Caso d'uso "Pubblica Accordo di Servizio"...................................................82 Figura 11: Caso d'uso "Compila Accordo di Servizio"....................................................83 Figura 12: Caso d'uso "Annota Parte Comune"...............................................................84 Figura 13: Caso d'uso "Annota Entit"............................................................................85 Figura 14: Caso d'uso "Estrai Concetti da Ontologia".....................................................86 Figura 15: Diagramma delle componenti del frontend....................................................90 Figura 16: Diagramma delle componenti del backend....................................................90 Figura 17: Diagramma UMLi dell'interfaccia utente......................................................96 Figura 18: Diagramma delle classi di SAXSD4J..........................................................131 Figura 19: Diagramma dell'architettura fisica di SAscha..............................................140 Figura 20: Class diagram del package radice di SIOM.................................................145 Figura 21: Class diagram della porzione di SIOM per ontologie..................................147 Figura 22: Class diagram della porzione di SIOM per XML Schema...........................149 Figura 23: Class diagram della porzione di SIOM per WSDL......................................150 Figura 24: Diagramma UML delle principali classi del package ui..............................157 Figura 25: Apertura di un descrittore WSDL e di un'ontologia in SAscha....................168 Figura 26: Apertura di uno schema XSD e di un'ontologia in SAscha..........................168 181

Figura 27: Annotazione di un portType con la classe ComunicazioneObbligatoria.....169 Figura 28: Rimozione di un riferimento semantico da un'operazione WSDL...............169 Figura 29: Riscontro nel codice XML delle modifiche alle annotazioni.......................169

Indice delle tabelle

Tabella 1: Funzionalit previste per ciascuna tipologia di Porta di Dominio..................28 Tabella 2: Ciclo di vita di un servizio e del relativo Accordo di Servizio.......................51 Tabella 3: Comparazione fra applicazioni SAWSDL esistenti........................................72 Tabella 4: Risorse a supporto dello sviluppo.................................................................103 Tabella 5: Panoramica delle implementazioni Java delle tecnologie adottate...............106 Tabella 6: Corrispondenza fra elementi in WSDL ed interfacce in JWSDL.................112 Tabella 7: Comparazione di librerie Java per SAWSDL...............................................124 Tabella 8: Mappa delle implementazioni estese............................................................137 Tabella 9: Risultati dei test cross-browser.....................................................................162 Tabella 10: Schema di un caso di test............................................................................167 Tabella 11: Elenco dei casi di test a scatola nera...........................................................167

182

Riconoscimenti
Ringrazio innanzitutto il Prof. Bongiovanni per la proposta di tesi e per averne sempre seguito lo sviluppo lungo tutto il suo periodo. Stefano Fuligni del CNIPA, per l'opportunit e per avermi fatto da Virgilio sin da quando conoscevo a malapena il linguaggio XML. Sempre dal CNIPA, ringrazio Mauro Draoli, Gabriele Bocchetta e Nunzio Casalino, per avermi sempre messo in condizione di lavorare al meglio. Inoltre, tutti i colleghi del Laboratorio Sperimentale. Aldo Gangemi e Valentina Presutti dell'ISTC-CNR, per il continuo ed inestimabile sostegno al lavoro di tesi. Insieme a loro, tutti i partecipanti al convegno EKAW 2008 per avermi introdotto, nel migliore dei modi, nello sterminato mondo del web semantico e dell'ingegneria della conoscenza: in particolare Claudio Baldassarre, Alfio Gliozzo, il Prof. Johan Bos, Mari Carmen Suarez-Figueroa Baonza e Johanna Vlker. Roberto Pariset, che mi ha segnalato il Google Web Toolkit. Per il sostegno di ogni genere in questi anni: Marco Castellano e tutta la famiglia estesa di CasaRuben, Rinaldo Raccichini, Enrico Schettino Montesano, Filippo Rubini, Valentina Rusconi, Gaia Curci, Gabriele e tutta la famiglia Svelto, Andrea di Biagio, Livio Guerrini; i colleghi del corso di laurea presenti e passati, in particolare quelli con cui ho condiviso progetti di laboratorio e preparazione di esami. Il Maestro Salvatore Leto e tutti i suoi allievi con i quali perseguo la Via della mano vuota. ! Ringrazio chiunque, in questi mesi di alienante lavoro, mi abbia consentito di apprezzare la buona tavola; chi mi ha fatto ridere o dato un gatto da accarezzare; chi si mostrato tollerante per la mia prolungata lontananza e per le email non risposte. Infine, i miei familiari tutti: quelli vicini come anche quelli molto, molto lontani. Chiunque altro non compaia in queste poche righe, di certo compare nei miei pensieri. 183