Università di Roma Tor Vergata Facoltà di Ingegneria. Laurea in Ingegneria Informatica

Transcript

1 Università di Roma Tor Vergata Facoltà di Ingegneria Laurea in Ingegneria Informatica Metodologie e Tecniche per la Cooperazione Applicativa nella Pubblica Amministrazione italiana: progettazione e sviluppo di una Porta di Dominio Relatore: Prof. G.F. Italiano Correlatore: Dr. S. Fuligni Correlatore: Ing. S. Armenia Candidato:

2 Indice Copyright Tutti i diritti sono riservati all'autore, all'università di Roma "Tor Vergata" ed al CNIPA" come da legge sul Diritto d'autore n.518 del 1992 e successive modifiche Autore: Mail: vittorio.ottaviani@gmail.com Titolo: Metodologie e Tecniche per la Cooperazione Applicativa nella Pubblica Amministrazione italiana: progettazione e sviluppo di una Porta di Dominio Roma, 23 Febbraio

3 Indice Indice 1. Introduzione L interoperabilità fra sistemi informatici Architetture orientate ai servizi Il modello a Web Services La cooperazione applicativa: approcci ed esperienze SPC: il Sistema Pubblico di Connettività e Cooperazione Il Sistema Pubblico di Connettività Il Sistema Pubblico di Cooperazione (SPCoop) Modello e architettura del SPCoop L Accordo di Servizio La Busta e-gov La Porta di Dominio SICA: i servizi infrastrutturali per la cooperazione applicativa Sviluppo di una Porta di Dominio Progettazione di una proof of concept di Porta di Dominio Fasi della progettazione Definizione degli Attori Casi d Uso Sequence Diagrams Architettura modulare Acquisizione Inoltro

4 Indice Ricezione Smistamento Smistamento degli Errori Gestione eccezioni Gestione dei SOAP:FAULT Gestione dei log Gestione dei messaggi diagnostici Funzionalità aggiuntive Strumenti utilizzati Tomcat AXIS JAXB Realizzazione della libreria Busta di e-gov Profili di comunicazione e collaborazione Messaggio singolo Comunicazione sincrona Comunicazione asincrona Problemi e soluzioni Conclusioni e sviluppi futuri Conclusioni Sviluppi futuri Community di Sviluppo Bibliografia Indice analitico delle figure Glossario

5 Introduzione 1. Introduzione Il presente lavoro è il primo nato dalla collaborazione tra il CNIPA e la facoltà di Ingegneria dell Università di Roma Tor Vergata sui temi dell interoperabilità e dell integrazione dei sistemi informatici ed in particolare sull evoluzione del Sistema Pubblico di Cooperazione (SPCoop), il framework per l interoperabilità dei servizi telematici delle amministrazioni pubbliche italiane. Questa tesi si pone l obiettivo di analizzare gli aspetti peculiari relativi alla progettazione ed implementazione di una cosiddetta proof of concept di una Porta di Dominio (cfr. 3.5), cioè l implementazione di un prototipo concettuale per la verifica della validità delle caratteristiche fondamentali di uno degli elementi architetturali principali del SPCoop. Un ulteriore obbiettivo è quello di proporre un modello sostenibile per la nascita ed il governo di una community Open Source con l obiettivo di sviluppare una implementazione di riferimento a codice aperto di una Porta di Dominio. Nel prossimo capitolo verrà condotta preliminarmente una panoramica sulle Architetture Orientate ai Servizi (SOA) (cfr. 2.1), a cui seguirà un analisi della tecnologia dei Web Services (cfr. 2.2), potenzialmente adatta all implementazione del modello architetturale SOA. Verrà inoltre trattato il tema dell interoperabilità dei sistemi informatici (cfr. 2.3), con un analisi sintetica di quanto accade nel mercato ICT, sia in Europa che nel nostro paese. Nel terzo capitolo verrà introdotto con maggiore dettaglio il concetto di cooperazione applicativa e come stato sviluppato nella Pubblica Amministrazione italiana; ciò verrà 4

