GovMix

L’INAIL già da circa un anno ha avviato la sperimentazione per realizzare l’erogazione dei propri servizi in cooperazione applicativa attraverso SPCoop. Già alcuni servizi sono stati attivati in via sperimentale, come ad esempio il servizio di “Denuncia Infortunio a fini assicurativi”, come annunciato sul sito dello stesso istituto tramite un comunicato.

Per semplificare lo scambio di informazioni con i soggetti partecipanti alla sperimentazione, al fine di rendere trasparenti, e quindi facilmente acquisibili, i dettagli tecnici necessari, INAIL ha reso disponibile un ambiente web di facile consultazione.

Il sito in questione propone i dati relativi ai servizi erogati tramite la Porta di Dominio INAIL in fase di collaudo ed è raggiungibile all’indirizzo:

http://spc.test.inail.it/pdd/controller?action=pa_index

Vediamo nella figura seguente un’immagine del sito:

registro servizi INAIL

Il pannello di sinistra elenca i servizi erogati al momento dalla PdD INAIL. Le voci presenti in tale pannello fungono anche da elementi di navigazione che consentono di visualizzare sul pannello di destra i dati di dettaglio relativi a ciascun servizio.

Vediamo con maggior dettaglio come è organizzato il sistema di consultazione.

Gli elementi della lista del pannello sinistro rappresentano i Procedimenti Amministrativi.

Quelli attualmente presenti sono:

• Certificati Medici

• Comunicazione Unica

• Convenzione INPS-INAIL

• Denuncia Infortunio

• Immigrazione

• Integrazione CC

• Lavoro Occasionale Accessorio

• Servizi DURC (4.0)

• Servizi DURC (4.1)

• Servizi Patronati (Mandato 1P)

• Servizio di TEST

Selezionando un procedimento amministrativo dalla lista, la voce si espande mostrando gli accordi di servizio ad esso riferiti. Selezionando l’accordo di servizio, sul pannello di destra si apre la pagina di dettaglio dello stesso, contenente:

• Endpoint del servizio

• Link per scaricare l’accordo di servizio parte comune in formato package SICA

• Link per visualizzare il WSDL

• Informazioni sulla sicurezza

Per ciascun Port-Type previsto nel WSDL, una tabella con i seguenti dati:

• Nome del Port-Type

• Lista delle operation previste e relativo profilo di cooperazione

• Lista dei soggetti fruitori

L’invio delle Comunicazioni Obbligatorie avviene tramite la fruizione di un servizio erogato dal sistema informatico del Ministero del Lavoro. L’operazione di trasmissione avviente tramite un comunicazione con profilo di cooperazione Sincrono avente una durata arbitrariamente lunga.

Alcuni client non prevedono una corretta gestione del timeout della connessione HTTP che può verificarsi abbastanza di frequente se non si è impostato un tempo sufficientemente ampio di timeout. Se il server invia la risposta dopo il timeout, il client non riceverà conferma e quindi ritenterà l’invio. Le richieste successive alla prima comporteranno la risposta del server “Comunicazione già presente” invece di “Invio effettuato correttamente”. Questa situazione porta ad un loop nel client che non riesce ad interpretare il primo messaggio nella maniera corretta.

Il modulo adattatore che è stato realizzato, supera questo problema ponendosi come interlocutore per il client trasformando opportunamente il messaggio di risposta del server per preservare le funzionalità esistenti.

I sorgenti e la documentazione sono reperibili accedendo al repository SVN di Gov4J all’indirizzo:

• svn://openspcoop.org/gov4j/proxyCO
• username: proxyCO
• password: proxyCO

Recentemente Ancitel ha sviluppato il nuovo sistema applicativo XML-SAIA (Sistema di Accesso e Interscambio Anagrafico) che è andato a sostituire il precedente formato di tracciato record la cui caratteristica principale è di introdurre il supporto del formato XML per l’interscambio di informazioni anagrafiche tra Comuni Italiani, Ministero degli Interni e ulteriori enti interessati.

Le funzionalità del sistema XML-SAIA sono state gradualmente estese nel tempo dalla versione 1.0 all’attuale versione 2.5, per rispettare le linee guida definite nell’AP5, la nuova struttura dati per i flussi di comunicazione dalle Anagrafi Comunali al Centro Nazionale Servizi Demografici. Nel documento allegato analizziamo tutte le possibili richieste supportate dal sistema XML-SAIA, elencandole in tabelle corrispondenti alle diverse versioni del formato, dalla versione 1 alla 2.5.

Un vantaggio del formato XML è dato dal fatto di aprire nuove prospettive per l’integrazione dei servizi INA-SAIA del Ministero degli Interni, in ambito SPCoop.

Negli articoli precedenti abbiamo chiarito che il sistema INA-SAIA funge da attuale  intermediario per tutte le comunicazioni di tipo Anagrafico tra i Comuni e tra Enti e Comuni.  Tutte le interazioni previste sono iniziate dai Comuni e dagli Altri Enti interessati verso il Ministero degli Interni, che funge quindi da unico erogatore di tutti i servizi.

Ogni interazione tra i Comuni ed il Ministero è di tipo sincrono, prevedendo una risposta di validazione/accettazione della richiesta. Tuttavia di norma le operazioni richiedono un’elaborazione successiva alla semplice accettazione della richiesta, ed in funzione del tipo di operazione possono richiedere:

• risposte al richiedente, disponibili pero’ in un momento successivo a quello della risposta alla richiesta originale
• invio di richieste ad attori terzi rispetto alla richiesta originale

In INA-SAIA queste richieste sono gestite grazie a due generiche richieste infrastrutturali, anch’esse sincrone: la Richiesta Stato e lo Stato delle Code.

La funzionalità di Richiesta Stato viene utilizzata per verificare lo stato di avanzamento di una precedente richiesta, utilizzando un numero di protocollo restituito dalla richiesta originale, mentre la funzionalità di Stato delle Code viene utilizzata dai Comuni per verificare la presenza di richieste ad essi indirizzate.

Grazie a queste operazioni infrastrutturali, il sistema INA-SAIA risolve il problema di ricondurre interazioni di qualunque tipo tra i vari attori in gioco in servizi di tipo sincrono erogati dal CNSD, presso il Ministero degli Interni.

I Servizi previsti in INA-SAIA potrebbero essere mappati in un Accordo di Servizio SPCoop in accordo a due diverse modalità. La prima prevede che si mappino uno-a-uno i vari servizi già presenti in INA-SAIA, prevedendo quindi come unico Erogatore il Soggetto SPC MinisteroInterni. La seconda mostra come utilizzare al meglio il modello degli Accordi di Servizio previsto in SPCoop per far evolvere l’attuale implementazione del CNSD verso un modello più vicino a quello paritetico previsto in SPCoop, nel quale i vari attori (nel nostro caso i Comuni) sono anche in grado di erogare servizi e non solo di fuirli.

Visto il significativo impatto che questo secondo modello avrebbe sull’attuale implementazione del Servizio INA-SAIA, questa ipotesi non viene analizzata, sarà quindi progettato un Accordo di Servizio aderente alla prima delle due modalità discusse.

Progettazione dell’Accordo di Servizio SPCoop

Di seguito introduciamo le caratteristiche di un possibile Accordo di Servizio SPCoop, in accordo con la struttura dei messaggi xml e delle operazioni previsti nel servizio INA-SAIA.

Il mapping più immediato tra l’attuale implementazione del Servizio INA-SAIA e la specifica SPCoop si può ottenere tramite un accordo di servizio SPCoop mono-erogatore/multi-fruitore. Questa tipologia di servizio è descritta nella sezione “5.1. Ciclo di Vita dell’Accordo di Servizio” del documento “Sistema pubblico di cooperazione: ACCORDO DI SERVIZI”, come segue:

<< Il servizio è erogato da un solo sistema erogatore indipendente Serog, di cui è titolare un soggetto della comunità SPCoop, e destinato alla fruizione di una classe di M sistemi indipendenti (i fruitori) Sfruit_1, …, Sfruit_M, di cui sono responsabili altri soggetti della comunità SPCoop. Il titolare del sistema erogatore ha la responsabilità di gestione del ciclo di vita degli accordi di servizio (indipendentemente dalle modalità del processo che ha condotto agli accordi) e dell’erogazione del servizio in conformità con gli accordi. Ogni titolare di sistema fruitore è responsabile della fruizione del servizio nel rispetto dei termini del suo accordo di servizio con il titolare del sistema erogatore. In questo caso, esiste una sola parte comune da cui vengono derivati M ASj (j = 1 .. M), uno per ogni fruitore. >>

Nel caso in esame, il ruolo di titolare dell’Accordo è quindi assunto dal Ministero degli Interni, unico erogatore del Servizio. I potenziali fruitori saranno invece sempre i comuni e solo per alcuni servizi anche gli altri Enti potenzialmente interessati alle consultazioni Anagrafiche.

Facendo riferimento all’analisi del sistema XML-SAIA svolta nel primo allegato, nella tabella seguente viene presentato uno schema di massima dell’Accordo di Servizio SPCoop da realizzare per il Sistema INA-SAIA.

Accordo di Servizio: INA-SAIA

(*) Elenco Tipologia Azioni relative al servizio di Comunicazioni Anagrafiche

• ComunicazioniNascita
• AnnullamentoComunicazioniNascita
• ComunicazioneCambioResidenza
• ComunicazioneDecesso
• ComunicazioneImmigrazioneAltroComune
• ComunicazioneImmigrazioneEstero
• ComunicazioneIscrizioneMancataIscrizioneAltroComune
• ComunicazioneMorte
• ComunicazioneEmigrazioneAltroComune
• ComunicazioneEmigrazioneEstero
• ComunicazioneCancellazioneIrreperibilità
• ComunicazioneCancellazioneOmessaDichiarazioneDimoraAbituale
• ComunicazioneCambioAbitazione
• ComunicazioneMatrimonio
• ComunicazioneVedovanza
• ComunicazioneDivorzio
• ComunicazioneAnnullamentoMatrimonio
• ComunicazioneVariazioneNomeCognome
• ComunicazioneVariazioneSesso
• ComunicazioneVariazioneCittadinanza
• ComunicazioneVariazionePermessoSoggiorno
• ComunicazioneVariazionePaternitàMaternità
• ComunicazioneRettifica
• ComunicazioneAnnullamentoComunicazioneAnagrafica
• ConfermaDati
• AnnullaVariazioneAnagrafica
• RettificaVariazioneAnagrafica

