Progettazione di un framework Open Source per la cooperazione applicativa nella Pubblica

Transcript

1 UNIVERSITÀ DEGLI STUDI DI PISA Facoltà di Scienze Matematiche, Fisiche e Naturali Corso di Laurea Specialistica in Tecnologie Informatiche Tesi di Laurea Progettazione di un framework Open Source per la cooperazione applicativa nella Pubblica Amministrazione Candidato Ruggero Barsacchi Relatori Prof. A. Corradini Controrelatore Prof. G. A. Cignoni Prof. T. Flagella Anno Accademico 2004/05

2 Sommario Elenco delle illustrazioni...5 Introduzione...8 Capitolo 1 Il paradigma di cooperazione applicativa nell'ambito della Pubblica Amministrazione Il contesto organizzativo Alcuni scenari applicativi I Sistemi di Cooperazione preesistenti SIGMA TER Sistema Informativo della Montagna Indice Nazionale delle Anagrafi I nuovi standard di cooperazione del CNIPA...29 Capitolo 2 Il Contesto Tecnologico Le architetture di cooperazione applicativa: RPC, SOA, EDA Il paradigma dei Web Services Schemi XML SOAP WSDL UDDI...53 Capitolo 3 Le specifiche SPCoop Architettura Relazioni di servizio Accordo di servizio Scambio di messaggi La Porta di Dominio dei Servizi Applicativi La Busta di e-government I servizi di cooperazione Il registro dei servizi Il repository documentale Il servizio di gestione degli eventi

3 3.4.4 I servizi di gateway applicativo verso altre reti Il portale dei servizi I servizi di gestione Paradigmi di interazione supportati Gli scenari applicativi nell'architettura SPCoop Richiesta senza risposta Richiesta con risposta Notificazione senza risposta Notificazione con risposta Altri scenari applicativi...92 Capitolo 4 Le soluzioni analizzate Il progetto CART della Regione Toscana L'architettura di CART I componenti di CART Il Framework CA I Proxy Applicativi Scenari applicativi in CART Conclusioni dell'analisi di CART Le altre soluzioni analizzate Il progetto SOLE Il progetto ICAR OpenPDD Capitolo 5 OpenSPCoop: un'implementazione Open Source dell'architettura SPCoop Motivazioni per un'implementazione Open Source Architettura di OpenSPCoop Il Proxy Redirector Il Proxy dei Servizi Web Gestione della sicurezza Gestione della tracciabilità Le componenti software e le loro funzionalità OpenSPCoop Richieste per servizi interni al Dominio di Cooperazione (gestione Porta Applicativa) Richieste per servizi esterni al Dominio di Cooperazione (Porta Delegata) Requisiti critici della Busta e-gov Cooperazione per notifica di eventi in OpenSPCoop Funzionalità supportate per la Cooperazione per Eventi

4 5.3.3 Autorità di Registrazione dei Servizi Squid L'Application Server e gli altri Componenti dell'infrastruttura di cooperazione L'Application Server JBoss SOAP Server: Apache AXIS UDDI Registry: Apache juddi Message Oriented Middleware: JbossMQ Vantaggi rispetto alle soluzioni analizzate Gli scenari applicativi in OpenSPCoop Interazione dall'esterno del dominio verso l'interno Interazione dall'esterno del dominio verso l'esterno Interazione dall'interno del dominio verso l'esterno Interazione dall'interno del dominio verso l'interno Capitolo 6 Implementazione di un Prototipo per OpenSPCoop Le funzionalità del prototipo OpenSPCoop L'architettura del prototipo OpenSPCoop Le complessità implementative Sviluppi previsti Conclusioni Appendice A Schema XML della intestazione e della descrizione della Busta di e-government Appendice B Esempi di utilizzo delle intestazioni della Busta di e-government B1 Messaggio senza replica B2 Messaggio con replica sincrono B3 Messaggio con replica Asincrono Simmetrico B4 Messaggio con replica Asincrono Asimmetrico B5 Notifica di evento Appendice C Il codice del prototipo OpenSPCoop C1 OpenSPCoop.java C2 Invoker.java C3 OpenSPCoopURLMapper.java

5 Bibliografia

6 Elenco delle illustrazioni Figura 2.1. L'architettura dei Web Services: attori, ruoli e operazioni...41 Figura 2.2. Pila delle tecnologie utilizzate nei Web Services...42 Figura 2.3. Schema di comunicazione SOAP utilizzando il protocollo HTTP...46 Figura 2.4. Struttura di un messaggio SOAP...47 Figura 2.5. Gerarchia delle sezioni che compongono un documento WSDL...50 Figura 3.1. Relazione di servizio...58 Figura 3.2. Accordo di servizio...60 Figura 3.3. Modello di riferimento per l'integrazione delle porte di dominio dei servizi applicativi...70 Figura 3.4. Struttura logica delle porte di dominio...72 Figura 3.5. Struttura della busta di e-gov...77 Figura 3.6. I servizi di cooperazione...79 Figura 4.1. Struttura dell'architettura di CART...97 Figura 4.2. Le componenti dell'infrastruttura di cooperazione Figura 4.3. Il ruolo di FCA nell'invio dei messaggi da parte dei SIL Figura 4.4. Le operazioni svolte dal Proxy Applicativo Figura 4.5. Flusso applicativo nella cooperazione per richiesta di servizio Figura 4.6. Flusso applicativo nella cooperazione per notifica di eventi Figura 4.7. Componenti architetturali che realizzano il CRIC Figura 4.8. Architettura logica di un Proxy Applicativo Figura 4.9. Architettura della Porta Applicativa nel progetto SOLE Figura Interventi progettuali del Progetto ICAR

7 Figura 5.1. Struttura logica di riferimento Figura 5.2. Architettura di un Nodo di COOPerazione (NCOOP) Figura 5.3. Architettura del Proxy Redirector Figura 5.4. Proxy dei Servizi Web Figura 5.5. Flusso applicativo nel processo di Gestione di Sicurezza Figura 5.6. Flusso applicativo nel processo di Gestione della Tracciabilità Figura 5.7. Infrastruttura di cooperazione applicativa realizzata da OpenSPCoop Figura 5.8. Architettura generale di OpenSPCoop Figura 5.9. Gestione delle Porte Applicative nell'architettura OpenSPCoop Figura Gestione delle Porte Delegate nell'architettura OpenSPCoop Figura Flusso applicativo nello scenario di cooperazione per notifica di eventi..157 Figura Flussi di comunicazione nella gestione della cooperazione per eventi Figura Architettura generale del componente di Autorità di Registrazione di Servizi Figura Architettura dell'application server JBoss Figura Pipeline di elaborazione dei messaggi SOAP di Axis Figura Implementazioni JMS dei paradigmi publish & subscribe e point-to-point Figura Confronto tra l'architettura dei nodi applicativi nel progetto CART e in OpenSPCoop Figura Diagramma di rappresentazione dei processi applicativi Figura Diagramma che illustra il processo effettuato per un'interazione proveniente dall'esterno del dominio e diretta verso l'interno Figura Diagramma che illustra il processo effettuato per un'interazione proveniente dall'esterno del dominio e diretta verso l'esterno Figura Diagramma che illustra il processo effettuato per un'interazione proveniente dall'interno del dominio e diretta verso l'esterno Figura Diagramma che illustra il processo effettuato per un'interazione proveniente dall'interno del dominio e diretta verso l'interno Figura 6.1. Scenario in cui due applicazioni accedono a due servizi Web

8 Figura 6.2. Ruolo di OpenSPCoop nello scenario in cui due applicazioni accedono a due servizi Web distinti Figura 6.3. Architettura del prototipo OpenSPCoop

9 Introduzione Obiettivo di questa Tesi è la progettazione di un framework Open Source, aderente alle specifiche per la Cooperazione Applicativa nella Pubblica Amministrazione recentemente emanate dal Centro Nazionale per l Informatica nella Pubblica Amministrazione (CNIPA). Con Cooperazione Applicativa si intende la regolamentazione delle modalità (standard) relative allo scambio di dati, finalizzato all'erogazione e alla fruizione di servizi, tra i sistemi informatici della Pubblica Amministrazione. L'esigenza di standard è maturata nel corso degli ultimi anni come naturale conseguenza del forte processo di informatizzazione in corso nella pubblica amministrazione, comunemente riferito come e-government. In questo contesto, nel 2001, è nato il Piano Nazionale di e-government promosso dal Ministero per l'innovazione e le Tecnologie con l'obiettivo di creare una rete di servizi erogati in via telematica ai cittadini e alle imprese. Subito dopo, a partire dalla metà del 2002, sono stati avviati i lavori per la definizione di una infrastruttura di comunicazione in grado di collegare tutte le amministrazioni, definita Sistema Pubblico di Connettività (SPC) e, più di recente, di una piattaforma per la Cooperazione Applicativa su SPC, il Sistema Pubblico di Cooperazione (SPCoop). Alla fine del 2004 il lavoro su SPCoop è giunto a compimento tramite la pubblicazione da parte del CNIPA della prima versione pubblica delle specifiche di Cooperazione Applicativa. La Tesi raccoglie i risultati dello studio delle problematiche relative alla Cooperazione Applicativa attraverso l'analisi delle specifiche organizzative e tecnologiche redatte contestualmente al Piano Nazionale di e-government, delle applicazioni in uso nella Pubblica Amministrazione e delle prime soluzioni realizzate per la Cooperazione Applicativa. Sulla base dei risultati raggiunti nella fase di analisi, ci si occupa quindi di 8

10 progettare una piattaforma completa di Cooperazione Applicativa, conforme alle specifiche governative e che superi i limiti evidenziati nelle soluzioni analizzate. Infine, le principali criticità dell'architettura progettata, sono state validate attraverso la realizzazione di un prototipo Open Source del sistema, che ha permesso di verificare la fattibilità dell'approccio proposto. Nel primo capitolo viene presentato il paradigma della cooperazione applicativa e si mostra il suo inquadramento nell'ambito della Pubblica Amministrazione e del Piano nazionale di e-government. Si descrive il contesto organizzativo che sta alla base della cooperazione applicativa e si presentano alcuni significativi scenari applicativi. Per comprendere la natura e le problematiche delle applicazioni che andranno ad utilizzare la piattaforma di cooperazione applicativa si descrivono alcuni sistemi in uso nella Pubblica Amministrazione. Tali sistemi sono particolarmente significativi poiché sviluppano una sorta di cooperazione applicativa primitiva e semplificata. Tuttavia anche lo studio delle esigenze di questi sistemi ha condotto alla formalizzazione delle specifiche, redatte dal CNIPA (Centro Nazionale per l'informatica nella Pubblica Amministrazione), dell'organizzazione e dell'architettura su cui si baserà il Sistema Pubblico di Cooperazione. Nel secondo capitolo si descrive il contesto tecnologico su cui si basa l'implementazione della piattaforma di cooperazione applicativa. Tale sistema deve essere in grado di realizzare sia un'architettura orientata ai servizi (Service Oriented Architecture) sia un'architettura basata sulla notifica di eventi (Event Driven Architecture). La tecnologia utilizzata per l'implementazione è quella dei Web Services perciò si descrive il paradigma dei Web Services e le principali tecnologie interessate: gli Schemi XML, il protocollo SOAP, il protocollo WSDL e il Registry UDDI. Nel terzo capitolo vengono descritte le specifiche rilasciate dal CNIPA nel mese di novembre 2004 riguardo all'organizzazione e alla architettura del Sistema Pubblico di Cooperazione. Particolare attenzione è stata posta sulle modalità di comunicazione tra 9

11 i soggetti che partecipano alla cooperazione: vengono descritte le relazioni di servizio e gli accordi di servizio che regolano lo scambio di messaggi tra i vari soggetti. Si analizza il ruolo della Porta di Dominio dei Servizi Applicativi, che costituisce la componente attraverso cui i sistemi si interfacciano alla piattaforma di cooperazione e si descrive il formato dei dati che è stato definito per realizzare le comunicazioni: la Busta di e-government. Quindi si elencano i servizi di cooperazione che fornisce la piattaforma di cooperazione applicativa, si descrivono i paradigmi di interazione supportati e si mostrano i possibili scenari applicativi. Nel quarto capitolo si illustrano le scelte architetturali e tecnologiche di alcune soluzioni inerenti alla cooperazione applicativa già realizzate o in fase di sviluppo. In particolare, si descrive l'analisi condotta sulla prima piattaforma completa di cooperazione applicativa: il progetto CART (Cooperazione Applicativa della Regione Toscana) definito dalla Regione Toscana e realizzato da Sun Microsystems prima della pubblicazione delle specifiche governative. Nelle conclusioni di questa analisi vengono discusse alcune scelte architetturali ed implementative che abbiamo ritenuto particolarmente critiche e che abbiamo cercato di superare attraverso il progetto oggetto del presente lavoro di Tesi. Oltre a CART, viene presentato il progetto SOLE (Sanità OnLinE), realizzato dalla Regione Emilia Romagna per consentire la cooperazione delle applicazioni utilizzate in ambito medico ed ospedaliero. Quindi si descrivono gli obiettivi del progetto, in corso di definizione, ICAR (Interoperabilità e Cooperazione Applicativa tra le Regioni), con il quale si intende realizzare i servizi infrastrutturali necessari alla cooperazione applicativa tra le Regioni. Infine viene presentata una panoramica di OpenPDD, un progetto Open Source che propone la standardizzazione delle interfacce programmatiche relative al componente Porta di Dominio dei Servizi Applicativi di SPCoop. Nel quinto capitolo si descrive in dettaglio l'architettura del progetto OpenSPCoop, la soluzione Open Source alle esigenze di cooperazione applicativa che rappresenta l'obiettivo di questa Tesi. Il progetto è conforme alle specifiche pubblicate dal CNIPA e 10

12 costituisce il risultato dello studio volto a comprendere le problematiche e le esigenze del paradigma di cooperazione applicativa, superando i limiti riscontrati nell'analisi del progetto CART. Si descrivono le componenti software Open Source utilizzate e le funzionalità di ogni componente dell'architettura. Inoltre, dopo aver illustrato i vantaggi ottenuti adottando il progetto OpenSPCoop rispetto alle soluzioni analizzate, si mostra la realizzazione degli scenari applicativi di cooperazione attraverso l'uso dei componenti di OpenSPCoop. Infine, nel sesto ed ultimo capitolo, si presenta la realizzazione di un prototipo di OpenSPCoop. Tale prototipo sviluppa il cuore applicativo del prodotto, cioè la parte che raccoglie la principale innovazione dell'architettura OpenSPCoop: evitare l'implementazione di un software specifico per ogni nuova applicazione da integrare nella piattaforma di cooperazione attraverso la realizzazione di un componente dinamico in grado di ricevere e di gestire le richieste applicative provenienti da qualsiasi applicazione, in funzione della loro descrizione. 11

13 Capitolo 1 Il paradigma di cooperazione applicativa nell'ambito della Pubblica Amministrazione All'inizio degli anni '90, all'interno della Pubblica Amministrazione, esisteva una pluralità di reti telematiche nate dalle differenti esigenze che nel corso degli anni si erano presentate. Nel 1997, attraverso la Legge n. 59 si è iniziato a razionalizzare tale scenario in un'unica rete, omogenea per qualità, sicurezza e costi, che ha rappresentato per le Amministrazioni Centrali la piattaforma di sviluppo delle applicazioni [1]. Negli anni successivi, in seguito alla progressiva trasformazione dello Stato in senso federale e all'avvio del processo di decentramento dei poteri e delle competenze, gli Enti locali sono stati chiamati a svolgere un ruolo di front office nei confronti del cittadino e delle imprese, che dovranno avere la possibilità di rivolgersi agli sportelli del proprio Comune per accedere a tutti i servizi offerti dalla Pubblica Amministrazione. In questo scenario la Pubblica Amministrazione centrale dovrà svolgere un ruolo di back office, in modo da garantire alle Pubbliche Amministrazioni locali il necessario supporto infrastrutturale e tecnologico. L'attuazione di questo modello di riferimento è iniziata nel 2001 per mezzo del Piano Nazionale di e-government [2] elaborato dal Governo, coerentemente con il programma di e-europe [3] realizzato dalla Commissione Europea [4]. Attraverso tale iniziativa è stato previsto la creazione di: una infrastruttura di comunicazione in grado di collegare tutte le amministrazioni, definita Sistema Pubblico di Connettività (SPC); una piattaforma che consenta alle amministrazioni di interoperare e cooperare 12

14 attraverso delle interfacce standard in grado di realizzare comunicazioni efficienti e trasparenti utilizzando l'infrastruttura SPC. Tale piattaforma è stata definita Sistema Pubblico di Cooperazione (SPCoop). In questo contesto è nata l'esigenza di approfondire e definire il paradigma di cooperazione applicativa, che si basa sullo scambio di dati, finalizzato all'erogazione e alla fruizione di servizi, tra sistemi informatici eterogenei. Nel presente capitolo sarà presentato il contesto organizzativo nel quale dovrà essere realizzata la piattaforma di cooperazione applicativa. Per descrivere con efficacia le problematiche più significative, saranno descritti gli scenari applicativi di riferimento ed alcune applicazioni in uso nella Pubblica Amministrazione. Quindi saranno presentate le specifiche organizzative e architetturali per la realizzazione della piattaforma SPCoop. 1.1 Il contesto organizzativo L'esigenza primaria della cooperazione applicativa connessa alla Pubblica Amministrazione è la costruzione di una infrastruttura in grado di integrare applicazioni di amministrazioni differenti, sviluppate su sistemi eterogenei e collegate attraverso una rete, al fine di consentire l'erogazione dei servizi di ciascuna amministrazione ai cittadini e alle imprese presenti su tutto il territorio. Tale infrastruttura deve essere caratterizzata da livelli di servizio, relativi al trasporto delle informazioni e alla sicurezza di queste, con caratteristiche, per ciò che riguarda prestazioni e qualità, omogenee su tutto il territorio nazionale, monitorate e rispondenti a politiche definite a livello nazionale fra tutti gli attori coinvolti [5]. Pertanto le problematiche per la realizzazione di un sistema di cooperazione applicativa spaziano dalla definizione e adozione di modelli architetturali volti ad implementare la cooperazione, alle attività ed agli strumenti per il governo dei processi di gestione; dal modello funzionale per la definizione dei servizi, alla individuazione delle infrastrutture tecnologiche che devono 13

15 1.1 Il contesto organizzativo supportare i livelli di trasporto e di sicurezza, dalla definizione dei flussi informativi, degli attori e dei ruoli, alla individuazione dei compiti e delle responsabilità degli erogatori di servizi [6]. Il modello adottato per lo sviluppo di un sistema di cooperazione applicativa si basa su due principi, quello dell'autonomia e quello della cooperazione. Ogni organizzazione implicata nella cooperazione deve essere considerata come un dominio autonomo, che gestisce in piena autonomia le proprie risorse e determina le politiche organizzative interne. Il dominio delimita inoltre il confine di responsabilità dell'organizzazione e permette di trattare ogni amministrazione alla pari con le altre. Quindi, al fine di poter regolamentare ogni attività di cooperazione, occorre che: tutti i soggetti (amministrazioni, enti pubblici e privati) siano considerati paritetici nel momento in cui cooperano fra loro; deve essere sempre possibile individuare le responsabilità a cui afferiscono le varie componenti della cooperazione nello svolgimento di un processo amministrativo [7]. Il modello proposto è di tipo federativo, in cui ogni amministrazione può richiedere i servizi che un'altra amministrazione mette a disposizione della comunità. L'amministrazione può inoltre aderire al servizio direttamente o attraverso intermediari abilitati (gestori di reti civiche, regioni e/o altri enti). Nel caso in cui l'amministrazione aderisca attraverso un intermediario, quest'ultimo si presenta al sistema per conto dell'amministrazione e si preoccupa di gestire il servizio per conto della stessa. Risulta evidente che il principio di autonomia debba essere centrale nello sviluppo della cooperazione applicativa: il sistema di cooperazione non deve entrare all'interno del dominio di una singola amministrazione, ma cerca di definire le interfacce applicative che ogni amministrazione deve esporre verso l'esterno per poter cooperare con le altre amministrazioni. Nel sistema ogni amministrazione può ricoprire ruoli diversi: può avvalersi di servizi erogati da altre amministrazioni, oppure può esporre i propri servizi al resto della comunità secondo politiche, regole, formati e condizioni definite e concordate tra tutti i soggetti cooperanti. Ne consegue che si tratta di un 14

16 1.1 Il contesto organizzativo modello molto flessibile che può essere, di volta in volta, adattato alla singola applicazione, lasciando le amministrazioni implicate nello scambio, libere di concertare le regole applicative nelle sedi e con le modalità più appropriate. Il modello prevede tuttavia che tutti i ruoli utilizzati devono essere predefiniti e per ogni servizio pubblicato devono essere definiti i profili applicativi relativi a ciascun ruolo e i livelli di sicurezza prescelti. 1.2 Alcuni scenari applicativi Nel paradigma di cooperazione applicativa confluiscono numerosi scenari applicativi poiché lo scambio dei dati può essere indirizzato in modo unidirezionale o bidirezionale consentendo le interazioni uno-a-uno, uno-a-molti, molti-a-molti. Le collaborazioni inoltre prevedono l'adozione di modalità sincrone e asincrone di scambio dei messaggi. In uno scambio sincrono, l'organizzazione mittente, a seguito dell'invio del messaggio di andata, rimane in attesa del messaggio di ritorno. Viceversa, in uno scambio asincrono, i due messaggi di andata e di ritorno vengono scambiati senza che una delle due parti rimanga in attesa. La scelta della modalità sincrona o asincrona può anche dipendere da aspetti legati alla latenza delle procedure amministrative, come ad esempio la necessità di un intervento umano per l'apposizione della firma digitale da parte di un pubblico ufficiale. Tuttavia tale scelta può dipendere anche da motivi di carattere esclusivamente tecnologico, come dimostra l'ampia diffusione nell'informatica gestionale dei sistemi basati su code, che adottano una modalità asincrona. Gli standard tecnologici attualmente disponibili hanno condotto alla formulazione di tre metodi di collaborazione attraverso i quali è possibile soddisfare qualsiasi esigenza: comunicazione di un evento, con cui un'amministrazione può notificare ad un soggetto o a molti soggetti destinatari il cambiamento del valore di un oggetto informativo interno; interrogazione, che costituisce una richiesta di accesso e trasmissione di dati ad 15

17 1.1 Il contesto organizzativo una o più amministrazioni da parte di una o più altre; transazione, attraverso cui si utilizza un servizio interamministrativo che modifica le informazioni gestite presso una amministrazione destinataria. Nella comunicazione di un evento gli interlocutori interagiscono in modo indiretto poiché la comunicazione è intermediata dall'infrastruttura di servizio che fornisce i servizi necessari alla pubblicazione di un evento e di sottoscrizione alla ricezione degli eventi stessi. In questo paradigma ad esempio un Comune, a fronte della richiesta di cambio residenza da parte di un cittadino, rende pubblico l'evento Cambio Residenza, insieme a tutti i dati ad esso relativi, attraverso l'infrastruttura di cooperazione applicativa. Un componente dell'architettura di cooperazione applicativa si occuperà di notificare tale evento, in modo opportuno, a tutte le amministrazioni che avevano preventivamente sottoscritto quell'evento specifico, che nell'esempio potrebbero essere l'asl, la Questura, il Ministero dell'interno, l'inps, ecc. Un caso significativo di utilizzazione del paradigma di interrogazione è costituito dalla realizzazione di uno sportello al cittadino da parte di una pubblica amministrazione, interfacciando i propri sistemi legacy per consentire di conoscere lo stato delle pratiche di interesse di soggetti pubblici e privati. Un esempio concreto è rappresentato dalla costruzione, da parte di una ASL, di uno sportello su Internet che consenta ai cittadini di consultare lo stato delle prenotazioni di una prestazione presso uno dei medici della ASL. La transazione rappresenta il paradigma di comunicazione più delicato, poiché richiede la modifica permanente di un oggetto informativo che si trova nell'organizzazione destinataria. Un esempio significativo per l'uso di questo paradigma si può trovare nell'ampliamento del servizio descritto dalla ASL nell'esempio precedente. Se il sistema fosse in grado di ricevere e modificare le prenotazioni ai servizi tramite lo sportello informatico utilizzato dal cittadino, saremo di fronte all'uso di transazioni, poiché una richiesta di modifica di un appuntamento 16

18 1.1 Il contesto organizzativo provocherebbe la modifica permanente di un oggetto informativo rappresentato dalla prenotazione. Nei capitoli successivi sarà descritta in dettaglio l'architettura necessaria alla concretizzazione di tale scenari e verrà presentato il flusso delle informazioni nell'infrastruttura di cooperazione applicativa. 1.3 I Sistemi di Cooperazione preesistenti Negli anni precedenti alla definizione del Piano di e-government che ha condotto allo studio del modello di cooperazione applicativa, sono state sviluppate numerose applicazioni in grado di far comunicare le amministrazioni e gli enti della Pubblica Amministrazione, sia a livello nazionale sia a livello regionale, all'interno di uno specifico ambito. Oggi si sente l'esigenza di integrare tutte queste applicazioni nell'infrastruttura di cooperazione applicativa. Tuttavia per determinare come effettuare l'integrazione occorre conoscere in dettaglio gli obiettivi ed il funzionamento di ciascuna applicazione. Di seguito sono descritti alcuni tra i più importanti progetti a livello nazionale: SIGMA TER, il progetto per la gestione delle funzioni catastali; Sistema Informativo della Montagna, l'applicazione nata con l'intento di salvaguardare e valorizzare il territorio e le comunità montane italiane; Indice Nazionale delle Anagrafi SIGMA TER Il progetto SIGMA TER (Servizi Integrati catastali e Geografici per il Monitoraggio Amministrativo del TERritorio) [8] nasce nel contesto del Piano di Decentramento del Catasto ai Comuni, in esecuzione della Legge n. 59 del 1997, così come definito dal D. Lgs. n. 112 del 31/3/1998. Il progetto affida la titolarità delle funzioni catastali ai Comuni, i quali devono decidere 17

19 1.1 Il contesto organizzativo in che modo espletare queste funzioni. Una caratteristica importante del progetto è rappresentata dall'ampiezza della aggregazione proponente in termini territoriali e di popolazione interessata, ma anche dal punto di vista dei livelli istituzionali coinvolti: Pubblica Amministrazione Centrale, Regioni, Province, Comunità Montane, Comuni e loro aggregazioni. In totale il progetto coinvolge una popolazione potenziale di oltre 10 milioni di abitanti. Il decentramento delle funzioni catastali delega ai Comuni le incombenze di carattere burocratico ma nello stesso tempo consente agli Enti Locali di pianificare la creazione di un sistema informativo integrato, capace di incrementarne la capacità di governo amministrativo del territorio, anche in funzione di una più razionale attività tributaria in campo immobiliare. Sviluppato per assicurare il flusso di dati catastali tra Agenzia del Territorio e i Comuni e garantire una migliore conoscenza del territorio sotto il profilo fiscale e amministrativo, SIGMA TER ha realizzato un infrastruttura per l interscambio di informazioni catastali e territoriali fra amministrazioni di diverso ordinamento (Ministero delle Finanze, Regioni e Comuni). Il progetto si è posto quindi due obiettivi principali: 1. creare una infrastruttura per l'interscambio di informazioni catastali e territoriali fra l'agenzia del Territorio e la Regione e fra questa e gli Enti Locali; 2. sviluppare un ampio numero di servizi basati sull'informazione catastale e territoriale a cittadini ed imprese. Le banche dati catastali soffrono storicamente di carenze nella qualità delle informazioni, ed il metodo più efficiente per migliorare tale qualità è quello di istituire nuovi flussi informativi fra le Amministrazioni Locali e l'agenzia del Territorio. Infatti le Amministrazioni Locali sono in grado di individuare gli errori presenti nelle informazioni catastali e di correggerli, non è presente però oggi un canale informatico stabile che consenta alle Amministrazioni Locali di correggere gli errori delle informazioni catastali e quindi migliorarne la qualità. Manca inoltre, ad oggi, un canale informatico stabile che consenta il trasferimento dei 18