6 Introduzione fatto accennando al Sistema Pubblico di Connettività (cfr. 3.1) nonché descrivendo il Sistema Pubblico di Cooperazione (SPCoop) (cfr. 3.2) e gli elementi che lo caratterizzano: la Busta di e-gov (cfr. 3.4), la Porta Di Dominio (cfr. 3.5), l Accordo di Servizio (cfr. 3.6) ed i Servizi di Interoperabilità, Cooperazione ed Accesso (SICA, cfr. 3.7). Verranno, inoltre, analizzate le modalità in cui questi elementi contribuiscono al conseguimento dell interoperabilità e della cooperazione applicativa tra le amministrazioni;ciò sarà illustrato nella sezione che descrive l architettura del Sistema Pubblico di Cooperazione (cfr. 3.3) Nel quarto capitolo saranno descritte le attività di progettazione ed implementazione della proof of concept di una Porta Di Dominio, descrivendo gli strumenti utilizzati, le scelte progettuali ed il processo di realizzazione, i problemi incontrati e le soluzioni adottate nonché i perfezionamenti apportati al codice in seguito alla prima stesura. Nel quinto capitolo verranno, quindi, proposte le conclusioni tratte da questa esperienza, le linee suggerite per sviluppi futuri ed un possibile modello per lo sviluppo di una community open-source sui temi affronati, motivando le scelte effettuate e descrivendo un modello di gestione compatibile con gli obiettivi del SPCoop. 5

7 L interoperabilità fra sistemi informatici 2. L interoperabilità fra sistemi informatici Nell ambito dell ICT (Information & Communications Technologies), l interoperabilità è definibile come la capacità dei sistemi informatici di cooperare, erogando e fruendo servizi, con altri sistemi ed usare i servizi scambiati per effettuare operazioni più complesse di quelle possibili agli stessi sistemi in un ambiente non cooperativo; questo vantaggio nasce dalla disponibilità di risorse, quali dati, servizi, risorse di calcolo o altre risorse, che in ambito non cooperativo non sarebbero disponibili. A livello software per interoperability si intende la capacità di differenti programmi o sistemi informatici di scambiare dati tramite gli stessi protocolli o le stesse procedure o leggere e scrivere files dello stesso formato. Spesso il software realizzato senza una progettazione che tenga in considerazione la standardizzazione delle procedure effettuate dal prodotto è un software che manca di interoperabilità. Ci sono diverse modalità per garantire l interoperabilità dei sistemi informatici, una di queste è utilizzare modelli architetturali di tipo orientato ai servizi; questo modello architetturale permette a sistemi eterogenei di interoperare utilizzando procedure e standard comuni. Nel seguito di questo capitolo (cfr. 2.1) verrà trattato il tema delle Service Oriented Architecture (SOA); verrà poi esaminata la tecnologia dei Web Services, una tecnologia che permette di sviluppare una SOA (cfr. 2.2). 6

