Proposta di un architettura modulare per lo sviluppo della Porta di Dominio SPCoop

Transcript

1 Università degli studi di Roma Tor Vergata Facoltà di Ingegneria Laurea specialistica in Ingegneria Informatica Proposta di un architettura modulare per lo sviluppo della Porta di Dominio SPCoop Relatore: Prof. Giuseppe Italiano Candidato: Lucio Lecce Correlatori: Dr. Stefano Fuligni Dr. Stefano Armenia Anno Accademico

2 Introduzione Lucio Lecce 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.58 del 992 e successive modifiche. Autore: Lucio Lecce Mail: lucio.lecce@gmail.com Titolo: Proposta di un architettura modulare per lo sviluppo della Porta di Dominio SPCoop Roma, 3 Maggio 2007

3 Introduzione Lucio Lecce Indice generale. Introduzione Il Sistema Pubblico di Connettività e Cooperazione (SPC) La Cooperazione Applicativa in SPC Cooperazione tra due amministrazioni Cooperazione tra più amministrazioni Ambito di responsabilità Accordi Tecnologie di cooperazione Il Modello SPCoop L Accordo di Servizio La Busta di E-Gov La Porta Di Dominio I servizi infrastrutturali per la cooperazione applicativa (SICA) La Porta di Dominio: obiettivi di progetto e contesto di riferimento Analisi del contesto di riferimento Proof of concept di una PDD OpenSPCoop OpenPDD PDD Sun Microsystems Sintesi delle indicazioni emerse Obiettivi di progetto Analisi delle esigenze e requisiti Caratteristiche dell ipotesi di soluzione

4 Introduzione Lucio Lecce 4. Architettura modulare di una Porta Di Dominio Requisiti di progetto Sviluppo della Porta Di Dominio Definizione degli Attori Casi d Uso Class Diagrams Sequence Diagrams Architettura della PDD Struttura modulare della PDD Strumenti utilizzati Realizzazione della libreria della Busta e-gov Implementazione di funzionalità avanzate di una Porta di Dominio Profili di collaborazione Comunicazione one way Comunicazione sincrona Comunicazione asincrona simmetrica Comunicazione asincrona asimmetrica Soluzioni specifiche adottate Verifiche e casi di test Comunicazione one way Comunicazione sincrona Comunicazione asincrona simmetrica Comunicazione asincrona asimmetrica Analisi dei risultati Conclusioni e sviluppi futuri

5 Introduzione Lucio Lecce Appendice A: Schema XML della descrizione della Busta e-gov Appendice B: Schema XML della descrizione della PDD sviluppata Appendice C: Codice della PDD sviluppata Appendice D: Diagrammi UML Flussi alternativi Appendice E: Guida ai contenuti del DVD allegato Appendice F: Strumenti utilizzati per lo sviluppo della PDD Bibliografia Glossario Indice analitico delle figure Figura : Pila SPC... 0 Figura 2: Architettura del SPCoop Figura 3: Comunicazione attraverso le PDD... 2 Figura 4: Struttura completa di un Accordo di Servizio Figura 5: Busta SOAP... 3 Figura 6: Intestazione Figura 7: IntestazioneMessaggio Figura 8: Diagramma dello schema XML dell'intestazione Figura 9: Comunicazione tra Porte di Dominio Figura 0: Architettura dei servizi SICA Figura : Architettura software del progetto OpenSPCoop... 5 Figura 2: Porta di Dominio del progetto OpenSPCoop Figura 3: Architettura generale di una PDD Figura 4: Architettura generale del Framework di Cooperazione Applicativa Figura 5: Porta di Dominio come Strato Protocollare Figura 6: Porta di Dominio come Proxy Applicativo Figura 7: Comunicazione Messaggio Singolo