20 1.1 Il contesto organizzativo dati catastali integrati con le informazioni di natura territoriale dalle Regioni agli Enti locali e viceversa. SIGMA TER si propone, in questo contesto, di eliminare il gap tecnologico che separa le amministrazioni locali dalla Regione e dall'agenzia del Territorio. Il Sistema di Interscambio fra l'agenzia del Territorio e le Regioni e fra queste e le amministrazioni locali si propone, quindi, di unificare la gestione delle informazioni catastali con quelle territoriali prodotte dagli Enti locali. L'Agenzia del Territorio realizza la componente di interscambio che consente di accedere ai dati catastali e di proporre aggiornamenti ai dati medesimi. Le Regioni realizzano le applicazioni infrastrutturali per interagire con il sistema di interscambio dell'agenzia per ricevere e fornire dati catastali, le applicazioni per creare e mantenere il database territoriale integrato regionale che unisce le fonti locali con quelle catastali, i servizi informatici a disposizione degli Enti locali sulla base dei quali implementare i servizi a cittadini, professionisti ed imprese; le Regioni impiantano inoltre appositi centri per la gestione dell'infrastruttura. I Comuni e le Province realizzano le applicazioni che, interagendo con i servizi infrastrutturali delle Regioni, erogano servizi a cittadini, professionisti ed imprese. Dalla realizzazione del progetto SIGMA TER sono stati ottenuti, quindi, grandi e sostanziali benefici: una maggior velocità nel servizio, un aumento della precisione, ed attendibilità delle prestazioni, grazie ad un migliore aggiornamento e gestione delle informazioni; una rete della Pubblica Amministrazione locale più efficiente e più vicina all'utente finale. La cooperazione applicativa necessaria per amministrare il flusso dei dati tra gli enti coinvolti nel progetto SIGMA TER è stata progettata garantendo la portabilità delle applicazioni indipendentemente dalla piattaforma tecnologica utilizzata. 19

21 1.1 Il contesto organizzativo Sistema Informativo della Montagna Il progetto Sistema Informativo della Montagna (SIM) [9] è un'applicazione nata con l'obiettivo di salvaguardare e valorizzare il territorio e le comunità montane italiane. Un'esigenza che trova espressione nella Legge n 97/94 per la salvaguardia e la valorizzazione delle zone montane. La Legge sulla Montagna coinvolge un'area pari ad oltre il 50% dell'italia e comprende il 50% dei Comuni, ma popolata da 11 milioni di abitanti (circa il 20% degli italiani): un dato che da solo denuncia il progressivo abbandono di questo territorio, con il conseguente rischio di depauperamento economico e culturale, e di una definitiva e cronica situazione di arretratezza in termini di servizi e infrastrutture della montagna. Per scongiurare questo pericolo nell'articolo 24 della Legge 97/94 viene previsto che il Ministero per le Politiche Agricole d'intesa con la Conferenza permanente per i rapporti tra lo Stato, le Regioni e le Provincie autonome di Trento e Bolzano, istituisca, nell'ambito del proprio sistema telematico, gli opportuni collegamenti dei servizi d'interesse delle aree montane, con le Comunità, i Comuni montani e l'uncem (Unione Nazionale Comuni Comunità Enti Montani). In particolare l'articolo 24 definisce gli obiettivi da raggiungere attraverso l'impiego di sistemi telematici: l'avvicinamento della Pubblica Amministrazione e dei suoi Servizi al territorio montano finalizzato al miglioramento della qualità della vita delle popolazioni residenti anche attraverso l'accesso facilitato a tutte le informazioni relative alle opportunità di sviluppo (finanziamenti e contributi pubblici, opportunità di impiego, informazioni di mercato, etc.); l'avvicinamento del territorio montano alla Pubblica Amministrazione in termini di conoscenze specifiche delle realtà locali, al fine di migliorare la capacità di programmazione e monitoraggio degli interventi a favore della montagna in tutti i livelli decisionali che, dal locale al centrale, intervengono nel settore. Il progetto SIM in particolare, rende fruibili e integra informazioni messe a disposizione da amministrazioni ed enti diversi, tramite un'infrastruttura telematica per le seguenti 20

22 1.1 Il contesto organizzativo aree di intervento: valorizzazione del patrimonio storico culturale presente nel territorio montano; prevenzione e difesa calamità; salvaguardia dell'assetto idrogeologico del territorio montano; supporto al ripristino del patrimonio forestale. Il SIM è basato su un modello di interscambio e cooperazione e su un'architettura di servizi distribuiti, che comportano: intermediazione tra organizzazioni eterogenee, che si devono rapportare per gestire procedimenti amministrativi correlati; tracciato dei flussi: sistema di documentazione, certificazione e controllo integrazione tra reti e sistemi informativi per valorizzare i patrimoni tecnologici esistenti. Infine, i servizi SIM vengono erogati sia tramite internet sia attraverso lo sportello per il cittadino. Tali servizi possono essere suddivisi in: 1. servizi informativi, prevalentemente rivolti a cittadini e imprese; 2. servizi amministrativi, rivolti a cittadini e imprese, ma anche alle stesse amministrazioni, comprendono l'accesso ai servizi delle PA centrali (Catasto, Anagrafe Tributaria), sia servizi di assistenza nella gestione dello Sportello Unico per le Attività Produttive (SUAP) e degli Sportelli Amministrativi (SA); 3. servizi territoriali, attualmente rivolti agli uffici della PA, comprendono anche servizi per la prevenzione e la difesa dalle calamità, la valorizzazione del patrimonio culturale del territorio, la salvaguardia dell'assetto idrogeologico, il supporto al ripristino del patrimonio forestale. 4. servizi di e-learning: corsi online (rete intranet) sui servizi SIM rivolti agli utenti del sistema (SIMforma). 21

23 1.1 Il contesto organizzativo Indice Nazionale delle Anagrafi Con Legge 28 febbraio 2001 n. 26 è stato istituito l Indice Nazionale delle Anagrafi (INA). Successivamente con un Decreto del Ministero dell'interno del 23 Aprile 2002 è stato fondato il Centro Nazionale per il Servizi Demografici (CNSD) [10] presso il Dipartimento per gli Affari Interni e Territoriali - Direzione Centrale per i Servizi Demografici. Quindi la Legge 43/2005 (G.U. del 1 aprile 2005, n. 75) ha previsto l'obbligo per i Comuni di provvedere, entro il 31 ottobre 2005, alla predisposizione dei necessari collegamenti all'ina presso il CNSD e alla redazione del piano di sicurezza per la gestione delle postazioni di emissione secondo le regole tecniche fornite dal Ministero dell'interno. La legge 88 del 31 maggio 2005 (G.U. del 31 maggio 2005, n. 125), poi, ha identificato l'ina come mezzo per la vigilanza anagrafica, imponendo ai Comuni di alimentarlo con tutti i dati anagrafici in possesso e di aggiornarlo costantemente. I vantaggi apportati dall'introduzione dell'ina sono essenzialmente due: 1. la circolarità anagrafica tra le Amministrazioni al fine di conseguire obiettivi di semplificazione e razionalizzazione dell azione amministrativa e della funzione statistica, assicurando la coerenza e l'allineamento delle anagrafi comunali e degli archivi delle altre Amministrazioni pubbliche a livello nazionale per la componente anagrafica e di residenza; 2. lo scambio di certificazioni anagrafiche tra i comuni e i soggetti interessati. Nella direttiva sull attività amministrativa per l anno 2004, il Ministero degli Interni ha stabilito, inoltre, la realizzazione di un modello nazionale di informatizzazione del sistema di vigilanza delle anagrafi comunali. Per far ciò è stato costituito presso la Direzione centrale per i servizi demografici del Ministero, un Comitato composto da ISTAT, CNIPA, prefetture, ANCI, ANUSCA (Associazione Nazionale Ufficiali di Stato Civile e di Anagrafe), DeA (Demografici Associati) e l Università di Tor Vergata. 22

24 1.1 Il contesto organizzativo Il comitato ha delineato il nuovo sistema di vigilanza anagrafica basato su tre componenti: 1. un modello di monitoraggio dei dati anagrafici e delle attività dell ufficiale demografico, con la registrazione e la valutazione sistematica dei carichi di lavoro. I parametri economici e organizzativi per la gestione dei servizi demografici sono correlati alla qualità dei servizi erogati; 2. un verbale ispettivo anagrafico, corredato da un vademecum con i riferimenti normativi ed alle circolari, come un utile strumento di lavoro per gli operatori. Il verbale è stato integrato rispetto alle attività informatizzate di gestione dell anagrafe, con l obiettivo di assicurare l integrità e la sicurezza dei dati, nonché la completezza e la correttezza dell azione amministrativa dell anagrafe comunale; 3. un modello di monitoraggio della sicurezza dei sistemi anagrafici informatizzati, articolato su due livelli d indagine. Il primo per acquisire informazioni sul piano di sicurezza comunale, ed effettuare una analisi preliminare di adeguatezza dello stesso. Il secondo livello riguarda gli aspetti tecnico-operativi di gestione della sicurezza, al fine di analizzare come il piano viene attuato dal Comune. Tutti questi sistemi già implementati che utilizzano una sorta di cooperazione applicativa sono stati analizzati approfonditamente per determinare un modello di comunicazione ed una architettura nella cooperazione applicativa in grado di semplificare la loro integrazione con la nuova piattaforma. In molti caso è stato necessario emanare una specifica norma di legge per consentire di dare una validità giuridica alle procedure telematiche che mettono in atto. Tuttavia, per evitare di proporre una normativa particolare per ogni applicazione esistente, è stato inserito nel Decreto Legislativo istitutivo del Sistema Pubblico di Connettività una norma generale che dia validità giuridica alla cooperazione applicativa. 23

25 1.1 Il contesto organizzativo 1.4 I nuovi standard di cooperazione del CNIPA Il Ministero per l'innovazione e le Tecnologie della Presidenza del Consiglio dei Ministri ha emanato, in occasione del Piano di e-government, le specifiche tecniche per il Sistema pubblico di connettività e di cooperazione (SPCoop) [11] sulla Rete Nazionale. Dal punto di vista tecnologico, l'approccio seguito coincide con quello definito a livello europeo dal progetto della Comunità Europea e-government (programma IST ). Per attuare il Piano di e-government, il Ministero per l Innovazione e le Tecnologie ha istituito il Centro Nazionale per l Informatica nella Pubblica Amministrazione (CNIPA) [12], che unifica in sé due organismi preesistenti: l Autorità per l informatica nella pubblica amministrazione ed il Centro tecnico per la R.U.P.A. Il CNIPA ha l'obiettivo primario di dare supporto alla pubblica amministrazione nell'utilizzo efficace dell'informatica per migliorare la qualità dei servizi e contenere i costi dell azione amministrativa. In sintesi il CNIPA: contribuisce alla definizione della politica del Governo e del Ministro per l innovazione e le tecnologie e fornisce consulenza per la valutazione di progetti di legge nel settore informatico; coordina il processo di pianificazione e i principali interventi di sviluppo; detta norme e criteri per la progettazione, realizzazione, gestione dei sistemi informatici delle amministrazioni, della loro qualità e dei relativi aspetti organizzativi; definisce criteri e regole tecniche di sicurezza, interoperabilità, prestazione; controlla che gli obiettivi e i risultati dei progetti di innovazione della pubblica amministrazione siano coerenti con la strategia del Governo; a tale scopo si affianca alle amministrazioni pubbliche nella fase di progettazione ed emette pareri di congruità tecnico-economica; cura l attuazione di importanti progetti per l innovazione tecnologica nella pubblica 24

26 1.1 Il contesto organizzativo amministrazione, la diffusione dell e-government e lo sviluppo delle grandi infrastrutture di rete del Paese per consentire agli uffici pubblici di comunicare tra loro e per portare i servizi della pubblica amministrazione ai cittadini e alle imprese; cura la formazione dei dipendenti pubblici nel settore informatico, utilizzando le nuove tecnologie per favorire l apprendimento continuo. La definizione del modello organizzativo del SPCoop si è basata sui seguenti principi fondamentali [7]: 1. il modello di cooperazione deve essere indipendente dagli assetti organizzativi e dai sistemi informatici interni dei soggetti cooperanti ; 2. ciascun amministrazione cooperante mantiene la responsabilità dei propri servizi e dei propri dati ; 3. la cooperazione applicativa si attua sulla base degli accordi tra le parti ed ha un fondamento normativo o istituzionale. Per soddisfare questi principi, l'architettura tecnica ed organizzativa è stata fondata sui seguenti elementi [7]: a) la cooperazione applicativa avviene attraverso lo scambio di messaggi applicativi e sulla base di accordi di servizio che esplicitano l'accordo stipulato sull'erogazione/fruizione delle prestazioni del servizio in questione ; b) ogni amministrazione gestisce i flussi di cooperazione applicativa con le altre amministrazioni per il tramite di un unico punto (logico) del proprio sistema informativo denominato Porta di Dominio dei Servizi Applicativi (PDSA) ; c) le amministrazioni che cooperano fra loro possono dar luogo a Domini di Cooperazione in cui siano stabiliti i servizi erogati, i relativi livelli di servizio e le responsabilità nel mantenimento di tali livelli ; d) è definita una infrastruttura unitaria di Servizi di Interoperabilità e di Cooperazione e Accesso (SICA) che garantisce l'erogazione di servizi tecnologici di base, comuni a tutti i Domini di Cooperazione. 25

27 1.1 Il contesto organizzativo L'utilizzo dei messaggi applicativi consente di garantire che ogni amministrazione non possa in nessun caso modificare lo stato delle informazioni presenti in un'altra amministrazione all'insaputa della stessa. Ogni comunicazione avviene quindi attraverso un formato di interscambio definito Busta di e-government, descritto in dettaglio nel paragrafo 3.3, che consente di gestire la cooperazione mantenendo le responsabilità e le autonomie previste per legge. Il modello organizzativo prevede che le amministrazioni partecipano alla cooperazione applicativa attraverso la componente denominata Porta di Dominio dei Servizi Applicativi, descritta nel paragrafo 3.2. Le amministrazioni possono scegliere tra differenti modelli di porte di dominio che si differenziano, in termini di funzionalità offerte, da un modello più semplice ad uno via via più complesso, in relazione alle proprie esigenze applicative. Quindi la Porta di Dominio rappresenta un elemento concettuale che consente ad ogni amministrazione l'erogazione dei servizi di cooperazione. Ogni amministrazione è responsabile della propria Porta di Dominio e dei servizi di cooperazione che la Porta gestisce. Per garantire autonomia alle singole amministrazioni, lasciando inalterato il loro patrimonio informativo, si è scelto di organizzare il SPCoop come una federazione di domini [13]. Ogni dominio rappresenta l'insieme delle risorse (in particolare procedure, dati e servizi) e delle politiche di una determinata organizzazione, nonché il confine di responsabilità dell'organizzazione stessa, in particolare per quanto riguarda le politiche che definiscono il suo sistema informativo. Il dominio di una amministrazione può eventualmente essere scomposto in più sottodomini. Secondo questo modello, la comunicazione avviene tra entità omogenee (i domini appunto) e lo scopo dell'architettura cooperativa è abilitare l'integrazione degli oggetti informativi (procedure e dati) e delle politiche di domini diversi. Al fine di garantire maggiore flessibilità al modello si è reso possibile la federazione di due o più domini attraverso il concetto di Dominio di Cooperazione, cioè un accordo 26

28 1.1 Il contesto organizzativo fra amministrazioni in cui si definisce chi è responsabile di che cosa e chi svolge le funzioni di supervisione e monitoraggio degli accordi presi. Per quanto riguarda i servizi, l'elemento fondamentale è rappresentato dalla definizione delle modalità in base alle quali un dominio servente esporta i propri servizi ed un dominio cliente vi accede. Il modello prevede uno schema generale di cooperazione flessibile che può essere, di volta in volta, adattato alla singola applicazione, lasciando le amministrazioni, implicate nello scambio, libere di concertare le regole applicative nelle sedi e con le modalità più appropriate. Il modello prevede tuttavia che tutti i ruoli utilizzati devono essere predefiniti e per ogni servizio pubblicato devono essere definiti i profili applicativi relativi a ciascun ruolo e i livelli di sicurezza prescelti. Quindi l'interoperabilità si sviluppa in modo tale che: 1. siano identificati i servizi ed i dati che ogni amministrazione decide di rendere disponibili sulla rete; 2. siano rispettati, per ogni servizio esposto, le politiche di sicurezza, di accesso, di controllo di qualità e correttezza dei servizi erogati, stabilite dalla amministrazione erogante. Al fine di rendere omogenei i metodi per esporre le funzionalità e le politiche dei servizi offerti, sono stati adottati gli standard offerti dal paradigma dei Web Services in merito all'erogazione di servizi. Tale tecnologia prevede l'esistenza di registri, cataloghi e schemi di servizio in cui sia trasparente e automaticamente gestibile, per ogni applicazione e per ogni Porta di Dominio, l'insieme dei servizi erogati da ogni amministrazione e le relative modalità di richiesta di servizio. Il compito dei SICA è quello di garantire per tutte le pubbliche amministrazioni e per i Domini di Cooperazione le funzionalità necessarie alla cooperazione applicativa e, inoltre, di assicurare funzioni di sicurezza di base (se richieste) e di tracciatura di rete, avvalendosi dei servizi di interconnessione del SPCoop. A livello infrastrutturale ogni registro SICA deve essere articolato su due livelli 27

29 1.1 Il contesto organizzativo operativi: il livello generale e il livello secondario. I servizi dell'infrastruttura di livello generale fanno parte dell'insieme delle strutture tecnologiche condivise previste dall'architettura generale. I SICA di livello secondario sono qualificati su decisione del Comitato SPCoop e possono essere realizzati da una qualunque amministrazione, quindi anche da un soggetto privato. Ogni Dominio di cooperazione può scegliere in completa autonomia se utilizzare i servizi infrastrutturali di livello generale o di un qualunque SICA di livello secondario già esistente o di realizzarne uno specifico. L'infrastruttura di livello generale, oltre ai servizi di interoperabilità, cooperazione ed accesso, gestisce anche le informazioni necessarie a mantenere l'elenco completo dei servizi applicativi realizzati e dei relativi accordi di servizio, in modo da assicurare a tutti i soggetti che partecipano alla cooperazione applicativa la conoscenza di tutti i servizi disponibili e di tutti i Domini di Cooperazione esistenti. A questo proposito deve essere tenuto un registro generale su cui sono pubblicati tutti gli accordi di cooperazione e tutti i servizi applicativi, con i relativi accordi di servizio. Ciascun soggetto può autonomamente decidere di pubblicare i servizi di interesse anche su uno o più registri SICA di livello secondario. Si deduce che l'infrastruttura complessiva, costituita dall'insieme dei servizi SICA di livello generale e SICA di livello secondario, è in accordo con il primo principio su cui si fonda il modello di cooperazione applicativa, consentendo una completa pariteticità fra tutti i soggetti partecipanti al sistema di cooperazione, senza imporre alcuno schema organizzativo precostituito fra amministrazioni centrali, regionali o locali. 28

30 1.1 Il contesto organizzativo Capitolo 2 Il Contesto Tecnologico Al fine di comprendere il reale funzionamento di una architettura di cooperazione applicativa e giustificare le motivazioni che hanno condotto alla definizione delle specifiche di SPCoop è utile elencare e descrivere le tecnologie ed i modelli di interazione che sono alla base del paradigma di cooperazione applicativa. 2.1 Le architetture di cooperazione applicativa: RPC, SOA, EDA Il concetto di Remote Procedure Call (RPC) [14], poiché nato ed evoluto per permettere, in generale, la comunicazione tra applicazioni remote, può essere interpretato come il primo vero tentativo di costruire un'architettura di cooperazione applicativa. Il paradigma delle RPC è stato ideato verso la metà degli anni 80, in un tempo in cui la programmazione ad oggetti non esisteva ancora, quindi si trattava di un ambito in cui per comunicazione remota si intendeva sempre la comunicazione tra processi. Le RPC non fanno altro che permettere l invocazione, o attivazione, di un processo su un host remoto. Applicato in un rapporto client-server, il client richiede un qualche servizio sul server inviando la richiesta Request( ) tramite il Communication Module integrato nel processo; il server risponde con una Reply( ) tramite il suo Communication Module. Il meccanismo è estremamente semplice, le possibilità offerte sono limitate così come lo scambio effettivo di dati e l interazione tra le applicazioni remote. 29

31 1.1 Il contesto organizzativo In seguito, in concomitanza con l espansione e la sempre maggiore diffusione dei modelli di programmazione a oggetti, si sono sviluppate, come evoluzione delle RPC, le Remote Method Invocation (RMI) [15]. La necessità che diede vita alle RMI è stata la volontà di stabilire una comunicazione tra host remoti di più alto livello, non più basata quindi sui singoli processi bensì sui metodi. L idea che ha condotto allo sviluppo delle RMI è molto semplice: se una singola applicazione funziona mediante l invocazione locale dei propri metodi interni (local method invocation), deve essere possibile controllare tale applicazione facendo sì che essa esponga alcuni dei suoi metodi verso l esterno, tramite un interfaccia, in modo tale che altre applicazioni remote possano invocarli e ottenere dei parametri di ritorno (remote method invocation). L interazione tra applicazioni in questo modo divenne estremamente più forte ed omogenea, aprendo le porte alla creazione di interi sistemi distribuiti. Tuttavia la vera rivoluzione che ha condotto alla definizione dei principi su cui è basato il paradigma di cooperazione applicativa è da ricondursi alla nascita e alla diffusione del formato XML (Extensible Markup Language) [16]. Infatti, alla fine degli anni '90, fu presentato XML-RPC [17], con cui, per la prima volta, si è cercato di ignorare completamente le problematiche legate al trasporto, per focalizzare l'attenzione sul contenuto dei messaggi con cui le applicazioni comunicano. Sfruttando l'infrastruttura del Web si è potuto delegare le problematiche relative al trasporto al protocollo HTTP, incapsulando messaggi codificati in linguaggio XML all'interno di una richiesta HTTP POST [18]. I molteplici vantaggi introdotti da questo nuovo approccio convergono verso la possibilità di focalizzare tutti gli sforzi in due ambiti: gestire la cooperazione attraverso lo scambio di messaggi, senza mettere direttamente in comunicazione le varie applicazioni attraverso chiamate di metodi; definire regole che rendano il contenuto del messaggio interpretabile da qualsiasi applicazione coinvolta nello scenario di cooperazione. In tale scenario è nato il concetto di servizio e, di conseguenza, si è sentita l'esigenza di avere a disposizione degli strumenti che consentissero di: 30

32 1.1 Il contesto organizzativo descrivere un servizio, descrivere le modalità di accesso ad un servizio, informare tutti i soggetti coinvolti nella cooperazione della disponibilità di tale servizio. Tutte queste necessità sono state soddisfatte con lo sviluppo di un modello basato su un'architettura altamente distribuita e orientata ai servizi, definita Service Oriented Architecture (SOA) [19]. Ogni servizio facente parte di questo sistema può comunicare direttamente con un gruppo di processi o funzioni, oppure può partecipare in un processo più complesso che coinvolge altri servizi, denotato con il nome di coreografia. SOA rappresenta un modello creato per pubblicare ed esporre i servizi che sono ospitati su una piattaforma. Questi servizi, normalmente, presentano caratteristiche di tipo enterprise quali sicurezza, transazionalità, pooling, clustering e batch processing. I servizi in se stessi non forniscono queste possibilità infrastrutturali, ma semplicemente espongono le interfacce che lo fanno. SOA offre l'opportunità agli intermediari di costruire nuovi servizi aggregandone altri. Il nuovo servizio non fornisce nuovo valore di per sé, ma raggruppa i servizi che vengono forniti da altri, sia dal front end sia dal back office. I soggetti aderenti ad un sistema di questo tipo espongono i servizi accedendo ad un insieme di applicazioni in grado di eseguire un intero processo applicativo. Ciascun soggetto che si propone come aggregatore di servizi, deve assicurare la disponibilità dei servizi esposti e fornire un ambiente transazionale e sicuro. Ogni servizio è composto da due parti: l'implementazione del servizio; l'interfaccia del servizio, descritta in XML e in grado di descrivere in modo astratto tipi di dati, operazioni, binding su protocolli di trasporto e indirizzo di accesso al servizio. Uno dei vantaggi principali dell'architettura SOA è la possibilità di costruire nuove applicazioni in modo incrementale semplicemente definendo interfacce basate su 31

33 1.1 Il contesto organizzativo standard per connettere diversi componenti; tale approccio però presenta il grande limite di dover conoscere a priori il modo in cui i servizi cooperano tra loro. Questa limitazione viene superata adottando un approccio event-driven (EDA, Event Driven Architecture) [20], che consente invece la gestione di numerosi eventi che possono avvenire in parallelo ed in maniera impredicibile e completamente asincrona per generare una singola azione. Dunque un modello di cooperazione EDA consente di gestire una richiesta di servizio elaborandola in real-time. Infatti, non appena viene notificato un evento, il sistema inoltra immediatamente alle parti interessate la presenza di quell evento che verrà gestito nelle modalità definite dal servizio stesso. Tipicamente il destinatario è un dominio che elabora il messaggio associato all evento e conseguentemente produce un'azione che va a modificare parte del suo contenuto informativo. Il paradigma di cooperazione applicativa necessita di una piattaforma distribuita in grado di sviluppare sia le peculiarità dell'architettura SOA sia quelle di un approccio EDA. I Web Services, presentati nei prossimi paragrafi del presente capitolo, costituiscono le tecnologie più adatte per lo sviluppo di una architettura capace di soddisfare queste necessità. 2.2 Il paradigma dei Web Services La tecnologia dei Web Services è nata all'inizio del nuovo millennio dalla necessità di mettere in comunicazione applicazioni web di notevoli dimensioni realizzate con tecnologie molto diverse tra loro in ambienti e sistemi operativi differenti. In particolare, dal gennaio 2002, il World Wide Web Consortium (W3C) [21], ha avviato la Web Services Activity [22], cioè un ambiente per la discussione e la definizione di un insieme di nuove tecnologie, coerenti con l'architettura del web, capaci di sviluppare al massimo il potenziale dei web services. Uno dei primi risultati ottenuti dal gruppo di lavoro che partecipa alla Web Services Activity è stata la definizione degli aspetti caratterizzanti di un web service: A Web service is a software 32

34 1.1 Il contesto organizzativo application identified by a URI, whose interfaces and bindings are capable of being defined, described, and discovered as XML artifacts. A Web service supports direct interactions with other software agents using XML based messages exchanged via internet-based protocols [23]. Come mostra la figura 2.1, l'architettura del paradigma Web Services è basata sulle interazioni tra tre componenti: l'erogatore dei servizi (service provider), il registro dei servizi (service registry) e il fruitore del servizio (service requestor). Tali interazioni riguardano le operazioni di pubblicazione (publish), ricerca (find) ed interfacciamento (bind). Figura 2.1. L'architettura dei Web Services: attori, ruoli e operazioni Tipicamente, dopo aver definito e pubblicato sul registro dei servizi la descrizione di ciascun servizio fornito, il sistema erogatore espone all'esterno un punto di accesso ai propri servizi in modo da renderli accessibili ai sistemi fruitori. Un sistema fruitore, 33