8 L interoperabilità fra sistemi informatici 2.1 Architetture orientate ai servizi Con Service-Oriented Architecture si identifica un modello architetturale che supporta l uso di servizi che soddisfano le richieste degli utenti, rendendo possibile l utilizzo delle singole applicazioni come componenti dei processi applicativi. Quindi, utilizzando modelli architetturali di tipo Service Oriented, si possono modificare, in modo abbastanza semplice, sia le modalità secondo le quali interagiscono i servizi, sia le combinazioni dei servizi stessi che vengono fruiti per realizzare un processo; allo stesso modo risultano semplificate le operazioni di aggiunta di servizi e la modifica di processi per rispondere alle specifiche esigenze di business: il servizio non è più vincolato ad una specifica piattaforma o ad un'applicazione ma può essere considerato come un componente riutilizzabile nell ambito di processi di business differenti. Il modello architetturale Orientato ai Servizi si applica preferibilmente ai sistemi che si mostrano particolarmente complessi sia nei processi che nelle applicazioni; questo deriva dal fatto che le interazioni tra diverse realtà vengono facilitate, permettendo allo stesso momento che le attività applicative sviluppino processi efficienti, sia all interno che all esterno dei sistemi stessi, aumentandone l'adattabilità e la flessibilità. Le Service Oriented Architecture non sono legate ad una tecnologia in particolare; esempi delle tecnologie con le quali si possono realizzare delle SOA sono: REST, RPC, DCOM, CORBA o i Web Services. L implementazione di una SOA, infatti, può avvenire anche in assenza di questi protocolli; una tecnica alternativa è l uso del file system; questo si realizza attraverso il trasferimento di dati secondo le specifiche dell'interfaccia tra i processi, in modo conforme al concetto di SOA. Il fulcro delle comunicazioni tra applicazioni è l'indipendenza tra i servizi che vengono caraterizzati da un interfaccia specifica e che, quando vengono invocati, eseguono le 7

9 L interoperabilità fra sistemi informatici proprie operazioni in maniera standard; ciò avviene mantenendo l applicazione chiamante all oscuro di quale sia il servizio che effettivamente esegue l operazione; allo stesso modo il servizio non ha necessità di conoscere come sia realizzata l applicazione chiamante. La conoscenza reciproca è del tutto irrilevante visto che erogatore e fruitore basano l interazione sulle interfacce esposte. Il modello architetturale SOA può essere considerato un buon metodo per implementare architetture di sistemi informatici adatte alla creazione di applicazioni sviluppate, combinando servizi debolmente accoppiati in modo da renderli interoperabili tra loro. La cooperazione tra questi servizi è indipendente dalla piattaforma sottostante e dalle tecnologie in cui sono sviluppati; importante è invece la definizione formale dei servizi stessi. Un esempio di ciò possono essere i servizi scritti in Java, usando la piattaforma Java EE e quelli in C# con.net; questi servizi possono essere utilizzati da una applicazione di livello più alto, utilizzando le interfacce di queste applicazioni. Le applicazioni in esecuzione su una piattaforma possono anche utilizzare servizi in esecuzione su altre, come succede con i Web Services; questa caratteristica favorisce la riusabilità di software già presente. 8

10 L interoperabilità fra sistemi informatici Figura 1 1 : Possibile architettura di una SOA (fonte: Wikipedia) In Figura 1 sono mostrati i possibili elementi di una SOA; come si può vedere i servizi sono solo una parte della struttura. Rimane il fatto che i servizi sono il cardine delle SOA; in un servizio, non è importante come venga fatta la realizzazione delle funzionalità stesse (Business Logic e Data); è invece fondamentale che laparte di Contratto (Contract) e di Interfaccia (Interface) seguano le specifiche definite. Anche il Service Repository è una parte fondamentale, è infatti su questo elemento che i servizi della SOA vengono registrati per poi essere erogati, tramite l Application front-end, utilizzando il Service Bus, che può essere realizzato sia logicamente sia fisicamente. Figura 1 è una possibile implementazione di una SOA, non è infatti obbligatorio che l architettura contenga tutti gli elementi mostrati nella figura; allo stesso modo è possibile che altre implementazioniche contengano elementi non presenti in questa immagine

