You are on page 1of 6

s DOSSIER

di Ciro DUrso

La Cooperazione Applicativa: la pubblicazione


Il modello di Publish & Subscribe come modalit di comunicazione tra sistemi informativi distinti consente di progettare infrastrutture di cooperazione in tutti quei contesti che non richiedono la sincronizzazione delle applicazioni che interagiscono tra loro
tali che vedono la partecipazione di vari enti pubblici, si struttura in una serie di domini indipendenti rappresentati dalle singole amministrazioni con i propri patrimoni informativi. La cooperazione assicurata dalle cosiddette porte di dominio, cio dallo strato di software che permette laccesso alle risorse applicative e alle procedure informatizzate delle varie amministrazioni, secondo precisi modelli di interazione che garantiscono adeguati controlli di legittimit e di efficienza2. I paradigmi della cooperazione applicativa sono riconducibili, come sopra accennato, a due tipologie principali. La richiesta di servizio consiste in un messaggio prodotto da unapplicazione di un dominio cliente e diretto ad unapplicazione di un dominio servente. Il messaggio richiede lesecuzione di unapplicazione del dominio servente, fornendo eventualmente anche le informazioni necessarie per lelaborazione, quindi il servente esegue una procedura ed invia una risposta destinata allapplicazione cliente. La risposta unindicazione certa che lapplicazione servente ha attuato la richiesta, anche se eventualmente con esito negativo. La richiesta di servizio - che realizza uninterazione sincrona nel senso che il cliente deve comunque sincronizzarsi, prima o poi, con la risposta del servente - pu essere di due tipi:
interrogazione: la richiesta di

e modalit di interazione telematica tra differenti soggetti pubblici e privati (cio aziende, pubbliche amministrazioni, istituti bancari) sono classificabili secondo due tipologie generali (cfr. [2] e [3]): la richiesta di servizio e la comunicazione di evento. La prima risolve tipicamente le esigenze di interazione sincrona (per esempio Request/Replay in RPC), anche se possibile immaginare scenari nei quali la risposta viene inviata in modalit asincrona (per esempio invio di una richiesta per mezzo di messaggi basati su protocollo SMTP al fine di non rimanere in attesa di un servizio con latenza di erogazione elevata). La seconda, invece, costituisce il paradigma per la collaborazione asincrona, ed in tale contesto il modello pi popolare senzaltro quello del Publish & Subscribe, che realizza la notifica di uno stesso evento a pi soggetti. Il presente articolo ha lo scopo di descrivere questa tipologia di comunicazione soffermandosi su una delle principali problematiche che un soggetto pubblicante deve affrontare al fine di connettersi ad un generico sistema di P&S: lestrazione dal sistema legacy delle informazioni da pubblicare. La Cooperazione Applicativa nella Pubblica Amministrazione Il Piano di Azione di e-government
22 www.iseries.it - www.news400shop.it

declina la proposta governativa a sostegno del cambiamento innovativo nelle pubbliche amministrazioni centrali e territoriali, da realizzare mediante lutilizzo diffuso e integrato delle tecnologie dellinformazione nellintero processo di ammodernamento. Le linee guida del Piano si propongono lobiettivo di:
realizzare linteroperabilit telema-

tica tra tutte le pubbliche amministrazioni per rendere possibile lerogazione di servizi integrati di sportello; realizzare laccesso telematico alle informazioni ed ai servizi di tutta la pubblica amministrazione. Lattuazione del piano di azione di e-government ha come fondamento imprescindibile la realizzazione di adeguati meccanismi di cooperazione tra le diverse amministrazioni. Se lobiettivo consentire al cliente, cittadino o impresa, di accedere ai servizi delle amministrazioni da un qualsiasi front-office, necessario che il back-office di ciascuna amministrazione sia raggiungibile da tali punti di accesso. Questo attuabile soltanto con tecnologie informatiche complesse, basate su una infrastruttura standard di cooperazione applicativa1. Lo scenario di cooperazione tra le pubbliche amministrazioni, cos come si sta delineando nei progetti orizzon-