35 1.1 Il contesto organizzativo attraverso l'operazione di ricerca recupera dal registro dei servizi la descrizione del servizio di interesse, e, con i dati in essa contenuti, effettua l'interfacciamento al sistema erogatore per usufruire del servizio [24]. Figura 2.2. Pila delle tecnologie utilizzate nei Web Services Oggi il termine Web Services ricopre l'insieme degli standard tecnologici che realizzano lo scenario appena descritto consentendo a tutti gli effetti la realizzazione di architetture di servizi su larga scala, garantendo sia l'interoperabilità sia l'autonomia nell'implementazione dei sistemi componenti l'architettura. In figura 2.2 è rappresentata la pila degli standard tecnologici che permettono di raggiungere questi scopi rendendo possibili le operazioni descritte precedentemente: la codifica dei messaggi avviene attraverso il linguaggio XML; l'interrogazione dei servizi avviene attraverso il protocollo SOAP (Simple Object Access Protocol) [25]; la descrizione dei servizi e delle sue modalità di accesso è realizzata in linguaggio WSDL (Web Services Description Language) [26]; la registrazione di un servizio e la sua individuazione sfruttano lo standard UDDI (Universal Description Discovery and Integration) [27]. 34

36 1.1 Il contesto organizzativo Schemi XML XML (Extensible Markup Language) nasce come strumento per la trasmissione di dati insieme alla loro semantica. Una grande novità introdotta rispetto ai precedenti linguaggi è stata la possibilità di crearsi un proprio markup e strutture adatte a rappresentare l'informazione in ambiti specifici. Lo strumento con cui, sin dalla nascita del linguaggio, è stato possibile definire la struttura di un documento XML è rappresentato dai Document Type Definition (DTD) [28], che consente di imporre dei vincoli sulla struttura per evitare il proliferare incontrollato di tag e per consentire un'elaborazione accurata da parte degli interpreti del linguaggio. In pratica, con i DTD si definisce la grammatica di un linguaggio di markup basato su XML utilizzabile per una specifica classe di documenti. Tuttavia i DTD hanno mostrato col tempo mancanza di flessibilità; tra le maggiori lacune risaltano le seguenti: l'obbligo di specificare il contenuto di ogni tag di tipo testuale (#PCDATA); l'impossibilità di definire nuovi tipi di dato, che non consente di ottenere totale controllo sul valore degli attributi; l'impossibilità di scrivere documenti XML che facciano riferimento a DTD diversi; la sintassi utilizzata per definire un DTD non coincide con quella di XML. Si è cercato di superare questi problemi con l'introduzione di uno strumento più semplice e al tempo stesso più articolato: XMLSchema [29]. Un documento XML Schema associato ad un documento XML svolge la stessa funzione di un DTD, consentendo la validazione del documento ma offre strumenti più completi nella definizione della struttura del documento: la sintassi con cui si definisce XML Schema è la stessa del linguaggio XML; la definizione di nuovi tipi di dato, sfruttando quelli elementari ed utilizzando l'ereditarietà; la possibilità di vincolare non solo l'annidamento o il tipo di ciascun elemento, ma anche il range di valori di ogni campo. 35

37 1.1 Il contesto organizzativo Un generico schema ha la seguente struttura: <?xml version"1.0"?> <xs:schema xmlns:xs=" definizione della grammatica desiderata... </xs:schema> Utilizzando XML Schema, quindi, uno sviluppatore può definire con precisione i nomi di elementi permessi in un documento e, all'interno di determinati elementi, quali sottoelementi, attributi e relazioni sono consentiti. Inoltre può importare frammenti da altri schemi ed estendere i tipi ereditandoli. Ciò consente relazioni complesse tra gli elementi, pur conservando la semplicità di una struttura lessicale ad albero. Gli sviluppatori possono inventare propri schemi o condividere quelli già creati da altri. I lettori possono controllare i riferimenti degli schemi al fine di verificare che il documento ricevuto sia del tipo corretto. Essi possono anche utilizzare le informazioni contenute nello schema per convalidare automaticamente la struttura del documento. Attualmente il W3C [21] ha pubblicato 3 documenti che definiscono le specifiche di XML Schema: [30] e [31] contengono una descrizione completa e sistematica, il primo documento in modo più discorsivo e con numerose esemplificazioni, il secondo in modo più formale; [32] riporta l'elenco dei tipi di dati predefiniti SOAP Il protocollo SOAP (Simple Object Access Protocol) [25] nasce nel dicembre 1999, a seguito del rilascio da parte dell'ietf [33] della specifica 1.1, sottoposta, nel maggio 2000 all'esame del W3C per essere standardizzata: dopo la pubblicazione di varie working draft, nel giugno 2003 il W3C rilascia la Recommendation di SOAP Versione 1.2, costituita da SOAP Version 1.2 Primer [34], SOAP Version 1.2 Messaging 36

38 1.1 Il contesto organizzativo Framework [35], SOAP Version 1.2 Adjuncts [36] e SOAP Version 1.2 Specification Assertions and Test Collection [37]. SOAP è un protocollo leggero studiato per lo scambio di informazione strutturata in un ambiente decentralizzato e distribuito come il Web. Infatti si avvale di protocolli standard come HTTP/S o FTP per il trasporto delle informazioni e del linguaggio XML per la codifica delle stesse; è progettato per lavorare con XML Schema, massimizzando così la sua utilità con una vasta gamma di strumenti XML. Inoltre fa uso dei Namespaces in XML come meccanismo flessibile e leggero per trattare la composizione di linguaggi XML. L'uso del protocollo HTTP consente a SOAP di lavorare in modo trasparente attraverso i proxy server ed i firewall. SOAP quindi permette la definizione di un framework per la descrizione delle informazioni contenute all'interno di un determinato tipo di messaggio e di quali siano le modalità di elaborazione delle stesse. A tale scopo definisce alcune regole di decodifica dei diversi tipi di dato ed alcune convenzioni per la rappresentazione delle richieste e delle risposte secondo il paradigma RPC. Il protocollo SOAP gestisce due tipi di messaggi: call e response. Come mostra la figura 2.3, un messaggio di tipo call permette di invocare un servizio remoto, mentre un messaggio di response costituisce il risultato proveniente dal servizio invocato. Figura 2.3. Schema di comunicazione SOAP utilizzando il protocollo HTTP 37

39 1.1 Il contesto organizzativo Il protocollo SOAP è costituito da tre parti, definite di seguito e mostrate in figura 2.4: envelope, che rappresenta il contenitore del messaggio e costituisce l'elemento root del documento XML; header, un elemento opzionale che contiene informazioni globali sul messaggio; body, che rappresenta la richiesta di elaborazione (call) o la risposta derivata (response) da una elaborazione. 38

40 1.1 Il contesto organizzativo Figura 2.4. Struttura di un messaggio SOAP L'elemento envelope rappresenta la busta che viene utilizzata come contenitore dell'intero messaggio e costituisce la radice del documento SOAP, come da specifica XML. La specifica SOAP 1.2 a proposito della sezione envelope prescrive le seguenti regole: può contenere l'attributo encodingstyle per indicare l'indirizzo di un XML Schema contenente le definizioni di regole utilizzate per la serializzazione delle informazioni; può contenere attributi aggiuntivi, qualificati attraverso l'utilizzo di namespace; può contenere la sezione header; deve contenere la sezione body; può contenere qualsiasi numero di sottoelementi, a condizione che siano qualificati attraverso l'uso di namespace e seguano la sezione body. 39

41 1.1 Il contesto organizzativo L'elemento header rappresenta la sezione nella quale è possibile specificare parametri di comunicazione ed informazioni per fornire una semantica al messaggio trasmesso. Questa sezione deve rispettare le seguenti regole: si tratta di una sezione facoltativa; deve rispettare le regole di encoding standard specificate in [38]; può contenere attributi aggiuntivi e dei sottoelementi, qualificati attraverso l'utilizzo di namespace; deve essere autoreferenziante, quindi un elemento esterno non può essere utilizzato all'interno; il parser XML che interpreterà la sezione body deve aver già interpretato la sezione header, in modo da poterne utilizzare i riferimenti; può contenere informazioni sullo stato del sistema, sullo stato del client, sulle impostazioni relative alla sessione corrente dell'oggetto e su tutto ciò che può essere utile alla personalizzazione della comunicazione. L'elemento body, il cui utilizzo è obbligatorio in qualsiasi messaggio SOAP, costituisce il contenuto applicativo del messaggio e deve rispettare le seguenti regole: deve rispettare le regole di encoding standard specificate in [38]; non può contenere elementi aggiuntivi; può contenere sottoelementi, qualificati attraverso l'utilizzo di namespace. Dunque un messaggio SOAP ha il seguente scheletro XML: <?xml version="1.0" encoding="utf-8"?> <soap:envelope xmlns:env=" <soap:header>... </soap:header> <soap:body>... </soap:body> 40

42 1.1 Il contesto organizzativo </soap:envelope> WSDL Web Service Description Language (WSDL) consente di sfruttare i vantaggi di SOAP, consentendo agli erogatori di servizi Web e ai fruitori di tali servizi di collaborare in modo molto semplice all'interno di un'architettura SOA. Mentre SOAP è uno standard per la comunicazione di contenuti, WSDL è divenuto il linguaggio standard per la descrizione dei contenuti. La figura 2.5 illustra la struttura di WSDL, che consiste in un documento XML, mostrando le relazioni tra le cinque sezioni che costituiscono un documento WSDL, divise in due gruppi: il gruppo di livello superiore è composto da definizioni astratte, mentre il gruppo di livello inferiore è composto da descrizioni concrete. 41

43 1.1 Il contesto organizzativo Figura 2.5. Gerarchia delle sezioni che compongono un documento WSDL Le sezioni astratte definiscono i messaggi SOAP in modalità indipendente dal linguaggio e dalla piattaforma. I componenti specifici del servizio vengono quindi relegati nelle sezioni sottostanti, che contengono le descrizioni concrete. Di seguito è riportato l'elenco di tutte le sezioni assieme alla loro funzione: tipi (types) definisce i tipi utilizzati all interno dei messaggi del servizio; l utilizzo del tag schema permette di scegliere quale tipo di encoding utilizzare attraverso un XML Schema; le sezioni messaggio (message) contengono le definizioni dei messaggi di scambio del servizio e fanno uso di parti definite come tipi nelle sezioni tipi; la sezione tipi di porta (porttype) definisce le operazioni esposte dall'erogatore del servizio; concettualmente si tratta dei metodi remoti dell oggetto remoto che costituisce il servizio web; per ogni metodo viene definito il messaggio di input ed il messaggio di output; la sezione associazioni (binding) contiene il collegamento tra i tipi di porta (cioè la definizione astratta del servizio) e l'end-point fisico; qui sono contenute le informazioni che indicano il protocollo da utilizzare e come ricondurre i messaggi di input ed output al protocollo utilizzato; la sezione servizi (service) contiene la definizione del servizio concernente la sua descrizione e la posizione fisica del servizio, tipicamente un url. Un generico documento WSDL ha il seguente scheletro XML: <?xml version="1.0" encoding="utf-8"?> <wsdl:definitions name="nomedelservizio" targetnamespace="url" xmlns= > <!-- Definizioni astratte --> <wsdl:types>...</wsdl:types> <wsdl:message>...</wsdl:message> <wsdl:porttype>...</wsdl:porttype> 42

44 1.1 Il contesto organizzativo <!--Definizioni concrete --> <wsdl:binding>...</wsdl:binding> <wsdl:service>...</wsdl:service> </wsdl:definitions> UDDI UDDI (Universal Description Discovery and Integration) è un iniziativa nata per creare un registro mondiale di società e di servizi. Per servizi non si intendono solo Web Services ma anche attività diverse, quali il trasporto o lo sviluppo di software su commissione; perciò il raggio d'azione di UDDI è molto ampio. Lo scopo prefissato con lo sviluppo di UDDI è quello di sviluppare un framework aperto ed indipendente dalla piattaforma per descrivere servizi, individuare società e integrare servizi di business utilizzando Internet. Dunque, rispetto agli altri standard tecnologici citati, UDDI si pone in un contesto meno tecnico ma più orientato alle problematiche commerciali delle società. Il framework di UDDI supporta la pubblicazione, l individuazione ed il collegamento a servizi web. Queste caratteristiche sono implementate tramite un registro di servizi (registry UDDI), che rappresenta il cuore della tecnologia UDDI. L architettura di UDDI ha un approccio distribuito, simile ai Domain Name Server (DNS) [39] di Internet, in questo modo ogni nodo è sempre aggiornato, in qualsiasi momento, con tutte le informazioni del registro. Le motivazioni che hanno portato alla creazione di un registro distribuito non sono solo tecniche, ma sono anche orientate a rafforzare la compatibilità tra i diversi produttori, evitando così di legare UDDI alla tecnologia specifica di un singolo produttore. Le informazioni fornite dai servizi UDDI possono essere catalogate in tre gruppi: pagine bianche, che contiene le informazioni relative al nome, indirizzo, numero telefonico ed altre informazioni sui contatti di una determinata azienda erogatrice di servizi; 43

45 1.1 Il contesto organizzativo pagine gialle, con cui si descrive la categorizzazione delle società e dei servizi e permette di individuare un determinato servizio; pagine verdi, in cui sono riportate informazioni tecniche a proposito dei Web Services forniti da una particolare azienda erogatrice; tra le informazioni che fornisce vi sono gli URL del servizio, le informazioni sui nomi, gli argomenti dei metodi ed altre informazioni tecniche. All'interno di una architettura SOA il funzionamento di UDDI si può riassumere in quattro passaggi: 1. i sistemi erogatori pubblicano sul registro dei servizi (in figura 2.1 l'operazione di publish) i documenti (WSDL) che descrivono i servizi che intendono erogare; 2. il registro dei servizi assegna un indicativo univoco per ogni tipo di servizio e per ogni sistema erogatore registrato; 3. i sistemi fruitori interrogano il registro dei servizi (in figura 2.1 l'operazione di find) per scoprire i servizi disponibili; 4. i sistemi fruitori utilizzano queste informazioni per raggiungere i servizi di cui necessitano (in figura 2.1 l'operazione di bind). 44

46 1.1 Il contesto organizzativo Capitolo 3 Le specifiche SPCoop Nel dicembre 2003 è stato costituito il Gruppo di Lavoro "Servizi ed architetture di cooperazione per garantire l'interoperabilità dei servizi" con l'obiettivo di definire il modello, l architettura e le regole per l interoperabilità evoluta, la cooperazione e l accesso ai servizi applicativi erogati dalle amministrazioni pubbliche nell ambito del Sistema Pubblico di Connettività [11]. Ai lavori hanno partecipano circa 120 persone in rappresentanza delle amministrazioni centrali e locali, del mondo accademico e delle principali associazioni dei fornitori di servizi. Nel marzo 2004 si è conclusa la prima fase dei lavori che ha portato alla definizione del modello e dei requisiti architetturali per i servizi di interoperabilità evoluta, cooperazione ed accesso. Nel presente capitolo sono elencati e descritti tali requisiti attraverso l'analisi dei documenti [13][40][41] rilasciati dal CNIPA a conclusione della prima fase dei lavori. 3.1 Architettura Il modello generale di riferimento di SPCoop [40] è un'architettura di servizi basata sulle tecnologie dei Web Services, dove con il termine architettura di servizi si intende un'architettura informatica distribuita costituita da un insieme di sistemi autonomi che comunicano per mezzo di messaggi scambiati attraverso interfacce standardizzate. I vantaggi principali che derivano dall'adozione di un tale modello sono: una struttura completamente distribuita che permette l'interoperabilità e la 45

47 1.1 Il contesto organizzativo cooperazione dei sistemi informatici sulla base di accordi sullo scambio di funzionalità, sulle interfacce che permettono tale scambio e sui suoi requisiti di sicurezza e qualità di servizio, garantendo completa autonomia delle scelte implementative e gestionali dei sistemi componenti l'architettura. L'indipendenza delle scelte implementative delle funzionalità applicative (gestione dei messaggi, sicurezza, qualità di servizio) rende tale modello adatto alle esigenze di autonomia di gestione delle amministrazioni centrali e locali e all'interoperabilità con i sistemi applicativi delle imprese; la realizzazione delle funzionalità infrastrutturali di interfaccia, sicurezza e qualità di servizio necessarie alla cooperazione applicativa, sulla base degli standard tecnologici Web Services, permette di minimizzare l'impatto sull'implementazione delle funzionalità applicative già realizzate nei sistemi informativi delle amministrazioni. Il modello garantisce la salvaguardia del patrimonio applicativo di tutti i soggetti impegnati nella cooperazione e ne stimola la valorizzazione attraverso il riuso in nuovi contesti applicativi Relazioni di servizio Il modello [40] stabilisce che le interazioni tra i sistemi applicativi e quelli infrastrutturali siano relazioni di servizio: una relazione di servizio tra due sistemi informatici si instaura se uno dei due sistemi, che riveste il ruolo di fruitore, utilizza i risultati di trattamenti informatici effettuati dall'altro sistema, che riveste il ruolo di erogatore. Un servizio è l'insieme dei risultati prodotti dai trattamenti effettuati dal sistema erogatore e utilizzati dal sistema fruitore. Quindi la logica di trattamento del sistema fruitore utilizza determinate funzionalità (applicative o infrastrutturali) fornite dal sistema erogatore. Il risultato prodotto da un trattamento effettuato dall'erogatore prende il nome di prestazione di servizio. Le prestazioni di servizio appartengono a quattro categorie: prestazioni di calcolo, cioè la fornitura da parte dell'erogatore al fruitore di dati 46

48 1.1 Il contesto organizzativo risultato di puri trattamenti di calcolo; prestazioni di informazione di stato, che prevedono la gestione da parte dell'erogatore degli stati e delle transizioni di stato di risorse su richiesta diretta o indiretta del fruitore; prestazioni di cambiamento di stato, determinate da caratteristiche specifiche di qualità di servizio degli stati e delle transizioni di stato delle risorse gestite dall'erogatore; prestazioni di interazione, che consistono in interazioni da parte del sistema erogatore con l'ambiente esterno (altri sistemi, utenti, dispositivi diversi) su richiesta diretta o indiretta del fruitore. Un sistema che partecipa all'architettura SPCoop può partecipare a più relazioni di servizio e ricoprire in queste relazioni i ruoli di erogatore e fruitore: il sistema in questione eroga un sottoinsieme delle funzionalità che implementa come prestazioni e fruisce delle prestazioni fornite da altri sistemi dell'architettura. In figura 3.1 è descritta una generica relazione di servizio. Figura 3.1. Relazione di servizio 47

49 1.1 Il contesto organizzativo L'architettura SPCoop si presenta come una rete di relazioni di servizio tra sistemi autonomi e indipendenti dal punto di vista architetturale e tecnologico. L'erogazione e la fruizione di tali servizi necessita, da parte dei sistemi eroganti e fruitori, dell'interazione con sistemi che implementano funzionalità infrastrutturali. Queste funzionalità sono realizzate attraverso relazioni di servizio dette servizi infrastrutturali. Risulta quindi che SPCoop è una architettura di sistemi distribuiti in cui la cooperazione tra i sistemi partecipanti avviene esclusivamente sotto forma di scambio di prestazioni di servizi applicativi e infrastrutturali Accordo di servizio Per instaurare una relazione di servizio tra sistemi è obbligatorio definire un accordo esplicito sull'erogazione e la fruizione delle prestazioni: l'accordo di servizio. Tale accordo riguarda le prestazioni del servizio e le modalità di erogazione e di fruizione dello stesso. In dettaglio, si occupa di definire: le funzionalità (classi di prestazioni) del servizio; le interfacce di scambio dei messaggi tra erogatore e fruitore; i requisiti di sicurezza dell'erogazione e della fruizione; i requisiti di qualità di servizio dell'erogazione e della fruizione. La figura 3.2 mostra il contesto di un generico accordo di servizio. 48

50 1.1 Il contesto organizzativo Figura 3.2. Accordo di servizio I termini dell'accordo di servizio sono elaborati in un insieme di documenti, di cui una parte redatta in linguaggio WSDL 1.1 in modo da essere interpretabile direttamente dalle applicazioni. Detto insieme di documenti costituisce una specifica per l'implementazione dei sistemi erogatore e fruitore, ed è utilizzato dai progettisti e dagli ambienti di sviluppo nelle fasi di implementazione dei sistemi erogatore e fruitore. L'utilizzo di documenti WSDL permette di lasciare non specificate alcune modalità operative dell'erogazione e della fruizione del servizio al momento della progettazione, facendo sì che siano perfezionate automaticamente al momento dell'esecuzione. Questa caratteristica rende flessibile la configurazione delle applicazioni ma richiede l'implementazione di capacità specifiche di contrattazione e di riconfigurazione dinamica da parte dei sistemi erogatore e fruitore. Un caso semplice di riconfigurazione dinamica si verifica quando l'uri [42] del punto di accesso del 49

51 1.1 Il contesto organizzativo sistema destinatario è sconosciuto al sistema mittente in esecuzione. In questo caso il mittente deve implementare una strategia dinamica di recupero dell'indirizzo (URI) del punto di accesso del destinatario, come ad esempio l'interrogazione di un servizio di rubrica. Una modalità alternativa di recupero dell'uri è la trasmissione dello stesso nel contenuto del messaggio. Quindi la rappresentazione dei termini dell'accordo di servizio in un insieme di documenti permette la totale dissociazione delle responsabilità di definizione del servizio da quelle dell'erogazione del servizio stesso. Un servizio dell'architettura SPCoop si considera standardizzato quando: è definito da una autorità di definizione, che gestisce l'accordo e la pubblicazione dei documenti che ne rappresentano i termini; è erogato da uno o più sistemi erogatori, gestiti da differenti responsabili, che si impegnano a fornire prestazioni conformi con i termini dell'accordo di servizio. L'accordo generale di un servizio standardizzato può limitarsi a definire le funzionalità, le interfacce, i requisiti di sicurezza e lasciare la definizione dei requisiti di qualità di servizio ai singoli erogatori o ad accordi specifici tra erogatori e fruitori del servizio. In generale, la definizione di un accordo di servizio impone: l'identificazione delle parti in causa (erogatori, fruitori e terzi, ovvero i servizi di intermediazione e di supporto); la descrizione delle funzionalità del servizio; la descrizione delle interfacce di scambio dei messaggi (eventuali protocolli di conversazione, formato del corpo e delle intestazioni dei messaggi, descrizione del collegamento con il protocollo di connessione, gli URI dei punti di accesso); la descrizione della semantica del messaggio; la descrizione dei requisiti di sicurezza. Per il principio di occultamento dell'implementazione, l'architettura, le tecniche e le risorse d'implementazione adottate dal sistema erogatore per fornire le prestazioni, così come quelle adottate dal sistema fruitore per utilizzare i risultati delle prestazioni, 50

52 1.1 Il contesto organizzativo sono escluse dall'accordo. Ad oggi, le specifiche che definiscono quali linguaggi sia obbligatorio utilizzare per la descrizione dei protocolli di conversazione sono ancora in fase di definizione ma si prevede l'introduzione in versioni successive di SPCoop del formalismo di orchestrazione OASIS WSBPEL (Web Services Business Process Execution Language) [43]. Nelle attuali specifiche SPCoop (versione 1.0), l'accordo di servizio prevede il formalismo XML Schema per la descrizione del formato del contenuto (corpo e intestazione) dei messaggi. Sono inoltre previste delle restrizioni, prescrizioni e raccomandazioni nell'uso dello standard XML Schema. Come linguaggio di descrizione dei messaggi, delle connessioni e dei punti di accesso è previsto l'uso di WSDL 1.1 con le restrizioni d'uso prescritte dalle raccomandazioni WS-I Basic Profile 1.1 [44]. Per la descrizione della semantica dei messaggi, è raccomandato l'uso dell'approccio Design by Contract [45]. Tale approccio è particolarmente adatto per specificare le richieste di prestazioni che producono transizioni di stato delle risorse gestite dall'erogatore. Per quanto riguarda i requisiti di sicurezza imposti dalle specifiche SPCoop, essi definiscono: l'uso dei meccanismi standard di autenticazione, ai livelli trasporto, connessione e porta; i meccanismi specifici di abilitazione e autorizzazione; l'uso dei meccanismi standard di controllo di integrità, ai livelli trasporto, connessione e porta; l'uso dei meccanismi standard di riservatezza ai livelli trasporto, connessione e porta; i meccanismi specifici di non ripudiabilità; 51

53 1.1 Il contesto organizzativo i meccanismi e le regole di ispezione Scambio di messaggi Nell'architettura SPCoop, l'unica modalità di interazione tra il sistema erogatore e il sistema fruitore di un servizio è rappresentata dallo scambio di messaggi, sulla base degli standard tecnologici dei Web Services. Lo scambio di messaggi è utilizzato per coordinare l'erogazione e la fruizione delle prestazioni di servizio ed eventualmente per trasportare dati facenti parte delle prestazioni stesse. In generale, nell'ambito di uno scambio di messaggi per l'erogazione o la fruizione di una prestazione di servizio, l'erogatore e il fruitore rivestono entrambi i ruoli di mittenti e destinatari di messaggi. Attraverso questa scelta si garantisce al tempo stesso l'interoperabilità dei sistemi partecipanti all'architettura SPCoop, l'autonomia e l'indipendenza nella scelta delle architetture e tecnologie di implementazione del sistema di ciascun soggetto. Per realizzare l'interoperabilità tra sistemi (applicativi e infrastrutturali) eterogenei è infatti sufficiente stabilire: il protocollo di trasporto dei messaggi; il protocollo di connessione tra punti di accesso dei sistemi; il contenuto dei messaggi; i protocolli di conversazione. L'accordo sul contenuto dei messaggi e sul protocollo di conversazione tra i sistemi che intraprendono una relazione di servizio è realizzato a livello applicativo. Quindi la sola dipendenza tecnologica è l'implementazione da parte di tutti i soggetti, ciascuno in piena autonomia e indipendenza, dei componenti di gestione dei protocolli di trasporto e dei protocolli di connessione in conformità agli standard tecnologici SPCoop. Lo scambio di messaggi è realizzato attraverso quattro livelli architetturali, ciascuno 52

54 1.1 Il contesto organizzativo dei quali caratterizzato da un insieme di tecnologie di implementazione. Nella Tabella 3.1 sono riportate le caratteristiche e le tecnologie corrispondenti ad ogni livello. Livello Servizio Porta Descrizione Standard tecnologici trattamento delle parti del messaggio direttamente utilizzate dai sistemi interagenti per coordinare l'erogazione e la fruizione del servizio Il formato del contenuto del messaggio è XML 1.0. trattamento del formato del contenitore generico del messaggio Il formato del contenitore è la Busta SPCoop o Busta di e-gov, estensione standard di SOAP 1.1, e di SOAP Message with attachments [51]/MIME per messaggi con allegati binari, usato in conformità con le raccomandazioni WS-I [52][53][54]. Il messaggio può comprendere allegati in formato binario MIME [46][47][48][49][50]. La Busta e-gov distingue tra il corpo del messaggio, che ospita il contenuto del messaggio trattato a livello servizio e le intestazioni del messaggio, contenenti dati trattati a livello porta. Connessione protocollo di connessione tra punti di accesso utilizzato per stabilire il canale di trasmissione dei messaggi Il protocollo di connessione: HTTP 1/1. Trasporto Questo livello, e i livelli sottostanti, sono implementati nell'ambito su protocollo IP. protocollo di trasporto dei messaggi Gli identificatori dei punti di accesso sono in formato URI (schema HTTP o HTTPS). Tali standards sono usati in conformità con le specifiche della connessione SOAP/HTTP di SOAP 1.1 e SOAP Message with attachments/http 1.1 e con le raccomandazioni WS-I. Tabella 3.1. Livelli architetturali nello scambio dei messaggi Nella trasmissione di un messaggio, il sistema mittente invia un messaggio al sistema destinatario. La Tabella 3.2 riassume i compiti del sistema mittente e del sistema destinatario. 53