Visto che alcuni servizi saranno accessibili ai soli Comuni, mentre altri saranno accessibili a tutti gli Enti interessati alle consultazioni anagrafiche, si impone la necessità di distinguere i servizi INA-SAIA in due diversi accordi di servizio, come mostrato nella tabella seguente. Il primo, denominato SAIAGestione

Sulla base delle indicazioni raccolte in questa sezione, si potrà ora redarre un Accordo formale di Servizio SPCoop. Il passo successivo sarà quello di costruire, partendo dagli xsd dei messggi INA-SAIA, i componenti formali obbligatori dell’Accordo, e cioè:

• il WSDL Concettuale
• il WSDL Erogatore, parte comune e parte specifica
• il WSDL Fruitore, che in questo caso risulterà un file vuoto

Alcuni esempi sono mostrati nel secondo documento allegato.

Conclusioni

L’architettura proposta supera tutti i limiti evidenziati per la soluzione attualmente in uso, analizzata nella sezione 2, integrandosi completamente con lo standard SPCoop e con l’infrastruttura standard INF-1 di ICAR. In particolare, i principali vantaggi della nuova soluzione sono i seguenti:

• la porta di accesso nei comuni non è più necessaria, in quanto:
  • le funzionalità di imbustamento eGov sono ora gestite in modalità standard dalla Porta di Dominio SPCoop dell’Ente;
  • le modalità di trasporto sono realizzate dalla Porta di Dominio Regionale (NICA, nella terminologia ICAR), sempre in accordo a quanto stabilito dallo standard SPCoop.
  • significativi benefici dal punto di vista della sicurezza complessiva del sistema, in quanto i collegamenti con il Ministero sono limitati al Centro regionale che ospiterà il NICA e che potrà quindi avere un’attenzione molto maggiore delle singole Porte d’Accesso presso i Comuni

• il tracciamento delle comunicazioni puo’ ora avvenire in maniera standard, in accordo a quanto stabilito dalla specifica SPCoop;
• la disponibilità di un Accordo di Servizio che include i file WSDL dei Servizi CNSD e non solo gli schemi dei messaggi, facilita significativamente l’integrazione degli Applicativi interni agli Enti.

Per interfacciarsi con i servizi IGRUE, il MEF propone alle altre Amministrazioni un’applicazione J2EE denominata “Sender” che unifica le funzioni di proxy applicativo e di Porta di Dominio SPCoop.

I sistemi applicativi locali, invocando i Web Service esposti dal Sender, attivano processi asincroni che gestiscono l’invio del file di attuazione verso il sistema centrale, la raccolta degli esiti dell’invio del file, lo scarico dei dati delle tabelle di contesto.

Il Sender semplifica l’interfaccia del Servizio IGRUE per i Sistemi Locali dell’Ente, rispetto all’uso diretto dei servizi esposti dal sistema centrale. Infatti i servizi di esito e l’operazione di invio dei file di attuazione sono trasparenti per il sistema locale. Inoltre le operazioni richieste al sistema locale per l’invio dei dati di attuazione sono principalmente: a) copiare il file zip in una determinata area del file system; b) invocare il servizio web PrenotazioneTicket fornendo in input l’identificativo dello zip file; c) recuperare i risultati dell’invio in una determinata area del file system. In questo modo l’invocazione di un unico Web Service permette di evitare le 6 comunicazioni SPCoop richieste per la comunicazione diretta verso il sistema centrale (prenotazioneTicket, invio file, quattro operazioni per raccolta esiti).

L’architettura del Sender è descritta in figura.

Architettura del Sender del servizio IGRUE

Tuttavia l’uso del Sender presenta una serie di limitazioni:

• Questo approccio, che integra le funzioni di PdD, può essere utile per gli enti che non dispongono ancora di una propria PdD, ma è controindicato per chi ha già una propria PdD che, in questo modo, viene scavalcata.
• Dipendenza dal Database Oracle 10g e dalla PdD Oracle.
• Dipendenza dall’application server WebSphere 6.1 o da Jboss <= 4.0.2.
• Il Sistema Locale deve implementare i client dei Web Service del Sender.

Per questo motivo si ritiene opportuno implementare il servizio sulla base di un nuovo proxy applicativo alternativo al Sender, che chiameremo Proxy IGRUE, in grado di replicarne i vantaggi superandone però le limitazioni.

Le linee guida progettuali per lo sviluppo del Proxy IGRUE sono le seguenti:

• Il Sistema Locale per interfacciarsi verso il Sistema Centrale utilizza esclusivamente il file system.
• Il ProxyIGRUE consulta il file system e una base di dati per capire le operazioni che deve effettuare.
• Il ProxyIGRUE costruisce i messaggi SOAP necessari per l’invocazione del sistema centrale ed invoca le porte delegate della PdD dell’Ente.
• La PdD dell’ente dialogherà con il sistema centrale tramite SPCoop.

Come prerequisiti devono essere noti l’identificativo del sistema locale ed il codice dell’amministrazione per cui l’applicazione deve operare.

Funzionalità

Il file system su cui opera il Proxy IGRUE ha la seguente struttura:

• OUTBOX: contiene i file zip con i dati di attuazione che l’ente desidera spedire. Ogni file zip deve possedere un nome univoco rappresentato da un codice incrementativo (es. 234.zip, 1567.zip)
• INBOX: contiene le informazioni relative ai dati di attuazione spediti verso il sistema centrale. Sarà formata da tante directory (con il nome del file zip inserito in OUTBOX) quanti sono i file gestiti o in corso di gestione dal proxy igrue (es. 234/ , 1567/). Le directory interne saranno cosi’ strutturate:
  • File zip contente i dati di attuazione spediti verso l’ente principale
  • INFO.txt: contiene le informazioni relative alla spedizione (es. Ticket utilizzato)
  • RISULTATI: contiene gli esiti (formato zip) che il proxy IGRUE ha scaricato dal sistema centrale
  • EVENTI: contiene gli eventi (formato txt) che il proxy IGRUE ha scaricato dal sistema centrale
• TIPI_EVENTI: contiene la zzclassificazione dei tipi di evento che il proxy IGRUE ha scaricato dal sistema centrale (e che mantiene aggiornata).
• CONTESTO: contiene i files zip con le tabelle di contesto che il proxy IGRUE ha scaricato dal sistema centrale. Se il proxy IGRUE si accorge di una modifica ad una tabella di contesto provvede ad aggiornare il file corrispondente.

L’upload di un file nell’OUTBOX fa scaturire automaticamente l’invio di dati di attuazione (con negoziazione del ticket).

Il Proxy effettua automaticamente il download degli esiti relativi ad invii di dati, e fornisce tali esiti in directory predefinite.

Il Proxy effettua automaticamente il download degli eventi, sia di carattere generale, che relativi ad un singolo ticket, e fornisce tali eventi nella directory EVENTI. Una volta scaricati, gli eventi vengono cancellati dal sistema centrale.

I dati di contesto vengono scaricati dal ProxyIGRUE automaticamente e memorizzati nella directory CONTESTO.

Ci sono tuttavia alcuni aspetti da chiarire:

• Come avviene la negoziazione dei codici di Procedura Attivazione? Alcune soluzioni possibili sono: a) negoziazione effettuata dal proxy IGRUE e modifica dello zip per inserire il codice prima dell’invio verso il sistema centrale; b) definizione di una modalità di inserimento di tale codice; c) implementazione di uno strumento (web service, interfaccia grafica, file system) utilizzabile dal sistema locale per ottenere un codice di procedura attivazione, sarà poi il sistema locale ad inserirlo nello zip file, in questo caso il Proxy IGRUE non deve modificare il file zip.
• Come memorizzare gli eventi? Gli eventi vengono ritornati dal sistema centrale nel body applicativo, ma in un body applicativo possono essere presenti più eventi.

Architettura

L’architettura del Proxy IGRUE è mostrata in figura.

Architettura del Proxy Applicativo IGRUE

Più nel dettaglio l’architettura è formata dai seguenti moduli:

• Modulo di Spedizione dei Dati di attuazione
• Modulo di Raccolta Esiti
• Modulo di Raccolta degli Eventi
• Modulo di Raccolta delle Tabelle di Contesto
• Modulo di Controllo della Consistenza dei dati

Il Proxy IGRUE utilizza un database per mantenere:

• Mapping tra codice file zip da spedire e ticket assegnato dal sistema centrale;
• Stato dell’invio e della raccolta informazioni di un ticket;
• Fornire una scadenza di validita temporale ad un’operazione;
• Stato della raccolta delle tabelle di contesto.

NOTA: le varie operazioni sono gestite in maniera transazionale, controllando che eventuali imprevisti software/hardware non rendano inconsistente l’area dati su filesystem e il database.

I vantaggi di questa nuova soluzione sono i seguenti:

• Ambiente di riferimento Open Source:
  • Database Postgresql
  • Application Server Jboss 4.x/5.x
  • Porta di Dominio OpenSPCoop
• Il sistema locale non è obbligato ad implementare applicazioni WebService come dovrebbe usando il sender, ma può invece limitarsi a trasferimenti di file via file transfer.

Modulo di Spedizione dei Dati di attuazione

Si tratta di un Timer EJB che si occupa di effettuare polling sulla directory OUTBOX in cerca di file zip da spedire.

Ad ogni file XX.zip corrisponderanno le seguenti azioni:

• Negoziazione ticket con il sistema centrale (invocazione PortaDelegata).
• Creazione Directory XX nell’area INBOX, creazione delle sottocartelle RISULTATI, EVENTI, creazione del file INFO.txt contenente il ticket negoziato e copia del file XX.zip.
• Creazione nel database del mapping tra XX e il ticket appena negoziato.
• Creazione MessaggioSOAP With Attachments per l’invio dei dati di attuazione formato dal body contenente il ticket, e da un allegato contenente il file XX.zip
• Spedizione dati di attuazione (Invocazione PortaDelegata).
• Completamento operazione, rimuovendo il file XX.zip dall’area OUTBOX.

Modulo di Raccolta Esiti

Si tratta di un Timer EJB che si occupa di effettuare polling sul database in cerca degli invii per cui non sono ancora stati raccolti gli esiti.

Gli esiti da raccogliere sono divisi in quattro categorie: StatisticheElaborazioni, StatisticheScarti, EsitoElaborazionePerAnagraficaDiRiferimento e LogDegliErrori.

La raccolta di una categoria di esito avviene tramite l’invocazione di una PortaDelegata.

