Accordo di servizio. Uno stralcio di Accordo di Servizio ad evidenziare l utilizzo di XML:

Transcript

1 Accordo di servizio Insieme delle definizioni, delle funzionalità, delle interfacce, dei requisiti di sicurezza e di qualità di uno o più servizi applicativi che vengono scambiati tra due amministrazioni pubbliche. L Accordo di Servizio è un documento standard totalmente formalizzato in XML che regola il rapporto erogatore/fruitore di un singolo servizio applicativo in tutte le parti che lo caratterizzano come l interfaccia, le modalità di interazione, i punti di accesso, i livelli di servizio e le caratteristiche di sicurezza previste. L Accordo di Servizio consente lo sviluppo armonico di un insieme trasparente di relazioni di servizio che, sul piano tecnico, consentono di aumentare sia l efficienza nell erogazione dei servizi telematici che il relativo livello di qualità. Ogni Accordo di Servizio si compone di due parti, una comune (per tutti gli accordi omologhi, ad esempio anagrafe) ed una specifica (da caratterizzare se necessario con ogni amministrazione cooperante), di seguito si illustra una schematizzazione logica di un accordo di servizio e della relativa parte comune: Uno stralcio di Accordo di Servizio ad evidenziare l utilizzo di XML: <?xml version="1.0" encoding="utf-8"?> <xsd:schema xmlns= targetnamespace= xmlns:xsd= elementformdefault="qualified" attributeformdefault="unqualified"> <xsd:element name="registro-servizi">

2 <xsd:complextype> <xsd:sequence> <xsd:element maxoccurs="unbounded" minoccurs="0" ref="accordo-servizio" /> <xsd:element maxoccurs="unbounded" minoccurs="0" ref="soggetto-spcoop" /> <xsd:element maxoccurs="unbounded" minoccurs="0" ref="connettore" /> </xsd:sequence> </xsd:complextype> </xsd:element> AP Il progetto ICAR si articola in un insieme di interventi progettuali paralleli, coordinati ed integrati tra loro: tre interventi di carattere infrastrutturale (INF) di tipo orizzontale e sette interventi di tipo verticale per lo sviluppo di casi di studio applicativi (AP). Questo nasce dalla consapevolezza che le infrastrutture sono indispensabili per veicolare tutte le banche dati di cui le amministrazioni dispongono e disporranno, ma occorre una metodologia condivisa per sviluppare ed operare in un ambito applicativo concreto. Questo può sicuramente essere visto come uno dei più importanti aspetti innovativi di ICAR : una doppia valenza che propone una nuova visione di insieme sia sul tema dell'infrastruttura che su quello dei contenuti. Nell'ambito dei contenuti, le Regioni e le Province Autonome si sono suddivise a seconda della propria sensibilità normativa e politica, individuando sette tematismi (Task). AP1 - La cooperazione e la compensazione sanitaria interregionale: temi come l'identificazione dell'assistito, la mobilità sanitaria, l'informativa per i medici di base, l'accesso ai dati clinici e amministrativi mettono in evidenza come sia necessario poter cooperare e lavorare in più regioni su temi di questo tipo e permettere all'utente, in qualunque regione si trovi, di poter accedere alla propria base dati ed avere anche una migliore assistenza. AP2 - La cooperazione tra i sistemi di anagrafe: apre un fronte di servizi complessivi per utenti, cittadini e imprese. AP3 - Area organizzativa omogenea: il livello di integrazione verrà realizzato attraverso un modulo integrativo di interfaccia tra sistema interregionale e l'applicazione che compete a ogni livello regionale. AP4 - Lavoro e servizi per l'impiego: l'obiettivo è facilitare il processo della domanda e dell'offerta di lavoro attraverso banche dati interregionali. AP5 - Tassa Automobilistica regionale: sembra una piccola cosa ma può portare benefici anche alle fonti di reddito dei sistemi tributari regionali. AP6 - Osservatorio interregionale sulla rete distributiva dei carburanti. AP7 - Sistema informativo interregionale: per realizzare un sistema federato di accesso ai sistemi statistici regionali. Applicativi Per applicativo in ambito di cooperazione applicativa, si intende un software di elaborazione dati capace di interfacciarsi attraverso l esposizione di web services con la porta di dominio dell ente di appartenenza, questo al fine di cooperare con altri applicativi (anche completamente diversi) di altre amministrazioni all interno di un Accordo di Cooperazione e secondo le specifiche dei relativi accordi di servizio.