11 L interoperabilità fra sistemi informatici Questo tipo di architettura è adeguato per una realtà complessa ed eterogenea, in termini informatici, come la Pubblica Amministrazione; per questo motivo tale modello viene ripreso sia dai progetti di interoperability in Europa che di cooperazione applicativa in Italia, con l obiettivo di sviluppare un framework per le Amministrazioni Locali e Centrali mediante il quale rendere disponibili i servizi. Utilizzando Architetture Orientate ai Servizi, infatti, la Pubblica Amministrazione che vuole pubblicare un servizio è responsabile di erogarlo in maniera conforme ai protocolli utilizzati nell architettura ma è del tutto padrona del servizio fornito e dunque può scegliere come erogarlo. 2.2 Il modello a Web Services Una tecnologia applicabile per implementare una architettura orientata ai servizi (SOA) è quella dei Web Services. Il W3C definisce un Web Service (servizio web) come un sistema software progettato per supportare l'interoperabilità tra diversi sistemi che cooperano su una stessa rete; una delle caratteristiche fondamentali di un Web Service è quella di esporre un'interfaccia software, che viene descritta secondo formati che possano essere gestiti automaticamente, ad esempio, il WSDL; utilizzando questa interfaccia i sistemi possono fruire delle prestazioni erogate dal Web Service effettuando chiamate alle operazioni descritte nell interfaccia tramite messaggi ad-hoc che vengono scambiati utilizzando la "busta" SOAP [46] [47]: tali messaggi sono, solitamente, trasportati tramite il protocollo HTTP e formattati secondo lo standard XML. È grazie al lavoro di standardizzazione in ambiente open (le specifiche dei protocolli di comunicazione utilizzati dai WS sono tutte di libero accesso e condivise), che viene 10

12 L interoperabilità fra sistemi informatici fatto da enti come consorzio OASIS (Organization for the Advancement of Structured Information Standards) ed il W3C (World Wide Web Consortium), che è possibile l interoperabilità di sistemi sviluppati in linguaggi differenti, come Java e Pyton, che lavorano su differenti piattaforme, come Linux e Windows. La pila protocollare dei Web Services è principalmente basata su: SOAP: protocollo secondo il quale vengono scambiati i dati tra i sistemi che partecipano ad una operazione di scambio di servizi utilizzando Web Services; UDDI [48]: protocollo utilizzato per elencare i servizi in un registro centrale e comune che permetta la ricerca; questo registro (registro UDDI) ha la funzionalità di permettere il reperimento dei servizi in maniera veloce; WSDL 2 : linguaggio descrittivo basato su XML utilizzato per descrivere l interfaccia dei Web Services. WS-Security [49]: protocollo che permette l'autenticazione degli utenti e la confidenzialità dei messaggi scambiati con l'interfaccia del Web Service. WS-Reliability [50]: specifiche basate su SOAP che soddisfano la richiesta di messaggi affidabili, richiesta critica per alcune delle applicazioni che utilizzano i Web Service come transazioni monetarie. 2 WSDL (acronimo di Web Services Description Language) è un linguaggio formale in formato XML utilizzato per la creazione di "documenti" per la descrizione di Web Service. Mediante WSDL può essere, infatti, descritta l'interfaccia pubblica di un Web Service ovvero creata una descrizione, basata su XML, di come interagire con un determinato servizio: un "documento" WSDL contiene infatti, relativamente al Web Service descritto, informazioni su: cosa può essere utilizzato (le "operazioni" messe a disposizione dal servizio); come utilizzarlo (il protocollo di comunicazione da utilizzare per accedere al servizio, il formato dei messaggi accettati in input e restituiti in output dal servizio ed i dati correlati) ovvero i "vincoli" (bindings in inglese) del servizio; dove utilizzare il servizio (cosiddetto endpoint del servizio che solitamente corrisponde all'indirizzo - in formato URI - che rende disponibile il Web Service). Le operazioni supportate dal Web Service ed i messaggi che è possibile scambiare con lo stesso sono descritti in maniera astratta e quindi collegati ad uno specifico protocollo di rete e ad uno specifico formato. Il WSDL è solitamente utilizzato in combinazione con SOAP e XML Schema per rendere disponibili Web Services su reti aziendali o su internet: un programma client può, infatti, "leggere" il documento WSDL relativo ad un Web Service per determinare quali siano le funzioni messe a disposizione sul server e quindi utilizzare il protocollo SOAP per utilizzare una o più delle funzioni elencate dal WSDL. La versione 1.1 di WSDL non è stata adottata come standard dal World Wide Web Consortium (W3C), ma l'11 maggio 2005 è stata rilasciata la "bozza" della versione 2.0 che sarà invece adottata come standard ufficiale (in forma di "raccomandazione") dal W3C [45]. 11