Gli esiti ottenuti in seguito all’invocazione di una PortaDelegata vengono memorizzati nella directory INBOX/<ID_INVIO>/RISULTATI dell’invio in gestione.

L’avvenuta raccolta di una categoria, viene memorizzata nel database, in modo che un successivo polling del timer si limiti a raccogliere le categorie di esiti rimaste.

Modulo di Raccolta degli Eventi

Si tratta di un Timer EJB che si occupa di effettuare polling sul database in cerca degli invii ancora in gestione (non scaduti).

Per ogni ticket trovato, viene controllato se sono presenti eventi sul sistema centrale, attraverso l’invocazione di una Porta Delegata.

Gli eventuali eventi ottenuti in seguito all’invocazione di una PortaDelegata vengono memorizzati nella directory INBOX/<ID_INVIO>/EVENTI dell’invio in gestione.

Una volta memorizzati gli eventi, questi vengono eliminati dal sistema centrale tramite l’invocazione di un altra PortaDelegata.

Ad intervalli regolari il timer si occupa anche di recuperare la lista delle tipologie di evento e di memorizzare tale lista nella directory EVENTI/TIPI.

Modulo di Raccolta delle Tabelle di Contesto

Si tratta di un Timer EJB che si occupa di effettuare ad intervalli regolari il download delle tabelle di contesto dal sistema centrale attraverso l’invocazione di una Porta Delegata.

Le tabelle di contesto vengono scaricate nella directory CONTESTO solo se risultano aggiornate rispetto ad un precedente download.

Il controllo di aggiornamento si basera su checksum, che viene associato al salvataggio delle tabelle di contesto.

Modulo di Controllo della Consistenza dei dati

Si tratta di un Timer EJB che si occupa di verificare la consistenza dei dati memorizzati su database. Verifica anche eventuali record scaduti e provvede all’eliminazione.

Le Comunicazioni Obbligatorie (CO) sono quelle che tutti i datori di lavoro, pubblici e privati, devono trasmettere in caso di assunzione, proroga, trasformazione e cessazione dei rapporti di lavoro.

L’articolo 4-bis del D.Lgs. n. 181/2000, così come modificato dall’art. 1, comma 1184 della L. 296/2006, prevede che dal 1° Marzo 2008 i datori di lavoro effettuino la CO avvalendosi esclusivamente dei servizi informatici messi a disposizione dai servizi competenti secondo le modalità stabilite da ciascuna Regione e Provincia Autonoma. Le comunicazioni devono essere poi inoltrate al Ministero del Lavoro che funge da “coordinatore” del sistema smistando, in via telematica, ai soggetti interessati (es: INPS, INAIL, DRL, DPL etc…) tutte le comunicazioni pervenutegli.

Per questo motivo il Ministero del Lavoro ha istituito il “Servizio informatico C.O.”, un servizio SPCoop erogato dalla sua Porta di Dominio che si basa sulla interoperabilità dei sistemi locali realizzati dalle Regioni e dalle Province Autonome di Trento e Bolzano, secondo gli standard tecnologici definiti con il decreto interministeriale 30 ottobre 2007 che definisce i moduli di comunicazione, i dizionari terminologici, le modalità di trasmissione e di trasferimento dei dati.

Il documento che fornisce le specifiche tecniche del servizio informatico delle comunicazioni obbligatorie del Ministero del Lavoro è disponibile alla url http://www.lavoro.gov.it/NR/rdonlyres/C073A08B-4D18-40B3-AA85-51098DBFC9FB/0/COModellieRegolemarzo2009.pdf. Per altre informazioni di carattere generale http://www.lavoro.gov.it/CO/LM/Funzionamento.

Le informazioni scambiate sono relative alle seguenti tipologie di comunicazioni:

• UniLav: comunicazione di una attività lavorativa, intesa come instaurazione di un rapporto di lavoro, cessazione rapporto di lavoro, proroga rapporto di lavoro e trasformazione rapporto di lavoro.
• UniUrg: comunicazione di un’attività lavorativa urgente
• UniSomm: comunicazione di una attività lavorativa promossa da una agenzia di somministrazione, intesa come instaurazione di un rapporto di lavoro, cessazione rapporto di lavoro, proroga rapporto di lavoro e trasformazione rapporto di lavoro.
• VarDatori: notifica della modifica della ragione sociale/denominazione di un datore di lavoro o di un trasferimento d’azienda.

In particolare:

• Tutte le suddette tipologie di comunicazione sono implementate per mezzo di servizi SPCoop di tipo richiesta/risposta sincrona.
• Ogni servizio richiede in input un messaggio xml derivante dai rispettivi xsd coinvolti. L’esito della risposta all’invocazione sincrona del messaggio è un OK nel caso in cui la ricezione e di controlli sintattici del messaggio xml sono andati a buon fine, KO in caso di verifica sintattica non corretta.
• Non esiste una logica di integrazione che deve essere implementata a livello di proxy applicativo

Per interoperabilità dei sistemi di protocollo informatico si intende la possibilità di trattamento automatico, da parte di un sistema di protocollo ricevente, delle informazioni trasmesse da un protocollo mittente, allo scopo di automatizzare le attività ed i processi amministrativi conseguenti.

Il protocollo interoperabile rappresenta quindi uno strumento di importanza fondamentale per l’attuazione dei processi di dematerializzazione dei flussi documentali e dei procedimenti all’interno delle Pubbliche Amministrazioni.

Le regole tecniche per l’interoperabilità dei sistemi di protocollo informatico sono fornite nell’art. 15 del DCPM 31 ottobre 2000 (GU 21 novembre 2000, n. 272) e dalla successiva circolare AIPA/CR/28 del 7 maggio 2001.

Oltre a modalità di trasmissione comuni (che sono quelle proprie dei sistemi di posta elettronica), l’interoperabilità dei sistemi di protocollo richiede una efficace interazione dei sistemi di gestione documentale. Per questo motivo le regole tecniche specificano le modalità di composizione dei messaggi protocollati identificando il tipo ed il formato delle informazioni archivistiche di protocollo minime ed accessorie che devono essere scambiate tra le pubbliche amministrazioni. Ad es. è stabilito che ogni messaggio di posta elettronica protocollato debba includere in allegato una segnatura informatica codificata in formato XML che riporta alcune informazioni archivistiche fondamentali, per facilitare il trattamento automatico dei documenti da parte del sistema ricevente.

Le stesse regole tecniche specificano inoltre il flusso dei messaggi che possono essere scambiati fra due AOO a seguito dell’invio di un messaggio protocollato; determinati eventi riguardanti il trattamento presso la AOO ricevente (per esempio, l’attivazione di un procedimento) possono essere accompagnati da messaggi di aggiornamento, generati automaticamente dal sistema informatico ricevente (ad es. messaggio di conferma di ricezione; messaggio di notifica di eccezione; messaggio di aggiornamento di conferma; messaggio di annullamento protocollazione).

Si noti tuttavia che tali specifiche riguardano esclusivamente le funzionalità che devono supportate dai sistemi informativi locali che gestiscono i processi di protocollo. In altre parole, non è compito dell’infrastruttura di cooperazione entrare nel merito dei messaggi, effettuando ad es. verifiche sul formato dei messaggi scambiati o distinguendo fra il primo messaggio di un flusso di protocollo ed i successivi messaggi di ritorno. Tali attività sono di esclusiva competenza dei servizi applicativi che devono essere predisposti per il loro trattamento.

L’infrastruttura di cooperazione deve invece supportare le modalità attraverso le quali può avvenire:

• l’invio di un messaggio da parte di un servizio applicativo mittente e
• la ricezione di un messaggio da parte di un servizio applicativo destinatario.

Da questo punto di vista la normativa stabilisce che lo scambio dei documenti soggetti alla registrazione di protocollo, e di tutti gli eventuali messaggi di ritorno è effettuato mediante messaggi conformi ai sistemi di posta elettronica compatibili con il protocollo SMTP/MIME definito nelle specifiche pubbliche RFC 821-822, RFC 2045-2049 e successive modificazioni o integrazioni.

In questo articolo descriviamo l’architettura proposta dal progetto GovMix per l’attuazione della convenzione fra CISIS e Ministero dell’Interno approvata dalla Conferenza Unificata in data 14 dicembre 2006, relativa al ruolo delle Regioni nella coperazione fra Enti locali e il Ministero dell’Interno per quanto riguarda il servizio Anagrafe INA-SAIA.

Ricordiamo che la convenzione prevede (articolo 5):

• la messa a disposizione delle regioni, per fini esclusivamente istituzionali, dei dati certificati dal INA (variazioni anagrafiche, accesso a INA, richieste di certificazioni anagrafiche - DM 240/2005)
• l’utilizzo delle reti regionali per il servizio di trasporto dei dati stessi al Ministero dell’Interno

La modalità di attuazione proposta rafforza il raccordo e le sinergie fra la normativa in materia anagrafica, le indicazioni contenute nella convenzione CISIS Ministrero dell’Interno, lo stato di attuazione del Servizio Pubblico di Cooperazione Applicativa SPCoop ed il progetto di Infrastruttura di Cooperazione Applicativa Intergerionale ICAR.

La soluzione è interamente basata sulle funzionalità standard della Porta di Dominio SPCoop, dettagliando l’Accordo di Servizio SPCoop per i Servizi INA-SAIA tra tutti gli enti previsti dalla Convenzione ed il Ministero, indirizzando le comunicazioni SPCoop su un canale di trasporto esclusivo a livello Regionale, stabilito tra il Centro Servizi SPCoop Regionale ed il Ministero degli Interni, in accordo con l’architettura regionale di cooperazione applicativa realizzata nel task INF-1 del progetto ICAR.

La soluzione non richiede la presenza di alcun elemento proprietario, eliminando del tutto la necessità della Porta di Accesso e quindi anche la necessità, per i sistemi applicativi degli enti, di supportare i tracciati XML della Porta di Accesso.

L’adozione di una soluzione si questo tipo è motivata dalle seguenti considerazioni:

1. Dopo un lungo periodo di sperimentazioni, l’adozione della specifica SPCoop come norma di legge rende l’uso della specifica non solo la soluzione più indicata ma anche l’unica a valore legale;
2. SPCoop è finalmente diventata un’infrastruttura matura e pienamente supportata, in seguito all’assegnazione delle due gare bandite dal CNIPA, la prima relativa all’attivazione dei servizi di Registro SICA nazionale e di certificazione delle Porte di Dominio, la seconda relativa alla fornitura di servizi SPCoop alle amministrazioni centrali;
3. Il task INF-1 del progetto ICAR ha rilasciato a tutte le Regioni coinvolte nel progetto guidelines e strumenti per la gestione di un’infrastruttura di cooperazione Regionale.
4. il task AP-2 del progetto ICAR rilascia a tutte le regioni aderenti ed in riuso a qualunque regione lo richieda, le componenti per l’attuazine di quanto previsto dalla Convenzione CISIS Ministero dell’Interno

La soluzione, rispondente alle regole tecniche di SpCoop, è predisposta per attuare le regole di sicurezza definite dal Ministero dell’Interno.

La figura evidenzia le caratteristiche principali della nuova soluzione proposta.

1. Si basa pienamente sullo standard SPCoop, prevede quindi che il Ministero degli Interni esponga i servizi INA-SAIA, descritti in un apposito Accordo di Servizio SPCoop, per tramite di una Porta di Dominio standard SPCoop.
2. Elimina del tutto la presenza della Porta di Accesso, e quindi la necessità di utilizzare l’xml ed i meccanismi di sicurezza proprietari dell’attuale soluzione INA-SAIA per rimpiazzarla con gli strumenti di integrazione della Porta di Dominio SPCoop. Si ricorda come gli strumenti di integrazione e di sicurezza della Porta di Dominio SpCoop siano adeguati al rispetto delle norme disposte dal Ministero dell’Interno
3. Si basa sull’architettura di cooperazione applicativa interregionale progettata nel task INF-1 del progetto ICAR, prevede quindi che il trasporto delle richieste tra il Comune ed il CNSD sia veicolato per tramite del componente Interregionale NICA previsto in ICAR (maggiori dettagli in proposito sono forniti nel documento allegato “Architettura INF1-ICAR“).

Il modello descritto consente di realizzare tutti i servizi previsti dalla Convenzione:

Nell’articolo seguente analizzeremo il formato di rappresentazione dei dati XML-SAIA utilizzato dagli Applicativi del CNSD al fine di proporre una prima bozza di Accordo di Servizio SPCoop per il sistema INA-SAIA.

La prima soluzione proposta dal progetto ICAR per l’integrazione dei servizi anagrafici nel sistema di cooperzione SPCoop aveva l’obiettivo di integrare le infrastrutture Regionali del progetto ICAR con le “Porte di Accesso” INA-SAIA già presenti presso i Comuni.

Questa proposta è stata successivamente abbandonata in favore di una soluzione aderente agli standard nel frattempo emersi in ambito SPC ed ICAR e finalizzata ad eliminare i collegamenti fisici tra Comuni e Ministero, veicolando le comunicazioni xml generate dalle Porte di Accesso dei Comuni verso un gateway Interamministrativo Regionale, il cui compito è quello di interagire, tramite un’unica porta di accesso Regionale con il centro servizi del CNSD.

Questa soluzione, pur risolvendo uno dei problemi principali della situazione attuale, la presenza di collegamenti fisici tra le Porte di Accesso dei singoli Comuni e quella del CNSD, mantiene tutte le criticità identificate nell’articolo precedete, ed introduce come nuovo elemento la necessità di modificare significativamente il software di Porta di Accesso dei Comuni per adattarlo alla nuova logica di comunicazione con le Porte di Dominio SPCoop dell’Ente. Resta inoltre da chiarire il dettaglio del comportamento del Gateway Interamministrativo identificato nell’architettura.

Il principio di base di tutti i servizi di tipo anagrafico è che la garanzia dell’identificazione del cittadino su tutti gli archivi della PA sia data dal codice fiscale che, in base alle normativa corrente, costituisce il codice identificativo univoco del cittadino e lo strumento per garantire la correttezza della sua identificazione in rete (art. 2 del D.L 15/01/1993 n. 6 e art. 2, comma 2 del DPCM 5/5/1994).

I titolari di codice fiscale sono registrati nell’INA, gestito dal Ministero dell’Interno e attualmente popolato con i dati di circa 25 milioni di cittadini. Uno specifico regolamento (adottato con decreto del Ministero dell’Interno) disciplina le modalità di aggiornamento dell’INA da parte dei comuni e le modalità per l’accesso da parte delle PA centrali e locali.

L’associazione fra i dati identificativi del cittadino e il comune di residenza completa la circolarità anagrafica, l’indice, infatti, non contiene le informazioni anagrafiche del cittadino, che restano di esclusiva pertinenza del comune di residenza, ma solo i dati minimi che servono a reperirle o ad accelerarne l´accesso.

SAIA consente ai comuni di inviare e ricevere dati anagrafici sotto forma di flussi documentali predisposti su specifici tracciati. SAIA presuppone che le banche dati anagrafiche siano delocalizzate nei comuni che, avendo la titolarità degli archivi anagrafici, garantiscono e certificano la congruità e correttezza delle informazioni in essi contenut.

Lo scopo di SAIA non è creare un’unica anagrafe bensì smistare, in velocità, le comunicazioni anagrafiche agli enti pubblici e concessionari di pubblici servizi che ne avessero necessità.

I dati scambiati sul sistema SAIA transitano per il dal Centro Servizi Anagrafe (CSA) del Centro Nazionale dei Servizi Demografici (CNSD) del Ministero dell’Interno dove vengono trattenuti solo per il tempo necessario all’inoltro e non vengono depositati in alcun archivio centrale. Il CSA distribuisce i dati ai diversi soggetti pubblici, suddivisi a seconda della legittimità al trattamento in base al generale principio di necessità di cui all’art. 3 del d.lgs 196/2003 (codice della privacy).

L’architettura INA-SAIA (descritta inl dettaglio nel documento disponibile a questo link) si basa su un sistema proprietario denominato “Porta di Accesso”, le cui specifiche sono disponibili sul sito del Ministero.

I comuni devono attivare e registrare al CNSD la propria Porta d’Accesso che è l’unico sistema informatico del Comune abilitato ad accedere direttamente ai domini applicativi del CNSD.

Come mostrato in figura, i sistemi comunali fruiscono i servizi indirizzando la Porta d’Accesso locale, esattamente come se fosse il server del CNSD che eroga i servizi che si intendono richiedere. L’interscambio tra i sistemi interni al Comune e la Porta di Accesso avviene in un formato xml, che permette di indicare i metadati relativi a Mittente Destinatario e Servizio richiesto, all’interno di opportuni elementi di imbustamento xml.

Di seguito viene mostrato lo schema del formato xml utilizzato dalla Porta di Accesso.

  <?xml version="1.0" encoding="UTF-8"?>
  <servizioDELIVERY>
    <Mittente>...</Mittente>
    <Destinatario>...</Destinatario>
    <NomeServizio>...</NomeServizio>
    <NomeAzione>...</NomeAzione>
    <IdentificatoreMessaggio>...</IdentificatoreMessaggio>
    <corpoDELIVERY> ......... </corpoDELIVERY>
  </servizioDELIVERY>

dove all’interno del tag <corpoDELIVERY> viene inserito il BODY della richiesta.

Questa soluzione presenta i seguenti limiti principali :

• il sistema non è in alcun modo integrato con il sistema di Porte di Dominio SPCoop, di cui gli Enti si stanno dotando;
• il sistema richiede che il servizio applicativo Anagrafe generi un xml nel formato richiesto dal CNSD;
• il sistema non implementa la gestione degli errori e del tracciamento delle comunicazioni di cooperazione;
• il sistema richiede di installare, mettere in sicurezza e mantenere nel tempo tutte le porte di accesso dislocate sul territorio regionale.

Il sistema INA-SAIA, costituito dall’ “Indice Nazionale” delle Anagrafi (INA) e dal “Sistema di Accesso e di Interscambio Anagrafico” (SAIA) è il backbone su cui avvengono le comunicazioni telematiche relative allo scambio di dati anagrafici fra le pubbliche amministrazioni. Il sistema garantisce l’interconnessione dei comuni e razionalizza l’interazione tra questi e le altre PA centrali e locali, assicurando la qualità e l’univocità dei dati e facilitando l’attività di vigilanza.

Il sistema garantisce inoltre le funzioni di supporto necessarie alla emissione della Carta d’Identità Elettronica (CIE) e Carta Nazionale dei Servizi (CNS) e la validazione degli accessi ai servizi eGov.

L’architettura INA-SAIA si basa su un sistema proprietario denominato “Porta di Accesso“, che presenta una serie di limitazioni:

• il sistema non è conforme alle specifiche SPCoop e, di conseguenza, non è integrabile con la Porta di Dominio;
• il sistema, che richiede di installare, mettere in sicurezza e mantenere nel tempo tutte le porte di accesso dislocate sul territorio nazionale, è di fatto, una infrastruttura parallela rispetto a quella SPCoop, dedicata a questa unica tipologia di servizi.

Per affrontare questi problemi, la Conferenza Stato-Regioni del 14 dicembre 2006 ha approvato uno schema di convenzione che prevede di integrare le “Porte di Accesso” INA-SAIA con l’infrastruttura SPCoop ed ha istituito uno tavolo tecnico (che coinvolge le Regioni, il Cisis ed il Ministero dell’Interno) per ridefinire i flussi INA-SAIA sia in termini di servizi, sia in termini architetturali. Le linee guida approvate prevedono che il CNSD (Centro Nazionale Servizi Demografici) si doti di una Porta di Dominio SPCoop attraverso la quale veicolare i servizi di interrogazione INA e di variazioni anagrafiche SAIA verso le Porte di Dominio Regionali realizzate nell’ambito del progetto ICAR, e che questa integrazione una volta sperimentata possa essere estesa ai comuni.

Riteniamo, tuttavia, che tale soluzione presenti ancora qualche criticità. Per questo motivo, GovMix ha sviluppato una proposta innovativa interamente basata sullo standard SPCoop, che non richiede la presenza di alcun elemento proprietario, eliminando del tutto la presenza della Porta di Accesso e semplificando l’integrazione dei Sistemi Applicativi degli Enti che non avrebbero più la necessità di supportare i tracciati XML proprietari previsti dalla stessa Porta di Accesso.

Questo tema si svilupperà in una serie di articoli così organizzati:

• Il primo articolo descrive le principali caratteristiche della soluzione attualmente adottata dal Ministero dell’Interno per l’attivazione del Servizio presso i comuni, basata sull’uso della “Porta di Accesso” .
• Il secondo articolo riassume la soluzione tecnica prevista nell’allegato tecnico alla Convenzione approvata dalla Conferenza Stato Regioni, indicandone alcune criticità.
• Il terzo ed ultimo articolo descrive nel dettaglio le modalità di attuazione della Convenzione proposte dal progetto GovMix.

Il prototipo del Bus di Integrazione GovMix è un sistema software realizzato in linguaggio Java e costituito dalle seguenti componenti:

• Porta di Dominio e Registro Servizi OpenSPCoop
• Nuovi connettori applicativi per la gestione dei protocolli SMTP, POP3, IMAP che abilitano l’integrazione con i sistemi di posta certificata.
• Revisione dei connettori Web Service, che sono stati resi compatibili con le specifiche WS-I Basic Profile v1.1.
• Modulo “caricatore”, che effettua appunto il caricamento di un GovAdapter, ovvero:
  • il deploy delle configurazioni su OpenSPCoop, su cui vengono istanziati il Soggetto SPCoop, il Servizio Applicativo, il Servizio ed il Servizio Applicativo relativi all’eventuale proxy (tutti con le rispettive credenziali di autenticazione);
  • il deploy dell’eventuale Proxy Applicativo;
  • la configurazione dell’eventuale server di posta.

A tali componenti, che rappresentano il nucleo del Prototipo, si aggiungono due ulteriori utility che consentono di generare i GovAdapter a partire dal descrittore GSD di un servizio eGov, e di instanziarli in funzione delle caratteristiche del particolare contesto di esecuzione, prima di caricarli sulla piattaforma.

Il descrittore GSD può essere infatti elaborato da un “Interprete” che genera le configurazioni OpenSPCoop necessarie per supportare il modello di cooperazione specificato (SPCoop, PEC o WebService WS-I compliant) e interfacciare i sistemi di back-end degli enti.

L’interprete produce un archivio zip che contiene tali configurazioni unitamente alle componenti applicative, e costituisce il GovAdapter propriamente detto, nel formato scaricabile dal sito Govmix.

Il GovAdapter prodotto dall’Interprete GSD è un oggetto generico caratterizzato da una serie di parametri che dovranno essere di volta in volta valorizzati in base all’ambiente di esecuzione. Questa attività può essere svolta in modo automatico da un modulo “instanziatore”, in grado di produrre una versione eseguibile del GovAdapter specifica per un determinato contesto.

A questo punto la versione eseguibile del GovAdapter può essere caricata sulla piattaforma. Questa attività è svolta dal modulo “Caricatore” che aggiorna la piattaforma effettuando il deploy delle configurazioni e delle componenti applicative. Al termine del processo il servizio eGov risulta immediatamente fruibile.

Lo schema riepilogativo dell’architettura del Bus di Integrazione è fornito in figura.

Primo Prototipo del Bus Govmix

Approfondimenti

Il white paper  allegato illustra tramite una serie di esempi il processo che consente di generare e caricare i GovAdapter a partire dalla specifica GSD dei servizi eGov.

Il  prototipo di Govmix è scaricabile dalla sezioneDownload.

In questo precedente articolo abbiamo chiarito che, per implementare un nuovo servizio eGov occorre per prima cosa analizzare l’accordo di servizio e la documentazione disponibile per estrapolare le modalità di interfacciamento con i sistemi applicativi di back-end e la configurazione della Porta di Dominio SPCoop. Successivamente può essere necessaria una ulteriore attività di integrazione software per rendere compatibili con l’accordo di servizio le interfacce dei sistemi applicativi preesistenti.

Salvo situazioni banali, gestibili tramite i meccanismi di integrazione generici già presenti in OpenSPCoop, la soluzione comunemente adottata in questi casi consiste nello sviluppo di specifici “proxy applicativi” per mediare tutte le comunicazioni fra la PdD ed i servizi di back-end ed eventualmente fornire a questi ultimi un’interfaccia più semplice e vicina alla logica supportata nativamente dall’applicazione.

Architettura di un tradizionale Proxy Applicativo

Questo approccio presenta alcune importanti controindicazioni:

• I proxy si sostituiscono alle reali applicazioni nel ruolo di fruitori/erogatori dei servizi SPCoop, con l’effetto collaterale di rendere poco significativi i dati raccolti dai sistemi di tracciamento e monitoraggio e più complesse le indagini diagnostiche sulla PdD. Il problema si acuisce quando uno stesso proxy si interfaccia con diverse applicazioni che diventano indistinguibili agli effetti delle transazioni registrate sulla infrastruttura SPCoop.
• Per garantire la sicurezza e l’affidabilità è necessario replicare nei proxy gran parte della complessa logica infrastrutturale presente nella PdD OpenSPCoop, ad es. le funzioni di registrazione, autenticazione ed autorizzazione dei servizi applicativi, la gestione dei canali di comunicazione, la gestione degli errori, etc..

Per ovviare a questi inconvenienti i GovAdapter non saranno realizzati come proxy applicativi ma come veri e propri servizi SPCoop.  In particolare:

1. L’integrazione di un nuovo servizio eGov comporterà la necessità di definire un servizio SPCoop “proxy” avente lo scopo di mediare le comunicazioni con il servizio applicativo locale e caratterizzato da un proprio accordo di servizio.
2. L’uso del servizio proxy consente di integrare il servizio applicativo locale per mezzo dei meccanismi di integrazione standard resi disponibili dall’infrastruttura OpenSPCoop, sia per la gestione della sicurezza (autenticazione) che e per la scelta del canale di comunicazione (protocollo).
3. Le specifiche di integrazione del servizio eGov remoto con l’intrastruttura OpenSPCoop (tipo e parametri del servizio inclusa la specifica di eventuali meccanismi di sicurezza) saranno date in un formato direttamente interpretabile e caricabile dall’infrastruttura di cooperazione: il cosiddetto “GovAdapter”.
4. L’eventuale logica applicativa necessaria per l’integrazione del servizio (ad es. per trasformare il formato dei dati o implementare un diverso flusso di messaggi) sarà implementata da un servizio applicativo (proxy applicativo) associato al servizio proxy e fornito come componente (opzionale) del GovAdapter.

Per ogni GovAdapter da realizzare sarà quindi necessario definire il relativo accordo di servizio (AdS) e le modalità di integrazione del servizio applicativo. Tali informazioni potranno essere rappresentate in modo più o meno esplicito, nel descrittore GSD del servizio.

La figura seguente mostra l’architettura implementata nel caso più complesso che prevede l’impiego di un proxy applicativo: le comunicazioni 1,2,7,8 riguardano l’interazione fra le applicazioni ed il servizio proxy del GovAdapter; le comunicazioni 3,4,5,6 riguardano le interazioni fra il servizio proxy ed il vero e proprio servizio eGov.

Architettura di un GovAdapter implementato come servizio SPCoop

Nella figura precedente sono evidenziati due particolari connettori:

• il connettore per l’integrazione del servizio eGov remoto;
• il connettore per il servizio applicativo locale.

(ndr. per semplicità non sono evidenziati i connettori relativi al servizio proxy ed al relativo servizio applicativo).

I vantaggi di questo approccio sono duplici:

• a livello dell’infrasruttura SPCoop si preserva l’identità e la tracciabilità dei reali servizi applicativi;
• l’integrazione delle applicazioni con l’infrastruttura avviene in modo standard utilizzando i meccanismi di sicurezza, comunicazione, affidabilità forniti off-the-shelf da OpenSPCoop.

E’ importante notare che il proxy applicativo potrebbe anche non essere presente. In tal caso il govAdapter contiene essenzialmente le infomrazioni necessarie per aggiornare la configurazione della Porta di dominio e del Registro Servizi SPCoop, oltre che l’eventuale scelta del connettore verso il servizio applicativo.

 Si noti che mentre le specifiche di integrazione del servizio eGov sono comuni per tutti i possibili fruitori, le specifiche di integrazione del servizio applicativo locale dipendono dalle caratteristiche specifiche di quest’ultimo.

Per questo motivo il GovAdapter (che prende in consideraione gli aspetti generali) potrebbe non includere i dettagli di integrazione del servizio applicativo locale che potranno tuttavia essere configurati caso per caso sull’infrastruttura di cooperazione.

Approfondimenti

Nel white paper  allegato sono descritti alcuni scenari di applicazione dei GovAdaper illustrando l’architettura applicativa che viene instanziata a seguito del loro caricamento sulla piattaforma OpenSPCoop.

GSD (eGov Service Descriptor) è il linguaggio in cui esprimere, in modo conciso ma formale, le specifiche di integrazione di un servizio eGov.

La sintassi del formalismo GSD è descritta dal suo schema XSD.

Un documento GSD è formato da un root element ’servizio’ che richiede la definizione di due attributi obbligatori:

• nome, il nome del servizio rappresentato dal gsd.
• profilo, il profilo di collaborazione del servizio: oneway o sincrono

All’interno della sua definizione sono utilizzabili i seguenti elementi xml:

• connettore (elemento obbligatorio), rappresenta un connettore ereditato dalla porta di dominio OpenSPCoop o dall’estensione fornita da GovMix. Definisce il connettore dove viene erogato il servizio che si desidera fruire.
• proxy (elemento opzionale), rappresenta un proxy necessario per l’integrazione completa del servizio con la porta di dominio. In pratica il proxy si pone tra i servizi applicativi fruitori e la porta di dominio stessa, modificando/gestendo in maniera opportuna i messaggi applicativi inviati dai servizi applicativi.
• invocazione-porta (elemento opzionale), definisce come i servizi applicativi si interfacciano alla porta di dominio.

Forniamo di seguito nella specifica di ciascun elemento.

Connettore

Un connettore definisce l’endpoint di erogazione del servizio che si desidera fruire. Le informazioni necessarie alla definizione di tale endpoint sono diverse a seconda se il servizio erogato è un servizio SPCoop o meno.

Il connettore di un servizio spcoop può assumere come attributo tipo i valori http-spcoop o https-spcoop, e come proprieta’ tutte le informazioni necessarie alla definizione del connettore stesso. Inoltre deve obbligatoriamente contenere all’interno della sua definizione l’elemento spcoop, dove vengono descritte le informazioni SPCoop del servizio:

• soggetto-erogatore (elemento obbligatorio), il tipo e il nome del soggetto SPCoop erogatore del servizio
• azioni (elemento opzionale), le azioni SPCoop utilizzabili con il servizio
• tipo (attributo opzionale, default SPC), tipo del servizio SPCoop