3 Autenticazione (Sistema Federato di Identità Digitale) La cooperazione applicativa è trasparente, ossia ogni operatore continuerà ad utilizzare il suo applicativo aziendale con le sue credenziali (smartcard o username/password). Concretamente il flusso attraverso gli applicativi (che possono essere diversi; ad esempio l applicativo sanitario della Regione A con l applicativo anagrafe della Regione B) avviene in questo modo l operatore della Regione A si autentica col suo applicativo regionale, a questo punto viene elaborata una funzione che richiede l acquisizione di informazioni dall applicativo della Regione B. Per garantire tale flusso il progetto ICAR e più in generale l SPCoop prevedono la federazione dei sistemi di identità digitale, ossia ogni sistema locale viene predisposto per cooperare con le altre amministrazioni anche per la gestione delle identità, dispiegando servizi che consentono nella massima sicurezza la verifica delle credenziali secondo un principio di reciproca fiducia. Busta E-gov I messaggi scambiati tra Enti della PA attraverso le Porte di Dominio, sono racchiusi in una Busta (Busta di e-gov), questa è un protocollo applicativo 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. Tale Busta è logicamente suddivisa in due parti, una parte che contiene tipicamente informazioni infrastrutturali, ed una parte di contenuto dipendente dal servizio applicativo oggetto della interazione. Poiché la finalità è quella di mantenere totalmente autonome le amministrazioni nella definizione del contenuto applicativo ma nel contempo di uniformare le informazioni necessarie alla gestione dello scambio in modalità sicura e affidabile, tali specifiche riguardano esclusivamente la definizione degli elementi di carattere infrastrutturale, senza entrare nel contenuto dei dati applicativi trasportati. Il messaggio è rappresentato da una struttura SOAP composta da due parti. una Header; un Body o Corpo. Nell Header SOAP è definito l elemento Intestazione che contiene tutte le informazioni legate alla logica di gestione del messaggio. Nella Header è prevista la possibilità di inserire una o più firme digitali (una per ogni elemento firmato). Nel Corpo, invece, vi sono i riferimenti agli altri blocchi dati o in alternativa contenuti informativi limitati e pre-classificati, i cosiddetti dati applicativi. Di seguito uno stralcio di una busta di e-gov per sottolineare l utilizzo dell XML come linguaggio:.<?xml version="1.0" encoding="utf-8"?> <xsd:schema targetnamespace=" xmlns:egov_it=" xmlns= xmlns:xsd=" xmlns:soap_env=" elementformdefault="qualified" attributeformdefault="unqualified"> <xsd:import namespace=" schemalocation=" <xsd:element name="azione" type="xsd:string"/> <xsd:element name="collaborazione" type="identificatoretype"/> <xsd:element name="confermaricezione"> <xsd:complextype> <xsd:sequence> <xsd:element ref="oraregistrazione"/> </xsd:sequence> </xsd:complextype></xsd:element>.