55 Tabella 3.1. Livelli architetturali nello scambio dei messaggi Livello Compiti del mittente Compiti del destinatario Servizio Composizione del contenuto del messaggio in formato XML e dei suoi eventuali allegati binari utilizzando lo standard MIME. Analisi sintattica, valutazione semantica e trattamento del contenuto del messaggio XML e dei suoi eventuali allegati binari in formato MIME. Porta Operazione di imbustamento: inserimento del contenuto del messaggio nella struttura Busta e-gov ed eventuale inclusione degli allegati in formato MIME. Validazione del formato e operazione prelevamento del contenuto del messaggio dalla Busta e-gov. Prelevamento degli allegati binari dal formato MIME. Connessione Apertura della connessione HTTP Ricezione della richiesta HTTP e inserimento della Busta e-gov POST e prelevamento del carico richiesta nel carico di una richiesta HTTP (Busta e-gov). HTTP POST, invio della richiesta alla URI destinataria. Connessione Inserimento della struttura Busta Ricezione della risposta HTTP e e-gov nel carico di una risposta prelevamento del carico (Busta erisposta HTTP, invio della risposta sulla Gov). HTTP connessione aperta dalla richiesta HTTP. Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione Ai livelli servizio e porta, i compiti del destinatario si dividono in quattro categorie: controllo del formato del messaggio con lo standard Busta e-gov; analisi sintattica dell'intestazione e del corpo del messaggio; valutazione semantica del processo di scambio attraverso la verifica che il mittente abbia la capacità, i diritti e l'autorizzazione per emettere il messaggio ed il destinatario abbia la capacità, i diritti e l'autorizzazione per riceverlo; trattamento del messaggio, cioè l'insieme delle operazioni che il destinatario deve compiere alla ricezione del messaggio, nell'ambito del coordinamento dell'erogazione e della fruizione del servizio a cui partecipa. L'architettura SPCoop non impone alcun ordine nell'espletamento dei compiti di controllo di formato, analisi sintattica e valutazione semantica, ma vieta al destinatario 54

56 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione del messaggio di intraprendere qualsiasi operazione di trattamento del messaggio ricevuto prima di aver completato la verifica di formato, sintattica e semantica del messaggio stesso. In conformità con le raccomandazioni WS-I sono stati definiti tre tipi di scambio elementare di messaggi, attraverso la composizione dei quali possono essere costruite tutte le possibili interazioni tra due sistemi dell'architettura di SPCoop. I tipi elementari sono elencati di seguito: messaggio senza replica, messaggio con replica sincroni, messaggio con replica asincroni. Lo scambio elementare di tipo messaggio senza replica è il paradigma più semplice nel quale un sistema mittente invia un messaggio ad un sistema destinatario. Nel caso dello scambio elementare di tipo messaggio con replica, un sistema richiedente trasmette un messaggio ad un sistema rispondente e si aspetta di ricevere successivamente da parte del sistema rispondente una replica correlata logicamente con il messaggio inviato. Nello scambio di tipo messaggio con replica sincroni il sistema richiedente, dopo aver inviato il messaggio, rimane in attesa di ricevere la replica. Nello scambio di tipo messaggio con replica asincroni il sistema richiedente non si preoccupa di attendere la replica; il rispondente trasmetterà in seguito una replica asincrona correlata logicamente con il messaggio ricevuto. 3.2 La Porta di Dominio dei Servizi Applicativi La Porta di Dominio dei Servizi Applicativi (PDSA) [40] è la componente del sistema di cooperazione applicativa che consente ad un dominio di esporre le proprie risorse applicative e di fruire dei servizi offerti dagli altri soggetti cooperanti. La porta di dominio quindi costituisce l'unico punto di accesso tra i domini: sulla propria Porta ogni 55

57 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione dominio veicola tutte le richieste di servizio verso gli altri domini e riceve tutte le richieste provenienti dagli altri domini. Si configura concettualmente come un proxy applicativo, anche se fisicamente può essere costituito da più sistemi. A livello concettuale esiste una sola Porta per ogni dominio, che rappresenta la somma di tutti gli apparati preposti all'accesso delle risorse del dominio. A livello di implementazione, può esistere una porta per ogni tecnologia o per ogni modello di interazione. Dal punto di vista dell'architettura, le porte di dominio possono essere viste come degli adattatori, che consentono a sistemi informatici esistenti, o comunque progettati e realizzati in base alle esigenze del dominio specifico, di affacciarsi a SPCoop e partecipare alla cooperazione applicativa. Figura 3.3. Modello di riferimento per l'integrazione delle porte di dominio dei servizi applicativi Nella figura 3.3 ciascuna delle due porte di dominio consente l'integrazione del sistema informatico della propria amministrazione, dove il termine sistema informatico è inteso nella sua accezione più ampia. In particolare, può trattarsi di: un sistema monolitico, o comunque operante su un singolo nodo presso una amministrazione di piccole dimensioni; un sistema distribuito su più nodi collegati in rete locale presso un amministrazione di dimensioni maggiori; una rete di area (ad esempio aggregazione di comuni, comunità montana, rete provinciale o regionale), alla quale sono collegati i sistemi informatici di 56

58 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione amministrazioni anche diverse, o di una singola amministrazione (ad esempio la rete territoriale gestita da un agenzia o un ministero). Dunque le porte di dominio, intese come componenti software di adattamento, possono svolgere funzioni di integrazione diverse, a seconda del contesto di dispiegamento. In quest'ottica, anche i sistemi di accesso ai servizi amministrativi per gli operatori umani, cioè i portali, devono essere considerati dei sistemi informatici che accedono alla rete di cooperazione applicativa. Infatti un portale può consistere in: un sistema di accesso ai servizi di cooperazione applicativa funzionante presso una singola amministrazione, a cui hanno accesso solo gli operatori dell'amministrazione stessa (intranet locale); un portale di servizi integrato a cui hanno accesso solo operatori autorizzati ed identificati, anche attraverso procedure di single sign-on (intranet di area); un portale di servizi per la pubblica amministrazione cui hanno accesso solo operatori identificabili (portale di back-office); un portale di accesso orientato ai cittadini, al quale essi possono accedere utilizzando sistemi di identificazione opportuni (ad esempio con una carta d'identità elettronica oppure con una carta nazionale dei servizi) ed ottenere servizi amministrativi di vario genere (portale di front-office). Risulta quindi evidente, come mostrato in figura 3.4, che, dal punto di vista logico, la PDSA si articola in due componenti distinte: 1. una componente che realizza le funzionalità di cooperazione con le altre porte che si affacciano sulla rete SPCoop, 2. una componente che realizza le funzionalità di integrazione verso gli applicativi operanti nel dominio. 57

59 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione Figura 3.4. Struttura logica delle porte di dominio La PDSA, e più in particolare la sua componente delegata alla cooperazione, rappresenta dunque l'unico punto di contatto telematico tra domini: sulla propria PDSA ogni dominio veicola le richieste di servizio verso gli altri domini aderenti a SPCoop e, simmetricamente, riceve tutte le richieste di servizio provenienti dagli altri domini, identificandovi il confine della propria responsabilità. Al fine di garantire che ogni PDSA, e quindi ogni amministrazione, possa effettivamente colloquiare con tutte le altre porte, sono stati adottati formati standard di codifica per i messaggi che veicolano le richieste di servizio fra le varie porte di dominio. L'adattamento di ogni applicativo ai formati standard definiti per la formattazione delle informazioni e dei dati prodotti all'interno del dominio, viene svolto dalla funzione di integrazione che dovrà essere quindi un componente software specifico del dominio ed adeguato alle realtà specifiche. In particolare, al fine di garantire il più possibile l'uniformità delle porte di dominio, la conversione dei dati e dei documenti dai formati specifici delle applicazioni nei formati standard deve essere realizzata dal solo componente di integrazione. Viceversa, il componente di cooperazione deve gestire solo documenti codificati secondo gli standard definiti per l'intero SPCoop. Lo standard previsto per la codifica del messaggio è il formato XML/SOAP, che permette di realizzare il disaccoppiamento tra la componente di integrazione della 58

60 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione porta e quella di cooperazione: le indicazioni relative al mittente, al destinatario (intese come porte di dominio), e al servizio richiesto sono descritte nell'intestazione della busta SOAP, che viene gestita dalla componente di cooperazione, mentre il contenuto applicativo con le informazioni effettive previste dal servizio è descritto nel corpo, trattato dalla componente di integrazione. La struttura del messaggio sarà descritta in dettaglio nel paragrafo 3.3. A livello logico il disaccoppiamento nella PDSA tra la componente di integrazione e quella di cooperazione è descritto dai due ruoli che può assumere ogni porta: la Porta Delegata e la Porta Applicativa. Una PDSA assume il ruolo di Porta Delegata quando espleta le funzioni di integrazione, quindi quando si occupa di ricevere un messaggio di richiesta di servizio da parte di un'amministrazione destinato ad un'altra porta di dominio. Una PDSA invece assume il ruolo di Porta Applicativa quando funge da componente di cooperazione, ovvero a seguito della ricezione di un messaggio di richiesta di servizio da parte di un'altra porta di dominio. 3.3 La Busta di e-government Come già accennato nei precedenti paragrafi, l'elemento fondamentale che caratterizza i messaggi per la cooperazione applicativa è la completa definizione del contenuto e del formato di codifica. I messaggi tra le porte di dominio sono infatti parte integrante di uno scambio tra applicazioni e non tra operatori umani. Di conseguenza, il contenuto di questi messaggi deve essere totalmente interpretabile in modo automatico. La distinzione tra componenti delle porta di dominio che realizzano funzionalità di integrazione e funzionalità di cooperazione si riflette nell'organizzazione della struttura generale di ciascun messaggio in due parti principali: 1. una parte che funge da contenitore (o busta), che contiene le indicazioni relative al mittente, al destinatario (intesi come porte di dominio), al servizio richiesto ed al tipo di collaborazione in atto; 59

61 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione 2. una parte di contenuto applicativo, rappresentato dalle informazioni effettive previste per quel tipo di servizio e di scambio (ad esempio, i dati identificativi personali di una richiesta di informazioni anagrafica). In generale, il tipo di struttura da utilizzare per la busta dipende dalla tipologia di comunicazione (con/senza replica, sincrona/asincrona) che si instaura tra erogatore e fruitore del servizio. La struttura del contenuto dipende unicamente dalla definizione del servizio. Il formato di tale messaggio è stato denominato busta di e-government [55] (o busta di e-gov) ed è costituito da una struttura SOAP (envelope, header e body), il cui contenuto è l'effettiva richiesta di servizio codificata in formato XML. Con la busta di egov si è cercato di fornire uno strumento indipendente dall'implementazione dell'architettura e dalle sue politiche di gestione, in modo tale da consentirne l'utilizzo all'interno di qualunque tipo di architettura definita in futuro. Basandosi sulle linee guida sulla cooperazione applicativa e facendo riferimento alle specifiche emesse da organismi di standardizzazione internazionali nell'ambito dei Web Services (W3C ed OASIS), considerando le tecnologie di riferimento per i Web Services (SOAP, WSDL, UDDI), la busta fornisce lo strumento attraverso il quale le porte di dominio possono fornire servizi a valore aggiunto quali sicurezza, affidabilità e auditing. Il messaggio SOAP (SOAP Envelope) è composto da un header ed un body. I dati contenuti nell'header vengono utilizzati dalla porta di dominio per gestire il messaggio ed attivare funzionalità a valore aggiunto che costituiscono i servizi infrastrutturali offerti dalle porte. Il body, invece, è riservato ai dati veri e propri e costituisce il cosiddetto contenuto informativo utilizzato ed elaborato dal sistema fruitore. Le specifiche tecniche della Busta di e-gov sono state rilasciate a più riprese. Attualmente l ultima definizione, diffusa nel mese di aprile 2004, migliora il modello 60

62 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione elaborato nel 2002, fornendo una specifica più dettagliata e precisa, in particolare nella definizione dello standard da utilizzare per garantire la sicurezza, e nel formato dell intestazione del messaggio, descritto in Appendice A. Tale modello permette di gestire efficacemente gli scambi di informazioni in modo indipendente dalle applicazioni, oltre a raggiungere migliori livelli di servizio, affidabilità e sicurezza. Tuttavia attualmente, in mancanza di soluzioni standard che comprendano tutte le funzionalità a valore aggiunto offerte dalle porte, il layout dell'header definito nell'ultima specifica costituisce una struttura interpretabile, cioè utilizzata in modo arbitrario per ogni servizio, ma che non preclude, nel momento in cui saranno disponibili sul mercato, l'adozione di future implementazioni rispondenti a standard internazionali ed interoperabili. In Appendice B sono riportate le linee guida per l'utilizzo degli header della busta nei vari scenari di comunicazione. La figura 3.5 mostra la struttura generale della busta di e-gov: la parte di busta è in grigio chiaro mentre la parte di contenuto è indicata in grigio più scuro. La parte più esterna della struttura è formata da elementi specifici di codifica per i protocolli HTTP o SMTP (tipicamente header fields) ed è di fatto indipendente dal resto. L'elemento principale di un messaggio è rappresentato da una struttura XML SOAP composta da due parti: intestazione e descrizione. L'intestazione (XML SOAP Header) contiene i dati relativi al messaggio ed in particolare contiene l'identificativo del messaggio, che coincide con l'identificatore di protocollo. La descrizione (XML SOAP Body) riporta i dati riguardanti il contenuto applicativo del servizio; tali dati possono includere l'insieme completo delle informazioni riguardanti la richiesta (o la risposta) oppure limitarsi alla semplice indicazione del tipo di documento informatico allegato e del relativo formato di codifica. Figura 3.5. Struttura della busta di e-gov 61

63 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione Dal punto di vista amministrativo, la struttura XML SOAP incorpora anche il ruolo della segnatura informatica in formato XML del messaggio in quanto riporta i dati minimi della registrazione di protocollo. La struttura XML SOAP può essere utilizzata in combinazione con lo standard WSDL per la descrizione dei servizi e con lo standard UDDI per la realizzazione dei repository di descrizione dei servizi. La struttura XML SOAP può inoltre essere inclusa in una struttura MIME allo scopo di allegare al messaggio uno o più documenti applicativi, in base allo standard XML SOAP with attachments. 62

64 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione Ad esempio potrebbe essere allegato un documento su cui è stata apposta la firma di un pubblico ufficiale. La presenza degli allegati è comunque opzionale. Una firma opzionale può essere inclusa nell'intestazione utilizzando gli standard XML SOAP Security [56] e XML Signature [57] e potrebbe, ad esempio, essere usata per garantire la fonte di provenienza delle informazioni (art. 43 del D.P.R. 445/2000). Quando non è presente la XML Signature, la struttura XML SOAP contiene unicamente le informazioni relative al protocollo e le informazioni necessarie alle porte di dominio per il routing applicativo, mentre il contenuto applicativo XML sarà riportato nell'allegato. Ciò ne consente, quando necessario, anche la cifratura (per esempio nella consultazione del casellario giudiziario); si noti che lo standard XML Encryption [58] si trova ancora in uno stadio di definizione preliminare. 3.4 I servizi di cooperazione Oltre alle porte di dominio, lo sviluppo dell'architettura SPCoop richiede la realizzazione di una infrastruttura di gestione con servizi comuni di cooperazione, che assicura il dialogo tra le porte di dominio secondo i paradigmi di cooperazione e permette il governo dei processi di back office tra le amministrazioni. Figura 3.6. I servizi di cooperazione 63

65 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione I servizi comuni di cooperazione prevedono l'erogazione di servizi applicativi, tra cui i più importanti, come mostrato in figura 3.6, sono: il registro dei servizi, il repository documentale, il servizio di gestione degli eventi, i servizi di gateway applicativo verso le altre reti Il registro dei servizi Permette di rendere disponibili le informazioni sui servizi esposti sulla rete fornendo tutte le informazioni utili alla fruizione. In particolare sono contenute nel registro tutte le informazioni necessarie alla: identificazione delle porte di dominio (caratteristiche e indirizzamento); identificazione dei servizi esposti (tipologia, caratteristiche, aderenti, ruoli abilitati etc.); caratteristiche dei servizi in termini di erogazione (orari, modalità di accesso, formati di codifica); 64

66 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione caratteristiche dei servizi in termini di sicurezza (utilizzo di firma, riservatezza dei messaggi, etc.). Il registro dei servizi viene realizzato adottando lo standard UDDI e successivamente, per le forme più complesse di cooperazione, quello ebxml [59]. Il servizio prevede, attraverso l'utilizzo di un portale, la gestione e la consultazione del registro per eseguire in modo automatico sia il processo di pubblicazione da parte dell'amministrazione erogatrice che quello di adesione da parte delle amministrazioni riceventi. La consultazione può essere effettuata in modo libero dalle amministrazioni accreditate sulla rete che possono decidere di aderire al servizio. Le amministrazioni che espongono i servizi possono richiedere di esporre un nuovo servizio inserendo, attraverso il portale, i dati e le informazioni previsti dal registro per ogni nuovo servizio Il repository documentale È l'archivio dove la procedura di gestione del registro dei servizi raccoglie le informazioni trattate dal servizio, un repository dove vengono mantenute tutte le informazioni documentali riferite ai messaggi oggetto dello scambio: tracciati XML e la documentazione a supporto dello stesso servizio. Le procedure di consultazione ed aggiornamento dell'archivio sono integrate con quelle di gestione e consultazione del registro dei servizi in quanto completano il processo di pubblicazione di un nuovo servizio seguendo lo stesso schema procedurale. La presenza, tuttavia, di un archivio separato permette la conoscenza dei dati e degli schemi XML anche in modo disgiunto dallo stesso servizio consentendone un riutilizzo anche da parte di altre procedure Il servizio di gestione degli eventi Il paradigma di cooperazione della gestione degli eventi prevede l'interazione tra le amministrazioni attraverso una infrastruttura di servizio che fornisce servizi per la pubblicazione e sottoscrizione di un evento. Il servizio prevede, attraverso l'utilizzo di 65

67 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione un portale, la gestione e la consultazione del registro degli eventi, per permettere, in modo automatico, sia il processo di pubblicazione di un evento che quello di sottoscrizione. La consultazione può essere effettuata in modo libero dalle amministrazioni accreditate sulla rete che possono decidere di aderire al servizio. Le amministrazioni che pubblicano gli eventi possono richiedere di pubblicare un nuovo evento inserendo, attraverso il portale, i dati e le informazioni relative all'evento. Il gestore degli eventi provvede ad eseguire tutti i necessari controlli per accreditare la nuova amministrazione ed iscrivere il nuovo evento nel registro I servizi di gateway applicativo verso altre reti Le esigenze applicative delle amministrazioni vedono lo scambio dei flussi non solo tra amministrazioni ma anche tra amministrazioni e cittadini, tra amministrazioni ed imprese e tra amministrazioni ed amministrazioni di altri settori (ad esempio, le banche). SPCoop prevede lo scambio dei flussi con altre amministrazioni esterne alla Pubblica Amministrazione attraverso la realizzazione di servizi di gateway applicativo verso altre reti. Il sistema di gateway applicativo si preoccupa di eseguire il routing applicativo dei messaggi da una rete all'altra gestendo l'indirizzamento tra le due reti e la conversione dal protocollo applicativo di una rete a quello dell'altra (nel caso di SPCoop dalla busta di e-gov al protocollo della rete interbancaria). Il sistema di gateway applicativo realizza nella sostanza un proxy applicativo tra una rete e l'altra garantendo i principi di sicurezza delle reti che interconnette e facendo da tramite tecnologico tra i soggetti presenti sulle due reti interconnesse Il portale dei servizi Al fine di facilitare la fruizione dei servizi sopra descritti, ed in particolare la consultazione e l'aggiornamento dei suddetti registri da parte di una qualunque delle amministrazioni, indipendentemente dalla posizione logistica e dalle modalità di partecipazione, il sistema prevede l'utilizzo di un portale (portale dei servizi). 66

68 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione I servizi di gestione Tra i servizi comuni di cooperazione vanno comprese anche le infrastrutture di gestione che assicurano il funzionamento dell'intero sistema tra cui le più importanti: un sistema di help desk ed assistenza alle amministrazioni per facilitare la loro presenza in rete; un sistema di monitoraggio e controllo per assicurare l'affidabilità degli scambi; un sistema di reporting e statistiche per fornire informazioni univoche sulla quantità e tipologia degli scambi. La realizzazione del sistema di cooperazione applicativa richiede il coinvolgimento di tutti gli attori coinvolti nei processi di cooperazione. In particolare, i servizi comuni di cooperazione, che permettono la cooperazione tra amministrazioni centrali e locali a livello paese, trovano la naturale collocazione presso il Centro tecnico [6], che costituisce un nodo centrale di competenza creato per fornire assistenza tecnica alle amministrazioni locali nel processo di integrazione. I soggetti (regioni, reti civiche, ecc.) che si propongono come gestori di reti locali possono prendersi carico degli stessi servizi per sviluppare la cooperazione tra amministrazioni locali e svolgere il ruolo di intermediarii tra il sistema di cooperazione generale e quello locale. 3.5 Paradigmi di interazione supportati I paradigmi di interazione supportati dalla cooperazione applicativa sono riconducibili a poche forme funzionali primitive, in particolare alle due seguenti: richiesta di servizio e notifica di evento. Per precisare la definizione di queste funzioni è utile introdurre la generica nozione di oggetto applicativo, definito come una struttura dati persistente di un dominio, dotata di valore modificabile e controllata da applicazioni del dominio direttamente o tramite un insieme di procedure predefinite. Si può pensare in pratica ad una qualsiasi struttura dati gestita da un'applicazione direttamente o tramite un sistema di gestione dati, o anche ad un oggetto, nel senso informatico del termine, dotato di propri metodi. 67

69 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione La richiesta di servizio è un messaggio, prodotto da un'applicazione di un dominio cliente e diretto ad un'applicazione di un dominio servente. Il messaggio determina l'esecuzione di un'applicazione del dominio servente che, in base alle informazioni contenute nel messaggio, esegue una procedura ed invia una risposta destinata all'applicazione cliente. La risposta è una indicazione certa che l'applicazione servente ha attuato la richiesta, anche se eventualmente con un esito negativo. La richiesta di servizio può essere di due tipi, interrogazione oppure transazione: 1. l'interrogazione è una richiesta di servizio finalizzata all'acquisizione di informazioni che non modifica lo stato interno dell'applicazione servente invocata; questa tipologia di interazione, in sola lettura, costituisce la maggior parte delle interazioni. Risultano particolarmente critici gli aspetti relativi alla confidenzialità, riservatezza e non ripudio delle informazioni fornite. La richiesta di servizio potrebbe essere sincrona, nel senso che l'applicazione richiedente rimane in attesa della risposta applicativa, oppure asincrona, nel senso che l'applicazione richiedente non attende la risposta applicativa. La risposta applicativa sarà oggetto di una (o più) successiva interazione. 2. La transazione è una richiesta di servizio che provoca una modifica dello stato interno dell'applicazione servente invocata. Questo tipo di interazione in letturascrittura prevede che il proprietario del dato possa adottare politiche di accesso più stringenti sulle modalità di utilizzo del servizio. La richiesta di servizio potrebbe essere sincrona, nel senso che l'applicazione richiedente rimane in attesa degli esiti della transazione; oppure asincrona, nel senso che l'applicazione richiedente non attende gli esiti della transazione. Gli esiti della transazione potrebbero essere oggetto di una (o più) successiva interazione. Il secondo tipo di interazione è la notifica di evento. Un evento è il cambiamento del valore di un oggetto informativo, determinato dall'esecuzione di un'applicazione in un 68

70 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione dominio sorgente dell'evento, che ha un significato anche per altri domini detti domini destinatari. La segnalazione o notifica di evento è il messaggio che un'applicazione sensibile all'evento genera allo scopo di informare dell'evento le applicazioni di uno o più domini destinatari che, sulla base del significato del messaggio associato all'evento, producono un cambiamento permanente del valore di propri oggetti applicativi. Mentre per quanto riguarda le interrogazioni e le transazioni viene sempre generata una risposta da un'applicazione nel dominio servente, per la notifica di evento non viene generata mai una risposta da un'applicazione. La notifica dell'evento viene fatta in realtà al dominio non ad un'applicazione ed il dominio sorgente non deve necessariamente conoscere l'uso che ne sarà fatto dai domini destinatari: la notifica di evento è una relazione asincrona tra domini. Quindi, la notifica di evento è un messaggio asincrono, che non richiede una risposta, non richiede cioè un messaggio di ritorno generato dall'applicazione destinataria verso l'applicazione sorgente, ma al più una ricevuta di notifica che attesta la consegna al dominio destinatario. La notifica di evento è tuttavia una funzione sincrona rispetto alla ricevuta di consegna al servizio di notifica eventi (equivalente alla ricevuta di accettazione). In questo tipo di interazione il messaggio, contenente informazioni relative alla modifica di un oggetto applicativo oppure alla nascita di un nuovo oggetto applicativo, viene inoltrato ad un sistema di gestione eventi. L'effetto del messaggio non è noto a priori al generante dell'evento stesso. L'interazione prevede l'utilizzo di un componente della Porta di Dominio, chiamato Gestore Eventi, che prende l'incarico di ricevere la notifica di eventi da parte di un originatore e di distribuirli ai destinatari. Ciò non introduce un nuovo modello di interazione poiché in realtà il Gestore Eventi segmenta l'interazione in due parti ponendosi come server verso i generatori di eventi e come client verso i destinatari. Sono possibili più soluzioni. Per esempio, il consumatore può restare in attesa degli eventi inviati su iniziativa del gestore (logica push); può interrogare il gestore circa l arrivo di nuovi eventi a lui destinati (polling); può interrogare il gestore circa l arrivo di 69

71 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione determinati tipi di eventi (polling selettivo); può segnalare al gestore la propria disponibilità a ricevere gli eventi a lui destinati (push sollecitato), oppure a ricevere solo certi tipi di eventi (push sollecitato e selettivo); ecc. I sistemi di messaging possono operare secondo due modalità diverse per l'invio e la ricezione dei messaggi: point-to-point: il messaggio può avere uno o più destinatari, ma una volta inviato alla coda (queue) corrispondente, viene recuperato dal primo che vi si collega, e poi cancellato; publish and subscribe: il messaggio non contiene indicazioni circa i suoi destinatari ma è semplicemente inviato rispetto ad un obiettivo (topic), e viene ricevuto da tutti i sottoscrittori per quell obiettivo che si sono registrati prima dell'invio. 3.6 Gli scenari applicativi nell'architettura SPCoop Definiamo all'interno di SPCoop uno scenario di coordinamento della prestazione di servizio uno scambio di messaggi utilizzato per coordinare l'erogazione e la fruizione di una prestazione di servizio. Qualsiasi scenario di coordinamento di una prestazione di servizio risulta esclusivamente dalla combinazione di scambi elementari di tipo messaggio senza replica, messaggio con replica sincroni, messaggio con replica asincroni. In Appendice B sono riportati alcuni esempi di utilizzo delle intestazioni della Busta di e-gov in funzione dei vari tipi di richiesta. Nei paragrafi seguenti sono presentati alcuni tipi di scenari elementari di coordinamento dell'erogazione e fruizione del servizio: richiesta senza risposta, richiesta con risposta, notificazione senza risposta, notificazione con risposta. 70

72 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione Richiesta senza risposta Nello scenario richiesta senza risposta, il sistema fruitore trasmette al sistema 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. Lo scenario di richiesta senza risposta coordina una modalità di erogazione della prestazione asincrona e su iniziativa del fruitore: i trattamenti per l'erogazione della prestazione di servizio seguono la ricezione dell'invocazione da parte dell'erogatore (precedute dalle verifiche di formato, sintattiche e semantiche), ma il sistema mittente della richiesta non ha nessuna informazione diretta sulla avvenuta erogazione della prestazione Richiesta con risposta Nello scenario richiesta con risposta, il sistema fruitore trasmette al sistema erogatore un messaggio contenente una richiesta di prestazione di servizio. L'erogatore esegue il trattamento di erogazione della prestazione (dopo aver effettuato le verifiche di formato, sintattiche e semantiche) e trasmette un messaggio di risposta contenente il resoconto di erogazione e eventualmente i dati la cui fornitura è parte della prestazione. Lo scenario richiesta con risposta coordina una modalità di erogazione della prestazione sincrona e su iniziativa del fruitore: l'erogazione della prestazione avviene sempre all'occasione e dopo la ricezione della richiesta e prima dell'emissione della risposta; la fruizione avviene dopo la ricezione della risposta. Le modalità dell'interazione (dal punto di vista del fruitore) possono essere sia sincrone che asincrone: nello scenario richiesta con risposta sincrona, 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 l'esecuzione. Questo scenario può essere implementato direttamente 71

73 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione utilizzando uno scambio elementare di tipo messaggio con replica sincroni; nello scenario di richiesta con risposta asincrona, 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 effettua le verifiche, esegue i trattamenti, prepara e emette 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. Lo scenario può essere implementato utilizzando lo scambio elementare di tipo messaggio con replica asincroni Notificazione senza risposta Nello scenario notificazione senza risposta, il sistema erogatore del servizio trasmette di sua iniziativa un messaggio di notificazione al sistema fruitore (che può contenente il resoconto di un trattamento effettuato o la notifica di un evento). Questo scenario coordina una modalità di fruizione di servizio asincrona e su iniziativa dell'erogatore. Come la richiesta senza risposta, tale scenario può essere implementato usando uno scambio elementare di tipo messaggio senza replica Notificazione con risposta Lo scenario di notificazione con risposta è simmetrico allo scenario richiesta con risposta: il sistema erogatore trasmette un messaggio di notificazione e successivamente il sistema fruitore trasmette un messaggio di risposta. Questo scenario coordina una modalità di fruizione sincrona e su iniziativa dell'erogatore. Come nel caso della richiesta con risposta, la notificazione con risposta può essere implementata con modalità sincrona o asincrona e quindi essere implementato rispettivamente dallo scambio elementare messaggio con replica sincrono o asincrono. 72

74 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione Altri scenari applicativi Per implementare trattamenti complessi e distribuiti tra più sistemi (processi distribuiti) in termini di scambio di prestazioni di servizio tra i detti sistemi, può essere necessario mettere in opera scenari complessi di coordinamento dello scambio di servizi. Tutti gli scenari di coordinamento della prestazione di servizio, indipendentemente dalla loro complessità, devono essere costruiti esclusivamente a partire dalla composizione di interazioni elementari di tipo messaggio senza replica, messaggio con replica sincroni, messaggio con replica asincroni. In una architettura di servizi, la realizzazione di processi distribuiti complessi può essere effettuata seguendo due approcci fondamentali: l'orchestrazione dei servizi, che prevede l'implementazione, oltre ai sistemi e servizi partecipanti al processo distribuito, di un ulteriore servizio specializzato (e del sistema erogatore di detto servizio) di coordinamento dello scambio di prestazioni di servizio tra i sistemi partecipanti al processo e di mediazione dello scambio di messaggi tra detti sistemi. Il coordinatore/mediatore non eroga servizi applicativi nell'ambito del processo, non implementa logica applicativa oltre a quella che presiede al coordinamento del processo e alla cooperazione dei sistemi. Il coordinatore/mediatore è l'interlocutore unico di tutti i sistemi e, se il processo implementa l'erogazione di un servizio verso sistemi terzi, svolge il ruolo di erogatore di tali servizi, così come svolge il ruolo di erogatore di servizi di pilotaggio e di monitoraggio del processo. Tecnologie come WSBPEL permettono di implementare l'approccio di orchestrazione dei servizi; la coreografia dei servizi, che richiede l'implementazione del coordinamento dello scambio di servizi tra i sistemi partecipanti al processo per mezzo di un protocollo di conversazione che ordina lo scambio dei messaggi tra detti sistemi (senza prevedere l'implementazione di un servizio dedicato a un ruolo di coordinatore/mediatore). Il protocollo di conversazione è una macchina a stati in cui le transizioni sono messaggi scambiati tra i sistemi partecipanti al processo. Tecnologie come WSCI [61] permettono di implementare l'approccio di coreografia 73