13 L interoperabilità fra sistemi informatici Semplicemente facendo riferimento alle interfacce esposte, ed utilizzando le funzioni che sono in grado di effettuare i servizi, sistemi sviluppati in maniera differente e con differenti scopi possono cooperare e scambiarsi informazioni. I Web Services sono applicabili sia la caso di piccole reti locali che al caso più generale ed eterogeneo che può essere internet. La funzionalità più innovativa dei Web Services e più in generale delle SOA è la possibilità di creare sistemi che cooperino in maniera completamente disaccoppiata; infatti, l interfaccia standard esposta dal Web Service rende possibile al sistema utente di fruire i servizi senza conoscere le procedure che vengono svolte nel lato del sistema erogatore. Altra caratteristica innovativa dei Web Services è quella di permettere di modificare le applicazioni che erogano i servizi in maniera del tutto "trasparente" all'interfaccia esposta; questo significa che mantenendo stabile l interfaccia, il programma, o più in generale il sistema erogatore, può cambiare senza creare problemi all interoperabilità tra i sistemi che cooperano. La flessibilità data dalla possibilità di disaccoppiare il Web Service dalla logica applicativa che effettivamente fornisce la prestazione consente la creazione di sistemi software complessi costituiti da componenti svincolati l'uno dall'altro ed una forte riusabilità di codice ed applicazioni già sviluppate. L interazione fra i Web Services avviene sulla base del paradigma find-bind-execute. 12

14 L interoperabilità fra sistemi informatici Figura 2: Paradigma Find-Bind-Execute In Figura 2 è mostrato uno schema di come funzioni questo paradigma articolato in tre fasi: 1. find: dove il servizio viene ricercato sui sistemi di registro, tipicamente i registri UDDI nel caso dei Web Services; 2. bind: dove il client si collega al sistema server del servizio che vuole eseguire; 3. execute: dove il client accede al Web Service eseguendo le procedure fornite dal sistema server. 2.3 La cooperazione applicativa: approcci ed esperienze Numerose iniziative sono state avviate nei paese dell Unione Europea in tema di interoperability: l Inghilterra, per esempio, sta sviluppando e-gif (e-government Interoperability Framework), un framewok per l interoperabilità tra le amministrazioni pubbliche tramite l uso di Servizi Web; la Germania sta implementando il sistema 13

15 L interoperabilità fra sistemi informatici SAGA (Standards und Architekturen für E-Government); sistema modellato con un architettura del tipo SOA riportata nella prossima figura. Figura 3: Architettura del Sistema SAGA [21] Anche paesi relativamente meno sviluppati sono attivi in questo settore e stanno presentando i propri modelli di interoperability: l Ungheria ne è un esempio; il suo sistema di interoperability prende il nome di MEKIK (Hungarian Electronic Public Administration Interoperability Framework) ed è un adattamento del sistema di tedesco alla realtà ungherese. Un progetto di rilevanza europea è IDABC (Interoperable Delivery of Pan-European e- Government Services to Public Administrations, Business and Citizens), nato con l obiettivo di definire un modello per l interoperabilità transnazionale fra i Paesi membri dell UE. Maggiore dettagli su IDABC sono riportati in Appendice1. 14

16 L interoperabilità fra sistemi informatici Nel nostro paese il modello per l interoperabilità fra i sistemi informatici della PA è definito dal SPCoop (Sistema Pubblico di Cooperazione), parte del progetto SPC (Sistema Pubblico di Connettività e Cooperazione), istituito dal Governo con il D.lvo n. 42 del 28 febbraio 2005 [1] poi confluito nel CAD [2] e sviluppato dal CNIPA. Il Sistema Pubblico di Cooperazione si caratterizza per l approccio a 360 gradi che ha riguardato sia gli aspetti normativi che tecnici ed organizzativi, curando particolarmente la condivisione del metodo e dei risultati fra tutti gli interlocutori coinvolti, amministrazioni centrali e locali ed operatori del settore ICT. 15