4 CNIPA Il Centro Nazionale per l Informatica nella Pubblica Amministrazione (CNIPA) opera presso la Presidenza del Consiglio per l attuazione delle politiche del Ministro per le riforme e le innovazioni nella PA. 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 esecuzione degli accordi relativi allo sviluppo del sistema di cooperazione applicativa nell ambito dell SPC, il CNIPA ha completato la stesura del nuovo set di documenti che costituisce il riferimento tecnico per lo sviluppo dei servizi infrastrutturali generali e della porta di dominio. Unitamente alle specifiche della busta e-gov questi documenti delineano compiutamente il quadro tecnico-implementativo del Sistema Pubblico di Cooperazione (SPCoop). I documenti rappresentano, inoltre, un riferimento per i piani di convergenza dei progetti infrastrutturali di cooperazione già realizzati o in corso di realizzazione. Tra questi progetti, ad esempio, è significativo il progetto ICAR, cofinanziato dal CNIPA nell ambito della II fase di e-government, che rappresenta il motore della convergenza dei progetti regionali di cooperazione applicativa nel SPC. In questo modo, pur preservando le autonomie, l approccio di sistema adottato consentirà una visione unitaria ed integrata dei back office delle amministrazioni centrali e locali. Cooperazione applicativa - Interoperabilità Con i termini interoperabilità e cooperazione applicativa ci riferiamo ad una specifica capacità di due o più sistemi informativi connessi in rete. E ovvero la capacità che essi devono avere, affinché l applicazione, operante in ciascun sistema, sia in grado di disporre automaticamente, per le proprie finalità applicative, dei dati che sono producibili e/o acquisibili solo attraverso il processo elaborativo delle applicazioni operanti negli altri sistemi informativi. In particolare, l interoperabilità attiene alla capacità di due o più sistemi informativi di scambiarsi informazioni e di attivare, a suddetto scopo, processi elaborativi nelle rispettive applicazioni. Ciascun sistema informativo può differenziarsi in genere dall altro per le scelte implementative (e.g. linguaggio di programmazione e formato dei dati). In tal caso, un approccio che può garantire interoperabilità è ad esempio l adozione di uno stesso formato di interscambio dei dati e di un protocollo di comunicazione condiviso. La cooperazione applicativa attiene alla capacità di uno o più sistemi informativi di avvalersi, ciascuno nella propria logica applicativa, dell interscambio automatico di informazioni con gli altri sistemi, per le proprie finalità applicative. In altre parole, un applicazione nel corso del suo processo elaborativo può far cosi uso di un informazione elaborata da un altra applicazione. La cooperazione applicativa in rete ha luogo quando ciò avviene in modo automatico. L interoperabilità è quindi un prerequisito essenziale per la cooperazione applicativa. Garantire l interoperabilità e la cooperazione applicativa tra i sistemi informativi delle Pubbliche Amministrazioni (PPAA), operanti a livello centrale, regionale e locale, è diventato quindi un requisito di primaria importanza al fine di realizzare il pieno ed efficace sviluppo dell e-government. Ciò risponde a due esigenze principali: integrare i processi automatizzati di back-office per l erogazione di servizi interni (da una PA all altra) ed esterni (dalle PPAA verso i cittadini); erogare al cittadino servizi finali integrati in rete al cittadino in modo trasparente ed unitario. In altre parole, l obiettivo è garantire al cittadino la possibilità di rivolgersi ad un unico sportello (online) per la fruizione di un servizio, senza avere la percezione del coinvolgimento di più amministrazioni nell erogazione del servizio richiesto, ove ciò sia necessario (secondo il modello di servizi di e-government one-stop ).