75 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione dei servizi. 74

76 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione Capitolo 4 Le soluzioni analizzate Per focalizzare le problematiche legate all'implementazione di una architettura di cooperazione applicativa abbiamo condotto uno studio sui prodotti già in uso o in corso di sviluppo che realizzano in toto o in parte le esigenze legate al paradigma della cooperazione applicativa. In particolare, lo studio principale è avvenuto tra il mese di giugno e il mese di settembre 2004, quindi prima della pubblicazione delle specifiche ministeriali presentate nel capitolo 3; in questa fase abbiamo analizzato in dettaglio quella che allora era l'unica piattaforma di cooperazione applicativa: il progetto CART della Regione Toscana. In seguito abbiamo studiato lo sviluppo di due soluzioni legate alla cooperazione applicativa: il progetto SOLE, sviluppato dalla Regione Emilia Romagna per l'interfacciamento dei sitemi sanitari e il progetto ICAR, che ha come obiettivo l'integrazione dei vari sistemi di cooperazione applicativa realizzati dalle regioni. Infine abbiamo analizzato il primo progetto Open Source nell'ambito della cooperazione applicativa: OpenPDD, che si propone di realizzare un'implementazione della PDSA. 4.1 Il progetto CART della Regione Toscana Regione Toscana si è dimostrata all'avanguardia nel processo di informatizzazione della Pubblica Amministrazione presentando nel 2002 il progetto CART (Cooperazione Applicativa della Regione Toscana) [58], sviluppato nel contesto del piano di egovernment ministeriale, secondo cui l'interoperabilità è l'elemento fondamentale per 75

77 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione poter erogare servizi ai cittadini e alle imprese in modo facile, veloce e completo da parte delle Pubbliche Amministrazioni. In effetti, l'esperienza del progetto CART è stata di fondamentale importanza nella definizione delle specifiche nazionali redatte dal CNIPA, e costituisce il primo tentativo di formalizzazione delle esigenze della Pubblica Amministrazione nello scenario di cooperazione applicativa. In particolare CART si propone di: realizzare una infrastruttura per lo sviluppo e la pubblicazione di servizi che facilitino la cooperazione, attraverso il mezzo telematico, delle Pubbliche Amministrazioni della Regione Toscana; utilizzare una architettura aperta, fondata su standard tecnologici per i quali le specifiche siano complete e pubblicamente disponibili; garantire scalabilità, cioè fornire la possibilità di applicazione della soluzione proposta a tutte le amministrazioni; garantire flessibilità, rendendo la soluzione capace di adattarsi alle esigenze e alla struttura esistente presente all'interno delle amministrazioni, senza dipendere dalle specifiche tecnologie utilizzate; garantire la sicurezza, per l'autenticità, l'integrità, la non ripudiabilità e la riservatezza dei dati scambiati; enfatizzare l'estremo valore delle informazioni create e gestite dalle applicazioni esistenti, riducendo al minimo l'impatto e le modifiche su queste ultime L'architettura di CART Il modello di riferimento [59] redatto dalla Regione Toscana per l'implementazione del progetto CART si basa sulla definizione di un insieme di componenti architetturali che vanno a realizzare dei livelli di intermediazione (layer) tra le pubbliche amministrazioni e tra le amministrazioni e il cittadino, al fine di realizzare uno scambio di informazioni 76

78 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione senza soluzioni basate su approcci applicativi e proprietari. L'architettura proposta non impone la creazione di soluzioni basate su specifici prodotti adattati alle necessità della comunicazione tra le pubbliche amministrazioni ma, partendo da queste, identifica componenti architetturali che implementano tecnologie e protocolli standard di mercato, naturalmente multipiattaforma. Questo requisito dunque segna il passaggio da un approccio applicativo basato su un prodotto ad un approccio per componenti, la cui integrazione è realizzata mediante l'adozione di standard, centrando l'obiettivo fondamentale della indipendenza da specifici produttori e da soluzioni realizzate ad hoc. Inoltre è stato posto tra i requisiti fondamentali l'adozione di una architettura in grado di supportare sia il modello SOA, sia il modello EDA; quindi la comunicazione tra le entità che ne fanno uso deve essere basata sullo scambio di messaggi. Regione Toscana ha deciso di codificare tali messaggi definendo il formato Busta e-toscana, equivalente alla Busta di e-gov discussa nel paragrafo 3.3. Come mostra la figura 4.1, la struttura di CART è basata su tre componenti complementari: il Front end Service Layer (FSL), il Virtual Service Layer (VSL), il Back end Service Layer (BSL). 77

79 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione Figura 4.1. Struttura dell'architettura di CART Il Front end Service Layer è il livello di esposizione dei servizi sviluppati all'interno del progetto verso gli operatori umani e verso le eventuali applicazioni esterne a CART. Le funzionalità di questo layer possono essere raggruppate in due tipologie: 1. esposizione dei servizi; 2. aggregazione dei servizi. Il FSL è immaginabile come un insieme di componenti che interagiscono sia con il VSL che con alcuni servizi trasversali (ad esempio di autenticazione, firma digitale, etc.). L'interazione con il VSL è rappresentata da componenti in grado di accettare su 78

80 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione protocollo HTTP parametri generati dall'interazione di un utente o da un altro sistema e inoltrarli verso il componente di business addetto all'elaborazione. Il punto di contatto con l'utente ed il sistema avviene esclusivamente a livello di VSL attraverso le Porte di Dominio dei Servizi Applicativi sfruttando il protocollo SOAP. Inoltre in questo layer sono collocati componenti e strumenti che consentono la gestione degli aspetti legati alla navigazione dell'accesso ai servizi, al deploy di nuovi servizi e alla pubblicazione di nuovi contenuti. Il Virtual Service Layer rappresenta il cuore del sistema informativo di CART poiché al suo interno dispone di una componente capace di trasformare le richieste provenienti dal front end in azioni e processi comprensibili dalle componenti applicative residenti nei back end. Il Virtual Service Layer rappresenta un middleware che assume la componente di erogatore quando le richieste provengono dal front end e il ruolo di fruitore quando si rivolge al back end. La Porta di Dominio dei Servizi Applicativi consente al VSL, oltre all'interazione con altri domini, di interagire con lo strato di Back End Service Layer attraverso le API JMS [60], qualora il Back End Service Layer sia dotato di un broker JMS che supporti HTTP, oppure direttamente con scambio di messaggi SOAP sincroni. Per l'implementazione del registro dei servizi, che fornisce l'accesso ai servizi di backend da parte del VSL, è previsto l'uso di un repository ebxml. Il Back end Service Layer svolge le funzioni di trattamento dei dati e dei servizi che devono essere erogati. Per espletare queste funzionalità dispone di tre tipi di interfacce: upload/download, usata dal back office attraverso un'applicazione web presente sulla PDSA; message listener, in grado di ricevere e processare messaggi spediti da un client applicativo, da un componente Web o da una applicazione JMS; code di messaggi, capace di ricevere messaggi JMS spediti dal back end. 79

81 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione I componenti di CART Il modello proposto dala Regione Toscana per la costruzione della piattaforma di cooperazione applicativa prevede l'attivazione di due tipi di componenti [61]: un nodo centrale, definito Centro Regionale per la Interoperabilità e la Cooperazione (CRIC), ed un insieme di nodi periferici, definiti Nodi Applicativi Locali (NAL). Le amministrazioni e gli enti locali che partecipano alla cooperazione applicativa prendono il nome di Sistemi Informativi Locali (SIL). Il CRIC implementa parte del VSL ospitando i servizi di rete comuni e condivisi da più amministrazioni che saranno di supporto alla cooperazione applicativa, tra cui il monitoraggio della rete e delle applicazioni. Un NAL espleta le funzioni di Porta Delegata e di Porta Applicativa per un determinato dominio, fornendo l'accesso alla infrastruttura di cooperazione applicativa ai sistemi informativi locali afferenti a quel particolare dominio. Il NAL è costituito da una parte infrastrutturale comune ad ogni NAL, sulla quale vengono installati dei componenti applicativi, definiti Proxy Applicativi, che consentono l'interfacciamento al sistema di cooperazione applicativa da parte dei sistemi operanti sui SIL. Dunque è presente un Proxy Applicativo specifico per ogni applicazione che deve operare nel contesto di cooperazione applicativa. Il compito del Proxy Applicativo è di ricevere i dati dal SIL, elaborarli secondo una logica applicativa specifica per quella applicazione, imbustarli secondo il formato Busta e-toscana ed inviarli al CRIC. La figura 4.2 illustra le componenti dell'infrastruttura di cooperazione. 80

82 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione Figura 4.2. Le componenti dell'infrastruttura di cooperazione Il Framework CA L'implementazione del progetto CART si è basata su una soluzione realizzata da Sun Microsystems [62]: il Framework CA (FCA). FCA è un framework che sviluppa il paradigma di cooperazione applicativa ed è realizzato interamente in ambiente Java sfruttando la piattaforma J2EE. Tali scelte tecnologiche sono state motivate dalla volontà di ottenere un'implementazione multipiattaforma in grado di realizzare l'interoperabilità tra sistemi eterogenei. FCA è stato progettato specificamente per soddisfare i requisiti richiesti dal progetto CART: interazioni basate sia sul modello SOA sia sul modello EDA, utilizzo del protocollo SOAP con e senza attachment, via messaging e via RPC, 81

83 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione utilizzo della firma digitale sui documenti trasmessi, utilizzo del Registry UDDI e del protocollo WSDL per l'interrogazione dei servizi su questo esposti. FCA, in seguito alla ricezione di ogni messaggio da parte del NAL, si fa carico di effettuare tutti i controlli e le verifiche necessarie al proseguimento della comunicazione. Quindi, in caso di esito positivo, inoltra il messaggio al NAL destinatario, se si tratta di una richiesta di servizio, oppure ai NAL e quindi ai SIL sottoscrittori dell'evento, se si tratta di una cooperazione per eventi. L'individuazione dei NAL e dei SIL sottoscrittori avviene tramite un apposito repository in cui sono contenute le informazioni di instradamento. Dunque FCA supporta le seguenti funzionalità: ricezione e instradamento dei messaggi inviati dai componenti software presenti sul NAL; autenticazione; il sistema verifica l'identità del componente software presente sul NAL che deve inviare il messaggio; autorizzazione; il sistema verifica che i componenti software presenti sul NAL siano autorizzati a pubblicare o ricevere il messaggio; gestione del messaggio; il sistema, in caso di esito negativo, in una delle fasi di autenticazione e autorizzazione invia un messaggio di risposta al mittente; nel caso in cui tutti i controlli abbiano esito positivo, il sistema processerà il messaggio instradandolo verso il NAL destinatario; funzioni di amministrazione relative alla assegnazione e gestione dei ruoli di pubblicatore e sottoscrittore dei SIL (e quindi dei NAL corrispondenti); gestione delle problematiche relative alla sicurezza; oltre a effettuare le verifiche necessarie per l'autenticazione e l'autorizzazione, il sistema garantisce che il messaggio sia protetto mediante crittografia. I componenti software utilizzati da FCA per garantire le funzionalità appena elencate 82

84 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione sono: Broker, si tratta di un provider JMS realizzato con Sun ONE Message Queue [63], per garantire: ricezione dei messaggi, autenticazione autorizzazione, gestione del messaggio, consegna dei messaggi, sicurezza; Configuration Manager CA, che fornisce la funzionalità di amministrazione per l'assegnazione dei ruoli ai diversi NAL ed ai SIL; Repository, utilizzato dal sistema per reperire le informazioni necessarie alla autenticazione e amministrazione dei ruoli dei SIL. Il Framework CA è composto da una parte centrale posta sul CRIC, che raccoglie i componenti software appena descritti, e da una componente periferica posta sui NAL, alla quale i Proxy Applicativi hanno accesso attraverso un'interfaccia chiamata SOLE Facade. Nel progetto CART, il NAL svolge la funzione di PDSA per ciascun dominio, includendo sia le funzioni di Porta Delegata sia quelle di Porta Applicativa. Dispone quindi di due interfacce: una verso i SIL ed una verso il CRIC. L'interfaccia verso il CRIC, in particolare verso il Framework CA, avviene attraverso SOLE Facade facendo uso del componente Message Handler Control CA che ingloba al suo interno il componente Message Control CA. Message Handler Control CA è il componente software che consente al NAL l'invio e la ricezione di messaggi in formato Busta etoscana. Al suo interno, il Message Control CA raccoglie le funzionalità che garantiscono la sicurezza delle transazioni dei messaggi applicativi: protezione del canale di comunicazione tra NAL e CRIC; validazione dei messaggi secondo la codifica Busta e-toscana; autenticazione dei messaggi; 83

85 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione controllo delle autorizzazioni attraverso l'interrogazione dell'apposito repository presente sul CRIC. La figura 4.3 mostra il ruolo del Framework CA. Figura 4.3. Il ruolo di FCA nell'invio dei messaggi da parte dei SIL I Proxy Applicativi Il Proxy Applicativo [64] consiste in un'applicazione Java sviluppata con le API Java 2 Platform Standard Edition che usa le funzionalità messe a disposizione dal Message Handler CA per l'imbustamento e la ricezione dei messaggi applicativi; usa le API Java per la propria logica applicativa e per l'interfacciamento verso l'rdbms ed infine presenta una interfaccia verso i SIL per ricevere i dati necessari alla composizione di 84

86 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione una richiesta di servizio o alla pubblicazione di un evento da inviare al CRIC. In base alle capacità dei SIL, si possono realizzare tre modalità di colloquio tra un SIL ed un Proxy Applicativo: 1. file upload su HTTPS; 2. Web Services; 3. JMS Provider. All'arrivo dei dati dal SIL [65] il Proxy Applicativo svolge le seguenti azioni: autentica il SIL attraverso il suo certificato digitale; effettua operazioni sui dati in relazione alle propria logica applicativa (ad esempio la validazione dei dati, il loro caricamento nel RDBMS etc.); costruisce un messaggio SOAP invocando un metodo crea_busta esposto dal Framework CA attraverso l'interfaccia SOLE Facade a cui passa tutti i valori necessari alla creazione del messaggio in formato Busta e-toscana e riceve come parametro di ritorno un oggetto che rappresenta la busta appena creata; invia la busta al Framework CA usando il metodo send_busta(busta e- toscana). Questo metodo restituisce una busta e-toscana contenente un messaggio di riscontro: un messaggio di Ack nel caso in cui la spedizione sia andata a buon fine oppure un messaggio di Fault in caso di errore. Inoltre l'interfaccia SOLE Facade offre ad ogni Proxy Applicativo di far uso del Sistema di Log del Framework CA, di consentire l'attivazione dei sottoscrittori agli eventi gestiti e di accedere alla configurazione del framework per ottenere informazioni inerenti al NAL. La figura 4.4 mostra le operazioni svolte dal Proxy Applicativo. Figura 4.4. Le operazioni svolte dal Proxy Applicativo 85

87 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione Scenari applicativi in CART Come descritto nei precedenti paragrafi, nel progetto CART è stata prevista l'aggregazione dei servizi infrastrutturali di cooperazione applicativa all'interno del CRIC. Questa scelta architetturale determina che la Porta di Dominio, le cui funzionalità sono espletate dal NAL, faccia uso dei servizi centralizzati presenti sul CRIC per realizzare le due forme di comunicazione supportate dalla cooperazione 86

88 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione applicativa: la richiesta di servizio e la notifica di eventi. In figura 4.5 è illustrato il flusso applicativo determinato da una richiesta di servizio inviata dal SIL1 al SIL2. Il SIL1 invia al Proxy Applicativo presente sul NAL1 i parametri necessari alla composizione della richiesta di servizio (1), tipicamente il nome del servizio, il destinatario, il corpo del messaggio ed eventuali documenti da allegare alla richiesta. Il Proxy Applicativo, dopo aver eseguito i controlli di autenticazione, compone la richiesta creando, attraverso FCA, il messaggio SOAP in formato busta e-toscana (2). FCA quindi interroga il Registro dei servizi presente sul CRIC (3) per determinare l'url del servizio. Il Proxy Applicativo, dopo aver ricevuto la busta SOAP da FCA, invia il messaggio al CRIC (4). Il CRIC riceve la richiesta dal NAL1 attraverso FCA, che provvede ad inoltrare la busta al NAL2 (5). Il componente FCA del NAL2 riceve la busta dal CRIC e la inoltra al Proxy Applicativo (6), il quale, dopo aver effettuato i controlli di sicurezza, la invia al SIL2 (7). Figura 4.5. Flusso applicativo nella cooperazione per richiesta di servizio 87

89 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione In figura 4.6 è illustrato il flusso applicativo determinato dalla pubblicazione di un evento da parte del SIL1 e della notifica dell'evento stesso da parte dei SIL sottoscrittori di tale evento. Il SIL1 invia tramite POST HTTP al Proxy Applicativo presente sul NAL1 i parametri per la pubblicazione dell'evento (1), tipicamente il nome dell'evento ed il corpo del messaggio. Il Proxy Applicativo, sfruttando FCA, esegue i controlli di sicurezza e determina se il SIL1 può effettuare l'operazione di pubblicazione per quel dato evento. Inoltre può effettuare altre operazioni, come la memorizzazione del messaggio nel RDBMS, in relazione alla propria logica applicativa. Se vengono superati tutti i controlli di sicurezza, il Proxy Applicativo attraverso i metodi esposti da FCA, compone il messaggio SOAP e lo inserisce nella apposito coda (topic) JMS presente sul CRIC (3). Ogni NAL utilizza FCA per recuperare il messaggio dalla coda JMS (4) e lo inoltra al Proxy Applicativo (5), che si 88

90 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione preoccupa di memorizzare il messaggio nell'apposito repository ed invia a tutti i SIL sottoscrittori un messaggio di notifica (6) per informarli della presenza di un nuovo messaggio per quel determinato evento. Figura 4.6. Flusso applicativo nella cooperazione per notifica di eventi Conclusioni dell'analisi di CART Nell'ambito del progetto CART è stata svolta una analisi approfondita sia del modello architetturale sia dell'implementazione di tale modello attraverso il Framework CA. Tale analisi ha avuto luogo prima della pubblicazione delle specifiche redatte dal CNIPA e discusse nel capitolo 3, dunque ha richiesto dapprima la formalizzazione di un modello organizzativo rispondente alle esigenze del paradigma di cooperazione applicativa e la formalizzazione dei ruoli dei vari componenti architetturali, con particolare attenzione alla PDSA. 89

91 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione A livello organizzativo sono emerse due problematiche: 1. la formalizzazione del concetto di dominio, del suo ruolo e dei ruoli delle varie amministrazioni all'interno di ciascun dominio; 2. l'utilizzo di un formato unico di comunicazione a livello nazionale. Entrambe le problematiche sono state ampiamente risolte dalle specifiche redatte dal CNIPA. La definizione dei domini di cooperazione, delle politiche che regolano la loro organizzazione e del ruolo che rivestono nell'ambito della cooperazione applicativa risolve interamente la prima problematica. La seconda è stata determinata dal fatto che al momento della progettazione e della implementazione di CART non era ancora stata formalizzata la struttura della busta di e-gov ed il ruolo degli headers della busta, bensì era presente solo una descrizione della busta di e-gov [1] come oggetto applicativo utilizzato per codificare i messaggi scambiati nell'ambito della cooperazione applicativa. Questo fatto ha condotto alla definizione ed all'uso della busta e-toscana. Con la pubblicazione delle specifiche della Busta e-gov [51] è possibile adottare correttamente in tutti i sistemi di cooperazione applicativa un formato di comunicazione unico. Lo studio dell'architettura e della sua realizzazione è stato condotto attraverso l'analisi: del Framework CA e dell'interfaccia SOLE Facade [68]; dell'utilizzo dei componenti architetturali nei vari modelli di comunicazione; di alcuni Proxy Applicativi. La figura 4.7 mostra i componenti architetturali che realizzano il CRIC. Figura 4.7. Componenti architetturali che realizzano il CRIC 90

92 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione La nostra analisi si è focalizzata in modo particolare sui componenti presenti sul CRIC che vanno ad integrare il Framework per la Cooperazione Applicativa: JMS Provider, RDBMS, Directory Server, Cruscotto di amministrazione del Framework. Gli altri componenti che realizzano il CRIC sono: Registro dei servizi; Servizi di Directory accessibili via LDAP; Servizi Applicativi centrali, cioè la componente centrale di servizi applicativi che prevedono un punto centrale di coordinamento o di accesso; Servizi di Web server; Servizi per la distribuzione, l'aggiornamento e il monitoraggio delle componenti software remote sui NAL; Cruscotto di amministrazione di sistema; Gateway verso altri Centri Servizi e/o verso altri Enti. Poiché non è stato reso pubblico il codice del Framework di Cooperazione Applicativa, l'analisi si è concentrata sul monitoraggio delle componenti architetturali per determinarne l'uso da parte di FCA. Il risultato ottenuto da questa analisi è stato 91

93 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione determinare che tutte le comunicazioni tra i NAL ed il CRIC e viceversa avvengono attraverso l'uso del JMS Provider. In particolare, questa scelta è stata analizzata in dettaglio nell'ambito della cooperazione per notifica di eventi; infatti è emerso che il Framework di Cooperazione Applicativa presente sul CRIC non invia effettivamente il messaggio ai destinatari bensì, come descritto nel paragrafo 4.1.5, lo inserisce in una coda (topic) JMS. Sarà poi compito del NAL recuperare il messaggio dalla specifica coda. Inoltre è stato importante determinare che il CRIC può essere replicato e distribuito a livello sub-regionale, ad esempio a livello provinciale. Questa scelta consente di incrementare sensibilmente l'efficienza e le prestazioni dell'intero sistema. La parte più consistente dell'analisi è stata svolta sull'architettura e sull'implementazione dei Proxy Applicativi. Il ruolo dei Proxy Applicativi risulta di fondamentale importanza nel progetto CART poiché: costituiscono l'interfaccia attraverso cui le amministrazioni (SIL) possono utilizzare la piattaforma di cooperazione applicativa; consentono l'integrazione dei sistemi legacy nell'infrastruttura di cooperazione applicativa; determinano come comporre i messaggi SOAP per effettuare una comunicazione. La figura 4.8 mostra la struttura logica di un Proxy Applicativo. 92

94 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione Figura 4.8. Architettura logica di un Proxy Applicativo L'adozione dei Proxy Applicativi risulta una scelta particolarmente critica poiché richiede per ogni servizio erogato all'interno della piattaforma di cooperazione applicativa lo sviluppo di un software specifico per consentire alle amministrazioni di poter usufruire di tale servizio. In tale scenario, con l'aumentare del numero di servizi erogati attraverso l'infrastruttura di cooperazione applicativa, su ogni NAL dovranno essere installati un numero sempre crescente di Proxy Applicativi. Quindi i risultati dell'analisi suggeriscono una modifica organizzativa ed una modifica strutturale. La modifica organizzativa si riferisce, in conseguenza alla definizione dei domini di cooperazione, alla possibilità di sviluppare il flusso di comunicazione in modo differente a seconda che la comunicazione si svolga tra amministrazioni afferenti allo 93