17 SPC: il Sistema Pubblico di Connettività e Cooperazione 3. SPC: il Sistema Pubblico di Connettività e Cooperazione Le amministrazioni pubbliche italiane interagiranno in rete attraverso il Sistema Pubblico di Connettività e Cooperazione, costituito da due livelli di servizi infrastrutturali: il Sistema Pubblico di Connettività, che ha come obbiettivo quello di fornire una infrastruttura di rete affidabile e sicura (cfr 3.1); il Sistema Pubblico di Cooperazione, il cui scopo è quello di fornire un framework per l iteroperabilità fra servizi applicativi (cfr. 3.2). Nella prossima figura (Figura 4) viene mostrata l architettura del Sistema Pubblico di Connettività e Cooperazione; si può vedere come il SPCoop si appoggi sui servizi offerti dallo strato di Connettività. Amministrazioni pubbliche Servizi applicativi S P C SP Cooperazione SP Connettività Messaggi Pacchetti Figura 4: Pila SPC 16

18 SPC: il Sistema Pubblico di Connettività e Cooperazione 3.1 Il Sistema Pubblico di Connettività La legge n. 59 del 15 marzo 1997 ha provveduto a colmare la lacuna di un unica rete, omogenea per qualità sicurezza e costi che aveva caratterizzato le Pubbliche Amministrazioni fino agli anni novanta; infatti, precedentemente a questa norma, non esisteva un organismo che operasse armonicamente nel contesto delle comunicazioni ma si era proceduto individualmente sulla base delle differenti esigenze che si erano presentate nel corso degli anni, dando vita ad una pluralità di reti dati non dialoganti tra loro. Questa rete unitaria ha rappresentato per le Amministrazioni Centrali la piattaforma di sviluppo delle applicazioni. Le precedenti reti delle Amministrazioni, realizzate con CDN e accessi X.25, si sono evolute in reti IP favorendo l utilizzo della posta elettronica e del web. Attualmente si sta convertendo in un sistema più moderno, denominato Sistema Pubblico di Connettività, la Rete unitaria della Pubblica Amministrazione (RUPA) che collegava la quasi totalità delle sedi delle Pubbliche Amministrazioni centrali. Tale sistema utilizza tecnologie e protocolli attuali. I principali obiettivi del Sistema Pubblico di Connettività sono: fornire un insieme di servizi di connettività condivisi dagli Enti interconnessi, definiti negli aspetti di omogeneità, qualità e sicurezza, ampiamente graduabili in maniera tale da poter essere ritagliati al meglio sulle esigenze delle diverse amministrazioni. Garantire inoltre l interazione della pubblica amministrazione centrale e locale con tutti gli altri soggetti connessi ad Internet, nonché con le reti di altri Enti che debbano interagire con la P.A., facilitando l erogazione di servizi di qualità 17