servizio finalizzata allacquisizione di uninformazione del dominio servente ma che non modifica alcun oggetto applicativo interno al dominio stesso; transazione: la richiesta di servizio destinata a produrre una variazione permanente in un oggetto applicativo del dominio servente. La comunicazione di evento invece il messaggio che viene generato da unapplicazione allo scopo di inforiSeries NEWS - SETTEMBRE 2002

La Cooperazione Applicativa: la pubblicazione s

FIGURA 1 Il modello federativo

vizi Integrati alle Imprese, nel cui ambito gli enti partecipanti hanno realizzato lintegrazione dei propri servizi verticali, sviluppati per i grandi utenti4 con il portale per le imprese, presentato ufficialmente allo SMAU 2001. Questo primo prototipo di front-office delocalizzato espone una serie di servizi propri delle diverse amministrazioni, che si integrano con laccesso alle risorse dei back-office federati. Lautenticazione del rappresentante dellimpresa, richiedente del servizio, avviene tramite una smart-card la cui certificazione garantita dalla legge5. In tale progetto sono stati utilizzati i due paradigmi della cooperazione applicativa, infatti non solo sono stati esposti i servizi delle singole amministrazioni per linterazione sincrona, ma stata anche realizzata linfrastruttura (Core System) per il Publish & Subscribe che consente ad ogni ente di affidare e/o ricevere in modalit asin-

Note
1 Con questo termine si indicano in generale i possibili schemi di interscambio di informazioni tra le amministrazioni; a livello tecnico si utilizzano anche termini quali web services e publish & subscribe systems, che indicano rispettivamente la disponibilit - secondo determinati protocolli - di servizi on-line, e la notifica di eventi attraverso un sistema comune. 2 Le modalit con cui le amministrazioni interagiscono sono o una richiesta di servizio ovvero una comunicazione di evento, realizzate per mezzo di messaggi XML su protocollo HTTP. 3

FIGURA 2 Autentica dellutente


mare altre applicazioni di uno o pi domini destinatari, dellavvenuto cambiamento delle informazioni relative ad un particolare oggetto applicativo (per esempio cambio di indirizzo legale di unimpresa) o della creazione di un nuovo oggetto applicativo (per esempio iscrizione di una nuova impresa). Il messaggio contiene anche le informazioni, nuove o modificate, che descrivono levento stesso. Il modello alla base delle interazioni dunque di tipo federativo: i diversi soggetti pubblici rendono disponibili reciprocamente i principali servizi di dominio e lutente pu interagire indiffeiSeries NEWS - SETTEMBRE 2002

rentemente con un front-office di dominio, cio con il portale verticale proprio di una determinata amministrazione, ovvero con un portale tematico centralizzato che realizza un front-office delocalizzato3 al fine di richiedere servizi a varie amministrazioni (figura 1). II requisito fondamentale, quindi, risiede nella possibilit, per lutente di autenticarsi, di farsi riconoscere e far riconoscere il diritto al servizio, con le modalit uniformi e semplici presso tutti i sistemi di front-office disponibili (figura 2). Una prima applicazione di questo modello ha riguardato il progetto Ser-

Si possono citare, al riguardo, il portale delle imprese, il portale dei lavoratori ecc.

Quali, per esempio, i consulenti del lavoro, i dottori commercialisti, per maggiore chiarezza, si precisa che con laggettivo verticale si indicano i servizi di interesse di ununica amministrazione esposti, tipicamente, sui rispettivi portali verticali; sono, invece, orizzontali i servizi che hanno impatto su pi di una amministrazione e che tipicamente derivano dallintegrazione di pi servizi verticali. Il soggetto certificatore deve essere iscritto nellelenco pubblico di cui al DPR 28 dicembre 2000 n.445, ovvero coincide con il Ministero dellInterno nel caso della CNS (Carta Nazionale Servizi).