6 Introduzione Lucio Lecce Figura 8: Comunicazione Sincrona Figura 9: Comunicazione Asincrona Simmetrica Figura 20: Comunicazione Asincrona Asimmetrica Figura 2: Use Case Porta Di Dominio Figura 22: Use Case Trasmissione Messaggio Figura 23: Use Case Ricezione Messaggio... 8 Figura 24: Use Case Gestione Tracciamenti Figura 25: Use Case Gestione Comunicazione One Way Figura 26: Use Case Gestione Comunicazione Sincrona Figura 27: Use Case Gestione Comunicazione Asincrona Simmetrica Figura 28: Use Case Gestione Comunicazione Asincrona Asimmetrica Figura 29: Vista generale degli Use Case Figura 30: InterfaceImpl - ServizioOneWay Figura 3: InterfaceImpl - ServizioSincrono Figura 32: InterfaceImpl ServizioAsincronoSimmetricoRichiesta Figura 33: InterfaceImpl ServizioAsincronoSimmetricoNotifica... 9 Figura 34: InterfaceImpl ServizioAsincronoAsimmetricoRichiesta Figura 35: InterfaceImpl - ServizioAsincronoAsimmetricoPolling Figura 36: Class Diagram Gestione Comunicazione One Way Figura 37: Class Diagram Gestione Comunicazione Sincrona Figura 38: Class Diagram Gestione Comunicazione Asincrona Simmetrica Richiesta Figura 39: Class Diagram Gestione Comunicazione Asincrona Simmetrica Risposta97 Figura 40: Class Diagram Gestione Comunicazione Asincrona Asimmetrica Richiesta Figura 4: Class Diagram Gestione Comunicazione Asincrona Asimmetrica Risposta Figura 42: Sequence Diagram Gestione Comunicazione One Way - Flusso base... 0 Figura 43: Sequence Diagram Gestione Comunicazione Sincrona - Flusso base... 5

7 Introduzione Lucio Lecce Figura 44: Sequence Diagram Gestione Comunicazione Asincrona Simmetrica - Richiesta - Flusso base... 2 Figura 45: Sequence Diagram Gestione Comunicazione Asincrona Simmetrica - Risposta - Flusso base... 3 Figura 46: Sequence Diagram Gestione Comunicazione Asincrona Asimmetrica - Richiesta - Flusso base... 4 Figura 47: Sequence Diagram Gestione Comunicazione Asincrona Asimmetrica - Risposta - Flusso base... 5 Figura 48: Sequence Diagram Gestione Comunicazione Asincrona Asimmetrica - Elaborazione - Flusso base... 6 Figura 49: Architettura della Porta di Dominio... 2 Figura 50: Funzionalità principali di una PDD Figura 5: Strumenti principali utilizzati per realizzare l architettura della Porta di Dominio Figura 52: Form per l'invocazione di un servizio one way Figura 53: Output sull'application Server (comunicazione one way) Figura 54: Busta e-gov relativa al messaggio di richiesta di servizio one way Figura 55: Interfaccia grafica che mostra la risposta al client Figura 56: Form per l'invocazione di un servizio sincrono Figura 57: Output sull'application Server (comunicazione sicrona) Figura 58: Busta e-gov relativa al messaggio di richiesta di servizio sincrona Figura 59: Busta e-gov relativa al messaggio di risposta sincrona Figura 60: Form per l'invocazione di un servizio asincrono simmetrico Figura 6: Output sull'application Server (comunicazione asicrona simmetrica) Figura 62: Output riferito all'applicazione "NotificaAsincronaSimmetricaHandler" (comunicazione asicrona simmetrica) Figura 63: Interfaccia grafica che mostra la ricevuta al client Figura 64: Output sull'application Server (comunicazione asicrona simmetrica) Figura 65: Output riferito all'applicazione "NotificaAsincronaSimmetricaHandler" (comunicazione asicrona simmetrica)