19 SPC: il Sistema Pubblico di Connettività e Cooperazione e la fruibilità degli stessi da parte dei cittadini e delle imprese. Tale operazione non potrà prescindere, in fase di qualificazione anche da requisiti circa la connettività degli ISP verso i NAP commerciali. Questi ultimi non dovranno costituire un collo di bottiglia per la fruizione dei servizi esposti dalle Amministrazioni da parte dei cittadini. Fornire un infrastruttura condivisa di interscambio che consenta l interoperabilità tra tutte le reti delle Pubbliche Amministrazioni oggi esistenti, favorendone lo sviluppo omogeneo su tutto il territorio, salvaguardando gli investimenti effettuati. Fornire, alle Amministrazioni che ne faranno richiesta, servizi telematici (connettività e applicazioni) per permettere l interconnessione delle proprie sedi e realizzare così anche l infrastruttura interna di comunicazione (dominio dell Amministrazione). Realizzare un modello di provisioning dei servizi multifornitore coerente con l attuale situazione di mercato e le dimensioni del progetto stesso. Realizzare un sistema che, ancorché si basi sull utilizzo dei paradigmi tipici di Internet, permetta la definizione di flussi di traffico con caratteristiche di disponibilità e prestazioni garantite tra soggetti serviti da operatori qualificati diversi. Garantire, tramite il mantenimento di un sistema di raccolta dei dati di prestazioni e disponibilità, uno strumento di valutazione indipendente della qualità dei servizi offerti dai provider qualificati Implementare opportune misure di sicurezza atte a garantire una adeguata continuità dei propri servizi, in quanto l indisponibilità degli stessi potrebbe causare disservizi anche di grande impatto sui processi G2G e quindi sui servizi erogati ai cittadini. 3 3 Sistema Pubblico di Connettività: scenario introduttivo, emesso dal Gruppo di Lavoro SPC, p. 9 18

20 SPC: il Sistema Pubblico di Connettività e Cooperazione Poiché il Sistema Pubblico di Connettività costituisce l ossatura di rete del sistema di interconnessione italiana il suo sviluppo risulta prioritario rispetto a quello rispetto a quello dei servizi tra i soggetti interoperanti. Il Sistema Pubblico di Connettività permette di attivare lo scambio di servizi fra soggetti pubblici in una logica Government to Government (G2G), mentre la contemporanea interconnessione ad Internet garantisce la fruibilità dei servizi stessi da parte dei cittadini e delle imprese in una logica di Government to Citizen (G2C). La possibilità di sviluppare servizi fra le diverse Pubbliche Amministrazioni, in una logica di G2G, permette di ottenere maggior efficienza nei procedimenti interamministrazioni e di raggiungere l obiettivo di presentare le diverse pubbliche amministrazioni al cittadino e all impresa, in modo unitario. In tale ottica questo strumento potrà permettere un erogazione di servizi secondo modalità diverse di integrazione, che realizzano una maggiore sinergia, utilizzando diversi strumenti di accesso tra i quali i Portali nazionali e locali della Pubblica Amministrazione. Il Sistema Pubblico di Connettività è da intendersi quindi anche come una infrastruttura abilitante per lo sviluppo di applicazioni cooperative fra PA Centrali, fra PA Locali, fra PA Centrali e Locali, fra PA e Imprese/Cittadini. In Figura 5 si può vedere schematizzata l architettura della Qualified exchange Network del Sistema Pubblico di Connettività. 19

21 SPC: il Sistema Pubblico di Connettività e Cooperazione Figura 5 4 : Esempio di una QXN del Sistema Pubblico di Connetività Per soddisfare alcuni degli obiettivi del Sistema Pubblico di Connettività il QXN dovrà poter supportare diverse tipologie di traffico tra le PA e, in particolare, anche il traffico tra i cittadini e le PA afferenti ai diversi ISP qualificati. Sarà possibile lo scambio sicuro di dati internamente e tra le Amministrazioni, utilizzando sistemi crittografici per realizzare reti private virtuali (VPN); le VPN verranno utilizzate solo in caso di necessità, e comunque la scelta sull utilizzo resta prerogativa delle singole Amministrazioni. Per quanto riguarda le infrastrutture, l obiettivo condiviso dalle reti regionali è quello di portare a sistema nell ambito di strategie di livello provinciale e regionale tutte le opportunità presenti nei territori, lasciando alle singole Amministrazioni la libertà di stipulare contratti diversi a seconda delle opportunità che possono trovare sui propri 4 Sistema Pubblico di Connettività: scenario introduttivo, emesso dal Gruppo di Lavoro SPC, p