95 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione stesso dominio o a due diversi domini. Nel caso in cui la comunicazione avvenga all'interno di un dominio, sia una richiesta di servizio sia la pubblicazione di un evento i cui sottoscrittori siano solamente amministrazioni afferenti allo stesso dominio dell'ente pubblicatore, occorre rendere sistematicamente più efficiente il flusso applicativo evitando di utilizzare componenti centralizzati. La modifica strutturale riguarda l'eliminazione della figura del Proxy Applicativo attraverso l'adozione sui NAL di: una interfaccia verso i SIL che sia in grado di accettare qualsiasi tipo di richiesta da parte delle amministrazioni; un modulo che vada a sostituire la componente di logica applicativa dei Proxy Applicativi; dunque che sia in grado di determinare come comporre il messaggio SOAP in funzione del servizio richiesto, sia esso una richiesta di servizio o una notifica di evento. Le specifiche di cooperazione applicativa redatte dal CNIPA forniscono un modello organizzativo che si adatta particolarmente bene ai risultati della nostra analisi poiché: attraverso la definizione dei domini di cooperazione e dei registri SICA consente di decentrare sistematicamente le funzionalità di cooperazione; attraverso l'invito a differenziare nella PDSA la componente di integrazione da quella di cooperazione risulta naturale il tentativo di fornire alle amministrazioni un unico punto di accesso all'infrastruttura di cooperazione, rendendo snella e scalabile l'intera architettura. Nel capitolo 5 sarà discusso in dettaglio OpenSPCoop, il progetto Open Source che cerca anche di superare i limiti riscontrati dall'analisi condotta nell'ambito del progetto CART. 94

96 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione 4.2 Le altre soluzioni analizzate Le iniziative inerenti alla cooperazione applicativa si sono moltiplicate nel corso degli ultimi mesi, tuttavia si tratta prevalentemente di progetti in fase di definizione o di sviluppo perciò non è stato possibile condurre un'analisi approfondita come quella realizzata nell'ambito del progetto CART. Inoltre abbiamo cercato soluzioni alternative sviluppate negli altri paesi europei ed in ambito internazionale, ma abbiamo constatato che il nostro Paese risulta all'avanguardia nel processo di e-government e nella definizione delle problematiche legate alla cooperazione applicativa. Quindi abbiamo ritenuto di particolare interesse analizzare almeno superficialmente alcuni progetti italiani che realizzano almeno in parte alcuni aspetti del paradigma di cooperazione applicativa. Nei prossimi paragrafi saranno presentati brevemente tali progetti con particolare attenzione ai loro obiettivi nell'ambito della cooperazione applicativa ed alle scelte tecnologiche adottate Il progetto SOLE Il progetto SOLE Sanità OnLineE [70], definisce lo standard per l'interfacciamento dei sistemi sanitari in conformità con il DGR 1686/2002. Il progetto è stato sviluppato dalla Regione Emilia Romagna in collaborazione con Webred S.p.A. [71], Dianoema S.p.A. [72] e Dedalus S.p.A. [73]. La prima versione del progetto è stata rilasciata nel dicembre A questa, attualmente, sono succedute altre undici versioni, l'ultima delle quali è la versione 13.1 [74] rilasciata nel mese di aprile Il progetto SOLE prevede la costruzione di una rete telematica integrata ospedaleterritorio nelle aziende sanitarie della regione Emilia Romagna. Più dettagliatamente la finalità del progetto è quella di rendere fruibili una serie di servizi che permettano al medico di indirizzare i propri pazienti verso le strutture sanitarie regionali. Il progetto è stato sviluppato secondo le logiche di cooperazione applicativa e gli 95

97 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione standard definiti in occasione del piano di e-government ed ha come obiettivo l'integrazione delle applicazioni attualmente utilizzate nell'ambito medico. Le iniziative del progetto prevedono anche la creazione di un Centro Operativo Regionale dove saranno implementati i servizi comuni e i sistemi di interoperabilità per un'architettura generale. Gli attori del progetto sono essenzialmente due: SOLE ed i sistemi di refertazione, prescrizione, accettazione, prenotazione, e tutti quei sistemi che chiedono e espongono servizi a SOLE. Infatti, per rispondere all'esigenza di connessione e di scambio dati tra numerosi sistemi sanitari, i medici, i quali devono potersi collegare a molteplici entità del mondo sanitario, avranno a disposizione un unico sistema di riferimento per tutti i sistemi, sia per quelli interni che per quelli esterni, che corrisponde alla Porta di Dominio dei Servizi Applicativi. Attraverso l'uso della PDSA si evita anche l'utilizzo di adattatori software proprietari che renderebbero estremamente gravosi i costi di manutenzione nel caso si desiderasse aggiungere un nuovo collegamento tra medico di base ed il sistema sanitario. In conformità con le specifiche redatte dal CNIPA le comunicazioni avvengono utilizzando la busta di e-gov. Nel progetto SOLE le funzionalità della PDSA vengono richiamate tramite una API che può essere utilizzata attraverso tecnologie diverse: Java; una libreria Dll in linguaggio C per sistemi Wintel; un metodo Main() esterno che comunica mediante I/O stream. La scelta tecnologica significativa intrapresa con il progetto SOLE riguarda 96

98 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione l'integrazione dei sitemi legacy con la Porta Applicativa in quanto avviene sempre attraverso un adapter o plugin Java. L'adapter è realizzato dal fornitore del sistema legacy ed ha un'interfaccia standard per ogni categoria di sistemi (ad esempio anagrafi, sistemi di laboratorio, etc.). Figura 4.9. Architettura della Porta Applicativa nel progetto SOLE Dunque l'architettura della Porta Applicativa, mostrata in figura 4.9, è composta da: 1. la componente telematica, che riceve la busta di e-gov, ne analizza i contenuti e richiama la componente applicativa mediante un plugin che permette di interagire con il servizio. Ogni fornitore fornisce una componente software di plugin che potrà essere utilizzato dalla componente telematica; 2. il plugin, che viene invocato dalla componente telematica. Il plugin dovrà essere realizzato dall'azienda fornitrice del software da integrare, rispettando le interfacce di dettaglio definite e le specifiche dei messaggi da scambiare. Più dettagliatamente il plugin: deve fornire un costruttore che accetta una stringa che sarà il file di configurazione eventuale del plugin, 97

99 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione deve essere thread-safe, può implementare un metodo public void shutdown() che è invocato dal registry allo shutdown per la chiusura delle eventuali risorse usate dal plugin. La gestione degli errori da parte del plugin viene sempre fatta attraverso la restituzione di un messaggio HL7 [75]. Lo standard HL7 descrive le modalità per lo scambio in forma elettronica di dati in ambiente sanitario, con particolare enfasi per gli aspetti riguardanti i pazienti degenti presso strutture ospedaliere. La dizione 'LEVEL 7' fa riferimento al livello più alto del modello OSI (Open System Interconnection), ciò significa che corrisponde alla definizione concettuale di una interfaccia di tipo paritario (applicazione-applicazione). HL7 fa riferimento ai dati scambiati, alla tempistica degli scambi, e alla comunicazione di errori fra le applicazioni, senza far riferimento ad aspetti implementativi. Il messaggio di errore HL7 nel progetto SOLE deve contenere il codice dell'errore ed una stringa in chiaro che ne precisi la natura. Per accedere ai servizi di SOLE un utente deve essere autenticato, identificato e infine autorizzato. L'autenticazione viene fatta dall'applicazione client che chiama SOLE. L'applicazione infatti subordina l'ingresso dell'utente all'immissione di uno username e di una password. Per verificare l'identità del mittente viene utilizzato un meccanismo di trust tra Porta Applicativa e Porta Delegata. Il profilo del mittente, necessario al processo di autorizzazione, viene associato all'utente tramite un'interrogazione ad un database esterno a SOLE, mediante il protocollo LDAP [76]. L'associazione tra nome utente e profilo viene fatta da un server LDAP interno all'azienda. Viene fornita, inoltre, la possibilità di associare ad ogni utente del progetto una classe LDAP specifica al fine di filtrare tra tutti gli utenti 98

100 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione presenti sul server solo quelli a cui è associato un profilo SOLE. In caso contrario tutti gli utenti censiti su LDAP saranno potenziali utenti del sistema SOLE. Il progetto SOLE è in grado di integrarsi sia con sistemi legacy sia attraverso Web Services. Nel primo caso la Porta Applicativa posta sulla PDSA non scambia direttamente informazioni con SOLE ma lo scambio avviene attraverso un adapter che isola SOLE dalla Porta Applicativa. L'adapter è costituto da due moduli in modo tale che l'interfaccia verso SOLE sia uguale per ogni Porta Applicativa, mentre dovrà adattarsi al sistema a cui è collegato. Questo verrà fatto attraverso metodologie diverse secondo il software che viene implementato sulla Porta Applicativa. L'integrazione mediante Web Server, invece, è un metodo più invasivo ma più efficiente. La Porta Applicativa, infatti, dialoga direttamente con un altro Web Server senza che vi sia un elemento di separazione con il compito di tradurre le informazioni scambiate. Infine, il progetto SOLE, per adesso, prevede l'introduzione della firma elettronica come opzionale, sebbene potrebbe essere utilizzata fin da subito sia nei documenti HL7/XML che negli appositi header della busta e-gov. È comunque previsto che, in futuro, i soggetti partecipanti a SOLE siano dotati di Firma Digitale, in modo che i documenti informatici da essi redatti abbiano a tutti gli effetti validità legale Il progetto ICAR Le direttive ministeriali inerenti al piano di e-government assegnano alle regioni uno specifico ruolo di proposta e di implementazione delle infrastrutture delle Pubbliche Amministrazioni per la cooperazione applicativa. Tali proposte sono relative al trasposto dei dati, alla sicurezza, all'accesso autenticato ai servizi e alle modalità di 99

101 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione cooperazione. In questo contesto è nato ed è in via di definizione il progetto ICAR (Interoperabilità e Cooperazione Applicativa tra le Regioni), avente per obiettivo la realizzazione dei servizi infrastrutturali necessari alla cooperazione applicativa tra le regioni. Finora hanno partecipato alla realizzazione della fase iniziale del progetto 17 regioni ed una provincia autonoma per una copertura di oltre il 95% della popolazione e di oltre il 91% del territorio nazionale. Come già affermato in precedenza, ICAR mira a fornire il supporto di base all'integrazione e alla cooperazione applicativa tra i servizi regionali in modo da permettere un'erogazione sempre più trasparente di servizi ai cittadini e rendere omogenea la cooperazione applicativa nell'ambito nazionale. Il progetto garantisce anche una piena autonomia alle singole amministrazioni per quanto riguarda la configurazione, implementazione e gestione dei sitemi informativi locali. Come mostrato in figura 4.10, ICAR definisce due tipi di interventi progettuali tra loro coordinati ed integrati [77]: 1. interventi infrastrutturali, che hanno come scopo la realizzazione dei servizi infrastrutturali di base per l'interoperabilità e la cooperazione applicativa a livelli interregionale, la gestione di strumenti di Service Level Agreement a livello interregionale, la realizzazione di un Sistema Federato interregionale di autenticazione. 2. Casi di studio applicativi, per la sperimentazione e la dimostrazione della funzionalità dell'infrastruttura di interoperabilità e di cooperazione applicativa in specifici domini applicativi significativi e di prioritario interesse per la cooperazione interregionale. 100

102 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione AP 1 AP 2 AP 3 AP 4 AP 5 AP 6 AP 7 Casi di studio INF 3 Sistema Federato di Autenticazione INF 2 Gestione di Strumenti Interregionali di Service Level Agreement Interventi infrastrutturali INF 1 Infrastruttura di base per la Cooperazione Applicativa Interregionale Figura Interventi progettuali del Progetto ICAR Gli interventi infrastrutturali hanno come obiettivo la realizzazione di servizi di base e di strumenti di gestione, conformi a modelli logici e specifiche condivise a livello interregionale: 1. Intervento INF-1, Realizzazione dell'infrastruttura di base per la Interoperabilità e la Cooperazione Applicativa a livello interregionale, che ha come obiettivo la realizzazione dell'infrastruttura fisica e logica indispensabile per la Cooperazione Applicativa interregionale; 2. Intervento INF-2, Gestione di Strumenti di Service Level Agreement a livello interregionale, che ha l'obiettivo di definire strumenti comuni per la gestione di strumenti interregionali di service level agreement, per un monitoraggio efficiente e costante dei livelli di servizio offerti; 3. Intervento INF-3, Realizzazione di un Sistema Federato interregionale di Autenticazione, che si propone di definire le specifiche del servizio di autenticazione e di implementare un sistema federato di autenticazione interregionale. Dall'altro lato, i casi di studio in domini applicativi si propongono di raggiungere i seguenti obiettivi: 101

103 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione l'analisi dei requisiti relativi alla cooperazione applicativa nello specifico dominio applicativo; lo sviluppo di moduli integrativi per l'interfacciamento delle corrispondenti applicazioni esistenti a livello intraregionale all'infrastruttura SPCoop. I moduli hanno il compito di convertire i dati dei sistemi informatici dei domini regionali in formati standard condivisi a livello interregionale. Tali moduli hanno caratteristiche specifiche che dipendono dal tipo di applicazione interregionale e per ogni regione dalle specifiche dell'applicazione di competenza già esistente. Per questi interventi progettuali, sono da prevedersi le attività di analisi dei requisiti, il progetto e la realizzazione delle interfacce tra le applicazioni esistenti a livello regionale/locale con SPCoop, che permettono l'attivazione di servizi di cooperazione applicativa interregionale in specifici domini di interesse: AP-1 Cooperazioni e Compensazioni Sanitarie Interregionali ; AP-2 Anagrafe ; AP-3 Area Organizzativa Omogenea ; AP-4 Lavoro e Servizi per l'impiego ; AP-5 Tassa automobilistica regionale ; AP-6 Osservatorio Interregionale sulla rete distributiva dei carburanti ; AP-7 Sistema Informativo Interregionale di Raccordo con Cinsedo. Concludendo, i risultati che ci si propone di ottenere con l'attuazione del progetto ICAR sono i seguenti: definizione di linee guida e standard relativi a servizi infrastrutturali di interoperabilità e cooperazione applicativa interregionali; specificazione, realizzazione ed integrazione dell'infrastruttura di base per l'interoperabilità e la cooperazione applicativa interregionale; definizione di strumenti interoperanti per la gestione di servizi di service level agreement, per un monitoraggio efficiente e costante dei livelli di servizio offerti a livello interregionale; 102

104 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione definizione delle specifiche del Sistema Federato di Autenticazione ed Integrazione con i sistemi di autenticazione regionali esistenti; sviluppo di casi studio in specifici domini applicativi, con l'obiettivo della sperimentazione e dimostrazione dell'uso dei servizi infrastrutturali di interoperabilità e cooperazione applicativa realizzati in alcuni scenari applicativi OpenPDD OpenPDD [78] è il primo progetto nato con l'obiettivo di sviluppare una implementazione Open Source della Porta di Dominio dei Servizi Applicativi. Il progetto OpenPDD è nato nel mese di luglio 2003 ed è sostenuto e promosso dalle aziende CORE [79] e InFormal [80]. Attualmente sono disponibili varie soluzioni implementative della PDSA, tra cui spiccano i prodotti di Sun Microsystems e di Microsoft, tuttavia si tratta di soluzioni proprietarie. OpenPDD invece, in conformità alle indicazioni del Ministero per l'innovazione e le Tecnologie riguardo allo sviluppo dei piano di e-government, affronta il problema usando un approccio Open Source. Come sarà espresso dettagliatamente nel paragrafo 5.1, riteniamo che le opportunità tecnologiche, oltre che economiche, offerte dal modello Open Source, risultino molto vantaggiose nel contesto della cooperazione applicativa nella Pubblica Amministrazione. Tuttavia nel progetto OpenPDD non è ancora stata realizzata un'implementazione completa della PDSA, bensì finora il progetto si è focalizzato sugli aspetti di integrazione della PDSA, proponendo un livello di astrazione per l'interfaccia applicativa (OpenPDD Livello 2 [81]) al fine di assicurare l'indipendenza dell'applicazione dall'implementazione della Porta di Dominio. OpenPDD Livello 2 è una libreria composta da una serie di interfacce e da alcune classi astratte e generiche che consente alle applicazioni e ai servizi applicativi di accedere ai servizi della Porta Di Dominio in maniera semplificata e neutrale. 103

105 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione OpenPDD Livello 2, dunque, costituisce un livello di astrazione generico che viene frapposto fra le applicazioni e le Porte Di Dominio allo scopo di rendere le prime indipendenti dalle ultime. OpenPDD Livello 2 aderisce alle specifiche redatte dal CNIPA ed attualmente è disponibile in due versioni: 1. OpenPDD Java, implementato in Java; 2. OpenPDD.Net, implementato attraverso la piattaforma.net e che rappresenta il risultato della collaborazione che Microsoft ha stretto nell'autunno 2004 con il team di sviluppatori del progetto OpenPDD. Benché il progetto OpenPDD non fornisca, almeno per il momento, una implementazione concreta della PDSA, è importante sottolineare che viene già impiegato nell'integrazione del progetto SIGMA TER, descritto nel paragrafo 1.3.1, nell'ambito della cooperazione applicativa. 104

106 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione Capitolo 5 OpenSPCoop: un'implementazione Open Source dell'architettura SPCoop Dopo aver discusso nel capitolo 3 le direttive governative redatte dal CNIPA e, nel capitolo 4, aver descritto i risultati dell'analisi condotta sul progetto CART e su alcuni prodotti attualmente in uso, ci apprestiamo a descrivere il risultato dell'analisi di questo lavoro attraverso la presentazione del progetto OpenSPCoop. OpenSPCoop è un'architettura in grado di supportare tutte le funzionalità del paradigma di cooperazione applicativa soddisfacendo i vincoli imposti dalle specifiche nazionali, superando alcuni limiti dei prodotti esistenti ed utilizzando componenti unicamente Open Source. 5.1 Motivazioni per un'implementazione Open Source La scelta di realizzare un'architettura basata interamente su componenti Open Source è motivata dalla volontà di contribuire alla costruzione del nuovo scenario disegnato con il piano di e-government per la Pubblica Amministrazione. Infatti, attraverso l'indagine conoscitiva [82] promossa dal Ministero per l'innovazione e le Tecnologie ad opera della Commissione per il software a codice sorgente aperto nella Pubblica Amministrazione, istituita nel dicembre 2002, sono emerse opportunità di risparmio economico che l'approccio Open Source potrebbe dare alla Pubblica Amministrazione nella costruzione dei sistemi informativi e nell'erogazione di servizi di e-government. 105

107 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione Tuttavia i principali vantaggi apportati dall'utilizzo di una piattaforma Open Source non sono solo economici ma si riferiscono ad aspetti tecnici: come evidenziato nell'indagine ministeriale, in uno scenario dove vige il principio del pluralismo informatico come metodo per assicurare la competitività tra le aziende e la trasparenza dei processi di acquisizione, si evidenzia la necessità di standard che consentano l'interscambiabilità delle componenti a parità di prestazioni. Tali standard e la loro adozione nello sviluppo dei sistemi informativi consentono alla Pubblica Amministrazione di: scegliere liberamente quale tecnologia adottare tra le diverse disponibili; assicurare l'interoperabilità tra i sistemi informatici di diverse amministrazioni; costruire le condizioni necessarie per un reale riuso delle soluzioni sviluppate; sostituire componenti dei sistemi in uso senza intervenire drasticamente sull'intero sistema. In quest'ottica, dunque, l'open Source non viene visto tanto come un'opportunità per usare del software svincolato da costose licenze d'uso, quanto come lo strumento per realizzare quegli standard di comunicazione e di interfacciamento da far conoscere a tutti affinché vengano utilizzati liberamente e migliorati progressivamente. Benché le specifiche di SPCoop soddisfano le esigenze che rendono possibile la creazione di uno scenario fondato sulla completa interoperabilità tra i sistemi informativi eterogenei dislocati tra le varie amministrazioni, occorre ancora definire in dettaglio le specifiche tecniche di tutte le componenti software coinvolte nel processo di interazione. A questo proposito è da sottolineare l'importanza della definizione di un formato di comunicazione omogeneo capace di soddisfare qualsiasi esigenza nello scambio informativo tra le amministrazioni, che è rappresentato dalla Busta di e-gov. Tuttavia riteniamo che il prossimo passo da compiere nella standardizzazione delle 106

108 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione componenti software sia il completamento della definizione dell'interfaccia che ogni amministrazione dovrà implementare per poter inviare e ricevere messaggi nell'ambito di SPCoop, ovvero la Porta di Dominio dei Servizi Applicativi. Quando il processo di definizione delle specifiche sarà completato sarà opportuno costruire lo scheletro della Porta di Dominio attraverso un progetto Open Source, sulla base del quale le aziende realizzeranno diverse implementazioni della Porta di Domino. In questo modo ogni amministrazione potrà scegliere liberamente una tra le diverse implementazioni della Porta di Dominio e su di essa basare lo sviluppo delle proprie applicazioni. È utile ricordare che nell'ambito del progetto OpenPDD, descritto nel paragrafo 4.2.3, si è cercato di intraprendere questa strada definendo un'interfaccia Open Source della PDSA. 5.2 Architettura di OpenSPCoop Il modello architetturale su cui si basa OpenSPCoop ha una struttura federativa che, compatibilmente con le specifiche di SPCoop e in conformità agli standard di mercato aperti e consolidati, offre: le funzionalità ed i servizi necessari affinché diversi enti ed amministrazioni dotate di infrastrutture informatiche proprie possano scambiarsi informazioni in modo controllato e sicuro; le modalità per realizzare la cooperazione applicativa rendendo possibile l'erogazione e la fruizione di servizi tra le amministrazioni afferenti al sistema. Il modello logico a cui si è fatto riferimento nella progettazione di OpenSPCoop è rappresentato in figura 5.1, dove ogni infrastruttura informatica delle varie amministrazioni è vista come un dominio vincolato ai meccanismi standard di interfacciamento. Per garantire l'interfacciamento dei sistemi legacy, ogni dominio dovrà utilizzare un componente di integrazione con funzione di adapter, il cui compito 107

109 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione è di rendere disponibili i servizi già attivi e funzionanti presso la specifica amministrazione. A tale proposito sono stati definiti due nodi funzionali che fungono rispettivamente da componente di cooperazione e da componente di integrazione della Porta di Dominio dei Servizi Applicativi. Il componente di integrazione prende il nome di NINT, mentre quello di cooperazione prende il nome di NCOOP: i nodi di integrazione (NINT) rendono accessibili i servizi applicativi di un dominio, integrando eventuali sistemi di adattamento (adapter); tali nodi possono offrire servizi in modo autonomo oppure attraverso un nodo di cooperazione; i nodi di cooperazione (NCOOP) costituiscono degli aggregatori di servizi, rendendo fruibili i servizi erogati dalle amministrazioni a cui fornisce accesso alla piattaforma e gestendo i servizi di supporto all'interoperabilità. Figura 5.1. Struttura logica di riferimento In effetti un NCOOP funge da componente di cooperazione della Porta di Dominio dei Servizi Applicativi per tutti gli NINT registrati su quel NCOOP, mentre in SPCoop è previsto un elemento di cooperazione e un elemento di integrazione in ogni PDSA. Questo tipo di ottimizzazione, che prevede l'aggregazione su un unico punto di tutte le 108

110 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione componenti di cooperazione dello stesso Dominio di Cooperazione è legato a una diffusa esigenza di economia di scala a livello regionale o di altre aggregazioni di più amministrazioni. Per le interazioni tra NCOOP ed NINT e tra NINT e NCOOP vengono utilizzati esclusivamente Web Services. Ogni NCOOP prevede una porta di accesso attraverso la quale gli NINT inviano le proprie richieste applicative utilizzando il protocollo SOAP. In caso di comunicazione tra NCOOP e NINT, il NCOOP, che ha ricevuto una busta egov, la deve aprire e consegnarne il contenuto applicativo al NINT; anche per questo motivo vengono usati dei Web Services di interazione. Quindi il NINT deve esporre una interfaccia Web Services per la specifica applicazione per cui è stata invocata dal NCOOP. L'interazione tra due NCOOP è più semplice, in quanto prevede solo uno scambio di buste, senza che entri mai in gioco il componente di integrazione. Già da questa introduzione al sistema, risulta evidente che il componente essenziale nell'architettura OpenSPCoop è NCOOP, al quale sono delegate tutte le funzionalità di cooperazione. Il nucleo di base di NCOOP e di tutto il sistema di cooperazione è il Proxy Applicativo, che si occupa di filtrare tutte le richieste applicative per realizzare le funzioni di sicurezza (attraverso processi di autenticazione e di autorizzazione) e di tracciamento, interagendo con appositi servizi esterni. Il Proxy Applicativo può ricevere: 1. richieste web in formato HTTP/HTTPS, in arrivo da utenti finali collegati al sistema tramite browser o altro device interattivo; 2. richieste Web Services in formato busta SOAP, in arrivo da applicazioni, come ad esempio un Portale, che richiedono un servizio Web tramite il Proxy Applicativo (uso di Porte Delegate in terminologia SPCoop); 3. richieste Web Services in formato busta e-gov, per servizi Web pubblicati sul NCOOP per conto dei NINT afferenti al Dominio di Cooperazione del NCOOP 109

111 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione (Porte Applicative in terminologia SPCoop) o per altri NCOOP più interni. Le richieste HTTP/HTTPS (punto 1) e quelle Web Services (punti 2 e 3) sono gestite da due sottosistemi diversi del Proxy Applicativo: il Proxy Redirector (PR), sostanzialmente un Proxy HTTP basato su tecnologia Squid; il Proxy dei Servizi Web (PSW), il componente che si occupa di gestire la funzionalità di base di ridirezione delle richieste verso i servizi interni e quelle aggiuntive, previste come servizi del NCOOP (sicurezza e tracciamento) per tutte le richieste di tipo Busta SOAP e Busta e-gov. Figura 5.2. Architettura di un Nodo di COOPerazione (NCOOP) La figura 5.2 mostra l'architettura di NCOOP mettendo in evidenza le componenti del Proxy Applicativo e le interazioni con i servizi di base di NCOOP. È interessante notare come tutte le richieste giungono comunque al PR, sfruttando così implicitamente anche le sue funzionalità di web caching. Poi, in funzione del profilo del servizio acceduto, il Proxy Redirector decide se girare la richiesta al PSW o gestirla direttamente, come specificato nel paragrafo seguente. 110

112 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione Il Proxy Redirector Il Proxy Redirector (PR), come rappresentato nella figura 5.3, è costituito da un proxy Squid (le cui caratteristiche sono descritte nel paragrafo 5.3.4), che utilizza un plugin di autenticazione e uno di autorizzazione per interrogare i rispettivi servizi del NCOOP per accettare o meno la richiesta ricevuta. Figura 5.3. Architettura del Proxy Redirector La Tabella 5.1 elenca e descrive le funzionalità supportate dal Proxy Redirector. Funzionalità Funzionalità di ridirezione HTTP Funzionalità di Web Cache Supporto per l Autenticazione Supporto per l Autorizzazione Descrizione Capacità di pubblicazione sul NCOOP di portali web degli Enti locali; in questo caso funge da proxy HTTP, configurato in modalità di Accelerator. Accetta cioè richieste HTTP, come se si trattasse di un vero e proprio Server Web, rigirandole poi al Server Web reale dell NINT che ha registrato quel servizio. Il proxy, anche se configurato in modalità Accelerator, fornisce le funzionalità di cache tipiche di un proxy HTTP. Il proxy, per le sole tipologie di servizio per cui è stato richiesto, si interfaccia al sistema di Sicurezza per effettuare l autenticazione degli utenti. Il proxy, per le sole tipologie di servizio per cui è stato richiesto, si interfaccia al sistema di Sicurezza per effettuare l autorizzazione degli utenti. 111