www.news400shop.it - www.iseries.it

23

s La Cooperazione Applicativa: la pubblicazione

crona certe tipologie di informazioni (per esempio nascita di unimpresa, variazione della sede legale). Il modello del sistema di P&S I soggetti che cooperano attraverso il sistema di P&S possono essere schematizzati come domini con i propri caratteristici patrimoni informativi ed organizzativi. Essi colloquiano attraverso le due entit generali: porta di pubblicazione e porta di sottoscrizione, come rappresentato nella figura 3. Pi in dettaglio il sistema di P&S costituito dalle seguenti componenti (figura 4):

Sistema Gestore del P&S Porta di Pubblicazione Porta di Sottoscrizione Gateway di Pubblicazione Gateway di Sottoscrizione

FIGURA 3 Colloquio fra domini

Il Sistema Gestore il cuore del sistema di P&S, esso realizza tutte le funzionalit del modello mettendo a disposizione delle porte i servizi di gestione delle code di pubblicazione e sottoscrizione, i servizi di amministrazione (definizione degli eventi da pubblicare, sottoscrizione di particolari eventi, modifica delle liste di sottoscrizione), i servizi di gestione (tracciamento di quanto avvenuto nel sistema con opportuni log). Costituisce quindi una componente comune ai domini. Le Porte di Pubblicazione e Sottoscrizione disaccoppiano la specificit dei domini dal Sistema Gestore. Esse sono sviluppate, come il Sistema Gestore, una volta per tutte e non prevedono una personalizzazione applicativa per linstallazione nel particolare dominio (tipicamente vengono sviluppate varie versioni unicamente per adattarsi alla specificit sistemistica del dominio). Costituiscono quindi linterfaccia standard con cui i sistemi dei domini colloquiano con il Sistema Gestore. I Gateway di Pubblicazione e Sottoscrizione isolano invece le specificit del sistema legacy del dominio: poich limplementazione delle porte unica e domain-indipendent occorre realizzare uno strato di adattamento tra le caratteristiche del particolare legacy e la generalit della porta.
26 www.iseries.it - www.news400shop.it

FIGURA 4 Componenti del sistema di P&S

La pubblicazione di un evento Come esempio di funzionalit del sistema di P&S esaminiamo in dettaglio le fasi che caratterizzano la pubblicazione di un evento, a tal fine consideriamo il sequence diagram di figura 5. Pubblicare un evento significa affidarlo al gestore delle code dopo aver fatto i dovuti controlli e riportato le varie operazioni effettuate in opportuni log (gestiti su file o tabelle). In particolare il Gestore Eventi riceve levento (in formato XML) dalla porta di pubblicazione e quindi riporta tale informazione nel log. Il Gestore Eventi chiama un servizio del Gestore dei Con-

trolli che verifica se il publisher possiede i diritti per pubblicare quel particolare evento, e realizza un controllo sintattico del messaggio XML che costituisce levento (ci possibile dal momento che esiste un repository dei DTD delle varie tipologie di evento). Da notare la generazione della ricevuta di presa in carico restituita al publisher opportunamente firmata dal Sistema di Gestione. Tale ricevuta non costituisce, ovviamente, una ricevuta di ritorno che, se prevista, deve essere consegnata in modo asincrono al dominio pubblicante attraverso la sua Porta di Sottoscrizione.
iSeries NEWS - SETTEMBRE 2002

La Cooperazione Applicativa: la pubblicazione s

larchivio dellapplicazione, per eventuali dettagli informativi, possibile costruire il messaggio da pubblicare. A tal fine il Gateway dovr:
interrogare la tabella dei log per

FIGURA 5 Le fasi che caratterizzano la pubblicazione di un evento

