Infrastruttura per la Cooperazione Applicativa

Transcript

1 Infrastruttura per la Cooperazione Applicativa - C.A.R.T. Linee guida per lo sviluppo di interfacce tra il Sistema Informativo Locale e il Nodo Applicativo Locale Ver. 1.2

2 Linee guida per lo sviluppo di interfacce tra il Sistema Informativo Locale e il Nodo Applicativo Locale Versione 1.2 xx YYYYY 2004 Questo documento illustra uno scenario di comunicazione tra il Nodo Applicativo Locale (NAL) e il Sistema Informativo Locale (SIL) per la pubblicazione e la ricezione di eventi. Il documento ha l intento di mostrare un possibile schema di interazione tra le parti basato su protocollo plain http. Non si riporta al momento alcuna indicazione riguardante le procedure di autenticazione e l uso di protocolli per la sicurezza della comunicazione (SSL). Descrizione dello scenario Il partecipanti allo scenario di cooperazione sono riportati qui di seguito in riferimento a quanto mostrato in Fig.1: NAL - Nodo Applicativo Locale: permette la partecipazione dei sistemi del dominio periferico alla infrastruttura di cooperazione. Proxy Applicativo: è la componente del NAL specifica per il tipo di applicazione (Anagrafe, Sanità, ). Presenta una doppia interfaccia verso il sistema di cooperazione regionale da un lato e i sistemi informativi locali dall altro. FrameworkCA (FCA): è la componente del framework di cooperazione applicativa presente sul NAL. FCA rappresenta il punto di accesso al CRIC da parte dei proxy applicativi. L accesso alle funzionalità del framework da parte dei proxy avviene attraverso una interfaccia rappresentata dalla facciata SoleFacade. SIL1, SIL2, SILn - Sistemi Informativi Locali: si riferiscono ad un NAL che fornisce ad essi l interfaccia verso il sistema di cooperazione regionale. Presentano una componente applicativa (client) che permette la comunicazione con il NAL. Si assume che tale componente possa essere costituita genericamente sia da un applicazione, sia da un semplice web browser. In questo scenario, la comunicazione tra SIL e NAL avviene sulla base del protocollo http in ognuna delle due fasi di pubblicazione e ricezione di eventi.

3 Figura 1: diagramma di deploy del sistema NAL-SIL Pubblicazione di Eventi Durante la fase di pubblicazione, il Sistema Informativo Locale di un ente ha il compito di inviare al NAL i dati relativi agli eventi. I dati possono essere file di testo o XML. In ogni caso il formato dei dati è dipendente dalla applicazione, pertanto ininfluente ai fini di questa descrizione. La pubblicazione avviene con l invio dei dati tramite POST http. La POST è indirizzata ad una URL che ha il formato seguente: dove: <NAL>::=<NOME_SERVER>:<PORTA> <NOME_SERVER>= nome del server che realizza l interfaccia http verso i sistemi locali <PORTA>= numero della porta su cui il server HTTP sul NAL è in ascolto <NOME_PROGETTO>=nome del progetto etoscana (es. C4, C6, ). Nella POST sono inseriti i seguenti parametri: nome_evento = nome dell evento pubblicato. (es. Nascita, Trasferimento, ) nome_sil = nome o identificativo del SIL pubblicante. Il parametro è opzionale in quanto si può risalire all identità del pubblicante in base all indirizzo IP attraverso un registro dei SIL presente sul NAL. È possibile inviare con una singola POST dati relativi a più eventi, purchè questi siano tutti del tipo indicato da nome_evento. (Ad esempio più eventi di tipo Nascita ) L invio dei dati può essere effettuato in diverse modalità in base al tipo di client che effettua l operazione: Web browser: l invio avviene attraverso una opportuna form richiesta al sistema di pubblicazione; Script realizzati tramite librerie libcurl;