113 Tabella 3.2. Compiti del mittente e del destinatario del messaggio ai livelli servizio, porta e connessione Supporto per il Tracciamento Il proxy agisce come componente essenziale del sistema di tracciamento, fungendo da sensore per le seguenti tipologie di eventi: Risorsa richiesta Soggetto che ha effettuato la richiesta Data arrivo richiesta Data completamento della risposta Esito della operazione Informazioni sullo stato del sistema Tabella 5.1. Funzionalità del Proxy Redirector Il Proxy dei Servizi Web Il Proxy dei Servizi Web (PSW) è il componente che si occupa di gestire le funzionalità di base della Busta di e-gov: funzionalità di Porta Applicativa, per cui riceve buste di e-gov relative a servizi ospitati da NINT registrati sul NCOOP e si occupa di consegnarne il contenuto al NINT; funzionalità di Porta Delegata, in cui riceve buste SOAP per i servizi per cui funge da proxy di accesso per i NINT registrati e si occupa di inviarli al destinatario corretto, dopo averle trasformate in buste e-gov; funzionalità di relay, in questo caso il PSW si limita ad inoltrare le buste e-gov ricevute ad un altro NCOOP. Figura 5.4. Proxy dei Servizi Web 112

114 Tabella 5.1. Funzionalità del Proxy Redirector Per ogni busta SOAP o e-gov in transito, il PSW interagisce con i servizi del NCOOP per gestire le funzionalità di Sicurezza (autenticazione e autorizzazione), e quelle di Tracciamento. Un ruolo essenziale è quello assunto dai registri UDDI, interrogati durante il trattamento delle buste, per individuare i corretti destinatari di ogni servizio. Come evidenziato in figura 5.4, esistono due registri UDDI, uno privato e uno pubblico. Ogni servizio registrato sul NCOOP viene configurato sia sul registro privato che su quello pubblico, con due indirizzi diversi, accessibili rispettivamente al NINT e agli altri interlocutori esterni al Dominio di Cooperazione. Il sistema PSW è strutturato, dal punto di vista funzionale, in 3 componenti: Web Services Gateway Registri dei Servizi Gestione della Busta e-gov Nella Tabella 5.2 sono elencate e descritte le funzionalità di ogni componente. Web Services Gateway 113

115 Tabella 5.1. Funzionalità del Proxy Redirector Routing di Web È la funzionalità principale del componente, consiste nella Services capacità di recepire dinamicamente una richiesta di servizio web, indipendentemente dalla disponibilità di uno skeleton specifico per quel servizio. Si tratta di una funzionalità analoga alla funzionalità di Dynamic Skeleton Interface dell architettura CORBA [83], dove il ruolo dell Interface Repository CORBA è giocato, nell architettura OpenSPCoop, dai registri UDDI. Registri dei Servizi Registro UDDI Il sistema fornisce un registro UDDI privato del Dominio di Privato Cooperazione del NCOOP; questo registro supporta la cooperazione tra il NCOOP e i NINT registrati su quel NCOOP; i servizi pubblicati su questo registro UDDI, sono raggiungibili solo all interno del Dominio di Cooperazione del NCOOP; si noti che lo stesso servizio potrebbe anche essere direttamente raggiungibile dall esterno del Dominio di Cooperazione, tramite un binding, registrato su un altro registro UDDI pubblico. Registro UDDI Il sistema fornisce un registro UDDI pubblico del Dominio di Pubblico Cooperazione del NCOOP; questo registro supporta la cooperazione tra il NCOOP ed altri NCOOP esterni al Dominio di Cooperazione; questo registro è in generale utilizzato dal solo NCOOP e non dai NINT, che usano invece Porte Delegate del NCOOP, registrate presso il registro UDDI privato del Dominio di Cooperazione. Registrazione e Le applicazioni client, interrogando (mediante il protocollo SOAP) il Ricerca server UDDI, possono identificare il fornitore di uno specifico servizio web e interpretare automaticamente le modalità di interazione con esso, grazie all elaborazione della sua descrizione nel formalismo WSDL. Le principali strutture dati di base gestite nei registri UDDI del NCOOP sono: businessentity: contiene informazioni sull Ente fornitore del servizio web, ad esempio il nome dell'ente o del reparto, la categoria associata alla sua attività, la sua localizzazione geografica, il riferimento per un contatto, etc.. businessservice: assolve la funzione di contenitore logico per un insieme di servizi tra loro in relazione. Questa struttura funge da contenitore per una o più istanze di tipo bindingtemplate. bindingtemplate: fornisce le informazioni necessarie per invocare uno specifico servizio web, come ad esempio la sua URL. Contiene riferimenti ad una o più strutture tmodel. tmodel: contiene le informazioni sulle interfacce di uno specifico servizio web. Ad ogni documento WSDL corrisponderà perciò un istanza di tmodel nei registri UDDI. 114

116 Tabella 5.1. Funzionalità del Proxy Redirector Semantica dei Servizi I servizi presenti sul registro UDDI mediante una o più tassonomie condivise, gestite tramite un servizio standard di categorizzazione condiviso da ogni applicativo dell infrastruttura. Tramite le tassonomie sarà possibile mappare in modo unico e in maniera precisa ed efficace l universo dei servizi registrati sul NCOOP. In questo modo si potrà arricchire la descrizione sintattica dei Web Services in modo formale ed omogeneo, aggiungendo conoscenze semantiche che aprono interessanti possibilità di sfruttamento dei servizi in un contesto di Semantic Web. Gestione Buste e-gov Funzionalità di Validazione, etc. Porta Applicativa Funzionalità di Il PSW, per le richieste di servizio per cui è stato registrato come Porta Delegata Porta Delegata, si occupa di identificare il destinatario della richiesta nel registro UDDI, e di trasformare la richiesta SOAP in Busta e-gov, aggiungendo anche, quando richiesto, le necessarie credenziali di sicurezza. Supporto per Il PSW, per le sole tipologie di servizio per cui è stato richiesto, si l Autenticazione interfaccia al sistema di Sicurezza per verificare l autenticazione degli utenti secondo gli header standard WS-Security e/o del CNIPA. Supporto per Il PSW, per le sole tipologie di servizio per cui è stato richiesto, si l Autorizzazione interfaccia al sistema di Sicurezza per verificare l autorizzazione del richiedente, identificato durante il processo di autenticazione, all utilizzo del servizio richiesto. Supporto per il Il PSW agisce come componente essenziale del sistema di Tracciamento tracciamento, fungendo da sensore per le seguenti tipologie di eventi: Risorsa richiesta, vengo loggati i seguenti campi della busta egov: o Destinazione; o Servizio; o Azione; Mittente della richiesta Identificativo Unico della Richiesta Data arrivo della richiesta Data consegna della richiesta Destinatario a cui la richiesta è stata consegnata (NINT o altro NCOOP) Tipologia della Richiesta 115

117 Tabella 5.1. Funzionalità del Proxy Redirector Supporto Architettura SOA Supporto Architettura EDA Implementazione completa di un Event Service compatibile con le specifiche della busta e-gov, con modalità di funzionamento Publish and Subscribe e Point to Point. Tabella 5.2. Funzionalità del Proxy dei Servizi Web Gestione della sicurezza Il Servizio di Sicurezza è un servizio essenziale del NCOOP, costruito aggregando i migliori software Open Source oggi disponibili sul mercato per realizzare funzionalità di Public Key Infrastructure (PKI) [84], autenticazione e autorizzazione federata. Da un punto di vista di architettura generale, è utile analizzare le interazioni principali in gioco a livello di macrocomponenti, evidenziate in rosso nella figura 5.5. Figura 5.5. Flusso applicativo nel processo di Gestione di Sicurezza La figura 5.5 evidenzia l interazione tra il Portale dell Ente e il Servizio di Sicurezza del NCOOP per scambiarsi informazioni relative agli utenti già autenticati dal NCOOP. In tal modo, la prima volta che l'utente (o l applicazione) accedono a un servizio pubblicato sul NCOOP, la richiesta viene ridiretta sul servizio di autenticazione federata del NCOOP; una volta autenticata, la richiesta dell'utente, marcata con uno 116

118 Tabella 5.2. Funzionalità del Proxy dei Servizi Web speciale token di accesso, viene ridiretta al portale web a cui era diretta. Quest ultimo dialoga con il Servizio di Sicurezza del NCOOP per verificare le autorizzazioni dell'utente a cui è associato il token ricevuto. A questo punto, può anche essere lo stesso portale a decidere in funzione delle proprie policy se consentire o meno l'operazione richiesta. Le principali funzionalità del sistema per quanto riguarda i servizi offerti dal sottosistema per la gestione della sicurezza sono elencate di seguito, suddivise per i diversi componenti software utilizzati: Controllo Accessi o servizio di certificazione di identità, o sottosistema di time stamp per la certificazione del tempo, o servizio di directory per certificati e credenziali, o gestione delle identità, o gestione dei certificati, Monitoraggio e Auditing Gestione della tracciabilità Il Modulo di Gestione Tracciabilità è il servizio del NCOOP che si occupa di collezionare tutte le informazioni di rilievo relative a transazioni avvenute sui sistemi in vario modo afferenti al NCOOP. Da un punto di vista di architettura generale, è utile analizzare le interazioni principali in gioco a livello di macrocomponenti, evidenziate in rosso nella figura 5.6. Figura 5.6. Flusso applicativo nel processo di Gestione della Tracciabilità 117

119 Tabella 5.2. Funzionalità del Proxy dei Servizi Web È interessante notare che non soltanto i componenti del NCOOP, ma anche i Portali e gli NINT, opportunamente autorizzati, possono agire da sensori per il Modulo di Tracciabilità, in modo da poter eventualmente tracciare anche le operazioni di accesso diretto all Ente Locale che non transitano dal NCOOP. Le principali funzionalità del Modulo Gestione Tracciabilità sono elencate nella Tabella 5.3. Tracciare sia gli utenti che i sistemi Gestione centralizzata Archiviare i log Log legati al sistema di autenticazione È possibile tracciare qualsiasi tipo di evento relativo sia ad utente che sistemi, attraverso il protocollo standard syslog che permette di catturare record di tracciamento da ogni sistema. La gestione avviene in un unico punto, l applicazione di Analisi e Gestione dei dati di tracciamento. I log sono memorizzati principalmente nel database centrale nel quale vengono archiviati e rimossi dopo un tempo prestabilito seguendo le politiche di archiviazione sicura del database centrale. Il modulo di tracciabilità effettua una correlazione dei log provenienti da tutti i sistemi e in particolare dal sistema di Gestione Sicurezza e dal suo sottosistema di autenticazione e autorizzazione. 118

120 Tabella 5.2. Funzionalità del Proxy dei Servizi Web Analisi dei dati nel sistema centrale L analisi dei log avviene tramite una applicazione web protetta con possibilità di definire i diversi ruoli per il suo utilizzo. È possibile agire sui report predefiniti e crearne di nuovi, oltre che applicare filtri e ed effettuare ricerche fini. Tabella 5.3. Funzionalità del Modulo Gestione Tracciabilità 5.3 Le componenti software e le loro funzionalità Come descritto nell'introduzione al presente capitolo, per la progettazione di OpenSPCoop si è scelto di adottare esclusivamente prodotti Open Source. Nei prossimi paragrafi presenteremo analiticamente le caratteristiche ed il ruolo dei singoli prodotti utilizzati necessari alla realizzazione dell infrastruttura di base di cooperazione: Sistema Operativo: Linux, Proxy HTTP: Squid [85], Application Server: JBoss [86], SOAP Engine: Axis [87], UDDI Server: Apache juddi [88], UDDI Java API: UDDI [89], Server LDAP: OpenLDAP [90], Si tratta di prodotti estremamente maturi, tutti caratterizzati da quelle proprietà di stabilità, efficienza e flessibilità tipiche dei progetti Open Source di maggior successo. Nell insieme questi prodotti offrono una soluzione completa, schematizzata nella figura 5.7, per la realizzazione del NCOOP, completamente riutilizzabile per scalare localmente le caratteristiche di NCOOP ed eventualmente anche per la realizzazione dei NINT. Figura 5.7. Infrastruttura di cooperazione applicativa realizzata da OpenSPCoop 119

121 Tabella 5.3. Funzionalità del Modulo Gestione Tracciabilità OpenSPCoop OpenSPCoop si configura come un servlet all interno di un Application Server, in attesa di ricevere richieste applicative tramite HTTP o anche tramite altri protocolli di trasporto, usando il SOAP Engine Axis per il trattamento dei messaggi SOAP. Punto di forza dell architettura di OpenSPCoop è il disaccoppiamento totale della componente di ricezione e consegna delle buste da quella di controllo e gestione delle buste SOAP/e-Gov in transito, tramite l uso di code persistenti per il mantenimento dei messaggi. L architettura generale di OpenSPCoop è schematizzata in figura 5.8. Figura 5.8. Architettura generale di OpenSPCoop 120

122 Tabella 5.3. Funzionalità del Modulo Gestione Tracciabilità L architettura evidenzia le seguenti macrocomponenti: 1. il Modulo di Check-in, componente che si occupa di ricevere le richieste provenienti da altri NCOOP o dai NINT del proprio Dominio di Cooperazione e di effettuare, per ogni richiesta, eventuali controlli di autenticazione ed autorizzazione a livello di trasporto. Se la richiesta supera i controlli di validità, il componente si occupa di inserirla nella coda Buste in arrivo; 2. il Modulo di Controllo, preleva le richieste dalla coda Buste in arrivo e, per ogni richiesta, analizza l header della busta, ricavando i riferimenti del mittente e del destinatario; interroga il Registro UDDI Privato ed il Registro UDDI Pubblico per determinare l indirizzo cui destinare la richiesta. Quindi, attraverso il database Servizi Gestiti ed il Registro UDDI Privato, determina quali controlli di autorizzazione e di autenticazione debba applicare alla busta; se il contenuto dell header della busta supera tutti i controlli di sicurezza, il componente determina, in funzione del destinatario, su quale coda inserire la richiesta: se il destinatario è un altro NCOOP, viene inserita nella coda Buste per Destinatari ExtraDominio; se il destinatario è un NINT interno al Dominio di Cooperazione, viene inserita nella coda Busta per Destinatari IntraDominio; 3. il Modulo di Check-out per Destinatari ExtraDominio, questo componente ha il compito di inviare le richieste in attesa di essere spedite ad altri NCOOP, 121

123 Tabella 5.3. Funzionalità del Modulo Gestione Tracciabilità utilizzando la coda in uscita Buste per Destinatari ExtraDominio; il componente preleva una busta dalla coda Buste per Destinatari ExtraDominio e interroga il Registro UDDI Pubblico per determinare l indirizzo del destinatario a cui inviare la richiesta; 4. il Modulo di Check-out per Destinatari IntraDominio, questo componente ha il compito di inviare le richieste in attesa di essere spedite ai NINT che fanno parte dello stesso Dominio di Cooperazione; il componente preleva una busta dalla coda Buste per Destinatari IntraDominio, interroga il Registro UDDI Privato per determinare l indirizzo del destinatario a cui inviare la richiesta Richieste per servizi interni al Dominio di Cooperazione (gestione Porta Applicativa) Quando il NCOOP assume funzione di Porta Applicativa, il Modulo di Check-in riceve richieste in formato Busta di e-gov da parte di altri NCOOP. L architettura di OpenSPCoop, in questo caso, è schematizzata in figura 5.9. Figura 5.9. Gestione delle Porte Applicative nell'architettura OpenSPCoop 122

124 Tabella 5.3. Funzionalità del Modulo Gestione Tracciabilità Se la richiesta è diretta ad un NINT che fa parte dello stesso Dominio di Cooperazione, il Modulo di Controllo, nel caso in cui vengano superati con successo i controlli di sicurezza, si occupa di prelevare la richiesta dalla Busta di e-gov e di generare una busta in formato SOAP da inviare al destinatario Richieste per servizi esterni al Dominio di Cooperazione (Porta Delegata) Quando il NCOOP assume la funzione di Porta Delegata, il Modulo di Check-in riceve richieste applicative in formato busta SOAP da parte dei NINT che fanno parte dello stesso Dominio di Cooperazione. L architettura di OpenSPCoop, in questo caso, è schematizzata in figura Figura Gestione delle Porte Delegate nell'architettura OpenSPCoop Se la richiesta è diretta ad un destinatario che si trova al di fuori del Dominio di Cooperazione, il Modulo di Controllo, nel caso in cui vengano superati con successo i controlli di sicurezza, si occupa di creare una Busta di e-gov a partire dalla busta in formato SOAP, dopodiché la inserisce nella coda Buste per Destinatari ExtraDominio. 123

125 Tabella 5.3. Funzionalità del Modulo Gestione Tracciabilità Requisiti critici della Busta e-gov La busta e-gov prevede alcune caratteristiche che hanno un significativo impatto sull architettura del NCOOP. I requisiti più significativi da questo punto di vista sono: 1. gestione dei duplicati; 2. gestione delle sequenze nell ambito di una Collaborazione Applicativa; 3. gestione dei riscontri, alla ricezione dei messaggi; 4. gestione del tracciamento del messaggio; 5. gestione delle eccezioni. Vediamo come tali requisiti siano gestiti nell architettura OpenSPCoop. Requisito n.1: l implementazione di questa caratteristica si basa sul campo identificatore, previsto nella busta, che identifica univocamente ogni messaggio; il Modulo di Controllo, per tutte le buste che abbiano l attributo inoltro del campo profilo trasmissione settato a EGOV_IT_ALPIUUNAVOLTA (rif. Appendice A), si occupa di verificare che l identificatore della busta non risulti già ricevuto, interagendo con il Documentation Service, nel qual caso il messaggio verrebbe scartato. Requisito n. 2: il Modulo di Controllo, se l attributo conferma ricezione del campo profilo trasmissione della busta ha valore True, genera un messaggio ad hoc contenente nell elemento lista riscontri, il riscontro relativo al messaggio ricevuto. Quindi inserisce tale messaggio nell apposita coda in uscita. Requisito n. 3: il Modulo di Controllo si occupa di inserire nella lista trasmissioni le informazioni necessarie per determinare che tale busta è transitata attraverso la PDSA a cui appartiene il Modulo. Requisito n. 4: il Modulo di Controllo è in grado di verificare gli errori presenti nell header del messaggio nel completo rispetto delle specifiche della Busta di e-gov 124

126 Tabella 5.3. Funzionalità del Modulo Gestione Tracciabilità e di segnalare di conseguenza l opportuna eccezione Cooperazione per notifica di eventi in OpenSPCoop OpenSPCoop dispone di un servizio applicativo in grado di implementare il modello di cooperazione per eventi, che prevede lo scambio di messaggi al fine di comunicare il verificarsi di uno specifico evento. In figura 5.11 è schematizzato il flusso applicativo che si determina nell'architettura OpenSPCoop in uno scenario di cooperazione per notifica di eventi. Figura Flusso applicativo nello scenario di cooperazione per notifica di eventi 125

127 Tabella 5.3. Funzionalità del Modulo Gestione Tracciabilità In questo tipo di interazione, il messaggio, contenente informazioni relative alla modifica di un oggetto applicativo oppure alla nascita di un nuovo oggetto applicativo, viene inoltrato al sistema di gestione eventi, chiamato Modulo Gestore Eventi, che prende l'incarico di ricevere la notifica di eventi da parte di un originatore e di distribuirli ai destinatari. Il sistema consente di sfruttare il paradigma di comunicazione per eventi mettendo a disposizione più soluzioni di interazione. Per esempio, il consumatore può restare in attesa degli eventi inviati su iniziativa del gestore (logica push); può interrogare il gestore circa l arrivo di nuovi eventi a lui destinati (polling); può interrogare il gestore circa l arrivo di determinati tipi di eventi (polling selettivo); può segnalare al gestore la propria disponibilità a ricevere gli eventi a lui destinati (push sollecitato), oppure a ricevere solo certi tipi di eventi (push sollecitato e selettivo) Funzionalità supportate per la Cooperazione per Eventi Sottoscrizione: consente ad un ente di sottoscriversi alla ricezione di un evento fornendo i necessari parametri quali tipo di evento, protocollo per la notifica (HTTP/SOAP o SMTP), etc. Pubblicazione: consente di immettere un evento affinché sia propagato a chi è interessato a riceverlo. L operazione di Publishing consiste nell invio di un messaggio contenente informazioni quali tipo evento, evento XML, priorità etc. Inoltro: consente di inoltrare un evento ad uno o più enti che sono sottoscritti per ricevere la particolare tipologia di evento. Inoltro per competenza: consente di inoltrare un evento ad uno o più enti che non sono direttamente sottoscritti per ricevere la particolare tipologia di evento ma che lo devono ricevere per competenza. Notifica: consente di notificare ai sottoscrittori la presenza di un nuovo Evento per la classe di eventi sottoscritti. Il messaggio notificato dal Gestore ai sottoscrittori contenente informazioni quali tipo di evento, identificativo del messaggio, etc. Ricezione: consente di attivare la ricezione di un evento di cui si sia ricevuta una 126

128 Tabella 5.3. Funzionalità del Modulo Gestione Tracciabilità notifica. L operazione di Retrieve consiste nell invio di un messaggio contenente informazioni quali tipo di evento, identificativo del messaggio, etc. La figura 5.12 evidenzia il Modulo Gestore Eventi ed i flussi di comunicazione nei quali è coinvolto per la realizzazione delle funzionalità supportate per la Cooperazione per Eventi. Figura Flussi di comunicazione nella gestione della cooperazione per eventi I componenti interessati alla realizzazione della cooperazione per eventi sono i seguenti: Modulo di Check-in: riceve le richieste di pubblicazione (attraverso messaggi in formato SOAP), di sottoscrizione e di notifica (attraverso messaggi in formato Busta di e-gov) e ne verifica l integrità. Se un messaggio supera i controlli di integrità viene inserito nella coda Buste in Arrivo, altrimenti viene scartato. Modulo di Controllo: preleva i messaggi dalla coda Buste in arrivo ed effettua i controlli di sicurezza come nel caso di richieste di servizio, secondo le modalità descritte nel paragrafo precedente. Se un messaggio supera tutti i controlli viene 127

129 Tabella 5.3. Funzionalità del Modulo Gestione Tracciabilità inserito nella coda Buste Eventi. Modulo Gestore Eventi: preleva i messaggi di cooperazione per eventi dalla coda Buste Eventi e, in base all analisi dell header della busta, processa la richiesta. o Sottoscrizione: verifica attraverso il Registro UDDI privato che l ente richiedente abbia i permessi necessari ad iscriversi a quel determinato evento e, in caso positivo, memorizza la sottoscrizione ed i parametri per l invio delle notifiche nel Registro. o Pubblicazione: verifica che il mittente possa pubblicare un messaggio per la classe di evento specificata nell header e, in tal caso, si occupa di generare un messaggio di notifica per ogni sottoscrittore dell evento e di inserirlo in una delle apposite code in uscita. Analizzando il Registro UDDI privato, verifica che a quel determinato evento sono associati degli enti cui deve essere inoltrato per competenza il messaggio, si preoccupa di generare dei messaggi di inoltro per ogni ente e di inserirli nell apposita coda in uscita. o Notifica: verifica se il destinatario del messaggio è un NINT che fa parte del proprio dominio di cooperazione. In caso positivo genera un messaggio in formato SOAP contenente un messaggio di notifica e lo inserisce nella coda Buste per Destinatari IntraDominio. Se invece il destinatario è un altro NCOOP, inserisce il messaggio nella coda Buste per Destinatari ExtraDominio. o Ricezione: verifica se il mittente è sottoscrittore per l evento descritto nella richiesta e, in caso positivo, genera un messaggio di inoltro e lo inserisce nell apposita coda in uscita. Modulo di Check-out per Destinatari IntraDominio: si occupa di recapitare agli NINT che fanno parte del dominio di appartenenza i messaggi instradati dal Modulo Gestore Eventi attraverso la coda Buste per Destinatari IntraDominio. I messaggi in questione sono la notifica o l inoltro di un evento al quale il NINT è sottoscrittore. Modulo di Check-out per Destinatari ExtraDominio: si occupa di recapitare ad altri NCOOP i messaggi instradati dal Modulo Gestore Eventi attraverso la coda Buste 128

130 Tabella 5.3. Funzionalità del Modulo Gestione Tracciabilità per Destinatari ExtraDominio. I messaggi in questione sono la notifica o l inoltro per competenza Autorità di Registrazione dei Servizi Si tratta dell applicazione che gestisce il provisioning dei servizi del NCOOP. Dal punto di vista architetturale, l applicazione utilizzerà le API o accessi Web Services dei componenti dei Servizi di Sicurezza e del Registro per configurare i sistemi gestiti secondo le esigenze del Provisioning richiesto dagli utenti registrati come gestori. L architettura generale dell applicazione è quindi schematizzabile come rappresentato in figura Figura Architettura generale del componente di Autorità di Registrazione di Servizi Squid Il Modulo Proxy Redirector usa un proxy HTTP/HTTPS per intercettare le richieste verso i server applicativi e gestirne autenticazione e autorizzazione. Il proxy scelto per lo scopo è Squid. Squid è un caching proxy web ad alte prestazioni che supporta i protocolli FTP, 129

131 Tabella 5.3. Funzionalità del Modulo Gestione Tracciabilità Gopher e HTTP. Derivato dal progetto Harvest [91] è stato sviluppato in modo autonomo con licenza libera GNU GPL [92]. Squid utilizza sia il disco sia la RAM per gestire la cache nella maniera più efficiente possibile. In particolare, memorizza in RAM un indice per ciascun oggetto presente nella cache su disco. Gli oggetti sono suddivisi in tre tipi differenti, a ciascuno dei quali è associata una diversa priorità. Lo spazio riservato alla cache, sia in RAM sia su disco, è configurabile ed ha un'importanza critica per determinare le prestazioni del sistema. Inoltre è possibile configurare il tipo di algoritmo che decide la rimozione degli oggetti dalla cache. Nel progetto OpenSPCoop vengono sfruttate, oltre alla cache, le caratteristiche seguenti: Modalità accelerator (reverse proxy). In questa modalità il proxy intercetta le richieste destinate ai server applicativi, per poi inviarle dopo averle eventualmente processate ed autorizzate. Gateway SSL/TLS. In modalità accelerator, Squid è in grado di funzionare come terminatore di richieste SSL/TLS. Nella versione 3.0, può anche verificare i certificati dei client che effettuano le richieste. Autenticazione, realizzata tramite un programma esterno. Squid supporta nativamente tre tipi di credenziali: Basic, Digest e NTLM. Possibilità di riscrivere e discriminare tra le richieste sottoponendole ad un redirector esterno per la riscrittura e/o la verifica. Possibilità di collegarlo in gerarchie di proxy, in particolare di poter ridirigere le richieste, tutte o in parte, ad uno o più ulteriori proxy. Disponibilità di un sofisticato meccanismo di controllo degli accessi che può essere sfruttato, ad esempio, per decidere quali client, o quali richieste, sottoporre ad autenticazione e/o ad autorizzazione, o quali richieste ridirigere ad un ulteriore proxy, o quali oggetti mantenere in cache. L'utilizzo di Squid è estremamente diffuso grazie alla sua flessibilità ed anche alle sue 130