5 Efficacia ed Efficienza Gli anni 90 sono stati caratterizzati da un momento di grande crisi politica e istituzionale che ha finito per coinvolgere anche la P.A. La grande produzione normativa avvenuta nell ultimo decennio del secolo appena trascorso è stata segnata da una grande coerenza che la lega ad un filo comune: quello di avvicinare la P.A. alla società civile con il decentramento di molte funzioni dallo Stato agli Enti Locali e riformando tutta la P.A. su criteri di: - efficienza cioè competenza e prontezza nell assolvere le proprie mansioni; - efficacia cioè la capacità di produrre l effetto voluto; - economicità. In particolare l art. 13 del Codice della PA Digitale lega strettamente l utilizzo delle tecnologie al raggiungimento di obiettivi di efficacia, efficienza economicità dell attività amministrativa. Le pubbliche amministrazioni devono utilizzare le tecnologie in modo da razionalizzare e semplificare i procedimenti amministrativi, le attività gestionali, la modulistica, le modalità di accesso ai servizi. Non basta informatizzare: l innovazione tecnologica deve essere chiaramente orientata ad un maggiore efficienza interna ed efficacia dei servizi resi a cittadini e imprese. L efficienza è il primo degli obiettivi, ed è abbastanza chiaro. Grazie alle ICT, le amministrazioni possono essere più rapide ed offrire servizi migliori, a parità di costo. Per ottenere ciò, è però necessario provvedere alla riorganizzazione ed aggiornamento dei servizi resi (art. 7), ma anche alla razionalizzazione e semplificazione di tutta la catena di gestione dei procedimenti amministrativi (art. 15). L efficacia non deriva solo dall efficienza, perché - nel riorganizzare i servizi - è necessario effettuare una preventiva analisi delle reali esigenze dei cittadini e delle imprese, anche utilizzando strumenti per la valutazione del grado di soddisfazione degli utenti stessi (art. 7 e 63). Tali pratiche sono da considerarsi ormai imprescindibili nell implementazione di qualsiasi politica pubblica, indipendentemente dall uso delle tecnologie. Esse comportano inoltre un rilancio degli Uffici per le relazioni con il Pubblico (URP), che possono in questa veste assumere un ruolo particolarmente strategico per le amministrazioni. ICAR Nell ottica di una visione condivisa tra Stato, Regioni ed Enti Locali, per lo sviluppo federato e cooperativo dell e-government, è stato assegnato alle Regioni uno specifico ruolo di proposta e di implementazione delle infrastrutture per la società dell informazione. In particolare alle Regioni è stato rivolto l avviso pubblicato dal CNIPA per la selezione di progetti per lo sviluppo dei servizi infrastrutturali e SPC, per la seconda fase di attuazione dell egovernment. Le Regioni, quasi nella loro totalità, hanno singolarmente presentato, in risposta all avviso, un progetto regionale che formalizza l impegno nella realizzazione coordinata e cooperativa del progetto interregionale ICAR (Interoperabilità e Cooperazione Applicativa in rete tra le Regioni). Il progetto ICAR è stato elaborato attraverso il coordinamento interregionale del Centro Interregionale per il Sistema Informatico ed il Sistema Statistico (CISIS), avvalendosi anche del supporto dello staff tecnico della tecnostruttura Q3I del medesimo centro. L obiettivo del progetto è di abilitare l interoperabilità e la cooperazione applicativa in rete tra i sistemi informativi di diverse amministrazioni pubbliche, nei domini applicativi che richiedono