8 Introduzione Lucio Lecce Figura 66: Interfaccia grafica che mostra la risposta al client Figura 67: Busta e-gov relativa al messaggio di richiesta di servizio asincrona simmetrica Figura 68: Busta e-gov relativa al messaggio di ricevuta della richiesta asincrona simmetrica... 2 Figura 69: Busta e-gov relativa al messaggio di risposta asincrona simmetrica Figura 70: Busta e-gov relativa al messaggio di ricevuta della risposta asincrona simmetrica Figura 7: Form per l'invocazione di un servizio asincrono asimmetrico Figura 72: Interfaccia grafica che mostra la ricevuta al client Figura 73: Interfaccia grafica che mostra la risposta al client Figura 74: Output sull'application Server (comunicazione asicrona asimmetrica) Figura 75: Output riferito all'applicazione "ServizioAsincronoAsimmetricoHandler" (comunicazione asicrona asimmetrica) Figura 76: Output sull'application Server (comunicazione asicrona asimmetrica) Figura 77: Output sull'application Server (comunicazione asicrona asimmetrica) Figura 78: Busta e-gov relativa al messaggio di richiesta di servizio asincrona asimmetrica Figura 79: Busta e-gov relativa al messaggio di ricevuta della richiesta asincrona asimmetrica Figura 80: Busta e-gov relativa al messaggio di richiestastato asincrona asimmetrica Figura 8: Busta e-gov relativa al messaggio di risposta asincrona asimmetrica Indice analitico delle tabelle Tabella : Tabella riassuntiva dei punti chiave delle soluzioni alternative analizzate

9 Introduzione Lucio Lecce. Introduzione Il presente lavoro è frutto della 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 Porta di Dominio (cfr. 4 e 5), finalizzata allo sviluppo di una implementazione di riferimento di uno degli elementi architetturali principali del SPCoop. Nell ambito di tali attività saranno analizzate alcune soluzioni alternative esistenti per lo sviluppo di una Porta Di Dominio allo scopo di evidenziare i vantaggi e svantaggi di tali soluzioni e le differenze principali rispetto all approccio proposto nel presente lavoro. Nel capitolo 2 verrà introdotto con maggiore dettaglio il concetto di cooperazione applicativa e come è stato sviluppato nella Pubblica Amministrazione italiana (cfr. 2.); ciò verrà fatto accennando al Sistema Pubblico di Connettività nonché descrivendo il Sistema Pubblico di Cooperazione (SPCoop) e gli elementi che lo caratterizzano: la Busta di e-gov (cfr ), la Porta Di Dominio (cfr ), l Accordo di Servizio (cfr. 2.2.) ed i Servizi Infrastrutturali di Interoperabilità, Cooperazione ed Accesso (SICA, cfr ). Verranno, inoltre, analizzate le modalità con cui questi elementi abilitano l interoperabilità e la cooperazione applicativa tra le amministrazioni pubbliche; illustrando l architettura del Sistema Pubblico di Cooperazione (cfr. 2.2). 8

10 Introduzione Lucio Lecce Nel terzo capitolo saranno inquadrati gli obiettivi generali di progetto, illustrando il contesto di riferimento e l esigenza dello sviluppo di una Porta Di Dominio. Verrà analizzata la proof of concept di una PDD realizzata in precedenza, evidenziando come alcune scelte progettuali di tale soluzione saranno recepite nel presente lavoro (in particolare quelle relative alla gestione della Busta e-gov). Verranno inoltre analizzate alcune soluzioni alternative esistenti per lo sviluppo di una Porta Di Dominio, illustrando le principali caratteristiche di ognuna. Nel quarto capitolo saranno descritte le attività di progettazione della Porta Di Dominio, le scelte progettuali relative all architettura ed ai componenti principali e gli strumenti utilizzati. Nel quinto capitolo saranno descritte le attività di implementazione della Porta Di Dominio, il processo di realizzazione, i problemi incontrati e le soluzioni adottate. Nel sesto capitolo verranno, infine, tratte le conclusioni di questa esperienza ed indicati alcuni suggerimenti per sviluppi futuri. 9

