La specifica SPCoop per la Cooperazione Applcativa

La specifica SPCoop per la Cooperazione Applcativa

Questo capitolo descrive il contesto generale in cui si inserisce il lavoro svolto in questa tesi. Cominceremo con il presentare il paradigma della Cooperazione Applicativa (SPCoop) introdotto dal CNIPA, e le ragioni che hanno motivato la creazione di questa nuova specifica. Proseguiremo introducendo il progetto specifico che questa tesi intende analizzare e migliorare, OpenSPCoop, implementazione open source della specifica SPCoop. Verrà mostrato come questo progetto si inserisce nel panorama dei Web Service, introducendo infine le ultime tecnologie in ambito Web Service, i Web Service Mediator.

1.1 Cooperazione Applicativa

Prima che si cominciasse ad affermare l'idea della standardizzazione di un paradigma di cooperazione applicativa, le comunicazioni nella Pubblica Amministrazione avvenivano tramite collegamenti punto-punto tra i server applicativi interessati. Poiché tipicamente questi server erano dislocati su reti private, raggiungibili quindi esclusivamente da altri server dislocati sulla loro stessa rete privata, era necessario realizzare reti virtuali private (VPN) tra le amministrazioni interessate a cooperare.

Questa soluzione si è rapidamente dimostrata inadatta nella gestione del processo di eGovernment, che prevede che due qualunque enti debbano essere potenzialmente in grado di comunicare tra loro.

SPCoop [01] risolve questo problema imponendo un'infrastruttura standard di comunicazione tra le amministrazioni pubbliche. In tal modo, una volta che l'infrastruttura sia diventata completamente operativa, sarà sufficiente il collegamento di un'amministrazione all'infrastruttura SPCoop per abilitarla alla comunicazione con qualunque altra amministrazione italiana ed europea.

Alla specifica SPCoop si è giunti attraverso un certo numero di passaggi che qui ricordiamo:

. Nasce il Piano Nazionale di e-Government, emanato dal Ministero per l'innovazione e le Tecnologie con l'obiettivo di definire una rete di servizi usufruibili dai cittadini e dalle imprese attraverso un mezzo di trasmissione telematico.

. Il Centro Nazionale per l'Informatica nella Pubblica Amministrazione (CNIPA) istituisce un gruppo di lavoro, a cui prendono parte circa 120 esperti, in rappresentanza delle Amministrazioni centrali e locali, delle Associazioni dei fornitori e del CNIPA con lo scopo di definire:

• Un'infrastruttura di comunicazione in grado di collegare tutte le amministrazioni, denominato Sistema Pubblico di Connettività (SPC);
• Un insieme di standard tecnologici e di servizi infrastrutturali che permettano alle amministrazioni di interoperare attraverso interfacce applicative standardizzate, denominato Sistema Pubblico di Cooperazione (SPCoop).

Aprile 2004. Il CNIPA rilascia la versione 1.0 della specifica della busta e-Gov, che definisce il formato standard in cui debbano avvenire le richieste di servizio e lo scambio dei dati tra l'erogatore e il fruitore di un servizio nella Pubblica Amministrazione.

Novembre 2004. Il CNIPA rilascia la versione 1.0 dell'Architettura SPCoop, che descrive i servizi infrastrutturali comuni e le modalità d'interazione tra i vari componenti del Sistema Pubblico di Cooperazione.

Ottobre 2005. Il CNIPA completa la stesura di un insieme di documenti che costituiscono il riferimento tecnico per lo sviluppo dei servizi infrastrutturali volti a delineare il quadro tecnico ed implementativo del Sistema Pubblico di Cooperazione.

La figura seguente mostra i principali componenti dell'infrastruttura SPCoop: la busta eGov [02], la Porta di Dominio [03], le porte delegate e applicative, e il Registro dei Servizi [04].

Uno dei componenti principali della specifica SPCoop è la Porta di Dominio (PdD), che delimita il confine di responsabilità di un ente o soggetto amministrativo e racchiude al suo interno tutte le applicazioni da esso gestite. Le comunicazioni da e verso un dominio devono quindi attraversare la sua Porta di Dominio. Le PdD si parlano tra  loro scambiandosi richieste e risposte in un formato standard, denominato busta eGov, che è sostanzialmente una specializzazione di un messaggio SOAP, esteso con un apposito header per definire le caratteristiche del protocollo SPCoop.

La Porta Delegata e la Porta Applicativa costituiscono gli elementi della PdD che mediano gli accessi tra i sistemi interni agli enti e l'infrastruttura SPCoop. In particolare la Porta Delegata è utilizzata come proxy per l'accesso al servizio destinazione, mentre la Porta Applicativa deve essere in grado di gestire la consegna dei contenuti applicativi a un server interno al dominio destinazione.