avere la chiave dei record relativi a nuove iscrizioni ad una certa data mediante la chiave ricavata interrogare la base dati legacy per recuperare le informazioni necessarie per la costruzione del messaggio affidare il messaggio alla Porta di Pubblicazione (questo pu essere realizzato prevedendo come interfaccia standard delle porte una semplice tabella di un DBMS relazionale che viene interrogata dalle funzionalit della porta stessa) Lobiettivo del tutto generale progettare il Gateway in modo da essere il pi possibile autonomo: qualsiasi errore incontrato in unelaborazione deve essere riparato nel corso delle successive, senza la necessit di intervento da parte di un operatore. Il flusso logico dellapplicazione diviso in due fasi: la fase 1 consiste nel popolamento di una tabella intermedia che contiene tutte le variazioni riscontrate nella generica elaborazione con i relativi dettagli, la fase 2 invece costituita dallinterrogazione della tabelBibliografia [1] F. Fabret, A. Jacobsen, F. Llirbat, J. Pereira, K. Ross, D. Shasha - Filtering algorithms and implementation for very fast publish/subscribe systems, Proceedings of the ACM SIGMOD conference, 2001 Riferimenti [2] Quaderno AIPA Dicembre 1999 - N. 3 - supplemento al N. 11-12 di Informazioni: http://www.aipa.it/servizi[3/p ubblicazioni[5/quaderni[3/qu aderni_3.pdf [3] Dipartimento della Funzione Pubblica Rete Nazionale, Architettura Applicativa, novembre 2001

FIGURA 6 Workflow generale del Gateway di pubblicazione


rappresentato il contesto applicativo del Gateway di pubblicazione.
Lazienda assicurativa riceve una

FIGURA 7 Diagramma di transizione dellautoma ASF


La progettazione del gateway verso il sistema legacy Lattivit pi rilevante che il generico dominio (per esempio azienda, realt pubblica) deve realizzare per connettersi ad un qualsiasi sistema di P&S consiste nella progettazione dei Gateway di pubblicazione e sottoscrizione. Esaminiamo in dettaglio la parte di pubblicazione. Al fine di riferirci ad un contesto reale, consideriamo unazienda assicurativa che, ricevuta liscrizione di un nuovo assicurato, voglia comunicarla attraverso il sistema di P&S ad altri soggetti (per esempio agenzie sul territorio, partner assicurativi). Il workflow generale rappresentato in figura 6, mentre in figura 9
iSeries NEWS - SETTEMBRE 2002

denuncia di iscrizione e la memorizza nei propri archivi (procedure e sistemi legacy) Il Gateway di Pubblicazione rileva la variazione eseguita e determina levento associato (in questo caso nuova iscrizione, ma si potrebbe estendere ad altri eventi come la variazione dei dati anagrafici) Il Gateway invia un messaggio al Sistema di Gestione del P&S indicante la tipologia dellevento, la sua chiave e le informazioni associate Il Sistema di Gestione del P&S distribuisce il messaggio ai soggetti sottoscrittori di quella tipologia di evento. Le informazioni relative alliscrizione di un nuovo assicurato sono tipicamente memorizzate su tabelle della base dati dellapplicazione di produzione: al fine di renderle disponibili per la pubblicazione occorre che esista e che sia interrogabile un log da cui verranno rilevate tutte le modifiche allarchivio effettuate in una certa data e classificabili per tipologia. Interrogando tali log e

www.news400shop.it - www.iseries.it

27

s La Cooperazione Applicativa: la pubblicazione

FIGURA 8 Il flusso dellelaborazione


la intermedia, dallelaborazione del messaggio in formato XML e dalla consegna alla Porta di Pubblicazione. In Figura 7 riportato il diagramma di transizione dellautoma a stati finiti (ASF) che modella lelaborazione degli errori: lautoma inizia una computazione se lelaborazione precedente si conclusa con un errore (in fase 1 o in fase 2) e termina la computazione in corrispondenza dellelaborazione andata a buon fine (che quindi ha riparato anche gli errori precedenti). Considerare gli errori avvenuti nel corso dellelaborazione i-esima, durante lelaborazione i+1-esima significa nel caso di errore in fase 1 - recuperare i record che dovevano essere pubblicati pri30 www.iseries.it - www.news400shop.it