4 Applicazione; Alla ricezione degli eventi, il Proxy effettua le operazioni di formattazione dei dati per l invio al CRIC. In particolare delega alla interfaccia SoleFacade presente sul NAL la creazione di un unico messaggio SOAP conforme alla busta etoscana che contiene come attachments tutti gli eventi dei quali è stata richiesta la pubblicazione. Il Proxy interagisce quindi con il CRIC attraverso l interfaccia SoleFacade effettuando l invio del messaggio. La pubblicazione del messaggio sul CRIC può avvenire con successo o fallimento. In ogni caso il Proxy risponde al SIL informandolo sull esito della pubblicazione. Questo avviene attraverso la restituzione al SIL di un messaggio XML il cui formato sarà: <Esito> <Codice> </Codice> <Descrizione> </Descrizione> </Esito> I frammenti XML seguenti mostrano esempi di messaggi che il SIL può ricevere in risposta alla richiesta di pubblicazione di eventi. <Esito> <Codice>0FF4D9E6-F79A-6CDB-EB7C-8DEE30A9218B Nascita OK</Codice> <Descrizione>Message sent</descrizione> </Esito> <Esito> <Codice>D5504F46-3E A7B-44D4500D60C8 Nascita KO</Codice> <Descrizione>Not authorized</descrizione> </Esito> Si osserva che il contenuto dei tag Codice e Descrizione sono riportati unicamente a titolo di esempio: il contenuto dei campi dipende dalla specifica applicazione. In generale il tag Codice contiene i codici che indicano il successo o il fallimento della trasmissione al CRIC del messaggio. Descrizione è il tag contenente la descrizione del codice corrispondente. Ricezione di Eventi Durante la fase di ricezione di un evento esiste la possibilità di adottare modalità differenti in base al tipo di collegamento del SIL ricevente con il NAL e alla tipologia del client http presente sul SIL (applicazione o semplice web browser). SIL con collegamento non permanente al NAL: in questo caso il NAL offre una interfaccia http che permette al Sistema Informativo Locale di prelevare gli eventi ad esso destinati. Il formato degli eventi potrà essere XML o HTML ottenuto da opportuna trasformazione XSLT applicata dal Proxy sul formato XML. La richiesta degli eventi avviene tramite una GET http al seguente indirizzo: [&nome_sil=<nome_sil>&formato=<formato>]

5 Dove <FORMATO> indica la richiesta dell evento in formato XML o HTML per essere visualizzato in un browser. Di default il formato scelto è XML. Il Proxy risponde a questa richiesta restituendo la lista dei messaggi che ha ricevuto per il SIL <NOME_SIL> in relazione a <NOME_EVENTO>. Il messaggio XML che il SIL riceve dal NAL contiene tutti i messaggi destinati al SIL e sarà conforme al seguente: <Messaggi> <Messaggio> <IdMessaggio>0FF4D9E6-F79A-6CDB-EB7C-8DEE30A9218B</IdMessaggio> </Messaggio> <Messaggio> <IdMessaggio> FE9-4CA8-D8A7-0DA9914EF9D1</IdMessaggio> </Messaggio> </Messaggi> Dove Contenuto è il contenuto di un evento e dipende dalla applicazione specifica. SIL con collegamento permanente verso il NAL. In questo caso si hanno due possibilità: o SIL in grado di ricevere l evento in modalità sincrona: in questo caso sul SIL è presente una applicazione che offre un accesso http al NAL. La URL della interfaccia http del SIL è riportata nel registro dei SIL presenti sul NAL. Il NAL, ogni volta che riceve un evento per un dato SIL, effettua una POST http a tale URL trasferendo l evento in formato XML. o SIL non in grado di ricevere l evento in modalità sincrona: in questo caso ci si riconduce al caso del SIL con collegamento non permanente al NAL. È pertanto compito del SIL effettuare periodicamente il controllo degli eventi ad esso destinati (modalità Polling). In ogni caso, i messaggi correttamente inviati dal Proxy al SIL non verranno più riproposti al SIL.