La specifica SPCoop prevede poi la presenza di un registro dei soggetti e degli accordi di servizio tra essi stipulati. Si prevede l'esistenza di un registro di primo livello gestito dal CNIPA, che includa tutti i servizi ufficiali SPCoop a livello nazionale, e di registri di secondo livello che possano contenere un sottoinsieme di tali servizi. La specifica prevede infine la presenza di un Gestore Eventi per permettere lo scambio di buste eGov secondo l'architettura event-driven (EDA).

1.2 OpenSPCoop

OpenSPCoop [05] è un progetto finalizzato alla realizzazione di un insieme di componenti open source aderenti alle specifiche per la Cooperazione Applicativa nella Pubblica Amministrazione, recentemente rilasciate dal CNIPA e note con il nome di Servizio Pubblico di Cooperazione (SPCoop). Come per ogni nuova specifica non banale, anche per SPCoop è di fondamentale importanza l'esistenza di un'implementazione di riferimento open source, che permetta di sperimentare in maniera condivisa i vari concetti proposti nella specifica, evidenziando e proponendo possibili soluzioni per le potenziali ambiguità o debolezze della specifica stessa. Il progetto OpenSPCoop nasce sostanzialmente con questo obiettivo, enfatizzando i noti vantaggi dell'approccio open source per indirizzare i seguenti aspetti:

• Interoperabilità, OpenSPCoop intende rappresentare un riferimento per disambiguare diverse possibili interpretazioni della specifica SPCoop;
• Sicurezza, l'apertura del codice assicura quelle caratteristiche di trasparenza del codice ormai considerate un atto dovuto in molti settori della sicurezza informatica;
• Comunità d'utenza, OpenSPCoop tende a fungere da catalizzatore per le esperienze e le competenze degli utenti, permettendo di ricapitalizzarle in risultati concreti e riusabili;
• Innovazione, un'implementazione open source è il veicolo ideale per proporre delle implementazioni condivisibili di quanto non ancora trattato nelle specifiche SPCoop.

Preceduta da un'approfondita fase di analisi e di progettazione svolta presso il Dipartimento di Informatica dell'Università di Pisa, la prima release del software OpenSPCoop è stata rilasciata da Link.it [06] il 27 ottobre 2005. Questa prima release è stata poi seguita da frequenti nuovi rilasci, anche grazie al feedback e al contributo dei primi utenti del software, fino alla versione 1.0b3 del 20 Novembre 2007, terza beta della versione 1.0. Attorno al sito del progetto si è sviluppata sin dal primo momento una comunità di utenti e sviluppatori molto qualificati, provenienti da aziende italiane, pubbliche amministrazioni locali e centrali e centri di ricerca. Già agli albori di questo progetto si è concretizzata una piccola comunità attiva anche nello sviluppo dello stesso, comunità che nel tempo si è ampliata e resa ancora più partecipe nell'evoluzione del progetto; questo ha dimostrato tra l'altro la bontà della scelta di una soluzione open source in un settore così critico come quello indirizzato dalla specifica SPCoop.

1.3 La Specifica SPCoop nel Contesto dell'Architettura Web Service

Dal punto di vista del contesto tecnologico, la specifica SPCoop è fortemente basata sugli standard dei Web Service. In particolare, essa richiede la compatibilità dei messaggi applicativi con lo standard SOAP 1.1 [13], in accordo alla specifica WS-I Basic Profile 1.1 [14]. La specifica SPCoop comprende due aspetti principali:

1. Il formato di un header di protocollo SOAP, comunemente riferito come busta eGov, che permette la gestione di numerosi aspetti del protocollo di comunicazione tra Enti Pubblici, quali l'indirizzamento, l'affidabilità della consegna e la gestione dei duplicati.
2. Un insieme di norme organizzative, che identificano alcuni componenti (principalmente le Porte di Dominio e i Registri di Servizi) e il loro ruolo di supporto alla cooperazione tra i servizi applicativi dei singoli domini. In particolare la Porta di Dominio ha un ruolo di mediazione tra i servizi applicativi interni al dominio e le Porte di Dominio degli altri Enti.

Poichè non è previsto che il formato della busta eGov sia parlato nativamente dalle applicazioni, la Porta di Dominio deve anche occuparsi di convertire le richieste applicative in formato proprietario nel formato di busta eGov. Facendo riferimento a questa problematica, i compiti della Porta di Dominio sono solitamente divisi in due diverse componenti: il componente di integrazione e quello di cooperazione. Mentre la specifica SPCoop copre completamente gli aspetti relativi al componente di cooperazione, per quanto attiene al componente di integrazione essa si limita a presentare un esempio di massima di una possibile realizzazione. Per questo motivo, i vari prodotti finora realizzati si differenziano significativamente proprio per quanto attiene al componente di integrazione, cioè a come costruire le buste a partire dai dati forniti dall'applicativo.