132 Tabella 5.3. Funzionalità del Modulo Gestione Tracciabilità prestazioni. Nella valutazione delle prestazioni va tenuto conto anche del fatto che è possibile realizzare soluzioni in load balancing, oltre che ridondate per ottenere fault tolerance. Tutte le caratteristiche di funzionamento di Squid sono monitorabili via SNMP (Simple Network Management Protocol) [93] e anche tramite l'elaborazione dei log di accesso, tramite strumenti standard L'Application Server e gli altri Componenti dell'infrastruttura di cooperazione Le considerazioni esposte nelle sezioni precedenti ed i flussi applicativi descritti in questo stesso capitolo spingono a definire per la realizzazione del NCOOP un architettura che unisca i vantaggi di un approccio orientato ai servizi a quello event-driven. La soluzione scelta deve quindi supportare a pieno queste due filosofie architetturali e al contempo fornire gli strumenti per gestire in modo efficiente il deploy, il monitoraggio e l amministrazione a run-time delle applicazioni. A tale scopo si è scelto l utilizzo di un application server Java J2EE capace di integrare in un unica architettura: un Message Oriented Middleware (MOM) per gestire servizi di messaging implementati nel rispetto dello standard Java Message Service (JMS); un motore per l esecuzione di web services, conformi allo standard SOAP; un servizio di registry UDDI per i web services. Oltre a ciò un application server offre delle funzionalità di base che garantiscono la scalabilità degli applicativi, il supporto alla transazionalità e alla persistenza, la sicurezza, insieme ad avanzate funzionalità per la gestione e il monitoraggio, con meccanismi standard, dell intero sistema: tutto ciò concorre a realizzare un architettura flessibile, sicura e robusta, che rappresenta lo stato dell arte della tecnologia attuale. Il sistema di cooperazione applicativa è progettato utilizzando soluzioni basate sull architettura Java J2EE e Open Source. In particolare il prodotto scelto come 131

133 Tabella 5.3. Funzionalità del Modulo Gestione Tracciabilità application server J2EE è JBoss. Il sistema è stato il primo application server Open Source ad essere certificato compatibile con gli standard J2EE dai laboratori SUN Microsystems. JBoss è la soluzione perfetta per realizzare l architettura descritta perché ingloba i due moduli JBoss.Net (rinominato JBossWS nella più recente implementazione di JBoss), per la gestione dei Web Services, e JbossMQ [94], un implementazione dello standard JMS per la realizzazione di applicazioni Java message oriented. JBossWS a sua volta è basato su tecnologie Open Source facenti parte della suite Apache, ovvero Axis per la gestione dei Web Services SOAP e juddi per la realizzazione della registry UDDI. Questi applicativi, grazie alla loro aderenza agli standard dei web services, possono interagire in modo trasparente con altre implementazioni di librerie SOAP e UDDI, che siano compliant con gli standard SOAP 1.1 e 1.2, WSDL 1.1 e UDDI 2.0. Nei paragrafi che seguono sarà presentato in dettaglio ogni prodotto proposto, iniziando con una breve descrizione delle funzionalità di JBoss. Per completezza di esposizione si preferisce dare una presentazione dettagliata di Axis e juddi anziché parlare genericamente della componente JBossWS. Questo è particolarmente utile per Axis, visto che questo software viene utilizzato per realizzare i servizi web dei sistemi da integrare nell architettura complessiva del NCOOP (servizi web che possono andare in esecuzione all interno di JBoss o direttamente in sistemi esterni al di fuori della componente di cooperazione applicativa). Infine si espongono le caratteristiche della componente JBossMQ che permette di realizzare un MOM conforme alla tecnologia JMS L'Application Server JBoss JBoss è caratterizzato da un architettura modulare, altamente scalabile, clusterizzabile su più server, basata sui seguenti quattro strati o layer: Microkernel layer: è il cuore del sistema. È caratterizzato da un occupazione di risorse ( footprint ) estremamente ridotta per garantire delle performance ottimali. Questo strato è basato sulla tecnologia Java JMX (Java Management Extension) 132

134 Tabella 5.3. Funzionalità del Modulo Gestione Tracciabilità [95] che garantisce un alta modularità all intero sistema. Services layer: è lo strato dove risiedono i servizi applicativi di base forniti dal sistema (ad esempio funzionalità di clustering, caching, monitoring, persistenza, supporto alle transazioni, etc.). È estremamente facile aggiungere nuovi servizi a questo strato: allo stesso tempo è possibile eliminare quelli non utilizzati in una particolare implementazione, in modo da ridurre l occupazione complessiva di risorse. In particolare per quanto riguarda il monitoring è disponibile il supporto al protocollo SNMP per il controllo del funzionamento dell application server con strumenti di monitoraggio standard. Aspect layer: è lo strato che interfaccia i servizi di base forniti nel Services Layer per poterli utilizzare con facilità nello strato application. Questo strato abilita inoltre lo sviluppo di applicazioni secondo il moderno paradigma dell Aspect Oriented Programming (AOP) [96], mediante il quale è possibile estendere le funzionalità di classi Java in modo semplice e trasparente per il programmatore. L Aspect Oriented Programming si basa sul concetto della separazione delle responsabilità (ovvero delle funzionalità) fra varie classi Java, che vengono poi estese combinando le funzionalità di ciascuna classe e senza necessità di ulteriori modifiche al codice, in modo da ottenere l applicazione finita richiesta. Questo è particolarmente utile per riutilizzare codice Java già esistente che inizialmente non era stato progettato e sviluppato per essere utilizzato in un application server J2EE. Application layer: è lo strato dove risiedono le applicazioni sviluppate, che possono sfruttare tutti i servizi e le feature dei layer sottostanti. La figura 5.14 schematizza l architettura appena descritta. 133

135 Tabella 5.3. Funzionalità del Modulo Gestione Tracciabilità Figura Architettura dell'application server Jboss Oltre che sul nucleo principale, lo sviluppo di JBoss si è concentrato, nell ambito di una serie di sottoprogetti, alla realizzazione di estensioni del server che coprono alcune specifiche funzionalità. Fra questi sottoprogetti, oltre ai già citati JBoss.Net/JBossWS e JBoss MQ, vale la pena di citare JBoss/Web, che copre l integrazione con Apache Tomcat [97] per l esecuzione di servlet e pagine JSP; JBossClustering, per implementare politiche di alta affidabilità e ridondanza mediante un insieme ricco di possibili soluzioni e strategie e JBossCache, una cache di dati replicata e transazionale le cui funzionalità, grazie all AOP, possono essere associate a classi Java preesistenti SOAP Server: Apache AXIS Axis è un prodotto della suite Apache Web Services [98], estremamente maturo, 134

136 Tabella 5.3. Funzionalità del Modulo Gestione Tracciabilità giunto ormai alla terza generazione di rilasci. Consente di sviluppare servizi web SOAP, sia lato client ma soprattutto server-side. In questo caso il servizio consiste di un applicazione Java J2EE, in esecuzione in un servlet engine (come ad esempio Apache Tomcat), che gestisce le richieste SOAP, processa i messaggi trasformando i dati dal formato XML ad opportuni oggetti Java e inoltra la richiesta verso l applicazione che implementa la business logic del servizio web. Quando questa ha completato il proprio lavoro il server traduce i dati di ritorno in XML e li impacchetta in una risposta SOAP che restituisce al chiamante. Axis è basato su un architettura modulare che elabora i messaggi SOAP tramite una pipeline configurabile di moduli software come mostrato in figura Figura Pipeline di elaborazione dei messaggi SOAP di Axis In questo modo si ottiene un architettura estremamente flessibile caratterizzata da: indipendenza dal trasporto: il core del framework è completamente separato dal trasporto. Questo permette di gestire scambio di messaggi SOAP su più protocolli di comunicazione come HTTP(S), JMS, socket TCP/IP, tutti supportati nativamente, ed è aperto per realizzare listener per gestire altri protocolli come SMTP, FTP, etc. estendibilità: è possibile definire dei plug-in per realizzare elaborazioni ad-hoc del 135

137 Tabella 5.3. Funzionalità del Modulo Gestione Tracciabilità messaggio component-oriented deployment: la pipeline di elaborazione viene definita mediante un file di configurazione e può essere facilmente adattata (per esempio cambiando il protocollo di trasporto o inserendo un altro modulo software che esegue un particolare processamento del messaggio) senza la necessità di modificare il codice sorgente del servizio SOAP. Axis supporta automaticamente la conversione dei tipi di dato base SOAP/WSDL a oggetti Java, consente la trasformazione automatica di un istanza di JavaBean in XML (serializzazione) e viceversa (deserializzazione) e gestisce la trasformazione da oggetti Java di tipo Collection ad Array SOAP. Fornisce inoltre dei tool per costruire automaticamente scheletri di classi Java a partire da definizioni WSDL di servizi web remoti; viceversa, permette inoltre di generare automaticamente le descrizioni WSDL dei servizi web implementati. Infine Axis garantisce performance ottimali in quanto fa uso della tecnologia SAX [99] per il parsing dei dati ricevuti in formato XML. Axis fornisce pieno supporto alle più recenti tecnologie dei Web Services, in particolare: SOAP 1.1 e 1.2; SOAP with Attachments, estensione che supporta il trasferimento di file binari (ad esempio multimediali) in attachment a messaggi SOAP; WSDL 1.1; API per la gestione dei Java Web Services. Axis fornisce anche delle librerie di API per costruire facilmente delle applicazioni client SOAP. Sono disponibili sia per il linguaggio Java che, in un implementazione parziale, per il C++, quest ultima per piattaforme Linux e Micorsoft Windows UDDI Registry: Apache juddi Il server, o registry, UDDI rappresenta il cuore dell infrastruttura di interoperabilità realizzata mediante Web Services. Per l implementazione del registry UDDI si propone ancora una volta una soluzione 136

138 Tabella 5.3. Funzionalità del Modulo Gestione Tracciabilità basata su un prodotto Open Source della suite Apache Web Services. Si tratta di juddi, un software maturo, estremamente affidabile, utilizzato in produzione in vari contesti mission-critical. juddi supporta la versione 2.0 del protocollo UDDI, si appoggia in maniera trasparente via JDBC ad un larghissimo numero di database relazionali (tra cui Oracle, DB2, MySQL, Postgres, etc.) e supporta una configurazione cluster per realizzare delle soluzioni ad alta affidabilità. Il servizio è implementato tramite servlet Java, compatibili con i più diffusi application server presenti nel mercato: per la realizzazione del NCOOP si gestirà il deploy di juddi sull application server JBoss. Citiamo infine che per lo sviluppo di applicazioni Java, sia client che server, che interagiscono con il registry UDDI verranno utilizzate le librerie UDDI4J, anch esse Open Source Message Oriented Middleware: JbossMQ JBossMQ è la componente dell application server JBoss che implementa le funzionalità di un message oriented middleware compatibile con la tecnologia Java JMS versione 1.1. Con questa tecnologia è possibile implementare i due modelli di comunicazione tipici dei MOM, ovvero il publish & subscribe (pub/sub) e il point-topoint (p2p), realizzati rispettivamente mediante le classi Java Topic, a cui il consumatore si aggancia creando una Subscription, e Queue. 137

139 Tabella 5.3. Funzionalità del Modulo Gestione Tracciabilità Figura Implementazioni JMS dei paradigmi publish & subscribe e point-to-point Il sistema permette di implementare il paradigma store-and-forward nello scambio dei messaggi, in modo da garantirne il delivery: in questo caso il messaggio generato da un produttore non viene perso se il consumatore non è collegato al sistema (caso pub/sub) o in situazioni di fallimento o di restart del server (caso p2p). Questo obiettivo viene raggiunto marcando i messaggi scambiati come persistent e, nel caso publish & subscribe, creando delle sottoscrizioni durevoli (durable). Come da standard JMS, JBossMQ può garantire che uno scambio di messaggi avvenga in modalità transazionale: in questo modo, operazioni multiple di invio di messaggi, da parte di un produttore, o una sequenza di accessi in lettura, da parte di un consumatore, possono essere considerate come operazioni atomiche. JBossMQ inoltre permette di includere le operazioni sulle code in una transazione distribuita gestita dalle API Java JTA (Java Transaction API) [100]. Questo consente di realizzare 138

140 Tabella 5.3. Funzionalità del Modulo Gestione Tracciabilità degli scenari transazionali complessi come il two-phase commit, che rendono atomiche sequenze di operazioni effettuate su repository di dati distinti ed eterogenei (ad esempio un database relazionale e un MOM). L architettura sofisticata e modulare di JBoss ha permesso numerose estensioni nelle funzionalità di JBossMQ, tra cui: molteplici protocolli di trasporto: la comunicazione dei produttori e dei sottoscrittori con la piattaforma dei messaggi può avvenire tramite socket TCP/IP, RMI e HTTP e può essere ulteriormente estesa sviluppando degli adattatori per specifici protocolli un architettura modulare per la sicurezza, basata sulla tecnologia Java JAAS (Java Authentication and Authorization Service) [101] persistenza dei messaggi, implementata mediante l utilizzo di database relazionali, acceduti via JDBC, o tramite salvataggio dei dati su file system performance e alta affidabilità, grazie ai servizi di load balancing e clustering di JBoss. In dettaglio, nell architettura tecnica di JbossMQ, al livello logico più alto risiede l implementazione della tecnologia Java JMS, che si appoggia ad uno strato architetturale, denominato Invocation Layer, che soprintende alla comunicazione tra i provider e i consumer. In questo strato troviamo il Destination Manager, una componente che agendo da broker, riceve tutte le richieste pervenute al server e le smista alle varie altri componenti di JBossMQ, in particolare: le richieste di sottoscrizione vengono passate allo StateManager che ha il compito di mantenere aggiornate le informazioni sui consumatori sottoscritti ai vari topic definiti sulla piattaforma; i messaggi inviati dai producer (operazione send) vengono passati al JMSDestination; le richieste di ricezione dei consumer (operazione receive) vengono inoltrate al ClientConsumer, che è la componente responsabile del dispatch dei messaggi ai clienti. Come da standard JMS, le possibili destinazioni dei messaggi sono i topic (JMSTopic), nel caso pub/sub, o le code/queue (JMSQueue), per le comunicazioni 139

141 Tabella 5.3. Funzionalità del Modulo Gestione Tracciabilità p2p. Per le code esistono quattro possibili implementazioni: BasicQueue: l implementazione più semplice, usata ad esempio per realizzare code temporanee; PersistentQueue, che permette di realizzare scambio di messaggi persistenti secondo la metafora store & forward ; ExclusiveQueue: un ottimizzazione della BasicQueue usata per lo scambio di messaggi non persistenti; SelectorPersistentQueue: estende la PersistentQueue per permettere ai consumatori di ricevere solo alcune informazioni dalla coda, specificando le caratteristiche dei messaggi a cui vogliono essere sottoscritti. A tale proposito al momento della sottoscrizione essi specificano un message selector, ovvero un espressione che verrà valutata sulle proprietà e sui campi di intestazione (header) dei messaggi, ma non sul loro corpo. L architettura di JBossMQ è poi completata da altri moduli che forniscono dei servizi di base come la sicurezza (SecurityManager) e la persistenza (PersistenceManager). Da quanto appena detto si evince che il disegno di JBossMQ è elegante, altamente modulare, perfettamente compatibile con le specifiche Java JMS e perfettamente integrato con le funzionalità dell application server JBoss, in quanto costruito a partire dagli stessi building blocks. 5.4 Vantaggi rispetto alle soluzioni analizzate Come già spiegato nel paragrafo 4.2, non è possibile fare una comparazione tra il progetto OpenSPCoop e le soluzioni descritte nel capitolo 4 poiché si tratta di prodotti che realizzano soltanto parzialmente il paradigma di cooperazione applicativa; tuttavia la loro analisi ha consentito di valutare differenti soluzioni architetturali e tecnologiche e di ponderare con maggiore attenzione e con senso critico le scelte fatte durante la progettazione di OpenSPCoop. Il progetto CART, attualmente, è l'unico prodotto in uso nella Pubblica 140

142 Tabella 5.3. Funzionalità del Modulo Gestione Tracciabilità Amministrazione che realizza la cooperazione applicativa ma non soddisfa completamente le specifiche redatte dal CNIPA perché è basato sulle linee guida elaborate dalla Regione Toscana prima della pubblicazione di tali specifiche. Tuttavia, ha senso comparare le scelte tecnologiche e progettuali che esulano dalle specifiche organizzative e architetturali del CNIPA e che mostrano i vantaggi offerti da OpenSPCoop. La soluzione più innovativa e significativa presentata nel progetto OpenSPCoop è l'eliminazione della figura dei Proxy Applicativi, presenti sia nel progetto CART, sia nel progetto SOLE. Nell'ambito di CART i Proxy Applicativi rappresentano la componente di integrazione della PDSA e costituiscono applicazioni di dimensioni consistenti dotate di una propria logica applicativa basata sulle caratteristiche del servizio che devono gestire. In realtà, tale logica applicativa determina soltanto le modalità di imbustamento o estrazione del messaggio applicativo in funzione delle caratteristiche del servizio. Nella implementazione del progetto CART i Proxy Applicativi implementano una interfaccia Java (SOLE Facade), utilizzando quindi il framework di cooperazione applicativa come una libreria per effettuare i controlli di sicurezza (autenticazione e autorizzazione) ed imbustare/prelevare i messaggi applicativi. Nel progetto SOLE invece il Proxy Applicativo deve essere realizzato come un plugin Java attraverso una interfaccia standard per ogni categoria di sistemi, come descritto nel paragrafo Qualsiasi implementazione si scelga per realizzare i Proxy Applicativi, emerge uno scenario nel quale su ogni nodo applicativo, nel progetto CART rappresentato dalla figura del NAL, con il crescere del numero di servizi di cooperazione applicativa, sarà installato un numero sempre maggiore di Proxy Applicativi. Questa scelta determina l'impiego di risorse sia per la creazione di tali software sia per la loro manutenzione. Come mostra schematicamente la figura 5.17 il progetto OpenSPCoop elimina i Proxy Applicativi proponendo una architettura più semplice ed efficiente. Figura Confronto tra l'architettura dei nodi applicativi nel progetto CART e in OpenSPCoop 141

143 Tabella 5.3. Funzionalità del Modulo Gestione Tracciabilità Negli altri sistemi analizzati le amministrazioni inviano la richiesta di un servizio al Proxy Applicativo che si occupa di gestire tale servizio, dunque su ogni nodo applicativo esistono numerosi punti di integrazione. Ogni Proxy Applicativo riceve la richiesta e, dopo aver effettuato i controlli di sicurezza, imbusta la richiesta utilizzando gli header della busta di e-gov in funzione delle caratteristiche del servizio richiesto (nome del servizio, URL di destinazione, richiesta sincrona/asincrona, richiesta di servizio o notifica di evento, etc.). In Appendice B sono descritte le configurazioni che devono assumere gli header in funzione dei principali modelli di comunicazione. Invece nell'architettura OpenSPCoop ogni nodo applicativo (NCOOP) espone un unico punto di accesso che è utilizzato da qualsiasi applicazione presente sui nodi locali (NINT) per invocare un determinato servizio. La logica applicativa codificata in ogni Proxy Applicativo viene replicata all'interno del nodo in una tabella di corrispondenza che descrive le caratteristiche di ciascun servizio. In questo modo, una applicazione invoca un determinato servizio inviando la richiesta, via HTTP attraverso il protocollo 142

144 Tabella 5.3. Funzionalità del Modulo Gestione Tracciabilità SOAP, all'interfaccia di accesso esposta dal nodo applicativo; il framework OpenSPCoop processa la richiesta andando ad estrarre dalla tabella di corrispondenza le caratteristiche del servizio, effettua i controlli di sicurezza previsti ed invia il messaggio al destinatario. Le funzionalità appena descritte costituiscono la novità più importante introdotta da OpenSPCoop nel paradigma di cooperazione applicativa, perciò la loro realizzazione rappresenta la maggiore complessità nell'implementazione del progetto OpenSPCoop. Per questo motivo il prototipo di OpenSPCoop prodotto durante il presente lavoro di Tesi è focalizzato sull'implementazione dei componenti che sviluppano tali funzionalità. Nel capitolo 6 sarà presentata l'architettura del prototipo e in Appendice C è raccolto il codice con cui è stato implementato il prototipo. Tra le migliorie introdotte dal progetto OpenSPCoop rispetto al progetto CART, oltre ai vantaggi precedentemente descritti nell'adottare un sistema basato su prodotti Open Source, è da segnalare la gestione differenziata delle richieste applicative in funzione della loro destinazione: se la richiesta è diretta ad una amministrazione che fa parte dello stesso Dominio di Cooperazione dell'amministrazione mittente, il processo applicativo viene ottimizzato e semplificato attraverso l'uso di specifiche code JMS. Nel paragrafo viene descritto in dettaglio il processo applicativo realizzato all'interno di OpenSPCoop in questo scenario. 5.5 Gli scenari applicativi in OpenSPCoop In questo paragrafo è mostrato il comportamento del sistema NCOOP durante l'accesso a servizi web pubblicati sul NCOOP, in alcuni casi di studio particolarmente rilevanti. Per facilitare la descrizione del comportamento del NCOOP, nei vari casi presentati sarà evidenziato come una particolare sequenza di passi all interno del processo generale di funzionamento del NCOOP, descritto in UML. La figura 5.18 mostra pertanto il diagramma generale di processo a cui si fa poi riferimento nella 143

145 Tabella 5.3. Funzionalità del Modulo Gestione Tracciabilità presentazione dei casi specifici. Va notato come alcuni dettagli del processo, come il tracciamento e la gestione della sicurezza nelle buste e-gov, non sono evidenziati negli schemi per facilitare la comprensione del processo generale. Figura Diagramma di rappresentazione dei processi applicativi Questi scenari sono caratterizzati dal fatto che le richieste in arrivo non sono semplici richieste HTTP, ma buste SOAP o e-gov. Si tratta di buste SOAP quando arrivano da NINT del Dominio di Cooperazione del NCOOP, e richiedono quindi un processo di 144

146 Tabella 5.3. Funzionalità del Modulo Gestione Tracciabilità imbustamento secondo gli standard della busta e-gov. Si tratta invece di buste egov quando arrivano da altri NCOOP e sono quindi già state imbustate precedentemente Interazione dall'esterno del dominio verso l'interno La figura 5.19 mostra il comportamento del NCOOP in caso di richiesta e-gov con mittente un NINT esterno al Dominio di Cooperazione (quindi in arrivo tramite un altro NCOOP) e destinata ad un NINT interno al Dominio di Cooperazione, che quindi richiedono l'estrazione del messaggio dalla busta prima della consegna al NINT locale. 145

147 Tabella 5.3. Funzionalità del Modulo Gestione Tracciabilità Figura Diagramma che illustra il processo effettuato per un'interazione proveniente dall'esterno del dominio e diretta verso l'interno Interazione dall'esterno del dominio verso l'esterno La figura 5.20 mostra il comportamento del NCOOP in caso di richiesta e-gov con mittente un NINT esterno al Dominio di Cooperazione (quindi in arrivo tramite un altro NCOOP) e destinata a un NINT esterno al Dominio di Cooperazione. In questo caso la richiesta non viene né imbustata né estratta dalla busta ma soltanto ruotata verso il 146

148 Tabella 5.3. Funzionalità del Modulo Gestione Tracciabilità NCOOP destinazione. Figura Diagramma che illustra il processo effettuato per un'interazione proveniente dall'esterno del dominio e diretta verso l'esterno Interazione dall'interno del dominio verso l'esterno La figura 5.21 mostra il comportamento del NCOOP in caso di una richiesta effettuata da un NINT interno al Dominio di Cooperazione e destinata ad un NINT esterno al Dominio di Cooperazione. In questo caso è richiesto quindi l imbustamento della 147

149 Tabella 5.3. Funzionalità del Modulo Gestione Tracciabilità richiesta, prima della propagazione verso il NCOOP dell NINT destinatario. Figura Diagramma che illustra il processo effettuato per un'interazione proveniente dall'interno del dominio e diretta verso l'esterno Interazione dall'interno del dominio verso l'interno La figura 5.22 mostra il comportamento del NCOOP in caso di una richiesta effettuata da un NINT interno al Dominio di Cooperazione (quindi registrato su questo NCOOP) e destinata ad un NINT anch esso interno al Dominio di Cooperazione. In questo caso è mostrato quindi prima l imbustamento e poi il successivo prelevamento della 148

150 Tabella 5.3. Funzionalità del Modulo Gestione Tracciabilità richiesta applicativa. Ovviamente questi due passi saranno ottimizzati nella realizzazione del Proxy Applicativo. Figura Diagramma che illustra il processo effettuato per un'interazione proveniente dall'interno del dominio e diretta verso l'interno 149

151 Tabella 5.3. Funzionalità del Modulo Gestione Tracciabilità Capitolo 6 Implementazione di un Prototipo per OpenSPCoop A completamento dell attività di progettazione di OpenSPCoop, è stato realizzato un prototipo del nucleo del sistema progettato con l obiettivo di verificare la fattibilità dell architettura progettata e di specificare in maggior dettaglio l architettura dei componenti più complessi. Il prototipo indirizza la principale complessità del progetto, che riguarda la possibilità di intercettare in maniera trasparente le richieste di servizio in arrivo dai nodi locali (NINT). Tali richieste possono quindi essere trattate in aderenza alle specifiche OpenSPCoop ed alla tipologia del servizio ad esse associato, prima di reindirizzarle al destinatario reale o trattarle come una notifica di evento. Nel presente capitolo vengono descritte le funzionalità del prototipo e la sua architettura; quindi si presentano gli sviluppi futuri previsti per il prototipo e per l'intero progetto OpenSPCoop. 6.1 Le funzionalità del prototipo OpenSPCoop La principale funzionalità che si intende realizzare nel prototipo è quindi quella di proxy SOAP, su trasporto HTTP, tra client Web Services e server Web Services. 150

152 Tabella 5.3. Funzionalità del Modulo Gestione Tracciabilità Lo scenario di partenza è quello di due (o più) applicazioni che intendono accedere a due servizi Web (WS1 e WS2) dislocati all esterno del proprio dominio, come mostrato nella figura 6.1. Figura 6.1. Scenario in cui due applicazioni accedono a due servizi Web Lo scenario che si intende realizzare prevede di indirizzare le richieste dei Client Web Services al Prototipo OpenSPCoop, anziché al destinatario reale, utilizzando una URL per ogni servizio, come specificato nella tabella 6.1, tutte associate allo stesso servizio OpenSPCoop: Web Service WS1 WS2 URL Reale URL utilizzata dal Client Tabella 6.1. Conversione degli URL utilizzati dai cliente negli URL reali dei servizi La chiamata di servizio per i due client resta completamente trasparente, a meno della URI utilizzata per il trasporto, informazione tipicamente ottenuta dinamicamente dal registro UDDI locale, quindi completamente gestibile a livello infrastrutturale. Il codice del client non richiede quindi nessuna modifica per utilizzare OpenSPCoop. La figura 6.2 mostra lo scenario appena descritto evidenziando il ruolo di OpenSPCoop. 151

153 Tabella 5.3. Funzionalità del Modulo Gestione Tracciabilità Figura 6.2. Ruolo di OpenSPCoop nello scenario in cui due applicazioni accedono a due servizi Web distinti 6.2 L'architettura del prototipo OpenSPCoop L architettura utilizzata per il prototipo è una semplificazione dell architettura complessiva di OpenSPCoop, evidenziata nella figura 6.3. Figura 6.3. Architettura del prototipo OpenSPCoop 152

154 Tabella 5.3. Funzionalità del Modulo Gestione Tracciabilità I due componenti infrastrutturali fondamentali utilizzati nella realizzazione del prototipo sono l Application Server JBoss e il framework per la gestione di Web Services Axis. All interno di questi contenitori applicativi, sono stati instanziati: la coda RequestQueue, utilizzata per realizzare la coda delle richieste ricevute da OpenSPCoop e in attesa di essere gestite; la coda ResponseQueue, utilizzata per realizzare la coda delle risposte, ricevute dai Servizi Target e in attesa di essere gestite; il Web Service OpenSPCoop, un servizio document/literal di cui è stato realizzato il deploy come servizio Axis, che ha il compito di ricevere generiche buste SOAP e, utilizzando JMS, memorizzarle nella RequestQueue; il Modulo di CheckOut, implementato come listener JMS sulla coda RequestQueue, per ogni nuova richiesta disponibile sulla coda si occupa di consultare la tabella dei servizi per identificare il Server associato al Web Service richiesto e invocare quindi il servizio utilizzando il trasporto HTTP; la 153