6 Note relative alla comunicazione SIL-NAL e SIL-SIL nel modello di cooperazione per eventi Figura 2: componenti della infrastruttura di cooperazione. L infrastruttura CART, nel modello di cooperazione asincrona EDA, permette ai SIL di pubblicare e ricevere eventi attraverso l infrastruttura di cooperazione (Fig.2). Il componente principale dell infrastruttura è rappresentato dal message server presente sul CRIC. I NAL ricoprono il ruolo di pubblicatori e sottoscrittori per i SIL che ad essi fanno riferimento. Il funzionamento si può così riassumere: Il message server riceve dai NAL pubblicanti i messaggi contenenti gli eventi e li invia ai NAL sottoscrittori in base alle regole indicate in fase di sottoscrizione. A seguito della ricezione di un messaggio, il NAL individua i SIL interessati alla ricezione degli eventi contenuti, quindi colloca una copia del messaggio nei repository dei SIL presenti sul NAL stesso. La consegna effettiva al SIL avviene in modo sincrono o asincrono (consegna su specifica richiesta del SIL sottoscrittore) in dipendenza dalla politica adottata dal SIL e dalle caratteristiche di permanenza del collegamento SIL-NAL. L accesso ad ogni funzionalità della architettura di cooperazione avviene attraverso l interfaccia SoleFacade. Essa presenta i metodi che devono essere utilizzati dai proxy applicativi per la costruzione del messaggio SOAP conforme alla busta etoscana, la pubblicazione, la ricezione e la cancellazione di eventi. Affidabilità del protocollo di spedizione e consegna dei messaggi Il modello architetturale complessivo permette il disaccoppiamento degli enti pubblicanti e dei sottoscrittori e l infrastruttura di cooperazione realizza un protocollo di invio e consegna dei messaggi affidabile.

7 L infrastruttura del CART garantisce che una volta che un messaggio è stato inviato con successo da parte di un proxy applicativo attraverso l invocazione di un opportuna funzionalità di spedizione presentata della interfaccia SoleFacade, il messaggio viene consegnato ad ogni NAL sottoscrittore e copiato nei repository dei SIL interessati a ricevere gli eventi. L infrastruttura del CART pertanto garantisce il trasferimento del messaggio dal componente FrameworkCA presente sul NAL al repository dei SIL sui NAL sottoscrittori. Al contrario, si osserva che non è compito della infrastruttura di cooperazione regionale gestire aspetti relativi al protocollo di comunicazione tra SIL e NAL. L implementazione del protocollo è responsabilità della specifica applicazione e può includere i seguenti aspetti: sicurezza della comunicazione; affidabilità in fase di pubblicazione di eventi (ad esempio attraverso la adozione di una strategia di comunicazione con riscontro tra SIL e NAL: il proxy applicativo comunica al SIL l esito della pubblicazione degli eventi sul CRIC. In caso di fallimento dell invio, il SIL può ripetere il tentativo di pubblicazione); affidabilità in fase di ricezione di eventi. Si riportano due tra le diverse strategie possibili: o Il SIL invia un riscontro di corretta ricezione degli eventi al proxy applicativo, a seguito del quale il proxy chiede la rimozione del messaggio dal repository del SIL. o Nessun messaggio è rimosso dal repository del NAL. La rimozione avviene solo a seguito di una precisa richiesta da parte del SIL. Gestione della comunicazione tra SIL La cooperazione attraverso scambio di messaggi secondo il modello asincrono EDA presenta la caratteristica di disaccoppiare i SIL pubblicanti dai sottoscrittori. In particolare i SIL pubblicanti non sono informati riguardo alla presenza e all identità dei sottoscrittori di un certo tipo di evento. È tuttavia ragionevole pensare che da un punto di vista amministrativo sia talvolta necessario superare la netta separazione imposta dal modello di cooperazione. Un caso significativo può essere rappresentato da situazioni in cui un ente pubblicante si aspetta di ricevere da un altro ente la conferma di ricezione di un evento: questo può essere necessario in situazioni nelle quali l avanzamento di una pratica amministrativa richiede l accertamento del fatto che più enti siano informati dello stato della pratica stessa. In questi contesti, la separazione tra i SIL, pur permanendo a livello di infrastruttura, può tuttavia essere superata attraverso l introduzione a livello applicativo di procedure di comunicazione di eventi con riscontro. Ovviamente, essendo la realizzazione di tali strategie di competenza applicativa, l infrastruttura del CART non è responsabile nel garantirne la corretta operatività.