6 cooperazione tra le amministrazioni regionali. Nel suo complesso, il progetto prevede la partecipazione di 16 Regioni e di 1 Provincia Autonoma ed ha una durata di 36 mesi. Le attività saranno cofinanziate dalle Regioni e dal CNIPA, secondo i termini e le modalità stabiliti nel suddetto avviso. Il finanziamento complessivo attualmente previsto per le attività del progetto, sia a livello interregionale che delle singole Regioni, è di circa 24 milioni di Euro. Le Regioni coinvolte nel progetto si propongono di cooperare in modo stretto per realizzare un sistema integrato di strutture e servizi che abilitino l interoperabilità e la cooperazione applicativa tra i sistemi di e-government a livello interregionale e regionale. Per risolvere le problematiche sopra accennate, le Regioni intendono cooperare alla realizzazione del progetto ICAR, mirando al raggiungimento dei seguenti obiettivi: realizzare l interconnessione sicura delle reti regionali, nella logica dell SPC, realizzando di fatto anche il primo nucleo sperimentale dell SPC in ambito nazionale; garantire lo scambio di flussi informativi e la cooperazione applicativa tra tutte le amministrazioni e gli enti dei diversi contesti regionali; implementare e sperimentare in campi applicativi di prioritario interesse delle Regioni i protocolli e formati di interscambio standard, al fine di fornire servizi efficienti agli utenti finali; promuovere la convenienza economica e l estensibilità ad ambiti applicativi, non previsti inizialmente dal progetto, basandosi sui principi di economia di scala e di riuso delle soluzioni tecnologiche ed organizzative e, dal punto di vista tecnico, sulla definizione di servizi infrastrutturali, estensibili con costi relativamente minimi rispetto a soluzioni ad hoc; promuovere la cooperazione con altre PPAA (PAC e PAL), aderendo ai processi di standardizzazione in contesti extra-regionali (e.g. linee guida nazionali ) INF Il progetto ICAR si articola in un insieme di interventi progettuali paralleli, coordinati ed integrati tra loro: tre interventi di carattere infrastrutturale (INF) di tipo orizzontale e sette interventi di tipo verticale per lo sviluppo di casi di studio applicativi (AP). Questo nasce dalla consapevolezza che le infrastrutture sono indispensabili per veicolare tutte le banche dati di cui le amministrazioni dispongono e disporranno, ma occorre una metodologia condivisa per sviluppare ed operare in un ambito applicativo concreto. In particolare il progetto ICAR prevede tre interventi progettuali a carattere infrastrutturale, che hanno come obiettivo la realizzazione dei servizi di base a livello infrastrutturale e di strumenti di gestione, conformi a modelli logici e specifiche condivise a livello interregionale: Intervento INF-1 Realizzazione dell Infrastruttura di base per l Interoperabilità e la Cooperazione Applicativa a livello interregionale ha come obiettivo la realizzazione dell infrastruttura fisica e logica indispensabile per l Interoperabilità e la Cooperazione Applicativa interregionale. Intervento INF-2 Gestione di Strumenti di Service Level Agreement a livello interregionale 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. 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 a livello interregionale. Le funzionalità sviluppate mediante questi interventi sono trasversali rispetto ai livelli applicativi che usufruiscono dell infrastruttura di cooperazione.

7 Porta applicativa e Porta delegata Nell'architettura prevista dagli allegati tecnici al piano di e-government nazionale la porta applicativa di un ente è un punto di accesso telematico che espone una o più applicazioni in grado di fornire i servizi invocati dalle porte delegate. Secondo il paradigma del framework regionale le porte applicative sono Web Services che dialogano in modalità SOAP con le porte delegate. La porta delegata è quindi quella infrastruttura che, sottesa al portale di accesso o al sistema informativo di front-end di un ente, si incarica di instradare in modalità SOAP una richiesta, formattandola correttamente, alla porta applicativa dell ente in grado di soddisfarla. Porta di dominio Una delle componenti dell SPCoop è rappresentata dalle Porte di Dominio. Le Porte dovranno interagire con i Servizi Applicativi esposti dalle singole Amministrazioni e colloquiare tra loro secondo gli standard definiti nell ambito dell SPCoop in maniera paritetica. La porta di dominio rappresenta il confine di responsabilità dell ente nel sistema SPC, in pratica l intero sistema informativo dietro la porta di dominio è di sola e diretta responsabilità dell ente, mentre il resto appartiene al sistema di cooperazione, condiviso con le altre amministrazioni cooperanti. Le componenti della Porta implementano le seguenti funzioni infrastrutturali: Funzionalità di base Gestione Busta e-gov Gestione Tracciatura Gestione Diagnostici Gestione SOAP with Attachments Gestione modalità consegna affidabile Gestione della Sicurezza Consolle di Monitoraggio Requisiti Funzionali - Acquisizione - La Porta di Dominio deve gestire i Messaggi Applicativi ricevuti dai Servizi Applicativi presenti all interno del Dominio; - Inoltro - La Porta di Dominio deve inoltrare il Messaggio Applicativo al Dominio destinatario; - Ricezione - La Porta di Dominio deve gestire i Messaggi SPCoop provenienti dalle altre Porte di Dominio secondo le specifiche della Busta di e-gov; - Smistamento - La Porta di Dominio deve inoltrare i Messaggi Applicativi ai servizi applicativi destinatari presenti all interno del Dominio; - Smistamento Errore - La Porta di Dominio, che riceve un Messaggio di Errore SPCoop deve inoltrare un Messaggio Applicativo Errore al servizio applicativo destinatario presente all interno del Dominio; - La Porta di Dominio deve generare un Messaggio SPCoop Errore nel caso di eccezioni, gestite dalla Porta, sollevate durante la fase di sbustamento oppure durante la fase di smistamento di Messaggi SPCoop contenenti richieste di interazioni sincrone o asincrone di tipo Richiesta/risposta oppure Notificazione/risposta ; - La Porta di Dominio deve gestire i Soap: Fault (non contenuti in Messaggi di Errore SPCoop) generati automaticamente dal Soap Server destinatario a seguito di richieste relative a scenari di coordinamento Richiesta/risposta ; - Tracciamento - La Porta di Dominio deve gestire il log dei Messaggi SPCoop ricevuti/inviati; - Monitoring - La Porta di Dominio deve gestire i Messaggi diagnostici generati; - La Porta di Dominio deve allineare il tempo di sistema al riferimento temporale di rete;