Il connettore di un servizio non spcoop puo’ assumere come attributo tipo i valori http-wsi, https-wsi, jms e stmp, e come proprieta’ tutte le informazioni necessarie alla definizione del connettore stesso.

Di seguito vengono descritte le varie proprietà utilizzabili per ogni tipo di connettore.

• http-spcoop, http-wsi
  • location (obbligatorio), url dove è erogato il servizio
• https-spcoop, https-wsi
  • location (obbligatorio), url dove è erogato il servizio
  • trustStoreLocation (obbligatorio), path nel file system dove è presente il truststore che contiene i certificati necessari a validare il certificato server
  • trustStorePassword (obbligatorio), password per accedere al truststore
  • trustManagementAlgorithm (opzionale, default: PKIX)
  • trustStoreType (opzionale, default: JKS), tipo del truststore
  • keyStoreLocation (opzionale), path nel file system dove è presente il keystore che contiene il certificato e la chiave privata del client necessari per l’autenticazione client
  • keyStorePassword (opzionale, obbligatoria se definito keyStoreLocation), password per accedere al keystore
  • keyPassword (opzionale, obbligatoria se definito keyStoreLocation), password per accedere alla chiave privata
  • keyManagementAlgorithm (opzionale, default: SunX509)
  • keyStoreType (opzionale, default: JKS), tipo del keystore
  • hostnameVerifier (opzionale, default: true), verifica che l’hostname invocato nella url sia uguale al dominio ritornato dal certificato server
  • sslType (opzionale, default: SSLv3), uno tra i seguenti valori: SSL, SSLv3, TLS, TLSv1
• jms
  • tipo (obbligatorio), tipo di risorsa JMS: queue o topic
  • location (obbligatorio), nome JNDI della risorsa JMS (es. queue/TestQueue)
  • connection-factory (obbligatorio), nome JNDI della ConnectionFactory
  • send-as (obbligatorio), tipo di messaggio JMS: TextMessage o BytesMessage
  • context- (opzionale), contesto JNDI per localizzare la coda e la connection factory. Esempio:
    • nome=context-java.naming.factory.initial valore=org.jnp.interfaces.NamingContextFactory
    • nome=context-java.naming.factory.url.pkgs valore=org.jnp.interfaces
    • nome=context-java.naming.provider.url valore=127.0.0.1
  • user e password (opzionale), autenticazione effettuata sulla connection factory
• smtp
  • location (obbligatorio), nome del server smtp
  • port (opzionale), porta del server smtp
  • mittente (obbligatorio), indirizzo email del mittente
  • destinatario (obbligatorio), indirizzo email del destinatario
  • subject (obbligatorio), subject utilizzato nella email
  • filename (opzionale, default: attach.xml), nome dell’attachment contenente il messaggio spedito
  • username e password (opzionale), autenticazione sul server smtp

Invocazione-Porta

Definisce come i servizi applicativi si interfacciano alla porta di dominio attraverso le seguenti informazioni:

• credenziali-accesso (elemento opzionale), elemento che puo’ contenere al suo interno le credenziali di accesso utilizzate dai servizi applicativi che fruiranno del servizio. Tali credenziali possono essere molteplici, ma con il vincolo che debbano possedere tutte lo stesso tipo: basic o ssl
• tipo (attributo opzionale, default ws), elemento che definisce come i servizi applicativi fruiranno del servizio (modalita’ di invocazione della Porta Delegata). I tipi possibili sono:
  • ws: zclassica interfaccia di accesso alla Porta Delegata di OpenSPCoop: web service
  • pop3: la ricezione di una email su di un account acceduto tramite protocollo pop3, farà scaturire l’invocazione della Porta Delegata con il messaggio portato come attachment nella email
  • imap: equivalente al pop3, con la differenza che l’account di posta viene acceduto tramite protocollo imap

In caso di tipo uguale a pop3 o imap deve essere valorizzato obbligatoriamente anche l’attributo server-mail. Tale attributo deve assumere uno dei nomi di account definiti in una lista contenente i mailserver conosciuti dal GovMix Bus (negli esempi successivi saranno forniti i dettagli). Tale lista contiene le seguenti proprietà che devono essere obbligatoriamente definite per ogni account:

• <nome_account>.protocollo, può assumere i valori pop3 o imap
• <nome_account>.host, nome del server
• <nome_account>.port, porta del server
• <nome_account>.ssl, può assumere i valori true o false, a seconda se si desidera l’accesso al server deve avvenire con comunicazione sicura
• <nome_account>.username e <nome_account>.password, credenziali di accesso al server

Proxy

Un proxy definisce un modulo software necessario per l’integrazione completa del servizio con la porta di dominio. In pratica il proxy si pone tra i servizi applicativi fruitori e la porta di dominio. Le informazioni da associare all’elemento proxy sono le seguenti:

• archivio (attributo obbligatorio), rappresenta il path dove è localizzato l’archivio che implementa il proxy (es. /tmp/Proxy.ear)
• connettore (elemento obbligatorio), rappresenta il connettore dove viene erogato il proxy. L’elemento connettore è identico a quanto descritto precedentemente, nel caso di connettore di un servizio non spcoop.
• Invocazione-porta (elemento opzionale), rappresenta come il proxy si interfaccia alla porta di dominio. L’elemento è identico all’elemento utilizzato direttamente nell’elemento servizio. Unico vincolo è la possibilita’ di definire unàunica credenziale di tipo basic o ssl.

Il servizio erogato dal Ministero dell’Economia e delle Finanze (MEF) - Ragioneria Generale dello Stato (RGS) - Ispettorato Generale per i Rapporti finanziari con l’Unione Europea (IGRUE), ha lo scopo di raccogliere e controllare in modo omogeneo le informazioni sulla programmazione e avanzamento dei progetti cofinanziati dai Fondi Strutturali e dal Fondo Aree Sottosviluppate (FAS).

Nel seguito del documento questo servizio (o meglio questo insieme di servizi) sarà per semplicità identificato come “Servizio IGRUE”.

Il sistema centrale di acquisizione dei dati di monitoraggio del QSN 2007/2013 raccoglie dati relativi a progetti.

Il servizio è fruito dai sistemi locali di proprietà delle Amministrazioni titolari di programmi rientranti nel Quadro Strategico Nazionale (QSN) che inviano le informazioni relative ai progetti di competenza al sistema centrale di monitoraggio.

Per ogni progetto possono essere fornite le seguenti informazioni:

• Anagrafica
• Finanziaria
• Fisica
• Procedurale
• Anagrafiche Soggetti Correlati
• Modalità Procedurali di Attivazione
• Modalità Procedurali di Aggiudicazione

Da un punto di vista logico, il sistema centrale di acquisizione è così strutturato:

• Ambiente di Ricezione e Controllo: alimentato dai dati trasmessi che dovranno essere sottoposti a controlli di completezza e congruità (ad es. regole di obbligatorietà, formato, range di valori, etc.); l’esito negativo di un controllo può provocare un “warning” oppure lo scarto dell’intera occorrenza.
• Ambiente ufficiale: dati che hanno superato i controlli.
• Ambiente consolidato: informazioni acquisite e validate dalle amministrazioni centrali e regionali.

Sistema Centrale di Acquisizione IGRUE

I progetti sono identificati tramite un Codice Unico di Progetto (CUP) e tramite un identificativo calcolato tramite concatenazione dei seguenti dati:

• Codice Regione/Amministrazione mittente
• Codice Sistema Informatico mittente
• Codice Identificativo del progetto nel sistema mittente

Un progetto una volta acquisito sul sistema centrale non può essere cancellato, ma solo aggiornato e/o integrato.

I servizi del sistema centrale sono esposti dalla Porta di Dominio SPCoop del Ministero dell’Economia e Finanze (MEF).

I dati devono essere trasmessi in messaggi SOAP With Attachments, in accordo ad un “protocollo unico di colloquio” che offre indicazioni su come implementare, nel proprio sistema informativo, le funzionalità esposte dal sistema centrale, e che è definito dalle seguenti specifiche:

• Monitoraggio unitario Progetti 2007/2013, “Protocollo di colloquio”, Versione 3.1, Marzo 2009.
• Protocollo Applicativo Alimentazione dati di attuazione 2007-2013, “Allegato al Protocollo di colloquio”, Versione 1.1, Aprile 2008.

Il sistema centrale mette a disposizione diversi servizi, ognuno caratterizzato da uno specifico insieme di operazioni:

• Servizio di Trasmissione dei dati di attuazione. Si tratta del servizio deputato ad accogliere nel sistema centrale i dati di attuazione.
  • Operazione di Prenotazione Ticket:il Sistema Informativo IGRUE riserva e restituisce un identificativo univoco per una fornitura di dati di attuazione. Il ticket ottenuto sarà utilizzabile negli altri servizi per ottenere informazioni relative all’invio e richiedere un codice per una procedura di attivazione (che verrà inviata successivamente).
  • Operazione di Invio File di colloquio dei dati di avanzamento da trasmettere al sistema nazionale di monitoraggio del QSN: il sistema centrale accoglie i dati inviati da un sistema locale (nota: il body della richiesta deve contenere il riferimento ad un ticket; l’allegato è un file compresso zip, contenente i dati di attuazione inseriti in un singolo file di colloquio ATT0001.txt attraverso un formato definito nella specifica. La risposta indica l’esito dell’operazione)
  • Operazione di Assegnazione Codice Procedura di Attivazione: il sistema centrale restituisce un identificativo che il sistema locale potrà utilizzare per codificare una nuova procedura di attivazione (il codice verrà inserito dal sistema locale nel file di colloquio dei dati di avanzamento che saranno trasmessi al sistema centrale tramite il servizio di Invio File).
• Servizio di Gestione degli Eventi. Permette di restituire e trattare eventi che si sono verificati sul sistema centrale.
  • Operazione di Lista Eventi: un sistema locale prende visione degli eventi che gli competono come, ad esempio, lo stato di elaborazione di una fornitura di dati di attuazione precedentemente inviata. Nella richiesta è possibile inserire un ticket per filtrare la lista ritornata ai soli eventi associati al ticket.
  • Operazione di Cancellazione Eventi: un sistema locale chiede al sistema centrale di cancellare (logicamente) un evento in modo da evitare che quest’ultimo sia preso in considerazione da una sucessiva operazione di lista degli eventi. La richiesta contiene gli id degli eventi da cancellare. La risposta contiene l’esito della cancellazione.
  • Operazione di Lista delle Tipologie di Evento: un sistema locale chiede al sistema centrale di avere la zzclassificazione degli eventi trattati.