11 Il Sistema Pubblico di Connettività e Cooperazione (SPC) Lucio Lecce 2. Il Sistema Pubblico di Connettività e Cooperazione (SPC) In questo capitolo viene descritto il Sistema Pubblico di Connettività e Cooperazione (SPC) che è l evoluzione della Rete unitaria della Pubblica Amministrazione (RUPA), rete che collegava la quasi totalità delle sedi delle Pubbliche Amministrazioni centrali. Esso è logicamente articolato su due livelli di servizi infrastrutturali: il Sistema Pubblico di Connettività, che ha come obbiettivo quello di fornire una infrastruttura di rete affidabile e sicura; il Sistema Pubblico di Cooperazione, il cui scopo è quello di fornire un framework per l interoperabilità fra servizi applicativi. Nella Figura è illustrata l architettura del SPC; come si può notare il Sistema Pubblico di Cooperazione si appoggia sui servizi offerti dallo strato di Connettività. Figura : Pila SPC 0

12 Il Sistema Pubblico di Connettività e Cooperazione (SPC) Lucio Lecce 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à 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.

13 Il Sistema Pubblico di Connettività e Cooperazione (SPC) Lucio Lecce 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.[5] Lo scambio sicuro di dati tra le Pubbliche Amministrazioni è reso possibile utilizzando sistemi crittografici per realizzare reti private virtuali (VPN); l utilizzo delle VPN non è necessario ma resta comunque a scelta delle singole Amministrazioni. L altra parte del SPC è il Sistema Pubblico di Cooperazione (SPCoop); framework di servizi abilitanti la cooperazione applicativa. In seguito all approvazione delle nuove forme di federalismo che hanno portato ad un decentramento amministrativo delle competenze è divenuta sempre più impellente, da parte delle varie Pubbliche Amministrazioni, la necessità di cooperare telepaticamente, ognuna per la propria competenza, nell ambito di procedimenti amministrativi interamministrazioni. Questo problema è rafforzato anche dalla legge 24/90 art. 4 e 8 - (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. Il Sistema Pubblico di Connettività e Cooperazione che si sta realizzando permetterà di vedere 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 telematica tale da valorizzare la specificità di ogni erogatore di servizi così che possa assicurare allo stesso tempo uniformità di interazione Vedi p. 9 2

14 Il Sistema Pubblico di Connettività e Cooperazione (SPC) Lucio Lecce 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. In sintesi, la cooperazione tra differenti Amministrazioni, ed in generale tra soggetti pubblici, richiede la definizione di un modello di cooperazione che sia: indipendente dagli assetti organizzativi dei soggetti cooperanti; indipendente dai sistemi informatici interni dei soggetti cooperanti; progettato in maniera rigorosa e sostenibile, tale che la sua evoluzione sul medio termine sia già pensata sin dall inizio, con passi ben delineati.[3] 2 2 Vedi p.8. 3

15 Il Sistema Pubblico di Connettività e Cooperazione (SPC) Lucio Lecce 2. La Cooperazione Applicativa in SPC 2.. Cooperazione tra due amministrazioni Per mezzo dell erogazione e della fruizione di Servizi Applicativi le Amministrazioni cooperano; ogni amministrazione offre questi servizi tramite un unico elemento del proprio sistema informativo denominato Porta di Dominio. L amministrazione gode di completa autonomia grazie a questo principio, in fase di progettazione, realizzazione e gestione dei Servizi Applicativi. Questo è possibile vista la caratteristica dei Servizi Applicativi di potersi basare su qualsiasi piattaforma applicativa, preesistente o di nuova acquisizione, purché vengano poi erogati attraverso la Porta di Dominio. I servizi applicativi vengono fruiti attraverso lo scambio di messaggi applicativi, secondo il formato definito nel documento di specifica della busta di e-gov Cooperazione tra più amministrazioni Il Dominio di Cooperazione è costituito da più insiemi di Amministrazioni che concorrono alla fornitura di Servizi Applicativi composti; per ogni servizio erogato dal Dominio, deve esistere un Accordo di Servizio che lo descrive, nel caso di servizi composti l Accordo di Servizio va corredato di una specifica che spiega come le varie Amministrazioni componenti concorrono al servizio composto finale. Questo documento viene definito Accordo di Cooperazione ed è trasparente rispetto ai fruitori del servizio composto, mentre ha utilità interna al Dominio di Cooperazione. Si definisce così un modo per distinguere tra servizi la cui responsabilità ricade esclusivamente sul singolo dominio/amministrazione e servizi di più domini/amministrazioni per i quali una singola amministrazione assume (per legge, per 4

16 Il Sistema Pubblico di Connettività e Cooperazione (SPC) Lucio Lecce delega concordata dagli altri, ecc.) la responsabilità che dovrebbe essere di tutte le Amministrazioni che erogano il servizio composto. In questo ambito si nota la differenza tra Dominio Applicativo e Dominio di Cooperazione: il primo infatti rappresenta l insieme dei Servizi Applicativi erogati dalla singola Amministrazione in ambito SPCoop; mentre il secondo rappresenta un insieme di amministrazioni che cooperano per l automazione di un insieme di procedimenti amministrativi su di uno specifico tema. Un altro componente di rilevante importanza nel modello sono i Servizi di Interoperabilità, Cooperazione ed Accesso (SICA), che offrono una serie di servizi e componenti software infrastrutturali (non riconducibili a nessuna amministrazione specifica), il cui obiettivo è di mediare e supportare la cooperazione tra le amministrazioni (cfr ). In sintesi, il modello di cooperazione applicativa del SPCoop è basato sul paradigma SOC (Service Oriented Computing) ed organizzato come una SOA (Service Oriented Architecture); mentre, però, gli aspetti base di questa SOA sono già definiti a livello di tecnologie/standard, su altri è necessario operare delle estensioni, al fine di rendere tale architettura adeguata al contesto del e-government italiano. Va notato, infine, che tutte le architetture a servizi/soa richiedono la presenza di un elemento logicamente neutro, con il compito di mediare tra i differenti soggetti che cooperano attraverso l erogazione/fruizione di servizi. Il SICA costituisce di fatto tale elemento mediatore, dotato di funzionalità evolute in virtù del fatto che il modello di cooperazione proposto prevede la gestione non solo degli aspetti di base, ma anche e soprattutto di alcuni aspetti avanzati dei Web Services.[3] Vedi p.. 4 rielaborazione delle parti ritenute interessanti del documento Sistema Pubblico di Cooperazione: Quadro Tecnico d Insieme [3]. 5

17 Il Sistema Pubblico di Connettività e Cooperazione (SPC) Lucio Lecce 2..3 Ambito di responsabilità La responsabilità dei servizi erogati e dei dati forniti attraverso tali servizi è attribuita alla singola Amministrazione cooperante, che apparirà come un singolo dominio con responsabilità del singolo elemento e non del dominio stesso. La responsabilità della Porta di Dominio è quella di fungere da porta di ingresso verso il dominio per le altre amministrazioni che vogliono fruire dei servizi erogati, e da porta di uscita dal dominio per l amministrazione interna al dominio che vuole fruire di servizi erogati esternamente Accordi L utilizzo di un servizio applicativo tra almeno due soggetti (erogatore e fruitore) deve essere regolamentato da degli accordi che vengono stipulati a monte della cooperazione tra i soggetti cooperanti. La formalizzazione dell accordo prende il nome di Accordo di Servizio ed è basata su linguaggio XML Tecnologie di cooperazione I servizi applicativi vengono erogati/fruiti attraverso tecnologie e standard indicati genericamente come Web Service, che rappresentano una soluzione in grado di soddisfare i requisiti sopraindicati al problema dell interoperabilità di sistemi applicativi eterogenei; infatti grazie a queste tecnologie/standard, qualsiasi funzionalità, indipendentemente dal tipo di piattaforma, diventa esportabile, in modo da essere invocata remotamente. 6

18 Il Sistema Pubblico di Connettività e Cooperazione (SPC) Lucio Lecce SPCoop è dunque caratterizzato dai seguenti elementi: un protocollo di comunicazione; una serie di linguaggi per descrivere le caratteristiche dei servizi definite in base agli accordi di servizio (ad es. interfacce, livelli di sicurezza e servizio, ecc.); un sistema di registri per gli accordi di servizio; Attualmente le tecnologie su cui si basano i Web Services presentano diversi livelli di definizione e maturazione; mentre, infatti, su alcuni aspetti, indicati come aspetti di base, gli standard e le tecnologie che implementano tali standard hanno un livello di maturità sufficiente, su altri aspetti, definiti avanzati, si è ancora nella fase intermedia tra il conseguimento dei risultati delle ricerche effettuate e l utilizzo degli stessi per le prime realizzazioni. In particolare risultano ben definiti i seguenti aspetti di base: protocolli applicativi per l invocazione remota dei servizi: SOAP (Simple Object Access Protocol); linguaggi per la descrizione dell interfaccia (intesa come insieme di operazioni) offerta da un servizio: WSDL (Web Service Description Language); architettura ed interfaccia di un sistema di registro con accesso prevalentemente basato su identificatori univoci: UDDI (Universal Description, Discovery and Invocation); mentre risultano non ancora sufficientemente sviluppati i seguenti aspetti avanzati: protocolli per l invocazione remota con caratteristiche di affidabilità, auditing e sicurezza point-to-point; descrizione delle conversazioni supportate/ammesse dal servizio; descrizione dei livelli di qualità del servizio; descrizione dei requisiti e caratteristiche di sicurezza end-to-end del servizio; 7

19 Il Sistema Pubblico di Connettività e Cooperazione (SPC) Lucio Lecce descrizione della semantica del servizio e della semantica dell informazione veicolata dal servizio; definizione dell architettura e dell interfaccia di un sistema di registro con caratteristiche di accesso più flessibili, basate sugli aspetti avanzati precedentemente menzionati.[3] 5 5 Vedi p.0. 8

20 Il Sistema Pubblico di Connettività e Cooperazione (SPC) Lucio Lecce 2.2 Il Modello SPCoop Come accennato in precedenza, gli elementi fondamentali dell architettura del SPCoop sono: l Accordo di Servizio, la Busta di e-government, la Porta di Dominio e i Servizi SICA. Nella Figura 2 viene mostrata l architettura del SPC, si può notare il ruolo infrastrutturale che svolgono i SICA a livello di coordinamento, per regolamentare le interazioni tra le amministrazioni (PAC e PAL), e come le amministrazioni stesse si interfacciano al sistema attraverso le Porte di Dominio (PDC), utilizzando l infrastruttura di trasporto, fornita dal Sistema Pubblico di Connettività, interoperano attraverso i Servizi Applicativi. La Porta di Dominio (PDD) e la Busta di e-gov rappresentano rispettivamente l interfaccia tramite la quale interoperano le Amministrazioni ed il protocollo attraverso il quale le PDD comunicano tra loro. Descrivendo più nello specifico cosa è una PDD, si può dire che tutti i servizi applicativi sono erogati/fruiti attraverso questo unico elemento logico. Di fatto la PDD è la piattaforma presso cui sono disponibili le interfacce applicative dei servizi; non necessariamente i componenti software che realizzano tali servizi sono poi ospitati sulla stessa piattaforma della PDD, anzi molto frequentemente ed opportunamente essa svolgerà le funzioni di semplice proxy e dispatcher verso altre piattaforme di back-end presso cui sono effettivamente dispiegate le logiche applicative dei servizi. 9

21 Il Sistema Pubblico di Connettività e Cooperazione (SPC) Lucio Lecce Figura 2: Architettura del SPCoop 20

22 Il Sistema Pubblico di Connettività e Cooperazione (SPC) Lucio Lecce La Busta di e-gov è il protocollo applicativo con cui i servizi applicativi sono invocabili remotamente ed è una estensione dello standard SOAP., necessaria al fine di supportare la sicurezza point-to-point, l affidabilità della trasmissione e la tracciatura di tutte le comunicazioni (aspetti avanzati non ancora standardizzati a livello SOAP). La Busta e-gov è dunque una estensione SOAP specificatamente progettata per SPCoop. Prevede l utilizzo di un header appositamente predisposto, elaborato dalle Porte di Dominio, in grado di veicolare tutte le informazioni necessarie per implementare le suddette funzionalità; tutto questo in maniera trasparente alle applicazioni che fanno uso delle Porte. La Busta e-gov è logicamente suddivisa in due parti: una contiene tipicamente informazioni infrastrutturali, l altra veicola il contenuto applicativo del servizio oggetto della interazione. In sintesi una Porta di Dominio è una piattaforma in grado di offrire servizi applicativi in maniera tale da poter essere invocati remotamente secondo le specifiche della Busta e-gov. La Figura 3 mostra un esempio di comunicazione attraverso le PDD. Figura 3: Comunicazione attraverso le PDD 2

23 Il Sistema Pubblico di Connettività e Cooperazione (SPC) Lucio Lecce L Accordo di Servizio è il cardine per la gestione del ciclo di vita del servizio. I servizi SPCoop sono obbligatoriamente gestiti per versioni dell Accordo di Servizio. Più versioni di uno stesso servizio (corrispondenti a versioni diverse dell Accordo di Servizio) possono essere erogate nello stesso momento. Ogni versione segue un ciclo di vita autonomo, che è definito dal soggetto responsabile dell Accordo di Servizio stesso. Per ogni versione del servizio applicativo, il ciclo di vita è composto da 6 fasi: Definizione dell accordo di servizio. Registrazione dell accordo di servizio sul registro SICA nazionale generale. Implementazione del servizio. Presentazione del servizio sul SPCoop. Erogazione/fruizione del servizio sul SPCoop. Dismissione dell accordo di servizio e del servizio dal SPCoop.[6] 6 Nella fase di Definizione dell AS il servizio viene ideato e formalizzato nell accordo generale di servizio e eventualmente negli accordi specifici sul livello di servizio e sul livello di utilizzo. Il processo che porta alla definizione del servizio segue fondamentalmente due approcci: Approccio unilaterale: Nell approccio unilaterale, l accordo generale di servizio viene concepito unilateralmente dal soggetto titolare dell erogatore, o da un soggetto delegato. Accordi specifici di livello di servizio o di livello di utilizzo possono seguire l approccio unilaterale o l approccio concordato. Approccio concordato: Nell approccio concordato, l accordo di servizio è ideato in modo congiunto dall erogatore (o il suo rappresentante) e dal fruitore (o il suo rappresentante).[6] 7 6 Vedi p Vedi p.6. 22

24 Il Sistema Pubblico di Connettività e Cooperazione (SPC) Lucio Lecce Nel SPCoop, la Registrazione del servizio è obbligatoria e deve essere attuata nella seconda fase. La registrazione comprende molteplici attività da effettuare attraverso il Servizio di Registro SICA (generale o secondari): registrazione dei titolari dei sistemi erogatori nell indice dei soggetti della comunità SPCoop (SICA generale), registrazione degli accordi generali di servizio nel catalogo degli accordi (SICA generale), registrazione degli accordi specifici di servizio nel catalogo degli accordi (SICA generale o secondario), registrazione dei servizi da presentare nel registro dei servizi (SICA generale o secondario), registrazione dei porti di accesso ai sistemi erogatori nella rubrica degli indirizzi (SICA generale o secondario).[6] 8 Nella terza fase, cioè l Implementazione del servizio, il servizio viene realizzato secondo le specifiche concordate nell AS. In questa fase, i sistemi per l erogazione e per la fruizione del servizio vengono implementati dai rispettivi titolari in una modalità che sia in accordo con quanto definito nell AS a proposito dei livelli di servizio e dei livelli di utilizzo. Per come è modellata l architettura del sistema è possibile minimizzare i livelli di aderenza e interdipendenza reciproca delle architetture e delle tecnologie di implementazione dei sistemi erogatori e fruitori; infatti, l unico elemento tenuto al rispetto dei vincoli è l interfaccia di scambio di messaggi. Sul piano tecnico i vincoli che devono essere rispettati sono quelli relativi all implementazione delle tecnologie di connessione e di trasporto; vale a dire che i servizi implementati devono essere 8 Vedi p.6. 23