ma di recuperare quelli correnti ovvero nel caso di errore in fase 2 - pubblicare dalla tabella intermedia quei record per i quali si verificato lerrore. La figura 8 riporta il flusso dellelaborazione. Conclusioni Sistemi di questo tipo, se realizzati per supportare lazione della Pubblica Amministrazione, contribuiscono al processo di cambiamento della realt pubblica attualmente in atto, processo che ha, infatti, una chiara ed inequivocabile direzione: tende a ridurre la distanza tra le istituzioni pubbliche e lutenza, singoli cittadini o sistema produttivo. Si tratta di un impegno che coinvolge tutte le istituzioni centrali e

FIGURA 9 Contesto applicativo del Gateway di pubblicazione

territoriali, dai ministeri agli enti pubblici, alle regioni e ai comuni, di dimensioni senzaltro ragguardevoli, sia in termini di unit organizzative, dipartimenti, uffici, sedi aperte al pubblico, sia in termini di funzioni e responsabilit da considerare. Linformatica in tale contesto ha un ruolo cruciale, in quanto il processo di cambiamento viene attuato prevalentemente attraverso il supporto della tecnoloiSeries NEWS - SETTEMBRE 2002

La Cooperazione Applicativa: la pubblicazione s

Il Piano di Azione di e-government 2000-2002


Il Piano di Azione di e-government declina la proposta governativa a sostegno del cambiamento innovativo nelle pubbliche amministrazioni centrali e territoriali, da realizzare mediante lutilizzo diffuso e integrato delle tecnologie dellinformazione nellintero processo di ammodernamento. Le linee guida del Piano si propongono lobiettivo di: realizzare linteroperabilit telematica tra tutte le pubbliche amministrazioni per rendere possibile lerogazione di servizi integrati di sportello; realizzare laccesso telematico alle informazioni ed ai servizi di tutta la pubblica amministrazione.
Linfrastruttura per lo scambio telematico delle informazioni fra le amministrazioni, costituito dalla Rete Nazio-

nale, definita nella direttiva del Presidente del Consiglio dei Ministri del 21/5/2001. Le modalit di interoperabilit tra i sistemi di protocollo informatico e la loro integrazione con la posta elettronica, disciplinata dal DCPM 31/10/2000 e dalla circolare AIPA CR/28 del 7/5/2001.
Le modalit di apposizione e verifica della firma digitale, nonch linteroperabilit dei sistemi basati su firma digi-

Queste azioni sono coordinate e finanziate nel contesto di un programma unitario che impegna le amministrazioni a perseguire, nel rispetto delle autonomie, finalit progettuali comuni. La realizzazione delle iniziative di integrazione ed interoperabilit del sistema della pubblica amministrazione diffusa sul territorio punta a consentire laccesso ai servizi amministrativi da qualsiasi sportello fisico di qualsiasi soggetto che svolge funzioni di pubblico servizio (per esempio scuole ed ospedali oltre a ministeri e comuni). Questo significa non confinare i benefici delle azioni di e-government ai soli mezzi di accesso telematico, ma offrire sia in modalit fisica sia in modalit virtuale il godimento di servizi pubblici erogati in tempi rapidi ed in modalit trasparente. La visione del programma considera come obiettivo quello di consentire al cittadino/impresa di ottenere ogni tipo di servizio pubblico rivolgendosi ad una qualsiasi amministrazione di front-office, indipendentemente da vincoli di competenza territoriale. Inoltre le richieste del cittadino/impresa non devono presupporre una conoscenza dettagliata del funzionamento delle amministrazioni (chi fa cosa) ma a far da guida esclusivamente lesigenza di un servizio o lobbligo di una comunicazione, che deve essere possibile effettuare una sola volta e presso un solo front-office, demandando quindi alla cooperazione tra le amministrazioni la distribuzione dellinformazione.

