Tesi_Adamou
Upcoming SlideShare
Loading in...5
×
 

Tesi_Adamou

on

  • 1,812 views

 

Statistics

Views

Total Views
1,812
Views on SlideShare
1,812
Embed Views
0

Actions

Likes
0
Downloads
19
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Tesi_Adamou Tesi_Adamou Document Transcript

  • Una Rich Internet Application per l'annotazione semantica degli Accordi di Servizio nel Sistema Pubblico di Cooperazione Facoltà di Scienze Matematiche, Fisiche e Naturali Corso di laurea quinquennale in Informatica Candidato Alessandro Adamou Matricola 691636 Relatore Correlatori Prof. Giancarlo Bongiovanni Dott. Stefano Fuligni Dott. Aldo Gangemi Anno Accademico 2007/2008
  • Indice Generale Indice generale Premessa..........................................................................................................................4 1. Introduzione al contesto di riferimento.....................................................................7 1.1. Il Centro Nazionale per l'Informatica nella Pubblica Amministrazione................7 1.2. Il Sistema Pubblico di Connettività e Cooperazione (SPC)...................................8 1.2.1. Il livello di connettività................................................................................12 1.2.2. Il livello di interoperabilità e cooperazione..................................................14 2. La semantica per l'interoperabilità dei servizi in SPCoop....................................37 2.1. Nozioni fondamentali e strumenti per la semantica.............................................39 2.1.1. Le ontologie computazionali........................................................................39 2.1.2. Strumenti formali per le ontologie: Resource Description Framework (RDF), RDF Schema e Web Ontology Language (OWL).....................................42 2.2. Analisi dell'Accordo di Servizio..........................................................................50 2.2.1. Ciclo di vita dell'Accordo di Servizio..........................................................50 2.2.2. Struttura dell'Accordo di Servizio................................................................52 2.3. Il ruolo del Catalogo Schemi ed Ontologie in SPCoop.......................................58 2.4. Annotazione semantica di un Accordo di Servizio e di uno schema XML concettuale..................................................................................................................59 2.4.1. La specifica SAWSDL per l'annotazione dell'Accordo di Servizio.............60 2.4.2. Riferimenti semantici in SPCoop.................................................................64 2.5. Criticità e problematiche nel supporto all'annotazione semantica in SPCoop.....68 3. La soluzione proposta................................................................................................74 3.1. Analisi e definizione dei requisiti funzionali.......................................................74 3.1.1. Modello dell'utente.......................................................................................76 3.1.2. Casi d'uso.....................................................................................................81 3.1.3. Modello delle componenti............................................................................86 3.2. Progettazione dell'interfaccia utente....................................................................91 4. Sviluppo ed implementazione: SAscha..................................................................100 4.1. Risorse e strumenti utilizzati..............................................................................101 2
  • 4.2. Software a supporto dell'implementazione........................................................105 4.2.1. API grafiche per AJAX..............................................................................107 4.2.2. Librerie per il supporto WSDL...................................................................111 4.2.3. Librerie per il supporto all'estensione SAWSDL.......................................115 4.2.4. Librerie per la gestione delle ontologie......................................................125 4.3. Estensione della libreria SAWSDL4J................................................................127 4.3.1. Attuali limitazioni.......................................................................................127 4.3.2. Supporto per schemi XML stand-alone: il plugin SAXSD4J....................129 4.3.3. Integrazione delle funzionalità incomplete................................................135 4.4. L'applicativo SAscha.........................................................................................140 4.4.1. Architettura fisica dell'implementazione....................................................140 4.4.2. SIOM: un object model intermedio per il passaggio di risorse fra client e server....................................................................................................................141 4.4.3. L'interfaccia di servlet................................................................................150 4.4.4. Motori applicativi server-side....................................................................153 4.4.5. Implementazione dell'interfaccia utente.....................................................156 4.5. Testing................................................................................................................160 4.5.1. Compatibilità cross-browser......................................................................161 4.5.2. Il caso di studio del progetto ICAR............................................................163 4.5.3. Casi di test..................................................................................................166 5. Conclusioni e sviluppi futuri...................................................................................170 Bibliografia..................................................................................................................173 3
  • Premessa Premessa Il presente lavoro è frutto della collaborazione tra il Centro Nazionale per l'Informatica nella Pubblica Amministrazione [CNIPA] e il Dipartimento di Informatica degli Studi di Roma “La Sapienza” [DI-UR1] sul tema dell'interoperabilità e della cooperazione applicativa nella Pubblica Amministrazione (PA) italiana. In particolare, viene affrontato uno dei campi applicativi di maggiore interesse presente e futuro: il framework denominato Sistema Pubblico di Cooperazione (SPCoop), un'infrastruttura avviata a divenire entro breve il backbone per l'interoperabilità telematica fra i domini della PA. Questa tesi si pone l'obiettivo di fornire un contributo, sotto forma di strumento software, a supporto della partecipazione attiva ad SPCoop da parte delle Amministrazioni che vi aderiscono. Tale obiettivo ha implicato ulteriori requisiti che questo strumento ha dovuto soddisfare rispetto ad analoghi strumenti, anche open- source, presenti oggi sul mercato: in particolare la semplificazione, l'adattamento alle particolari esigenze di SPCoop e l'indipendenza dalle diverse piattaforme informatiche. Scopo principale della tesi è dunque la progettazione e lo sviluppo di un'applicazione web altamente interattiva a supporto del processo di annotazione semantica dei servizi erogati in SPCoop. Questo obiettivo è emerso nel corso dello studio degli standard e delle tecnologie che concorrono al modello SPCoop, a seguito dell'analisi delle connotazioni semantiche del sistema, svolta in collaborazione, oltre che con il CNIPA, con il Consiglio Nazionale delle Ricerche, in particolare l'Istituto di Scienze e Tecnologie della Cognizione [ISTC]. La soluzione applicativa sviluppata ai fini della tesi, ancorché concepita in seno a questa particolare architettura, ha prospettive di estensibilità tali da renderla, nel corso di eventuali futuri sviluppi, uno strumento general-purpose a sostegno della gestione dei cosiddetti Web Service semantici. Un obiettivo secondario, emerso in corso di sviluppo del progetto, è stato 4
  • Premessa l'estensione di un object model preesistente, noto come SAWSDL4J, con un pacchetto software aggiuntivo, da un lato per soddisfare un particolare requisito di SPCoop e dall'altro per sopperire alle lacune della libreria in questione. Il presente lavoro si articola in cinque capitoli. Il primo introduce il lettore allo scenario delle architetture orientate ai servizi (SOA) e dei Web Service, con riferimento al loro impiego nella Pubblica Amministrazione italiana ed in particolare al Sistema Pubblico di Connettività e Cooperazione (SPC) ed al framework SPCoop, di cui si illustrano i componenti infrastrutturali alla base. Il secondo capitolo è dedicato al problema dell'integrazione fra i servizi della PA e il contesto del web semantico, ed è accompagnato da un'analisi approfondita di uno degli elementi infrastrutturali di SPCoop, l'Accordo di Servizio. Tale analisi, dapprima prettamente strutturale, si focalizza sulle convenzioni adottate per l'estensione di questo oggetto con metadati che descrivono il significato delle informazioni veicolate dai servizi. Segue una descrizione delle modalità e dei processi di annotazione semantica dei servizi erogati in SPCoop. Sono infine esaminati i relativi standard definiti dal CNIPA sulla base delle raccomandazioni del World Wide Web Consortium (W3C), di cui viene individuato il set minimale utile in ambito SPCoop. Il terzo capitolo è dedicato alla progettazione di un sistema che soddisfi i requisiti di essenzialità ed integrazione con i servizi infrastrutturali di SPCoop, per supportare in dettaglio i processi di annotazione semantica descritti nel capitolo precedente. La progettazione riguarderà in particolar modo l'accoppiamento debole fra logica applicativa ed interfaccia, nonché la modellazione di quest'ultima sulla base di un determinato paradigma dell'utente. Il quarto capitolo si concentra sullo sviluppo dell'applicativo SASCHA, uno strumento basato su web a supporto dell'annotazione semantica degli Accordi di Servizio. Sono altresì descritte le attività di progettazione e sviluppo complementari, tra cui l'estensione della libreria SAWSDL4J. Si presenta una panoramica delle varie 5
  • Premessa tipologie di risorse prese in esame in corso di progettazione, fornendo per ciascuna di esse opportune motivazioni in merito alla loro adozione o meno per il presente progetto. Queste risorse comprendono sia l'ambiente di sviluppo scelto, dall'hardware fino agli strumenti per redigere questa tesi, sia le API (Application Programming Interface) utilizzate per rispondere ai requisiti di progetto dell'applicazione. Il capitolo si conclude con l'esposizione delle attività di collaudo, svolte sia sul piano tecnico che in relazione ad un caso di studio con esempi sia di Accordi di Servizio che di modelli semantici da impiegare per annotarli. Per concludere, nell'ultimo capitolo vengono proposte le conclusioni tratte da questa esperienza e le possibili direttrici di sviluppo, con prospettive di estensibilità dell'applicativo SASCHA, sia per una più netta integrazione con i servizi di SPCoop che per una migrazione verso un modello di sviluppo compatibile con i mondi aperti dei Web Service e del web semantico. 6
  • 1.Introduzione al contesto di riferimento 1. Introduzione al contesto di riferimento La IEEE definisce l'interoperabilità come “la capacità di due o più sistemi o componenti di scambiare informazioni ed utilizzare le informazioni che sono state scambiate” [IEEE91]. L'interoperabilità è uno dei temi di maggior rilievo in un contesto quale è quello dell'adozione, in tutto il mondo, di forme di eGovernment, ossia l'uso di tecnologie dell'informazione e della comunicazione (ICT) come piattaforma per la fornitura di servizi, scambio di informazioni e svolgimento di transazioni da e verso il cittadino e le amministrazioni [Bro03][JaiSha07]. Vista dalla prospettiva dell'eGovernment, questa definizione si traduce nella capacità di fornire ed utilizzare i servizi della Pubblica Amministrazione, assicurando una coerente interpretazione dei dati in un ambito inerentemente eterogeneo, ad esempio in termini di standard, di categorizzazione e, in contesti di interoperabilità internazionale, di barriere linguistiche. La necessità di interpretare automaticamente e con un sufficiente grado di accuratezza il significato delle informazioni scambiate e dei servizi utilizzati viene definita interoperabilità semantica [SWZK06]. Il Sistema Pubblico di Connettività e Cooperazione (spesso citato come Sistema Pubblico di Connettività, SPC) [CNIPA04] rappresenta la risposta italiana a tali esigenze, a fronte di un crescente fenomeno di decentramento delle competenze rivolto verso forme di federalismo che hanno come riferimento le regioni e le autonomie locali del nostro Paese. 1.1. Il Centro Nazionale per l'Informatica nella Pubblica Amministrazione Operante presso la Presidenza del Consiglio dei Ministri “con autonomia tecnica, funzionale, amministrativa, contabile e finanziaria e con indipendenza di giudizio”1 , il Centro Nazionale per l'Informatica nella Pubblica Amministrazione (CNIPA)2 è l'organo preposto a supportare l'utilizzo efficace delle tecnologie dell'informazione e delle comunicazioni nelle Pubbliche Amministrazioni (PPAA) per ottimizzare la qualità dei 1 D.L.vo 30 giugno 2003, n. 196, art. 176 comma 3 2 http://www.cnipa.gov.it 7
  • 1.Introduzione al contesto di riferimento servizi e rendere efficiente l’azione amministrativa, contenendone nel contempo i costi. Il CNIPA nasce nel 2004 dalla fusione di due precedenti organismi: l’Autorità per l’Informatica nella Pubblica Amministrazione ed il Centro tecnico per la Rete Unificata della Pubblica Amministrazione (RUPA)3. Quest'ultima, in esercizio tra il 2000 e il 2007, è stata la prima esperienza di infrastruttura condivisa nell'ambito della PA italiana, ed ha costituito il primo stadio evolutivo del SPC. A partire dal 2003, su incarico del Ministero per la Pubblica Amministrazione e l'Innovazione [MPAI], il CNIPA ha svolto attività di studio e definizione degli standard dell'infrastruttura di interoperabilità che avrebbe rappresentato la naturale evoluzione della RUPA. Un importante passo di questo processo è rappresentato dal decreto legislativo del 28 febbraio 2005 n. 42 (brevemente il Decreto 42-2005) [DL4205], che istituisce e disciplina il Sistema Pubblico di Connettività. Tale decreto conferisce anche al CNIPA il compito di seguire attivamente e in maniera continuativa la costituzione e l'evoluzione del SPC. In particolare, al CNIPA è affidato il compito di gestire le “risorse condivise del SPC e le strutture operative preposte al controllo e supervisione delle stesse” e “la progettazione, la realizzazione, la gestione e l'evoluzione del SPC” 4. 1.2. Il Sistema Pubblico di Connettività e Cooperazione (SPC) SPC è definito come “l'insieme di infrastrutture tecnologiche e di regole tecniche, per lo sviluppo, la condivisione, l'integrazione e la diffusione del patrimonio informativo e dei dati della pubblica amministrazione, necessarie per assicurare l'interoperabilità di base ed evoluta e la cooperazione applicativa dei sistemi informatici e dei flussi informativi, garantendo la sicurezza, la riservatezza delle informazioni, nonché la salvaguardia e l'autonomia del patrimonio informativo di ciascuna pubblica amministrazione”5. La realizzazione del SPC avviene nel rispetto di principi fra i quali l'architettura federata e non gerarchica del sistema e l'efficienza, 3 http://www.cnipa.gov.it/site/it-it/Attivit %C3%A0/Sistema_Pubblico_di_Connettivit%C3%A0_(SPC)/RUPA/ 4 [DL4205], articolo 10. 5 [DL4205], articolo 2 comma 2. 8
  • 1.Introduzione al contesto di riferimento anche economica, nell'utilizzo dei servizi di interoperabilità e cooperazione applicativa6. Il SPC ha la finalità di mettere a disposizione delle PPAA centrali e locali un insieme di servizi di connettività che sia condiviso e scalabile nei livelli di sicurezza e di qualità del servizio e di funzionalità. Su questi servizi di connettività si poggia un'infrastruttura di interscambio che consenta l'interoperabilità di tutte le reti delle PPAA esistenti, garantendo l'interazione delle amministrazioni con altri soggetti, fra cui cittadini ed enti privati7. Successivamente il Decreto 42-2005, pur senza entrare nel merito delle caratteristiche tecniche del SPC, definisce l'ambito di responsabilità delle singole amministrazioni che vi partecipano, elenca i requisiti necessari affinché un soggetto possa qualificarsi come fornitore di servizi ed istituisce un organismo, la Commissione di Coordinamento del SPC, che promuova la cooperazione applicativa nella Pubblica Amministrazione, verifichi la qualità dei servizi erogati ed approvi le modalità operative degli stessi. Inoltre, il Decreto dà le prime disposizioni in materia di migrazione dalla RUPA al SPC8. Alcune importanti linee guida in materia di gestione, trasmissione, accesso e conservazione dell'informazione supportata dalle tecnologie dell'informazione e della comunicazione sono state raccolte nel “Codice dell'amministrazione digitale” (di seguito il “Codice”) [DL8205]. Il Codice ha varato norme in materia di procedimento amministrativo informatico, uso della posta elettronica certificata (PEC), attività di certificazione della firma digitale e dematerializzazione dei documenti delle Pubbliche Amministrazioni. Fra queste norme sono riportate, al Capo VIII, le stesse disposizioni di cui al Decreto 42-20059. L'articolo 71 del Codice stabilisce che, entro nove mesi dalla sua entrata in vigore, siano adottate le Regole tecniche e di sicurezza per il funzionamento del sistema 6 [DL4205], articolo 2 comma 3. 7 [DL4205], articolo 6. 8 [DL4205], articolo 13. 9 [DL8205], articoli 72-87. 9
  • 1.Introduzione al contesto di riferimento pubblico di connettività10 (brevemente le “Regole tecniche”). Queste sono state approvate e rese pubbliche con il Decreto del Presidente del Consiglio dei Ministri del 1 aprile 2008 [DPCM08] ed hanno rappresentato un passo fondamentale dell'evoluzione del SPC. Applicando le definizioni di cui al Codice, tali Regole tecniche entrano, per la prima volta nel contesto normativo, nel merito degli standard e delle tecnologie da adottare nella definizione delle infrastrutture e dei servizi del Sistema Pubblico di Connettività. Dato che si entrerà nel dettaglio delle varie disposizioni e definizioni in sede di analisi delle componenti d'interesse di SPC, ci si limita qui a riassumere le finalità e i punti ritenuti salienti di questo decreto. Sinteticamente, le Regole tecniche: ● ribadiscono le finalità del SPC, ridefiniscono ruoli e responsabilità delle amministrazioni che vi partecipano e stabiliscono un modello federato di mutua e paritetica collaborazione; ● espongono l'architettura del SPC stratificata come segue: (i) un livello di interconnessione e comunicazione tra più amministrazioni e all'interno di una stessa amministrazione, basato sul protocollo IP; (ii) un livello di interoperabilità evoluta e cooperazione applicativa tra le amministrazioni aderenti al SPC; (iii) il livello dei servizi applicativi messi a disposizione attraverso il SPC. Sono dettagliate anche le componenti logiche e infrastrutturali del sistema; ● danno le definizioni di tutte le fondamentali componenti architetturali del SPC; definizioni che saranno più volte assunte come punto di riferimento nel corso di questo capitolo; ● dispongono le caratteristiche di sicurezza e i servizi infrastrutturali (SICA) per l'erogazione e la fruizione dei servizi applicativi; ● forniscono le specifiche per la realizzazione dei servizi SPC, tra cui: (i) i 10 [DL8205], articolo 71 comma 1-bis. 10
  • 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 (One- Way Delay) ≤ 20 ms; (iii) percentuale di perdita di pacchetti (Packet Loss) ≤ 0,05%. Figura 2: Esempio di collegamenti in una QXN (fonte: [CNIPA04], p. 23) Si è previsto, a discrezione delle singole amministrazioni e solamente in casi di necessità, che sia consentito lo scambio di informazioni, sia tra più amministrazioni che all'interno di una stessa, per mezzo di reti private virtuali (VPN) [GLHA+00] supportate 11 http://www.qxn-scpa.it 13
  • 1.Introduzione al contesto di riferimento da opportuni sistemi crittografici. 1.2.2. Il livello di interoperabilità e cooperazione Assodata a questo punto la disponibilità di un'infrastruttura di connettività affidabile, sicura ed efficiente, quale è la QXN, si ha la necessità di configurare due ambiti applicativi omogenei: 1. un ambito di cooperazione ad uso delle amministrazioni che partecipano ad SPCoop, interagendo per mezzo di servizi applicativi che seguono determinate modalità standard. Tali soggetti amministrativi dovranno, per l'erogazione e la fruizione di detti servizi, concordarne i termini concettuali, logici ed implementativi per mezzo di una convenzione anch'essa standardizzata. 2. un ambito che comprende servizi generali di infrastruttura per la cooperazione applicativa, non afferenti ad un particolare soggetto amministrativo che partecipa al sistema. Il fine di questi servizi è di supportare e coordinare l’interazione fra i servizi applicativi definiti dalle Amministrazioni. Figura 3: Schema di integrazione in SPCoop dei servizi applicativi (SA) attraverso le Porte di Dominio (PD) (fonte: [CNIPA]) 14
  • 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 l’implementazione del servizio. Mentre l'analisi di questo standard, d'obbligo nel corso del presente studio, verrà affrontata in una sede più 12 http://www.w3.org 13 Si veda il Web Services Description Working Group, http://www.w3.org/2002/ws/desc 16
  • 1.Introduzione al contesto di riferimento opportuna, si anticipa che esso è stato impiegato in maniera estesa nel definire più di un aspetto dei servizi applicativi in SPCoop. Lo scambio di messaggi, nel rispetto dei canoni dei Web Service e delle convenzioni stabilite in linguaggio WSDL [CCMW01], che avviene tra due sistemi coinvolti nell'esecuzione di un servizio, detti rispettivamente erogatore e fruitore, costituisce di fatto l'unica forma ammissibile del flusso informativo di un servizio SPCoop. È bene, a questo punto, definire una tassonomia sia dei servizi dal punto di vista dell'ordine dei messaggi che scambiano, sia delle modalità di scambio dei messaggi stessi dal punto di vista della loro natura transazionale. I tipi di scambio elementare di messaggi, definiti nella documentazione di riferimento di SPCoop [BFMT05a] sono tre: • messaggio senza replica: un sistema mittente invia un messaggio a un sistema destinatario. Come si vedrà, ciascun sistema può indifferentemente, a seconda dei casi, coincidere con l'erogatore o il fruitore del servizio; • messaggio/replica sincroni: un sistema detto richiedente trasmette un messaggio sincrono a un sistema detto rispondente e si mette in attesa (non necessariamente bloccante) della replica sincrona. Successivamente il rispondente trasmette una replica sincrona al richiedente correlata logicamente con il messaggio; • messaggio/replica asincroni: un sistema detto richiedente trasmette un messaggio asincrono (cioè senza attesa di risposta) a un sistema detto rispondente. Il rispondente trasmette in seguito una replica asincrona al richiedente correlata logicamente con il messaggio ricevuto. La correlazione a livello logico tra messaggio e replica asincroni è rappresentata esplicitamente dall’inserzione nella replica di un identificatore di correlazione. Questi tipi elementari di scambio di messaggi, ed essi soltanto, identificano le possibili modalità di utilizzazione del servizio, ovvero gli scenari di coordinamento delle 17
  • 1.Introduzione al contesto di riferimento prestazioni di servizio. La tipologia di coordinamento seguita da ciascun servizio sarà indicata, mediante un'opportuna nomenclatura, nei documenti in linguaggio WSDL che descrivono il servizio stesso. Sono previsti in tutto quattro tipi di scenari elementari di coordinamento: • Richiesta senza risposta: il fruitore trasmette all’erogatore un messaggio contenente una richiesta di prestazione e continua il trattamento. Tale scenario può essere implementato utilizzando come tipo di interazione il messaggio senza replica. • Richiesta/risposta: il fruitore trasmette all’erogatore un messaggio contenente una richiesta di prestazione di servizio. L’erogatore esegue il trattamento di erogazione della prestazione e trasmette un messaggio di risposta contenente il resoconto di erogazione e eventualmente i dati la cui fornitura è parte della prestazione. Le modalità dell’interazione (dal punto di vista del fruitore) che implementano lo scenario di richiesta/risposta possono essere sia sincrone che asincrone: o Richiesta/risposta sincrone: il sistema fruitore prepara e emette il messaggio di richiesta della prestazione e blocca la sua linea di esecuzione in attesa della risposta. Alla ricezione della risposta, la linea di esecuzione del fruitore riprende. Lo scenario richiesta/risposta sincrone può essere implementato direttamente utilizzando uno scambio elementare di tipo messaggio/replica sincroni. o Richiesta/risposta asincrone: il fruitore del servizio prepara la richiesta di prestazione, la trasmette all’erogatore e continua l’esecuzione. La richiesta viene trasmessa al sistema erogatore che esegue i trattamenti, prepara e emette 18
  • 1.Introduzione al contesto di riferimento la risposta. La ricezione della risposta ha come effetto presso il fruitore l’avvio di una linea di esecuzione indipendente che esegue i trattamenti conseguenti alla ricezione della risposta. Può essere implementato utilizzando lo scambio elementare di tipo messaggio/replica asincroni. L’identificatore di correlazione messaggio/replica può essere utilizzato come identificatore di correlazione richiesta/risposta. • Notifica senza risposta: l’erogatore del servizio trasmette di sua iniziativa un messaggio di notificazione al fruitore (che può contenente il resoconto di un trattamento effettuato o la notifica di un evento). Tale scenario può essere implementato usando uno scambio elementare di tipo messaggio senza replica. • Notifica/risposta: l’erogatore trasmette un messaggio di notificazione e successivamente il fruitore trasmette un messaggio di risposta. Può essere implementata con modalità sincrona o asincrona e quindi essere implementato rispettivamente dallo scambio elementare messaggio/replica sincrono o asincrono.14 Prima di inquadrare le categorie fondamentali degli elementi architetturali di SPCoop e di entrare nel dettaglio di ciascuno di essi, è utile fornire alcune indicazioni intuitive sulla loro funzione nel ciclo operativo del sistema. Innanzitutto, un esempio di comunicazione fra un sistema erogatore e uno fruitore di un determinato servizio è esplicitato in figura 4. 14 [BFMT05a] sezione “Concetti di Base”, pp. 9-10 19
  • 1.Introduzione al contesto di riferimento Figura 4: Esempio di Servizio di tipo Richiesta/Risposta (fonte: [ABFM+05]) La lettura dello scenario illustrato da questo esempio è la seguente: un sistema fruitore, appartenente ad un certo dominio applicativo15, deve utilizzare un servizio applicativo di tipo richiesta/risposta (si tralasciano al momento i dettagli sulla sincronia) esposto da un altro dominio applicativo, quello del sistema erogatore. La natura della conversazione, i nomi dei messaggi scambiati e altre informazioni sono contenute in un oggetto chiamato Accordo di Servizio, definito apposta per questa coppia <erogatore, fruitore>. Questi messaggi, veicolati attraverso l'infrastruttura di connettività di SPC, sono serializzati secondo un protocollo detto Busta eGov e scambiati fra gli endpoint dei due domini amministrativi, detti Porte di Dominio. Con questo schema è stata introdotta una prima terminologia che mette in evidenza gli elementi fondamentali del Sistema Pubblico di Cooperazione: il Dominio di servizi applicativi, (o Dominio Applicativo) la Busta eGov, la Porta di Dominio e l'Accordo di Servizio per quanto riguarda l'ambito di cooperazione descritto nel cappello di questa sezione. Nell'ambito dei servizi infrastrutturali sarà introdotto ora un ulteriore termine: i Servizi di Interoperabilità, Cooperazione ed Accesso (SICA). Tutti questi elementi saranno ora dettagliati uno per uno, sia sul piano tecnico che su quello normativo/istituzionale, con particolare riferimento alle Regole Tecniche per il Sistema Pubblico di Connettività16. 15 [DPCM08], articolo 1, comma 1, lettera k. 16 v. definizioni in [DPCM08], articolo 1. 20
  • 1.Introduzione al contesto di riferimento Dominio Applicativo Per dominio applicativo si intende “l'insieme delle risorse (infrastrutture, hardware, software, procedure, dati, servizi) e delle politiche che ricadono sotto la responsabilità di una specifica organizzazione”17. La definizione di un dominio per ciascuna amministrazione garantisce il principio dell'autonomia dei soggetti amministrativi nelle fasi di progettazione, realizzazione e gestione dei servizi applicativi. Il fatto che questi domini siano definiti in corrispondenza di ciascuna amministrazione che aderisce ad SPC non deve indurre a credere che l'unica possibile tipologia di servizi sia quella le cui parti siano esattamente due distinti soggetti amministrativi. Al contrario, molti procedimenti e compiti istituzionali sovente prevedono il concorso dell’azione di più soggetti. Scenari di questo genere, che in un'ottica di decentramento amministrativo verso le Regioni e gli Enti locali si fanno nel tempo più frequenti, sono stati classificati in due principali tipologie: • procedimenti inter-amministrativi, nei quali più amministrazioni concorrono, con compiti diversi, al conseguimento di un risultato complessivo, riconducibile ad uno o più servizi integrati erogati sia a fruitori esterni alla PA (ad es. Sportello unico alle imprese, Sportello unico per l’immigrazione, ecc.) che a fruitori interni alla PA. Questo tipo di procedimenti è incentrato sulla amministrazione che eroga il servizio integrato finale; • procedimenti di razionalizzazione, coordinamento e controllo, in cui è individuato normativamente un soggetto vigilante e/o di regolazione, a livello centrale o territoriale (ad es. Regioni, Province, ecc.), mentre le funzioni amministrative sono attribuite a soggetti periferici, tipicamente enti locali (ad es. Anagrafi, Catasto, Demanio…) che erogano sul territorio una stessa gamma di servizi.18 17 [DPCM08], articolo 1, comma 1, lettera k. 18 [BFMT05a], sezione “Dominio di Cooperazione, Accordo di Cooperazione e relazioni con l’Accordo di Servizio ”, p. 54 21
  • 1.Introduzione al contesto di riferimento I soggetti amministrativi che rientrano in quest'ottica hanno la possibilità di costituire un ulteriore soggetto organizzativo di SPCoop, detto dominio di cooperazione [BFMT05a]. In un siffatto dominio, i servizi erogati nascono da un procedimento di integrazione e composizione dei servizi offerti dai singoli domini applicativi (in applicazione del principio di composizionalità delle SOA). Tale procedimento è regolato in maniera invisibile al di fuori del dominio di cooperazione, e si basa su accordi specifici tra le parti in causa. Questa trasparenza è anche garantita dal fatto che, al momento del dispiegamento di un servizio composto, l'amministrazione responsabile della pubblicazione dello stesso sulla sua Porta di Dominio è sempre e comunque una sola. Tale PA, detta soggetto coordinatore responsabile, ha l'obiettivo di coordinare i compiti di ciascun partecipante ed assicurare l'efficacia tecnico-organizzativa del procedimento cooperativo. Il soggetto coordinatore responsabile è solitamente individuato da una norma di legge che specifica i ruoli dei soggetti coinvolti e indica quello con responsabilità di coordinamento o di vigilanza. Altrimenti, le parti in causa devono concordare una delega ad un soggetto coordinatore appositamente eletto, per mezzo di un'opportuna procedura tra soggetti paritetici che può anche essere mutuata dalla teoria degli algoritmi di consenso distribuito. Anche se sarà questo soggetto ad esporre il servizio sulla sua Porta di Dominio, vige comunque il principio di responsabilità dell'azione amministrativa del singolo procedimento; pertanto, ciascuna sua parte è associata al soggetto pubblico che istituzionalmente ne ha la responsabilità. 1.2.2.1 Busta eGov Definita dalle Regole Tecniche come il “protocollo di comunicazione tra servizi applicativi basato sullo standard SOAP”19, la Busta eGov [GMRF+05b] è di fatto un'estensione della versione 1.1 di questo protocollo [BEKL+00]. Nato nel 1998, SOAP è diventato de facto il successore dello standard XML-RPC20 per lo scambio di messaggi basati su XML, poggiandosi solitamente su HTTP o HTTPS, ed è la base della pila protocollare dei Web Service, su cui possono essere costruiti arbitrari strati di 19 [DPCM08], articolo 1, comma 1, lettera gg. 20 http://www.xmlrpc.org 22
  • 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: ● l’elemento 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à dell’interazione ecc; ○ Lista Riscontri. Contiene i riscontri generati in risposta a messaggi per i quali il mittente ha richiesto la conferma di ricezione; ○ Lista Trasmissioni. Contiene informazioni utili per il tracciamento del messaggio; ○ Lista Eccezioni. Contiene tutte le informazioni relative alle eventuali eccezioni occorse durante il trattamento dell’elemento Intestazione del messaggio.23 ● l’elemento Wsse:Security, contenente un blocco conforme alle specifiche del protocollo di comunicazione WS-Security [NKMH06], rilasciato come OASIS open standard24. Questo elemento può comparire in una Busta zero o più volte e può contenere più blocchi di firma digitale secondo le specifiche XML-Signature [ERSH+08]. Può essere usato per garantire la provenienza del messaggio. È fatto obbligo, in presenza di contenuto applicativo allegato al messaggio SOAP (vale a dire quando tale contenuto non è formalizzato in XML nel SOAP body), che esso sia codificato nel rispetto degli standard MIME [Gra93]. In questo caso l’elemento Descrizione conterrà il manifesto dei riferimenti agli allegati, nel rispetto delle specifiche SOAP 1.1. with Attachments [BTN00]. 22 [GMRF+05b], p. 17 23 [GMRF+05b], p. 18-19 24 http://www.oasis-open.org 25
  • 1.Introduzione al contesto di riferimento 1.2.2.2 Porta di Dominio L'unico metodo previsto perché un dominio applicativo possa integrarsi in SPCoop è che esso esponga una particolare interfaccia applicativa detta Porta di Dominio (brevemente PdD) [GMRF+05a]. Le Regole Tecniche la definiscono infatti come “unico componente architetturale del SPC attraverso il quale si accede al dominio applicativo dell'Amministrazione per l'utilizzo dei servizi applicativi”25. La PdD è essenzialmente un proxy che si fa carico di tutto il traffico su Busta eGov riguardante il dominio che la espone, e di fatto costituisce l'unica possibile tipologia logica degli estremi di uno scambio di informazioni per mezzo di servizi SPCoop. Di fatto, tutti i servizi erogati da un determinato dominio applicativo vengono esposti e pubblicati sulla sua PdD, affinché essa possa fungere da nodo di scambio di messaggi applicativi per ciascun servizio che tale dominio eroga o del quale deve fruire. Questo non significa che l'implementazione dei servizi erogati sia effettivamente disponibile sulla PdD stessa; al contrario, sarà frequente uno scenario in cui ad essa sia delegato il solo compito di instradare (dispatch) messaggi applicativi e, in alcuni casi, di effettuare la serializzazione (marshalling) e la deserializzazione (unmarshalling) di messaggi codificati come Busta eGov, il cui contenuto applicativo viene in realtà gestito da opportuni sistemi software che possono o meno risiedere sulla stessa piattaforma della PdD. Queste le funzionalità infrastrutturali che possono (e in alcuni casi devono) essere implementate da una Porta di Dominio: 1. Funzionalità di base • Gestione Busta eGov. Comprende tutte le attività (conversione di formato, implementazione degli algoritmi per gestire il protocollo) relative alla gestione della componente Intestazione dello header di una Busta eGov. • Gestione Tracciatura. Si tratta della funzionalità di logging della PdD, che è 25 [DPCM08], articolo 1, comma 1, lettera z. 26
  • 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à Porta Applicativa Porta Applicativa Light Advanced Gestione Busta eGov sì sì Gestione Tracciatura sì sì Gestione Diagnostici sì sì Gestione SOAP with Attachments sì sì Gestione modalità consegna affidabile sì sì Sicurezza di Base SSL sì sì Sicurezza avanzata Wsse: Security no sì Consolle base sì non richiesta Consolle evoluta no sì Tabella 1: Funzionalità previste per ciascuna tipologia di Porta di Dominio La facoltà di una PdD di firmare la Busta eGov relativa ai servizi che espone è sottesa al conferimento di opportuna certificazione digitale. Il processo che porta a tale certificazione è la qualificazione della Pubblica Amministrazione presso SPCoop, che prevede uno step in cui la Porta di Dominio viene accreditata presso il sistema, previa richiesta da parte di un soggetto con ruolo di Amministratore della Porta di Dominio. Per essere accreditata, una PdD deve sostenere un test di qualificazione nei confronti di un'altra PdD di riferimento esposta dal CNIPA. Tale test prevede l'esecuzione di un servizio infrastrutturale composto di una serie di operazioni che verificano che lo header della busta eGov sia correttamente gestito dalla PdD in esame, ovviamente a seconda della tipologia della Porta stessa con riferimento a caratteristiche di sicurezza. I 28
  • 1.Introduzione al contesto di riferimento test riguardano sia il ruolo di erogatore che quello di fruitore di una PdD. La qualificazione è un processo obbligatorio perché la PdD sia abilitata ad operare in SPCoop, poiché comporta il rilascio del certificato digitale necessario alla mutua identificazione dei soggetti nel sistema. 1.2.2.3 Accordo di Servizio e Accordo di Cooperazione Le Regole Tecniche definiscono l’Accordo di Servizio (brevemente AdS) [BFMT05a] come "la convenzione tra erogatore e fruitore del servizio applicativo, redatta in formato XML e resa pubblica attraverso le infrastrutture condivise del SPC, che descrive l’oggetto del servizio e le relative modalità di erogazione e fruizione"26. Questa definizione normativa, ancorché imprecisa dal punto di vista delle specifiche formali e tecnologiche (come vedremo, sono alcune parti dell'AdS ad essere rese in XML, e non l'AdS stesso), illustra in maniera esauriente il ruolo e le finalità di queste componenti di SPCoop. Si può dire che l'AdS è la componente infrastrutturale di SPCoop che fa sì che venga soddisfatto il principio di contrattazione delle SOA in forza del quale, lo ricordiamo, erogatore e fruitore comunicano aderendo ad una predeterminata convenzione, che può essere redatta dal soggetto erogatore ovvero da terze parti. L'AdS, che implementa tale convenzione nel framework in esame, consiste di fatto in un fascicolo, opportunamente archiviato, contenente una serie di documenti redatti in specifiche formali per il loro trattamento automatico, opzionalmente corredati di documenti non formalizzati, per esempio a supporto dell'interpretazione del servizio da parte di un agente umano. Si richiede, a livello sia tecnico che normativo, che un AdS contenga, in opportune codifiche XML, le seguenti informazioni relative al servizio cui fa riferimento: (i) l'insieme di operazioni supportate dal servizio, compreso l'ordine, le tipologie e i nomi dei messaggi scambiati da esse; (ii) le specifiche dei livelli di sicurezza e di qualità del servizio; (iii) i riferimenti a modelli concettuali che descrivono il significato delle informazioni trattate; (iv) vincoli tecnologici relativi 26 [DPCM08], articolo 1, comma 1, lettera x. 29
  • 1.Introduzione al contesto di riferimento all'implementazione del servizio vero e proprio, inclusa la sua ubicazione. Essendo l'Accordo di Servizio un elemento fondamentale per il presente studio, tutti questi aspetti verranno elaborati in dettaglio nel prossimo capitolo. L'Accordo di Servizio è il prodotto finale del processo organizzativo che definisce l'erogazione di un servizio in funzione dei suoi attori e del servizio stesso: si può rappresentare questo processo con una funzione: servdef: S × PA × PA → ADS dove S è l'insieme dei servizi disponibili, PA quello dei sistemi partecipanti ad SPCoop (alias Pubbliche Amministrazioni) e ADS quello degli Accordi di Servizio. Un Accordo di Servizio completo in tutte le sue parti si forma di due componenti, dette rispettivamente parte comune e parte specifica. Questa divisione è stata effettuata con la prospettiva, da un lato, di favorire il riuso di quelle componenti che possono concorrere alla definizione di più servizi; dall’altro, di minimizzare gli elementi ridondanti nel caso di servizi definiti fra più di due soggetti. Negli scenari pratici, è spesso possibile definire elementi comuni fra più accordi di servizio, specialmente dal punto di vista concettuale e logico, pertanto lo scopo di una parte comune è di fornire una base per gli accordi che definiscono servizi simili tra loro. La parte specifica di un AdS può allora essere vista come una specializzazione della parte comune, nel senso che aggrega tutte quelle caratteristiche strettamente dipendenti dalla coppia <erogatore, fruitore>, con particolare riferimento alle specifiche dell’implementazione del servizio. Per meglio comprendere questa distinzione, i servizi sono stati classificati, con riferimento alla portata della loro erogazione/fruizione, in quattro tipologie. È importante precisare che, in ciascuna di esse, la parte comune di un AdS è unica, e che gli ambiti di responsabilità inquadrati sono indipendenti dalle modalità del processo, sia esso unilaterale o concordato, di definizione del servizio che ha portato alla creazione dell'Accordo27: 27 Per i dettagli si rimanda a [BFMT05a], pp. 12-15 30
  • 1.Introduzione al contesto di riferimento 1. Servizi mono-erogatore/mono-fruitore, in cui ciascuno dei sistemi erogatore e fruitore è unico, indipendente e responsabile per il rispetto dei termini dell'AdS dalla propria parte. In questo caso si ha un'unica parte specifica. 2. Servizi mono-erogatore/multi-fruitore, destinati alla fruizione di una classe di m sistemi fruitori indipendenti, per ciascuno dei quali è definita una parte specifica. 3. Servizi multi-erogatore/mono-fruitore, erogati da n sistemi indipendenti (per ciascuno dei quali è definita una parte specifica) ma destinati alla fruizione da parte di un solo sistema. La gestione del ciclo di vita dell’Accordo, tuttavia, è affidata sempre ad un unico soggetto, eventualmente terzo rispetto agli erogatori ed al fruitore, a cui viene delegato il compito. 4. Servizi multi-erogatore/multi-fruitore, in cui i sistemi erogatori e fruitori possono essere organizzati in una matrice n × m, portando a n · m parti specifiche. La gestione del ciclo di vita segue gli stessi criteri dei servizi multi-erogatore/mono- fruitore. La divisione in parte comune e parte specifica è perfettamente compatibile con il caso di definizione unilaterale di un Accordo di Servizio da parte di un singolo erogatore: in questo scenario (applicabile sia quando il fruitore è unico che quando ve ne sono due o più), il soggetto erogatore definisce la parte comune e una sorta di template della parte specifica, ovvero una parte specifica non concordata e definita dall'erogatore, completa in tutte le sue parti, ma priva di esplicita indicazione del fruitore; sulla base di questa verrà istanziata la parte specifica vera e propria, nel momento in cui il fruitore (dopo un'eventuale fase di negoziazione delle caratteristiche col soggetto erogatore) decida di farla propria per poter utilizzare il servizio. Benché un Accordo di Servizio descriva astrattamente una collaborazione fra due soggetti, l'erogatore e il fruitore, ciascuno responsabile per i servizi offerti dal proprio Dominio, in realtà molti procedimenti amministrativi sono il frutto del concorso all'azione amministrativa di più soggetti. Come già anticipato, in simili scenari le PPAA 31
  • 1.Introduzione al contesto di riferimento formalizzano la loro volontà (o l'obbligo per legge) di associarsi, costituendo un Dominio di Cooperazione. Rimane a questo punto da definire come possa una situazione di azione di governo collettiva conciliarsi con il paradigma uno-a-uno formalizzato nell'Accordo di Servizio. Come per i Domini di responsabilità delle singole amministrazioni, anche un Dominio di Cooperazione è visto come un erogatore di servizi, con la differenza che tali servizi esposti all'esterno sono il frutto di un procedimento coordinato di integrazione e composizione dei servizi offerti dai singoli domini (servizi componenti) e sono perciò detti servizi composti. Un Accordo di Cooperazione (brevemente AdC) descrive l'insieme degli Accordi di Servizio definiti per i servizi composti, detti pertanto Accordi di Servizio Composti. Si tratta, in sintesi, della specifica dei servizi applicativi offerti da un Dominio di Cooperazione. Gli elementi fondamentali che caratterizzano l’erogazione di servizi applicativi da parte di un Dominio di Cooperazione sono, oltre ai servizi componenti e composti, anche la specifica delle modalità secondo cui sono coordinati i servizi componenti (che può essere definita in ottica di orchestrazione o di coreografia) per formare ciascun servizio composto28. Un Accordo di Cooperazione non è un insieme di Accordi di Servizio, né tantomeno una sottospecie di tale Accordo. Si tratta di una componente basata su di una specifica ben definita, che prevede l'inclusione dei seguenti elementi: • un documento istitutivo, redatto in linguaggio naturale, che descrive le finalità e la ragion d'essere di questo Dominio di Cooperazione, citandone eventuali riferimenti in campo normativo o istituzionale; • un insieme di liste di riferimenti ad Accordi di Servizio Composti, cioè gli AdS dei servizi composti, che descrivono i servizi applicativi erogati dal Dominio di Cooperazione: 28 Per approfondimenti, vedere [BFMT05a], pp. 55-57 32
  • 1.Introduzione al contesto di riferimento Un Accordo di Servizio Composto è invece una specializzazione di AdS che rappresenta un servizio derivante dalla composizione di un insieme di servizi componenti. Queste le sue componenti: • la parte comune dell’Accordo di Servizio Composto stesso, redatta come le parti comuni di tutti gli AdS; • la parte specifica, che in questo caso contiene i riferimenti ad uno o più Accordi di Servizio che rappresentano i servizi componenti; • il documento di coreografia degli AdS Componenti, redatto in WS-BPEL [JEAA+07], un linguaggio basato su XML che si utilizza per descrivere formalmente i processi aziendali, al fine di modularizzarli e suddividerne i compiti fra attori diversi. • altri documenti descrittivi non formali. Si ricorda, infine, che l'Accordo di Cooperazione, così come tutto il procedimento che porta alla sua costituzione, non ha visibilità al di fuori del Dominio di Cooperazione cui fa riferimento. I servizi composti offerti dal Dominio sono esposti, attraverso la sua Porta di Dominio, da quel soggetto amministrativo che funge da vigilante o coordinatore del processo di composizione dei servizi. Tale esposizione avviene tramite la pubblicazione di Accordi di Servizio del tutto analoghi a quelli definiti per due soggetti amministrativi semplici. Un Accordo di Cooperazione sarà allora completo di un insieme di riferimenti ordinati agli AdS che descrivono questi servizi composti. 1.2.2.4 Servizi Infrastrutturali di Interoperabilità, Cooperazione ed Accesso Si è detto, all'inizio di questa sezione, che per poter operare a livello di servizi applicativi in SPCoop è necessario che si configuri un ambito applicativo nel quale vengono forniti i servizi generali di infrastruttura necessari per il coordinamento del 33
  • 1.Introduzione al contesto di riferimento flusso informativo e per massimizzare l'efficienza dello scambio di informazioni. I Servizi di Interoperabilità, Cooperazione ed Accesso (brevemente SICA o “servizi SICA”) sono stati concepiti in risposta a questa esigenza. Le Regole Tecniche definiscono i SICA come “l'insieme delle regole, dei servizi e delle infrastrutture condivise che abilitano l'interoperabilità e la cooperazione applicativa fra le Amministrazioni e l'accesso ai servizi applicativi da queste sviluppati e resi disponibili sul SPC”29. Dunque non si tratta di un insieme di soli servizi applicativi in senso stretto, ma di un aggregato di differenti elementi, alcuni di carattere documentale ed altri sotto forma di veri e propri componenti software. La documentazione comprende, ad esempio, linee-guida per la redazione degli Accordi di Servizio, la specifica delle naming conventions adottate e la specifica dei requisiti di sicurezza. Quanto ai componenti software, essi sono raggruppati in una serie di servizi, schematizzati in figura 6: ● I Servizi di Registro SICA [BFMT05b] offrono funzionalità per la registrazione, l’accesso, l’aggiornamento, la cancellazione e la ricerca degli Accordi di Servizio e di Cooperazione. Possono essere visti come la base di dati di tali Accordi, si basano su di un'ampia estensione dello standard UDDI e sono organizzati in modo distribuito attraverso un’architettura con replicazione dell’informazione. • Il Catalogo Schemi e Ontologie (brevemente “il Catalogo”) [BFMT05c], su cui si tornerà nel prossimo capitolo per chiarirne il fondamentale ruolo nel contesto applicativo d'interesse, è un servizio SICA che nasce dall'esigenza di sostenere il principio di individuabilità delle SOA. Si tratta di un repository che raccoglie i modelli concettuali con i quali è possibile descrivere i servizi applicativi e sui quali è possibile “ragionare” con strumenti semiautomatici per l'individuazione dei servizi stessi. Si può dire, pertanto, che esso sia la base di conoscenza dell'intero Sistema Pubblico di Cooperazione. 29 [DPCM08], articolo 1, comma 1, lettera r. 34
  • 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 l’interpretazione dei termini o predicati. I linguaggi della logica utilizzati per la rappresentazione delle ontologie, più frequentemente la logica del primo ordine e la logica descrittiva, individuano il limite dell'espressività e della decidibilità delle conclusioni che si vogliono trarre da esse. Non si entrerà del dettaglio di tali limiti di espressività, preferendo rimandare una trattazione più esauriente al momento in cui saranno definiti i linguaggi formali il cui utilizzo è previsto nel Sistema Pubblico di Cooperazione. Ci si limita ad anticipare che questi linguaggi formali devono poter codificare i seguenti costrutti: (i) costanti predicative unarie (chiamate di solito classi, o tipi); (ii) costanti individuali (chiamate di solito individui o istanze); (iii) costanti predicative relazionali (relazioni, proprietà, attributi, associazioni, slot), usate per mettere in relazione tra loro sia intere categorie di individui che gli individui stessi; (iv) assiomi sulle classi (chiamati variamente vincoli, restrizioni, regole), che a loro volta usano un insieme ristretto di operatori logici, fra cui operatori booleani, quantificatori ed insiemi [Gan08]. Idealmente, un'ontologia ben formata contiene molte altre informazioni che possono essere rese per mezzo di metadati o annotazioni. Queste informazioni si basano 40
  • 2.La semantica per l'interoperabilità dei servizi in SPCoop su costrutti che esulano dallo scope dei linguaggi logici, pertanto sono molto più utili alla progettazione e concettualizzazione delle ontologie che non ad agenti software automatici, detti ragionatori, finalizzati a derivare conclusioni a partire dalle asserzioni di un insieme di ontologie. L'ambito applicativo della semantica dei domini rappresentata con le ontologie è sterminato. In linea generale, le ontologie computazionali possono entrare in gioco in qualunque contesto ove si pongano problemi di comunicazione fra più attori, dove per attore si intende sia un agente vero e proprio, sia un elemento passivo come una sorgente di informazioni. Sul piano applicativo, sono già moltissimi i servizi informativi o basati sull'uso di sistemi informativi che fanno affidamento alle ontologie per favorire l'efficienza, il risparmio di risorse e l'operatività: oltre ovviamente ai campi dell'eGovernment e dei Web Service, anche l'indicizzazione e l'estrazione di informazioni da documenti, l'interrogazione o il merging di basi di dati eterogenee, la condivisione di dati scientifici, il commercio elettronico e il social networking sono solo alcuni dei campi d'impiego di strategie operative basate su ontologie. Dal punto di vista del contenuto, si fanno sempre più frequenti i gruppi di lavoro finalizzati alla produzione di ontologie di riferimento per particolari domini, fra i quali si possono citare Gene Ontology30 per la biologia molecolare, RosettaNet31 per l'elettronica e Agrovoc32 per l'agricoltura. Parallelamente, uno dei campi di studio dell'ontology engineering è la creazione di modelli che sappiano descrivere concetti generali che siano gli stessi in tutti i domini. Esempi di queste ontologie, delle fondazionali o upper ontologies, sono: Basic Formal Ontology (BFO)33, General Formal Ontology (GFO)34, Suggested Upper Merged Ontology (SUMO)35 e Descriptive Ontology for Linguistic and Cognitive Engineering (DOLCE)36. Altra importante risorsa semantica che 30 http://www.geneontology.org 31 http://www.rosettanet.org 32 http://www.fao.org/aims/ag_intro.htm 33 http://www.ifomis.org/bfo 34 http://www.onto-med.de/ontologies/gfo 35 http://www.ontologyportal.org 36 http://www.loa-cnr.it/DOLCE.html 41
  • 2.La semantica per l'interoperabilità dei servizi in SPCoop condivide alcuni aspetti delle ontologie fondazionali è il database lessicale WordNet37, nato come network semantico basato su principi di psicolinguistica e oggi assurto a vero e proprio dizionario monolingue inglese. Nel campo dei Web Service, due dei progetti meglio conosciuti per concettualizzarne lo scambio di informazioni sono le ontologie Web Service Modeling Ontology (WSMO)38 e OWL-S (evoluzione di DAML-S) [MBHL+04]. Nel seguito saranno esposti i più noti formalismi utilizzati nella creazione e gestione delle ontologie, di cui alcuni saranno poi adottati nella definizione del layer semantico di SPCoop: in particolare RDF per la codifica della conoscenza ed OWL per l'authoring di ontologie. 2.1.2. Strumenti formali per le ontologie: Resource Description Framework (RDF), RDF Schema e Web Ontology Language (OWL) Originariamente progettato come un data model per la rappresentazione di metadati, RDF (acronimo per Resource Description Framework) [LasSwi99] è una famiglia di specifiche del W3C che, nel periodo dal 1999 al 2004, si sono consolidate in un linguaggio general-purpose per la rappresentazione delle informazioni sul web. Il data model di RDF si basa sull'idea che le risorse descritte abbiano delle proprietà, ciascuna con un valore, e che queste risorse possano essere descritte per mezzo di asserzioni, o statement, che ne specifichino le proprietà e i rispettivi valori. I membri di un tale statement sono descritti in RDF seguendo una particolare terminologia mutuata da una metafora linguistica comune: un'espressione in RDF è una tripla soggetto- predicato-oggetto, dove soggetto e predicato sono risorse, che possono essere identificate ciascuna da un Uniform Resource Locator (URI), mentre l'oggetto può essere una risorsa, una costante (o letterale) o a sua volta una tripla RDF. Una risorsa può essere anonima, nel qual caso è detta blank node. 37 http://wordnet.princeton.edu 38 http://www.wsmo.org 42
  • 2.La semantica per l'interoperabilità dei servizi in SPCoop Il data model di RDF è astratto, pertanto prescinde dal formalismo usato per serializzarlo. Tuttavia, mentre da un lato è comune (anche per la rappresentazione di ontologie) l'impiego di una sintassi XML appositamente definita, è anche utile pensare ad un insieme di statement come ad un grafo i cui nodi sono i soggetti ed oggetti e per ogni statement vi è un arco tra soggetto ed oggetto, etichettato con l'identificatore della proprietà. RDF Schema (o RDFS) [BriGuh04] è un linguaggio che è stato pensato per strutturare le risorse RDF a fini di porre le basi per la descrizione di ontologie (o vocabolari RDF). Le sue componenti principali, che ritroveremo successivamente in tema di linguaggio OWL, sono: ● rdfs:class per dichiarare che una risorsa rappresenta il tipo (o la classe) di un'altra risorsa; ● rdfs:subClassOf per dichiarare gerarchie di classi; ● rdfs:domain, dichiarato per una proprietà, indica la classe a cui appartengono i soggetti di tutte le triple che hanno questa proprietà come predicato; ● rdfs:range, dichiarato per una proprietà, indica la classe o il tipo di dato primitivo a cui appartengono gli oggetti di tutte le triple che hanno questa proprietà come predicato; Mentre RDFS rappresenta una valida base di partenza per la formalizzazione di modelli semantici, esso si rivela limitato ed insufficiente a garantire determinati trade- off di espressività e computabilità. Ad esempio, non è possibile rappresentare assiomi sulle classi come l'equivalenza o la disgiunzione, poiché l'unica relazione rappresentabile è quella di tipo “is-a” (tramite assiomi detti di sussunzione). La descrizione del superamento di queste limitazioni è affidata alla prossima sezione. Ad oggi, per Web Ontology Language (abbreviato come OWL) [DSBH+04] si 43
  • 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 globali di cardinalità: owl:FunctionalProperty e 48
  • 2.La semantica per l'interoperabilità dei servizi in SPCoop owl:InverseFunctionalProperty. 4. Caratteristiche logiche delle proprietà: owl:SymmetricProperty e owl:TransitiveProperty. Per ragioni di spazio, si rimandano ai riferimenti del W3C per OWL [DSBH+04] i dettagli di questi costrutti sintattici, il cui significato si presta comunque all'intuizione a partire dai loro nomi. Aggiungiamo infine che i tre costrutti di OWL usati per formare assiomi di classe (sottoclasse, equivalenza e disgiunzione) sono tre proprietà aventi descrittori di classe sia come dominio che come codominio. Gli individui, infine, rappresentano istanze di classi e sono la componente basilare di un'ontologia. Non è necessario, in senso stretto, includere alcun individuo nella definizione di un'ontologia, ma è bene tener presente che una delle finalità fondamentali delle ontologie è la categorizzazione di oggetti, anche se non sono definiti esplicitamente come parte del modello (cosa possibile visto che, data la natura distribuita del web semantico, è sempre possibile istanziare una classe anche trasversalmente a domini applicativi diversi). Per definire un individuo, è sufficiente dichiararlo come membro di una classe tramite un assioma di istanza, che in RDF/XML sarebbe: <Servizio rdf:ID="ServizioIndiceSoggetti" /> Un'importante considerazione riguarda la questione della dicotomia fra le relazioni di sottoclasse e di istanza. Nell'esempio di cui sopra, come è stato possibile determinare che ServizioIndiceSoggetti indicasse un particolare servizio piuttosto che una sottoclasse di servizi? Nella pratica, questa scelta è arbitraria e costituisce uno dei capisaldi dell'ingegneria della conoscenza. 49
  • 2.La semantica per l'interoperabilità dei servizi in SPCoop 2.2. Analisi dell'Accordo di Servizio L'Accordo di Servizio è il prodotto finale di quel processo organizzativo che è la definizione di un servizio in SPCoop. Nell'ottica di voler lasciare a ciascun soggetto amministrativo partecipante la libertà di apportare aggiornamenti e modifiche, anche sui piani concettuale e logico, ai servizi erogati da esso anche successivamente alla loro pubblicazione, si è reso fondamentale un supporto al versioning dei servizi. Questo si traduce a sua volta nella definizione di versioni diverse dei corrispondenti Accordi di Servizio, i quali dovranno necessariamente differire anche a livello di parte comune. 2.2.1. Ciclo di vita dell'Accordo di Servizio Ciascuna versione di un servizio segue un ciclo di vita autonomo, e così l'AdS corrispondente. Questo ciclo di vita è suddiviso nelle sei fasi illustrate in Tabella 239. Fase Descrizione Fase 1. Il servizio viene ideato e formalizzato nella parte comune e in una Definizione o più parti specifiche, a seconda della tipologia del servizio. Due dell’Accordo di sono i possibili approcci che può seguire il processo di Servizio definizione: 1. Approccio unilaterale. La parte comune viene concepita unilateralmente dal soggetto erogatore, o da un soggetto delegato. Le parti specifiche possono seguire l’approccio unilaterale o l’approccio concordato definito al punto 2. 2. Approccio concordato. La definizione dell’Accordo di Servizio, nelle sue parti comune e specifica, è negoziata in modo congiunto dall'erogatore e dal fruitore (o da loro rappresentanti). 39 [BFMT05a], sezione “Ciclo di Vita dell’Accordo di Servizio”, pp. 15-17 50
  • 2.La semantica per l'interoperabilità dei servizi in SPCoop Fase 2. La registrazione del servizio, obbligatoria in SPCoop comprende Pubblicazione le seguenti attività da effettuare presso i Servizi di Registro SICA: dell’Accordo di Servizio sul • registrazione dei titolari dei sistemi erogatore e fruitore, Servizio di • registrazione della parte comune, Registro SICA. • 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. I titolari dei sistemi erogatori e fruitori implementano Implementazione rispettivamente l’erogazione e la fruizione del servizio in del servizio. conformità con l’Accordo di Servizio. Questa fase può essere parallela, o anche precedente la pubblicazione sul SICA Fase 4. I titolari dei sistemi erogatori e fruitori presentano i componenti Presentazione software che realizzano il servizio sulla rete, ovvero li mettono in del servizio su esercizio sulla Porta di Dominio. SPCoop. Fase 5. Il servizio è erogato in conformità con l’Accordo di Servizio. La Erogazione/fruizi fase di erogazione/fruizione comprende attività di logging e può one del servizio comprendere attività di monitoraggio definite nell’AdS ed su SPCoop. effettuate dai soggetti designati da detto accordo. Fase 6. Questa fase prevede l’archiviazione (della versione) del servizio, Dismissione del suo AdS e dei giornali di tracciatura.. dell’Accordo di La fase di dismissione prevede la sottrazione (della versione) del Servizio e del servizio da SPCoop, dopo annuncio preventivo ai titolari dei servizio. sistemi fruitori. Tabella 2: Ciclo di vita di un servizio e del relativo Accordo di Servizio 51
  • 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. L’Accordo 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 l’implementazione 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 l’esecuzione e la gestione dei sistemi erogatore e fruitore: è utilizzato dai sistemi di gestione dell’esecuzione nell’operatività 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 dell’Accordo 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. L’alto grado di formalità consiste nel fatto che tutti i documenti di questa specifica sono resi in un’opportuna 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 WS- Agreement 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 dell’AdS 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 dell’Interfaccia, la Specifica delle Conversazioni ed il Riferimento alla Semantica dell’Informazione 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 dell’Interfaccia è formalizzata in una rappresentazione su due livelli di astrazione, uno dei quali si differenzia in relazione all’erogatore e al fruitore. Essa consiste in tre documenti, tutti resi nel linguaggio WSDL versione 1.1. Nello specifico, essi sono: (i) WS_Concettuale, la descrizione dell’interfaccia del servizio a livello di scenario di coordinamento; (ii) WS_ErogatoreLogico, che descrive la parte di competenza dell’erogatore in termini di scambio elementare di messaggi; (iii) WS_FruitoreLogico, analogo a WS_ErogatoreLogico, ma per la parte di competenza del fruitore. ● Questi tre documenti rappresentano la specifica astratta del servizio, pertanto sono scevri di informazioni relative all’implementazione dello stesso e rappresentano per questo una componente dell’AdS potenzialmente riusabile. Nei termini del linguaggio WSDL 1.1, questo significa che gli unici costrutti di primo livello (vale a dire figli dell’elemento 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 l’implementazione) 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 dell’interfaccia, 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 dell’Informazione 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 dell’informazione 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 l’erogatore 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 dell’Interfaccia della parte specifica di un AdS. Si ricorda, a tale proposito, che la base per l’implementazione 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 l’esercizio e la gestione, dell’aderenza 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 dell’AdS. ● 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: • memorizzare ontologie e schemi concettuali, ai quali si presume facciano 58
  • 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 l’utente 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 semi- automatici 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>, a sua volta provvisto dell'attributo sawsdl:modelReference. È fondamentale ricordare, a questo proposito, che l'elemento attrExtensions 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: “l’ontologia dei dati scambiati nell’ambito 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 l’interpretazione autentica; l’ontologia dei servizi consente di generalizzare l’insieme degli stessi rispetto a opportune classi di servizio sul cui significato non ci sono ambiguità; infine l’ontologia dei processi mira a generalizzare l’insieme 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 = "http://progettoicar.it/2008/06/owl/co" xmlns = "http://progettoicar.it/2008/06/owl/co#" xmlns:co = "http://progettoicar.it/2008/06/owl/co#" xmlns:ads = "http://www.lego-lab.it/icar/ads#" xmlns:owl = "http://www.w3.org/2002/07/owl#" xmlns:rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs = "http://www.w3.org/2000/01/rdf-schema#" xmlns:xsd = "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 user- friendly 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 WSMO Studio Autori LSDIS WSMO Working Group Piattaforme supportate Linux, Mac OS X, Windows Linux, Mac OS X, Windows Supporto per WSDL 1.1 limitato (solo elementi comuni limitato (solo elementi comuni con WSDL 2.0 più l'elemento con WSDL 2.0) attrExtensions) Supporto per XSD stand-alone sì no Gestione dipendenze ontologie limitata limitata Visualizzazione strutturata di sì sì ontologie Visualizzazione strutturata di sì sì WSDL/XSD Paradigma di interazione fail-safe 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 http://www.adobe.com/products/flash/about/ 48 http://java.sun.com/docs/books/tutorial/deployment/applet/ 49 http://www.wsmostudio.org 50 http://lsdis.cs.uga.edu/projects/meteor-s/downloads/index.php?page=1 51 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 http://javafx.com 56 http://www.sun.com/software/javafx 57 http://silverlight.net 58 http://www.openlaszlo.org 59 http://www.adobe.com/products/flex 60 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 x86_64 multicore, 2048+ MB Piattaforma di virtualizzazione VMware Server63 Sistemi Operativi host Linux Fedora 864 Windows XP SP3 Sistemi Operativi guest Windows XP SP2 Java Virtual Machine e kit di sviluppo Sun JDK SE65 1.6.0 con aggiornamenti Ambiente di sviluppo integrato (IDE) Eclipse Europa (3.3) – Ganymede (3.4) Servlet Container Apache Tomcat66 5.5 Editor di ontologie NeOn Toolkit67 1.0 – 1.2 Protégé68 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. Notepad++79 (Windows) gedit80 (Linux) Authoring di documentazione e grafica 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 http://www.google.com/chrome 75 http://www.mozilla.com/en-US/firefox/ 76 http://www.microsoft.com/windows/products/winfamily/ie 77 http://www.opera.com 78 http://www.apple.com/safari 79 http://notepad-plus.sourceforge.net 80 http://www.gnome.org/projects/gedit/ 81 http://dia-installer.de/index_en.html 82 http://www.gimp.org 83 http://www.inkscape.org 84 http://www.lyx.org 85 http://www.openoffice.org 86 http://www.papyrusuml.org 87 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: ● Protégé è 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 Protégé-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 F- Logic. È basato su Eclipse e vanta una quantità considerevole di estensioni, anche commerciali. 88 http://www.stanford.edu 89 http://protege.stanford.edu/overview/protege-owl.html 90 http://mindlab.umd.edu 91 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 Implementazioni Grafica e trasporto per AJAX Google Web Toolkit93, Ext GWT94, GWT-Ext95, Tatami96, SmartClient97, JSON98 WSDL WSDL4J99, Woden100 XML Schema (XSD) W3C DOM101 SAWSDL Woden4SAWSDL102, WSMO4J Grounding API103, SAWSDL4J104 OWL Jena105, OWL API106, Manchester OWL107, KAON2108, Pellet109, FaCT++110, Hoolet111, RACER112 Tabella 5: Panoramica delle implementazioni Java delle tecnologie adottate 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 Interfaccia JWSDL binding javax.wsdl.Binding definition javax.wsdl.Definition fault javax.wsdl.Fault import javax.wsdl.Import input javax.wsdl.Input message javax.wsdl.Message operation javax.wsdl.Operation output javax.wsdl.Output part javax.wsdl.Part port javax.wsdl.Port portType javax.wsdl.PortType service javax.wsdl.Service types 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 all’Apache 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 dell’Università dell’Indiana119 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 dell’Apache Web Service Project. E’ espressamente dichiarato nella pagina del progetto che Woden nasce con l’intento 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 d’interesse, ha costituito forte motivo ostativo per l’adozione della suddetta all’interno 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 l’intenzione 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 un’estensione 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 l’API siano: (i) Apache Axis 2, l’implementazione Java del principale motore per Web Service impiegato dalla Apache Software Foundation; (ii) Apache ServiceMix, un middleware per infrastrutture d’impresa basato su SOA.; (iii) Woden4SAWSDL, un object model per l’accesso a documenti SAWSDL rispondenti ai requisiti di Woden. Ovviamente, il terzo progetto è stato quello che ha raccolto la nostra attenzione come candidato all’impiego nel progetto SASCHA. Si è pertanto proceduto ad un’analisi 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 l’implementazione dei metodi d’accesso a classi specializzate, che vengono istanziate da appositi oggetti di tipo WSDLFactory (ad esempio l'interfaccia org.apache.woden.wsdl20.InterfaceOperation rappresenta elementi di tipo operation). 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, dall’altro rende pressoché inutile una conoscenza approfondita di WSDL4J. L’esame 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. L’accesso 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 all’utente di assegnare o modificare annotazioni semantiche alle varie componenti WSDL. Gli unici metodi presenti consentono l’accesso 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 l’editor WSMO Studio, il set di librerie WSMO4J fa parte delle implementazioni più conosciute che fanno capo all’ontologia di riferimento per i Web Service WSMO, o Web Service Modeling Ontology [KLR05]. WSMO4J consiste in una API, corredata da un’implementazione di riferimento per la costruzione sia di Web Service che di processi aziendali semantici. L’API è 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 l’insieme 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 l’aggiunta 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à un’implementazione di riferimento per tutte le interfacce incluse nella grounding-api. Pur basando il proprio object model su interfacce, WSMO4J non estende né utilizza l’object model di WSDL4J. La libreria è difatti stand-alone e non ha dipendenze esterne. Il punto d’accesso alle annotazioni semantiche di un documento WSDL è rappresentato dall’interfaccia org.wsmo.grounding.sawsdl.Grounding, da cui il nome dell’API, 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 dell’interfaccia 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 l’aggiunta, 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. L’ultima 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 l’object 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 dall’interfaccia javax.wsdl.PortType, non esiste un’interfaccia 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 l’albero DOM di un XML Schema. L’estensione di WSDL4J viene effettuata tramite specializzazione sia delle sue interfacce che della loro implementazione di riferimento. Esemplificando, l’interfaccia javax.wsdl.Definition, che fornisce una rappresentazione di un intero documento WSDL, viene estesa in SAWSDL4J dall’interfaccia edu.uga.cs.lsdis.sawsdl.Definition, che integra nella precedente i metodi di accesso a versioni specializzate delle varie componenti WSDL di primo livello come Message (accessibile per mezzo del metodo getSemanticMessage(QName name)) e PortType (accessibile per mezzo del metodo getSemanticPortType(QName name)). L’impostazione 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 all’utente-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 e dall’elemento 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 un’implementazione 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 dell’albero DOM di un XML Schema), dall’altro 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 dell’interfaccia utente). Pertanto, si rende necessario costruire a mano questa rappresentazione mediante una visita dell’albero DOM che tenga conto solamente delle componenti XML Schema d’interesse, 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 l’annotazione 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 l’API con un plugin che supporti la creazione di un’istanza di 121
  • 4.Sviluppo ed implementazione: SAscha Schema in SAWSDL4J a partire direttamente da un documento XSD, per poi passarla al motore SAWSDL dell’applicazione, che la tratta esattamente come le istanze di Schema per schemi importati da WSDL. Ipotizzando che SAWSDL potesse rappresentare la scelta definitiva per l’API 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 nell’esecuzione 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 d’uso 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 l’attributo 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 dall’insieme di model reference. Questo implica la mancata rimozione dell’attributo quando questo insieme è vuoto, così come dell’elemento sawsdl:attrExtensions richiesto per l’annotazione semantica di operazioni in WSDL 1.1. Sono stati anche riscontrati casi di model reference duplicate in ragione di questa lacuna. 3. L’indentazione 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 Svantaggi Woden4SAWSDL ● In attivo sviluppo e con ● Supporto per WSDL 1.1 previsioni di un futuro previsto, ma attualmente supporto per vari dialetti assente di WSDL ● Accesso alle annotazioni ● Ricalca da vicino in sola lettura l'intuitivo object model di JWSDL ● Fortemente orientato all'estensibilità senza però richiedere un intervento diretto sulla core API WSMO4J Grounding API ● Gestione delle annotazioni ● Mancato supporto di SAWSDL in un layer WSDL 1.1 indipendente ● Manca di un object model ● Completa di tutti i metodi per gli elementi WSDL, d'accesso alle annotazioni pertanto non è possibile semantiche di un operare con esso documento WSDL prescindendo da WSDL4J ● API molto più ricca e complessa di quanto richiesto ai fini del progetto 123
  • 4.Sviluppo ed implementazione: SAscha SAWSDL4J ● Supporto per WSDL 1.1 ● Sviluppo discontinuo ● Integrazione con WSDL4J ● La serializzazione verso ● Estensibile con XML e la rimozione o annotazioni fuori standard modifica di annotazioni non sono implementate ● Annotazioni XSD gestite in maniera non coerente con quelle di WSDL 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 all’interno del progetto SASCHA. D'altro canto la WSMO4J Grounding API, pur costituendo solamente una minima parte dell’API 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 l’analisi dettagliata dei costrutti WSDL standard. Tuttavia, il mancato supporto per WSDL 1.1 ha finito per pregiudicare la candidatura di questa libreria per l’impiego come middleware per il supporto semantico in SASCHA. Il fatto che SAWSDL4J estenda l’object 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 l’API di WSDL4J. Il fatto che il programmatore debba, a seconda dei casi, scegliere di utilizzare un’interfaccia standard o quella specializzata per gestire un elemento WSDL, comporta nelle difficoltà nel passaggio da una rappresentazione 124
  • 4.Sviluppo ed implementazione: SAscha all’altra. 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 l’object model in codice XML con evidenziamento della sintassi tramite rendering in HTML. Questa caratteristica, unita all’innegabile vantaggio di essere l’unica 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 stand- alone; 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 all’interno 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. ● Un’altra 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” o “http://www.w3.org/2000/10/XMLSchema”, questi nodi sono 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 per schemi XML stand-alone: il plugin SAXSD4J 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 e xsd:redefine di uno schema incluso in un elemento wsdl:types. 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 schemaURI, String contextURI, boolean recurseReferences) 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. Tutti gli oggetti di tipo Schema che vengono creati da SchemaFactoryImpl 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 startElement, String path, ModelReference ref) 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 references per un elemento viene trattata come un insieme, è necessario evitare ripetizioni. A supporto di questo requisito si fa presente che, 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 individuato valutando l'espressione XPath path a partire dall'elemento DOM startElement. Analizzando il codice sorgente si è osservato che l'argomento 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 startElement, String path, Set<ModelReference> refs) 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 Classe di implementazione javax.wsdl.Definition edu.uga.cs.lsdis.sawsdl.impl.Definiti onImpl javax.wsdl.extensions.Extension org.example.sascha.server.wsdl.overri Registry de.StandardExtensionRegistry javax.wsdl.xml.WSDLReader org.example.sascha.server.wsdl.overri de.WSDLReaderImpl javax.wsdl.xml.WSDLWriter org.example.sascha.server.wsdl.overri de.WSDLWriterImpl 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 specifica SAWSDL ammette tre attributi (modelReference, 137
  • 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. 3. Un'enumerazione è serializzabile. Le costanti dell'enumerazione sono 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 e com.google.gwt.user.client.rpc.IsSerializable, 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 GWT- RPC 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; • getMergedSAWSDLDocumentLocation(). Prende in input la 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: ● loadOntology(URI uri, boolean forceReload): boolean tenta di caricare 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() e 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 Layout Efficienza del Altro funzionalità dell'interfaccia e motore di progetto interpretazione JavaScript126 DOM Firefox 2.x corretta perfetto sufficiente Firefox 3.0 corretta perfetto buona FireBug segnala errori non fatali negli script di ExtJS Internet corretta Non gestisce Buona, eccetto Explorer 7 correttamente il che per il dimensionamento parsing XML delle colonne lato client negli StackPanel Safari 3.1.2 corretta perfetto buona Chrome 0.2 corretta Qualche problema eccellente Sporadici crash nel dimensionamento delle finestre Opera 9.x Non supporta perfetto scarsa Non tratta in i menu maniera corretta contestuali i messaggi in JavaScript formato JSON 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). 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 nell’Indice della Pubblica Amministrazione (IPA)129 su SICA. L’attività 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 nell’ambito del sistema informativo lavoro, con particolare riguardo alla sinergia fra l'operato delle Regioni e l’azione 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 dall’infrastruttura di cooperazione applicativa rilasciata da ICAR all’interno 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 Descrizione del requisito applicativo. Si tratta della postcondizione che dev'essere soddisfatta dallo stato finale. Stato iniziale Stato iniziale in cui si può ragionevolmente assumere che si trovi il sistema. Individua le precondizioni del caso di test. Step di esecuzione Sequenza delle azioni eseguite dall'utente a partire dallo stato iniziale sino allo stato in cui si verifica la postcondizione. Stato finale 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. # Descrizione 1 Apertura documento senza annotazioni 2 Apertura documento con annotazioni 3 Apertura documento con schemi importati 4 Annotazione documento senza prefisso 5 Annotazione documento con prefisso 6 Annotazione di dipendenze 7 Annotazioni fuori standard 8 Annotazioni ripetute 9 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 interattività131, 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., Yalçınalp, Ü., "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., Siméon, 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/SPCoop- AccordoServizio_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/SPCoop- ServiziRegistro_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://www- 128.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 dell’Accordo di Servizio e dell’Accordo 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 dall’articolo 71, comma 1-bis del decreto legislativo 7 marzo 2005, n. 82, recante il "Codice dell’amministrazione 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-201- 63361-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/SPCoop- Busta%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/ws- gloss, 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 E- government, 2007 [JEAA+07] : Jordan, D., Evdemon, J., Alves, A., Arkin, A., Askary, S., Barreto, C., Bloch, B., Curbera, F., Ford, M., Goland, Y., Guízar, A., Kartha, N., Liu, C. K., Khalaf, R., König, 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.oasis- open.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/BasicSecurityProfile- 1.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.oasis- open.org/committees/download.php/16790/wss-v1.1-spec-os- SOAPMessageSecurity.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 la pubblica amministrazione e l'innovazione, http://www.funzionepubblica.it [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 Völker. 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