• Servizio di Gestione degli Esiti. Permette di comunicare ad un sistema locale il risultato dell’elaborazione di una fornitura di dati di attuazione. Tutte e quattro le operazioni sono così formate: la richiesta contiene il ticket per cui richiedere informazioni; la risposta contiene un allegato contenente gli esiti (file zip).
  • Operazione di Statistiche Elaborazioni: il sistema centrale fornisce alcune statistiche relative ai dati elaborati.
  • Operazione di Statistiche Scarti: il sistema centrale fornisce alcune statistiche relative ai dati scartati.
  • Operazione di Log degli Errori: il sistema centrale fornisce alcune informazioni di dettaglio relative ai dati con errori o warning.
  • Operazione di Esito Elaborazione per Anagrafica di Riferimento: il sistema centrale fornisce alcune informazioni di dettaglio relative ai dati acquisiti. Sono presenti tre strutture di riferimento per i dati di attuazione inviati: a) Anagrafica dei progetti; b) Anagrafica delle procedure di attivazione: c) Anagrafica dei soggetti. Per ogni tipologia di dato viene indicato se le strutture dati trasmesse siano state completamente acquisite o totalmente/parzialmente scartate, la rilevazione di warning e di enventuali errori.
• Servizio di Consultazione delle Tabelle di Contesto. Si tratta del servizio in grado di fornire ai sistemi locali le tabelle contenenti i dati di contesto da utilizzare per la trasmissione dei dati di attuazione al sistema centrale (le tabelle di contesto sono fornite in un allegato compresso come file zip).
  • Operazione di ricezione delle Tabelle di Contesto Complessive: il sistema centrale restituisce tutte le tabelle di contesto che competono al sistema locale chiamante.
  • Operazione di ricezione Tabelle di Contesto Indicate: il sistema centrale restituisce le tabelle di contesto, richieste e di competenza, al sistema locale chiamante.

Dal punto di vista infrastrutturale GovMix estende la piattaforma OpenSPCoop per metterla in condizione di caricare e configurare, in modo automatico le funzionalità di integrazione descritte nei GovAdapter, nonché di attivare l’eventuale logica applicativa in essi specificata (ad es. trasformazioni del formato dei dati, ed altre elaborazioni che possono essere necessarie per rendere compatibili con l’accordo di servizio le interfacce dei sistemi applicativi di back-end).

In particolare le operazioni da svolgere sono:

• aggiornare la configurazione della Porta di Dominio SPCoop;
• aggiornare la configurazione del Registro dei Servizi SPCoop;
• eventuale deploy e configurazione di proxy applicativi o di componenti applicative esterne.

In questo modo, i gestori della Porta di Dominio OpenSPCoop avranno la possibilità di aggiungere “on-demand” gli adattatori per i servizi eGov che di volta in volta dovranno essere integrati.

Un ulteriore obiettivo del progetto è inoltre quello di estendere le funzionalità della piattaforma OpenSPCoop per consentire ai servizi applicativi di interoperare anche con servizi eGov che non siano ancora stati integrati con il Sistema Pubblico di Cooperazione. La Porta di Dominio, infatti, non consente di interoperare con protocolli di comunicazione diversi da SPCoop, come ad es. la Posta Elettronica Certificata (PEC) ed i Web Service, che tuttavia costituiscono una parte significativa dei servizi eGov oggi disponibili, in quanto la conversione verso il protocollo SPCoop richiederà ancora tempo ed investimenti.

GovMix trasformerà OpenSPCoop in un bus di cooperazione applicativa in grado di comunicare con modalità multicanale con diverse tipologie di implementazione di servizi eGov, permettendo di scegliere fra una molteplicità di connettori disponibili: il protocollo SPCoop, la Posta Elettronica, i Web Service conformi alle specifiche WS-I Basic Profile, etc..

Il Bus estende le funzionalità di integrazione di OpenSPCoop

La possibilità di agganciare nuovi canali di comunicazione alternativi SPCoop preservando tutti i vantaggi indotti dalla gestione centralizzata su un’unica piattaforma (ad es. i servizi di tracciamento, auditing e monitoraggio) estende le potenzialità di OpenSPCoop oltre l’ambito eGov rendendolo una soluzione applicabile anche per contesti di tipo B2B.

Approfondimenti

Questoarticolo descrive l’architettura del primo prototipo del Bus di Integrazione Govmix.

Un Ente che voglia rendere i propri servizi interoperabili secondo gli standard del Sistema Pubblico di Cooperazione (SPCoop) deve dotarsi di una Porta di Dominio. Dopo anni di sperimentazioni e raffinamenti questa è un componente ormai standardizzata, disponibile sia nell’offerta di vari produttori che nel mercato open-source (ad es. i progetti OpenSPCoop e FreESBee.

Tuttavia, per ottenere che i propri sistemi informativi siano effettivamente in grado di condividere i propri dati con quelli delle altre Amministrazioni, l’Ente dovrà interfacciare la Porta di Dominio con i propri “servizi applicativi” (ndr. nella terminologia SPCoop così sono chiamate le applicazioni di back-end, per distinguerli dai “servizi eGov” pubblicati sulla Porta di Dominio).

Per svolgere tali attività, il gestore della Porta di Dominio necessita di informazioni specifiche per

• predisporre l’infrastruttura per erogare e/o fruire i servizi eGov e

• identificare i punti e le modalità di integrazione dei sistemi di back-end.

L’esperienza di numerosi progetti dimostra che tali informazioni non sono immediatamente derivabili dall’Accordo di Servizio e devono essere ogni volta ricavate con una complessa attività di analisi della (talvolta scarsa) documentazione disponibile. In alcune realtà la raccolta di tali informazioni avviene per mezzo di formulari espressi il linguaggio naturale che, pur rappresentando un passo avanti, forniscono specifiche di tipo informale che il gestore deve comunque tradurre in termini di configurazioni della Porta di Dominio con un processo manuale e quindi soggetto all’errore umano.

GovMix intende sperimentare una metodologia innovativa che semplifica in modo drastico questi processi grazie alla possibilità di caricare sulla Porta di Dominio gli “adattatori” specifici dei servizi eGov che si desiderano integrare. Tali adattatori, denominati GovAdapter, potranno essere scaricati da repository online (uno dei quali sarà ovviamente disponibile sul nostro portale) o prodotti in modo automatico a partire da un descrittore XML (il GSD o “eGov Service Descriptor“) che fornisce una specifica formale delle caratteristiche di integrazione del servizio .

Caricamento ed attivazione di un GovAdaper

Dall’impiego dei GovAdapter si attendono grandi benefici non solo dal punto di vista della riduzione dei tempi e dei costi di integrazione, ma anche e soprattutto dal punto di vista della semplificazione organizzativa e del processo.

Infatti, la disponibilità dei GovAdapter permette infatti di evitare del tutto la complessa fase di analisi, modellazione e progettazione dei servizi a partire dalle specifiche formali degli Accodri di Servizio, attività che nella gran parte dei casi si rivela particolarmente critica sia per l’inerente complessità, sia per la necessità di coinvolgere analisti altamente specializzati.

Anche la configurazione della Porta di Dominio si semplifica in modo drastico. Ad es., nel caso di OpenSPCoop si passa dalla necessità di operare tramite la control station, e quindi di padroneggiare i concetti della specifica SPCoop, ad un approccio di tipo plug&play in cui per l’installazione di un nuovo servizio sarà sufficiente conoscere e specificare le caratteristiche di indirizzamento e sicurezza dei sistemi applicativi di back-end (indirizzi ip, porte, protocolli, chiavi di accesso, etc.). L’intero processo risulterà alla portata di un comune sistemista applicativo e viene meno l’esigenza di impiegare personale specializzato sulla piattaforma SPCoop.

Infine,questa metodologia semplicifca la valutazione dei costi di attuazione dei progetti eGov. Il costo di installazione di un GovAdapter è infatti una costante indipendente dalla complessità del servizio. La parte variabile dei costi del progetto sarà invece relativa allo sviluppo delle funzioni applicative eventualmente necessarie per adattare la logica dei sistemi di back-end all’interfaccia esposta dal servizio proxy. Si tratta, tuttavia, di sviluppi applicativi tradizionali, tipicamente indirizzati alla soluzione di problemi di trasformazione di formato dei dati e di flussi di messaggi, e quindi facilmente valutabili ad es. con la Function Point Analysis (FPA), la tecnica raccomandata dal CNIPA per la stima dei costi dei progetti di sviluppo software, inclusi quelli relativi all’integrazione di servizi eGov.

Questo articolo descrive l’approccio seguito per la progettazione dei GovAdapter e quindi del Bus di Integrazione GovMix.

Per consentire un rapido sviluppo dei contenuti, gli strumenti inizialmente messi a disposizione della comunità sono standard e facili da usare:

• articoli e discussioni per commentare gli articoli pubblicati in perfetto stile “blog”; inizialmente, per non disperdere l’attenzione, l’idea è di mantenere il focus su un insieme limitato di argomenti per volta, successivamente con l’espandersi della community e la crescita del numero di utenti che potranno svolgere un ruolo attivo di moderatori, si valuterà la possibilità di ospitare delle aree libere di discussione (forum);

• feed rss, per essere sempre “sintonizzati” sulle novità relative agli argomenti di interesse ed aggregare i contenuti di GovMix sui propri siti e blog;

• mailing list, per favorire la circolarità delle informazioni;

• glossario, per concordare una terminologia comune ed evitare le ambiguità.

Dal punto di vista organizzativo, le regole con le quali intendiamo partire sono molto semplici e potranno via via essere aggiornate in base all’evolversi delle esigenze della comunità e dei servizi utilizzati.

1. La registrazione è necessaria per partecipare alle discussioni. Invitiamo a registrarsi anche i semplici visitatori perché ciò consentirà di monitorare la eventuale crescita della comunità e la potenziale diffusione dei risultati.

2. I contributi degli utenti potranno essere “moderati”, ma ciò avverrà solo in casi estremi. Lo staff conserva comunque il diritto di restringere l’accesso nel caso di violazioni continue e ripetute delle comuni regole di netiquette.

3. Lo staff che gestisce il portale è aperto, l’auspicio è infatti che presto un certo numero di utenti del sito possa collaborare attivamente ai lavori della comunità, sia come autore, proponendo i propri articoli, sia come moderatore, sia anche solo segnalandoci altri progetti, software o iniziative che possano essere utili ai nostri scopi. Vi inviamo ad inviarci i vostri contributi tramite la seguente casella di posta, appena possibile vi contatteremo.

Se non altrimenti specificato dall’autore, tutto i contenuti prodotti e pubblicati sul sito sono da intendersi regolati dalla licenza “Creative-Commons Attribution (by)”.

Hai delle osservazioni o dei  suggerimenti? registrati e lascia i tuoi commenti in calce a questo post.

“Enterprise Integration Pattern” (EIP) è un libro di Gregor Hohpe and Bobby Woolf (titolo completo “Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions”, Addison-Wesley, 2004, http://www.eaipatterns.com), in cui gli autori definiscono tramite un preciso vocabolario ed una corrispondente notazione grafica, un sistema di 65 diversi pattern di integrazione caratteristici dei sistemi a scambio di messaggi, classificati in sei principali categorie:

• Channel Patterns: descrivono le caratteristiche salienti dei sistemi di messaging.
• Message Construction Patterns: pattern relativi alla costruzione dei messaggi.
• Routing Patterns: spiegano i meccanismi e gli algoritmi per inoltrare/smistare opportunamente i messaggi alle corrette destinazioni.
• Transformation Patterns: descrivono i meccanismi di trasformazione (sintattica e/o semantica) del contenuto del messaggio.
• Endpoint Patterns: descrivono le varie viste dei possibili client del sistema di messaging e il modo di produrre e/o consumare messaggi.
• System Management Patterns: descrivono i pattern per monitorare il percorso dei messaggi all’interno del sistema di messaging.

Gli Enterprise Integration Patterns possono essere implementati senza la necessità di scrivere codice utilizzando il prodotto open source Apache Camel.

Un GovAdapter è un descrittore formale di un servizio eGov che ne specifica la logica di interfacciamento. Una volta caricato dal bus GovMix, un GovAdapter onsente automaticamente di interoperare con il servizio eGov corrispondente senza la necessità di sviluppare codice applicativo ad-hoc.

La sfida per l’affermazione dei servizi eGov si gioca sul difficile terreno dell’integrazione dei sistemi applicativi. Govmix è un punto di incontro e confronto per gli sviluppatori ed un laboratorio aperto dove si provano soluzioni innovative per semplificare l’integrazione e l’interoperabilità dei servizi della Pubblica Amministrazione.

Questa pagina contiene l’indice delle risorse disponibili per il download.

1) Presentazione del progetto alla CONFSL 2009 (III Conferenza Italiana sul Software Libero), Bologna 13 giugno 2009

• Scarica la presentazione in versione PDF
• Scarica la presentazione in versione ODP

2) Linguaggio GSD per la descrizione delle specifiche di integrazione dei Servizi eGov