8 Registro dei Servizi (SICA) I Servizi di Registro sono il componente software in cui gli Accordi di Servizio vengono registrati e mantenuti. Semplificando, si può dire che, poichè sono una base di dati di Accordi di Servizio e Cooperazione, i quali riuniscono le informazioni basilari per la cooperazione, i servizi di registro costituiscono, di fatto, la base di dati della cooperazione. Questa componente offre funzionalità per la registrazione, l accesso, l aggiornamento, la cancellazione e la ricerca degli Accordi di Servizio (e di Cooperazione). Lo standard UDDI costituisce un punto di partenza per la definizione, progettazione e realizzazione di tale componente. Fra tutti gli elementi infrastrutturali definiti nei servizi SICA, ai Servizi di Registro spetta un ruolo di primo piano, proprio per la loro natura di cardine di tutto il modello di cooperazione applicativa. Questo elemento costituisce quindi uno degli elementi base del SICA, e può essere articolato su due livelli, indicati come Generale e Secondario. In particolare, i Servizi di Registro SICA possono essere organizzati in modo distribuito attraverso un architettura masterslave con replicazione dell informazione così strutturata: un occorrenza dei Servizi di Registro SICA, indicata brevemente come Registro SICA Generale, che contiene la totalità delle informazioni necessarie all erogazione delle funzionalità previste; un numero N di occorrenze dei Servizi di Registro SICA, indicate brevemente come Registri SICA Secondari, che contengono delle viste (i.e., sottoinsiemi, non necessariamente disgiunti) di tali informazioni, definite secondo differenti criteri (e.g., localizzazione geografica, per affinità funzionale, per affinità rispetto all erogatore, etc.) Un informazione presente in un Registro Secondario è sicuramente presente nel Registro Generale, ma non vale necessariamente il viceversa (possono esserci informazioni mantenute nel solo Registro Generale e non replicate in nessun Registro Secondario). Il documento SERVIZI DI REGISTRO dettaglia la specifica funzionale di questo componente e la sua architettura concettuale, in maniera da fornire il riferimento per la successiva realizzazione di questo elemento. Smartcard (Username/password) La smart card è un dispositivo hardware delle dimensioni di una carta di credito che possiede potenzialità di elaborazione e memorizzazione dati ad alta sicurezza. Più in generale, il termine smart card sottintende un insieme di tecnologie, comprendenti circuiti integrati, microprocessori, memorie RAM, ROM, EEPROM, antenne, ecc., integrate nello stesso circuito elettrico per formare un microchip che è il cuore della smart card La smart card è costituita da un supporto di plastica nel quale è incastonato un microchip connesso ad un interfaccia di collegamento che può essere una contattiera o un antenna. Il microchip fornisce funzionalità di calcolo e memorizzazione dati; la contattiera o l antenna consentono al microchip di dialogare con uno speciale terminale di lettura collegato solitamente ad un computer mediante porta seriale, parallela, USB, ecc. SOA L architettura dei servizi di cooperazione applicativa adotta il modello SOA (Service Oriented Architecture).