22 SPC: il Sistema Pubblico di Connettività e Cooperazione territori, con la priorità di garantire l uniformità di adeguati livelli di servizio e modalità di interconnessione indipendentemente dalla densità di popolazione. L altra parte del SPC è il progetto SPCoop (Sistema Pubblico di Cooperazione); progetto che si occupa di curare lo sviluppo della cooperazione applicativa. Il CNIPA, con i rappresentanti di Amministrazioni centrali e locali, e delle Associazioni dei fornitori, ha redatto un insieme di documenti che delineano un quadro tecnico-implementativo del sistema Il Sistema Pubblico di Cooperazione (SPCoop) Negli ultimi anni l Italia sta operando verso un decentramento amministrativo delle competenze secondo le nuove forme di federalismo con più efficienti modelli di Pubblica Amministrazione che hanno come riferimento il sistema delle regioni e delle autonomie locali e da questa tendenza emerge il problema di come organizzare la cooperazione tra le amministrazioni che devono condividere le risorse ed i servizi. Ciò è tanto più pressante alla luce del dettato della legge 241/90 art. 14 e 18 - (concetto ripreso anche negli art. 5 e 7 del D.Lgs. SPC 42/2005), secondo cui, la PA ha il dovere di farsi carico (attraverso la conferenza dei servizi telematici, la riorganizzazione dei processi e l integrazione telematica dei back-office) dell integrazione dei procedimenti delle diverse amministrazioni interessate al processo interamministrativo che riguarda una qualsiasi istanza di un cittadino o un impresa. Si realizza così un servizio caratterizzato come multi-ente, che nasce della cooperazione delle varie Amministrazioni le quali concorrono, ognuna per la sua parte di competenza nell ambito del processo, a comporre il procedimento che porta all erogazione del servizio richiesto dall utente finale. 5 rielaborazione delle parti ritenute interessanti del documento Sistema Pubblico di Connettività: scenario introduttivo, emesso dal Gruppo di Lavoro SPC [4]. 21

23 SPC: il Sistema Pubblico di Connettività e Cooperazione La progettazione e lo sviluppo del Sistema Pubblico di Cooperazione in CNIPA prendono il nome di SPCoop. SPCoop è un progetto che fa parte dell area d interesse del progetto SPC. Un infrastruttura così complessa ed articolata può mantenere ed accrescere nel tempo il consenso solo se da un lato viene supportato a livello organizzativo e politico e dall altro viene mantenuto un approccio analitico in grado di coinvolgere il mercato ed il mondo della ricerca. Entrambi questi aspetti devono essere tenuti in considerazione. In tale direzione si colloca la collaborazione con l università di Roma Tor Vergata così come anche in altri ambiti a livello regionale. Queste collaborazioni saranno utili al fine di mantenere attiva l attenzione sul tema della cooperazione applicativa ed a creare in tal modo una connessione tra diversi soggetti del mondo della ricerca e delle amministrazioni al fine sia di accrescere la sensibilità per quanto riguarda le applicazioni dei concetti relativi ai sistemi distribuiti che per la creazione di comunità e grouppi di interesse su aluni dei temi specifici. Il Sistema Pubblico di Connettività e Cooperazione che si sta realizzando permetterà di vedere tutti i servizi di ogni Amministrazione Pubblica sia centrale che locale in maniera integrata ed indipendente dal canale di erogazione. Per questo è stato necessario definire un modello comune di interazione on-line tale da valorizzare la specificità di ogni erogatore di servizi così che possa assicurare allo stesso tempo uniformità di interazione e certezza nell identificazione dell erogatore e del fruitore, o allo stesso modo degli attori dell interazione. Essendo già presenti a livello nazionale molteplici soluzioni architetturali per la Cooperazione Applicativa è emersa la necessità di individuare una soluzione infrastrutturale unica che da un lato tendesse a preservare l autonomia delle scelte delle amministrazioni e, dall altro, consentisse ai diversi sistemi di interoperare fra loro per erogare servizi integrati agli utenti. 22