• Scarica lo schema XSD

3) Prototipo del Bus di Integrazione GovMix

Il  prototipo include i GovAdapter dei servizi di Comunicazioni Obbligatorie, IGRUE e Protocollo Interoperabile.

• Scarica la versione 0.5

GovMix si propone di essere il punto di riferimento per ottenere informazioni complete e qualificate per l’integrazione dei principali servizi eGov attivi sul territorio nazionale.

Il primo obiettivo della community sarà quindi di censire i servizi, classificandoli in funzione dei protocolli utilizzati (SPCoop, PEC, WS-I, etc.) schedando, secondo uno schema standard di raccolta, le caratteristiche e le risorse pubblicamente disponibili (documenti, software, etc.) utili per la loro integrazione. Si noti che il focus dovrà sempre essere rivolto alle problematiche di integrazione, rimandando alle fonti ufficiali per tutti gli altri aspetti relativi al servizio (scenari di applicazione, riferimenti normativi, etc.).

Affinché il materiale raccolto possa risultare un efficace strumento di supporto alle concrete esigenze che gli utenti della comunità affrontano nell’ambito dei loro progetti, è importante garantirne la qualità, in particolare in termini di concretezza, non ridondanza e immediata fruibilità.

GovMix intende sperimentare un processo di produzione innovativo tramite il quale le competenze di numerosi esperti su diversi domini applicativi siano, dapprima raccolte in schede informative semi-formali, quindi trasformate in una descrizione formale, tramite un linguaggio descrittivo basato su XML, dal quale possano infine essere trasformate in adattatori applicativi direttamente utilizzabili dalla piattaforma OpenSPCoop.

A tale scopo sarà definito ed adottato un formato di descrizione dei servizi, che chiameremo “eGov Service Descriptor (GSD), che permetta di specificare in maniera semplice, diretta e non ambigua, tutto quanto necessario e sufficiente alla integrazione di un servizio eGov. Tale formato sarà ottenuto sia estendendo in modo opportuno gli attuali standard di descrizione dei servizi (principalmente il linguaggio WSDL e/o il formato di rappresentazione degli Accordi di Servizio e degli Accordi di Cooperazione SPCoop), sia identificando metodologie di descrizione semiformali che vadano efficacemente a sostituire le centinaia di pagine di documentazione che solitamente si accompagna ad ogni nuovo servizio.

Il GSD fornisce la specifica formale delle caratteristiche di integrazione di un servizio eGov

Approfondimenti

Questo articolo formula una prima proposta per il linguaggio di descrizione dei servizi eGov.

Questa sezione del sito ospita il catalogo dei servizi eGov attualmente censiti.

Oggi gli standard e le tecnologie per la cooperazione applicativa sono largamente disponibili, ma, come affermato da Emilio Frezza (CNIPA) a conclusione del convegno “Semplificazione, efficienza, cooperazione: l’ora dei fatti!“, tenutosi il 24 settembre 2008 a Roma, l’ostacolo principale per l’attuazione dei progetti di integrazione in ambito SPC è la cosiddetta “curva di apprendimento”, per superare il quale è necessario formare risorse specializzate nell’ambito delle aziende, ma soprattutto diffondere la cultura della cooperazione applicativa all’interno delle amministrazioni.

Tuttavia, fatte salve le eccezioni, i dettagli operativi dei servizi eGov sono spesso scarsamente documentati o, di contro, formalizzati in complessi sistemi di specifiche di difficile comprensione e che possono essere fonte di notevoli ambiguità interpretative. Tutto ciò ostacola la diffusione dei servizi ed è uno dei principali motivi degli alti costi di gestione che caratterizzano i progetti di informatizzazione dei flussi amministrativi che richiedono l’interoperabilità tra diversi Enti.

Da ciò l’idea di aggregare una comunità intorno al comune obiettivo di favorire la circolarità delle informazioni, la condivisione di esperienze, buone pratiche e strumenti software. Ritieniamo infatti che la logica di questi servizi possa essere invece correttamente ricostruita in maniera più semplice coinvolgendo in un comune sforzo collaborativo coloro che abbiano già avuto esperienze concrete nell’utilizzo e nell’erogazione dei servizi. Realizzare e mantenere nel tempo una base di conoscenza e una libreria di componenti software open-source per l’utilizzo dei servizi eGov è un compito ideale da svolgere in maniera collaborativa, in linea con la filosofia open-source ed utilizzando gli strumenti del Web 2.0.

Un altro vantaggio che si potrà trarre dagli sforzi di un’ampia comunità di utenti è la possibilità di sperimentare i GovAdapter  (i moduli open-source per l’integrazione dei servizi eGov) in una molteplicità di contesti e quindi di raccogliere utili feedback che consentiranno di migliorare rapidamente la qualità delle soluzioni proposte.

Inizialmente la comunità sarà moderata dai fondatori del progetto (Link.it ed il dipartimento di Informatica dell’Università di Pisa) ma l’auspicio è che presto essa trovi dei propri ed autonomi meccanismi di autogoverno ed esprima nuovi soggetti intenzionati a partecipare in maniera attiva.

In particolare, la comunità è aperta ai contributi diretti da parte di tutti i progetti che, a livello nazionale, hanno realizzato, o sono in procinto di realizzare, servizi eGov. Ad essi GovMix fornisce una vetrina ed un canale di divulgazione dei risultati, sempre privilegiando gli aspetti tecnici ed operativi relativi all’utilizzo effettivo dei servizi.

Approfondimenti

Questo articolo descrive gli strumenti ed i servizi che consentono agli utenti della comunità Govmix di svolgere le proprie attività e formula una proposta organizzativa per il coordinamento delle stesse.

L’integrazione è il task più complesso e costoso dei progetti eGov ed uno dei principali ostacoli all’attuazione dell’interoperabilità dei servizi della Pubblica Amministrazione.

Il progetto GovMix intende ideare e sperimentare una nuova metodologia di produzione in grado di fornire soluzioni “chiavi in mano” per l’integrazione di servizi di eGov.

GovMix persegue questo obiettivo in due modi:

• promuovendo la condivisione della conoscenza fra gli esperti e gli utilizzatori dei servizi in modo da favorire la circolarità delle informazioni;

• sperimentando tecniche innovative per sintetizzare tali conoscenze in descrittori formali che possano essere utilizzati per produrre in modo automatico dei moduli “adattatori” (i cosiddetti “GovAdapter”) che consentono di semplificare l’integrazione dei servizi con la Porta di Dominio ed i sistemi di back-end degli enti, riducendo i tempi e le risorse necessarie per l’attuazione dei progetti eGov.

GovMix è un’iniziativa condotta nello spirito proprio dei progetti open-source per affrontare in modo innovativo e pragmatico il problema dell’integrazione efficace dei servizi eGov.

Elenchiamo di seguito gli obiettivi, in ordine progressivo di complessità:

• diventare un punto di aggregazione e confronto per una comunità di utenti ed esperti di settore che operano nelle Pubbliche Amministrazioni, nelle aziende e negli istituti di ricerca;
• censire tutte le informazioni utili per l’integrazione dei servizi eGov oggi disponibili e costruire una base di conoscenza condivisa a disposizione di tutti i membri della comunità;
• utilizzare le conoscenze acquisite per mettere a punto una libreria di componenti open source (i cosiddetti “GovAdapter”) per semplicare l’integrazione dei servizi eGov;
• costruire e sperimentare in modo collaborativo un framework che semplifichi al massimo l’integrazione delle applicazioni preesistenti permettendo l’effettiva fruizione ed erogazione “chiavi in mano” dei servizi eGov.

GovMix è un’iniziativa di Link.it, la società promotrice del progetto OpenSPCoop (la Porta di Dominio open source), e dell’Università di Pisa.