9 Il paradigma find-bind-execute della SOA prevede: - La registrazione di un servizio su di un sistema di Registro da parte di una amministrazione proponente (Fornitore di servizi) - La ricerca di un servizio da parte di un amministrazione fruitrice (Client) e la connessione al servizio - L esecuzione del servizio stesso SPC Spcoop L SPcoop è l'insieme di infrastrutture tecnologiche e di regole tecniche, per lo sviluppo, la condivisione, l'integrazione e la diffusione del patrimonio informativo e dei dati della pubblica amministrazione, necessarie per assicurare l'interoperabilità di base ed evoluta e la cooperazione applicativa dei sistemi informatici e dei flussi informativi, garantendo la sicurezza, la riservatezza delle informazioni, nonché la salvaguardia e l'autonomia del patrimonio informativo di ciascuna pubblica amministrazione. Il Sistema Pubblico di Connettività (SPC) ed Sistema Pubblico di Cooperazione (SPCoop) forniscono una infrastruttura comune per l interconnessione, fino al livello applicativo, delle amministrazioni pubbliche, centrali e locali. La loro realizzazione costituisce il presupposto essenziale per integrare, velocizzare ed armonizzare i processi di comunicazione tra i back-office delle amministrazioni, attività propedeutiche per una efficiente erogazione di servizi on-line a cittadini ed imprese. Una delle componenti di tale disegno infrastrutturale è rappresentata dalle Porte di Dominio. Le Porte dovranno interagire con i Servizi Applicativi esposti dalle singole Amministrazioni e colloquiare tra loro secondo gli standard definiti nell ambito dell SPCoop in maniera paritetica. Per attuare tale disegno occorre che tutti gli attori (amministrazioni centrali e locali, enti ed aziende): condividano le specifiche, gli standard e le modalità di realizzazione e gestione dei complessi elementi infrastrutturali comuni che disaccoppiano i sistemi delle amministrazioni ed implementano i servizi che abilitano la cooperazione applicativa tra sistemi; si impegnino ad esporre ed utilizzare (in qualità di fruitori) servizi erogati da terzi secondo modalità standard predefinite e consolidate tecnologie di mercato. Standard XML L'XML, acronimo di extensible Markup Language, ovvero «Linguaggio di marcatura estensibile» è un metalinguaggio creato e gestito dal World Wide Web Consortium (W3C), e più precisamente dal presidente di tale "consorzio", Michael Sunshine. È una semplificazione e adattamento dell'sgml, da cui è nato nel 1998, e permette di definire la grammatica di diversi linguaggi specifici derivati. Rispetto all'html, l'xml ha uno scopo ben diverso: mentre il primo è un linguaggio per la realizzazione della struttura di template di pagine Web, il secondo è un linguaggio utile allo scambio dei dati, quindi di back-office e non di front-office, o di esposizione che dir si voglia. Per scambio dei dati si intende la conservazione in una struttura XML di dati presi, presumibilmente, da un database o da altre fonti, oppure memorizzati direttamente all'interno di una struttura XML. Ecco un esempio tipico di file XML: <?xml version="1.0" encoding="iso "?> <utenti> <utente> <nome>luca</nome>

10 <cognome>ruggiero</cognome> </utente> <utente> <nome>max</nome> <cognome>rossi</cognome> </utente> </utenti> Web Services I Web services forniscono un approccio comune largamente diffuso - per definire pubblicare e usare servizi secondo il modello SOA I web services forniscono i mezzi standard di interoperabilità fra applicazioni differenti, funzionanti su diverse piattaforme. I web services sono caratterizzati dalla loro alta capacità di essere interoperabili ed estensibili, grazie soprattutto all utilizzo del linguaggio XML (da Web Services Activity Statement W3C)