tale, sono disciplinate dal DCPM 8/2/1999 (Regole tecniche per la formazione, la trasmissione, la conservazione, la duplicazione, la riproduzione e la validazione, anche temporale, dei documenti informatici in corso di aggiornamento), e dalla circolare AIPA CR/24 del 19/5/2000.
Il Documento di programmazione economica e finanziaria 2002-2006, approvato il 16 luglio 2001, in linea con

lorientamento strategico del piano di azione, prevede interventi in diversi campi quali: lo sviluppo di grandi infrastrutture di rete a larga banda e la completa liberalizzazione dei servizi di telecomunicazioni; la crescita della cultura informatica tra studenti e insegnanti nelle scuole; la promozione del commercio elettronico, soprattutto tra le piccole e medie imprese, con agevolazioni fiscali e altre misure dedicate; linformatizzazione della Pubblica Amministrazione, abbinata ad una forte semplificazione normativa, volta a realizzare significativi risparmi di gestione (15.000 miliardi lanno a regime) e a migliorare i servizi ai cittadini e alle imprese.

Limpianto normativo
Il modello delle interazioni tra cittadini/imprese e pubblica amministrazione disciplinato dal DPR 28 di-

cembre 2000 n.445 (Testo unico delle disposizioni legislative e regolamentari in materia di documentazione amministrativa), che regola lutilizzo del documento informatico, la sua trasmissione telematica, nonch lutilizzo della firma digitale1. Il Piano di e-government promuove la diffusione e lutilizzo della firma digitale in primo luogo come mezzo di firma per i dipendenti pubblici. A questo fine, in corso un bando di gara del Centro Tecnico della Rete Unitaria per distribuire i certificati di firma ai dipendenti pubblici aventi, appunto, potere firma.

Il DPCM 14 febbraio 2002, infine, disciplina procedure e modalit di assegnazione dei circa 400 milioni di Euro che nellambito del Piano nazionale per le-government andranno a co-finanziare i progetti innovativi di digitalizzazione della Pubblica amministrazione centrale e periferica. Il decreto prevede che circa 260 milioni di Euro siano destinati al finanziamento dei progetti di regioni ed enti locali.
1 Al momento il quadro normativo nazionale ancora in evoluzione, poich lItalia deve recepire la Direttiva Comunitaria sulla firma elettronica il cui termine era il 19 luglio 2001. Il nostro ordinamento, infatti, sembra pi restrittivo (nella Direttiva europea, per esempio, non c obbligo per i certificatori di iscriversi ad un albo, sono definite regole differenti sono contemplate firme che danno pi livelli di sicurezza, ecc.). Per i dettagli si veda la Direttiva 1999/93/CE del Parlamento europeo e del Consiglio del 13 dicembre 1999 relativa ad un quadro comunitario per le firme elettroniche.

gia e prevedendo variazioni a livello organizzativo nelle varie componenti della PA stessa, coinvolgendo in modo rilevante i sistemi informativi automatizzati in esercizio presso le varie istituzioni che compongono la PA.
iSeries NEWS - SETTEMBRE 2002

Ciro DUrso, ingegnere informatico, ha

lavorato in diverse aziende private, a Roma e Milano, come progettista di database e applicazioni. Ha prestato servizio, come specialista di integrazioni di sistemi, presso vari Istituti di Credito e So-

ciet di Intermediazione Mobiliare. Attualmente segue, in qualit di IT Consultant, il processo di informatizzazione ed avvicinamento al cittadino della Pubblica Amministrazione. Indirizzo Internet: cirodurso@ieee.org.
www.news400shop.it - www.iseries.it 31