Il problema rientra nella problematica più generale dell'uso dei Web Service per l'Integrazione Applicativa in ambito Enterprise (EAI), problema di importanza centrale negli ambienti Enterprise, e per il quale si sono andate evolvendo soluzioni sempre più sofisticate.

Approccio "End to End"

Il problema è stato gestito per molto tempo, e in larga parte ancora adesso, direttamente dagli applicativi (mittente e richiedente), che si occupavano in prima persona di gestire sia le modalità di integrazione (imbustamento dei contenuti applicativi in SOAP) che quelle di cooperazione (gestione dei vari servizi a livello di header SOAP).

Approccio "Enterprise Service Bus"

In vista di un significativo incremento dei servizi realizzati tramite tecnologia Web Service all'interno delle organizzazioni, sono stati sviluppati ambienti che forniscono servizi infrastrutturali comuni per la gestione dell'affidabilità, il routing e la trasformazione dei servizi web. Tali soluzioni, note come Enterprise Service Bus (ESB), forniscono quindi servizi comuni sia di Integrazione che di Cooperazione. Tra gli ESB più noti ci sono Mule, ServiceMix, Celtix e Artix.

Gli ESB hanno costituito un significativo passo avanti per la gestione delle problematiche tipiche dell'EAI. Tuttavia, proprio in quanto indirizzati alla gestione di problematiche di integrazione "general purpose", si tratta di ambienti significativamente complessi, tanto da manifestare alcune controindicazioni per l'implementazione dell'ambiente SPCoop:

1. La configurazione di nuovi servizi è in generale piuttosto complessa e richiede solitamente la scrittura di codice ad-hoc per programmare le logiche di trasformazione. Questa complessità aumenta il rischio di errori nella configurazione dei nuovi servizi.
2. Le funzionalità di trasformazione di messaggio dei Service Bus non sono sufficienti a gestire il protocollo SPCoop, che prevede complesse logiche di indirizzamento e affidabilità. Quindi, anche usando un ESB rimane necessario implementare il servizio SPCoop come servizio di base, parte del core del Service Bus.
3. L'uso di una piattaforma "general purpose" di questo tipo rende difficile assicurare performance elevate in termini di numero di messaggi gestibili al secondo. Questo problema è particolarmente serio per quelle istanze di Porte di Dominio che operano come smistatori e validatori di messaggi in transito, come ad esempio si può verificare per dei gateway interregionali. Queste porte hanno solo funzionalità di cooperazione e non di integrazione, e sono proprio quelle soggette al maggior carico di messaggi da smistare.
4. Gli ESB supportano sempre connettori SOAP su vari trasporti standard (come SMTP, HTTP e HTTPS); tuttavia le funzionalità a maggior valore aggiunto sono specifiche per la piattaforma sulla quale sono implementati (ad esempio disponibilità del trasporto JMS per gli ESB su piattaforma J2EE). Quindi la dipendenza dalle funzionalità a valore aggiunto degli ESB implica spesso anche la dipendenza da una specifica architettura software.

1.4 Web Service Mediation

Un nuovo approccio per la soluzione della stessa problematica affrontata dagli ESB è emerso di recente in alcuni progetti, tra i quali sta raggiungendo una notevole notorietà il progetto Apache Synapse [07]. In questo approccio si parte dalla constatazione che l'ampia diffusione dell'XML e del paradigma dei Web Service permette di considerare i sistemi interni al Dominio di Servizio come già capaci o facilmente adattabili al dialogo tramite Web Service. Se si assume questa premessa, la componente di integrazione del Service Bus non dovrà più supportare tecnologie diverse per ogni possibile sistema legacy da interfacciare (CORBA, RMI, JMS, .NET, etc.), ma potrà essere invece un generico container che funga da mediatore dei messaggi SOAP in arrivo dai clienti interni per i servizi esterni e viceversa.

Il mediatore potrà ancora fornire tutti i servizi a valore aggiunto dei Service Bus, introducendo o interpretando gli headers del messaggio SOAP in transito, ma rispetto agli ESB tradizionali esporrà solo un generico connettore per l'accettazione di buste SOAP, come componente di integrazione.

Dal punto di vista dell'architettura Web Service, il ruolo del Web Service Mediator è quello di un "nodo intermedio". L'architettura dei Web Service prevede infatti che un messaggio SOAP viaggi dal mittente fino al destinatario finale, passando eventualmente attraverso un certo numero di nodi intermedi. Ogni nodo intermedio quindi riceverà il messaggio SOAP e lo ritrasmetterà verso la destinazione finale. Il messaggio passando da un nodo all'altro può essere manipolato secondo le politiche definite per ogni servizio. Di conseguenza quello del Web Service Mediator si pone anche come l'approccio più corretto da un punto di vista architetturale.