Infrastruttura per la Cooperazione Applicativa - C.A.R.T. –

Transcript

Versione al 02/12/2003
I n f r a st r u t t u r a p e r l a Co o p e r a z i o n e
Appl i c a t i v a
- C. A . R. T. –
Il Modello e l’Architettura
Rete Telematica Regionale Toscana
Infrastruttura per la Cooperazione Applicativa – CART________________________________________________________________________________________ _____________
Indice
1
INTRODUZIONE
4
2
IL MODELLO
6
Vista di insieme sulle diverse Macrocomponenti (layers)
2.1.1
Virtual service layer
2.1.2
Il Back End Service Layer
2.1.3
Front End service Layer
2.1.4
Modalità di cooperazione applicativa supportate
2.1.4.1 Cooperazione applicativa per eventi
2.1.4.2 Cooperazione per Richiesta di Servizio
2.1.5
Sicurezza
7
9
11
11
12
12
14
18
3
20
L’ARCHITETTURA
Aspetti generali
20
Front End Service Layer
22
Virtual Service Layer
22
Back End Service Layer
24
Architettura per la modalità Publish&Subscribe (EDA)
24
Architettura per la modalità richiesta di servizio (SOA)
26
I Nodi Applicativi Locali
3.1.1
Message Handler CA
3.1.2
Message Control CA
3.1.3
Proxy applicativo
3.1.4
Servizi di supporto allo sviluppo, monitoraggio e aggiornamento dei
Proxy Applicativi
29
32
32
33
Centro Regionale per l’Interoperabilità e la cooperazione
3.1.5
Framework CA
3.1.6
Registry di servizi
3.1.7
Servizio di Directory
3.1.8
Publish&Subscribe Broker
3.1.9
Aggiornamento software dei NAL
3.1.10 Monitoraggio
34
35
37
39
39
39
39
page 2/53
33
Infrastruttura per la Cooperazione Applicativa – CART________________________________________________________________________________________ _____________
3.1.11
Interfacce verso il mondo esterno
40
4
COOPERAZIONE APPLICATIVA CON ALTRI CODOMINI NON
E.TOSCANA
40
Modelli di cooperazione tra Centri Regionali di Interoperabilità e
Cooperazione
4.1.1
Cooperazione applicativa per eventi
4.1.2
Cooperazione applicativa per invocazione di servizio
42
43
46
Registry dei Servizi
4.1.3
Registry Primario
4.1.4
Rete di Registry e modalità di colloquio
4.1.4.1 Allineamento reciproco automatico
4.1.4.2 Comunicazione Publish & Subscribe
4.1.4.3 Federazione di Registry
48
48
49
49
50
51
page 3/53
Infrastruttura per la Cooperazione Applicativa – CART-
1
INTRODUZIONE
Il programma e.Toscana, quale intervento strutturato a supporto delle politiche di
sviluppo della società dell’informazione con particolare riferimento al settore dell’egovernment, prevede specifici interventi nel settore delle infrastrutture a supporto dei
processi di sviluppo dell’e-government e più in generale della società
dell’informazione.
Lo sviluppo di infrastrutture costituisce un elemento strategico in quanto queste
costituiscono condizioni abilitanti per lo sviluppo degli specifici progetti applicativi.
In particolare sono previsti interventi in relazione a:
Infrastrutture per il trasporto delle informazioni - costituite dall’offerta di mercato
dei carrier ( società che offrono o realizzano reti fisiche e cablaggi), degli ISP (Internet
Service Provider) e dalle iniziative autonome di cablaggio dei territori realizzate da
soggetti pubblici e privati.
Infrastrutture per la sicurezza nel trasporto delle informazioni - finalizzate ad
armonizzare le iniziative di trasmissione telematica dei dati, garantendo livelli di
servizio garantiti e di qualità, al fine di creare le premesse per un sempre maggiore
utilizzo delle reti anche in settori nei quali maggiormente è sentita l’esigenza di
sicurezza e fiducia.
Infrastrutture per la cooperazione applicativa dei sistemi informativi - finalizzate
a garantire la comunicazione e la interoperabilità delle applicazioni e dei sistemi
informatici, prerequisito indispensabile per l’attuazione della semplificazione
amministrativa, la riduzione dei tempi, l’aggiornamento delle basi di dati di interesse
pubblico e la circolarità, senza barriere tecnologiche, delle informazioni di interesse
condiviso.
Infrastrutture per l’autenticazione e l’accesso ai servizi e alle informazioni finalizzate alla diffusione di sistemi sicuri di riconoscimento telematico (certificati
digitali) e alla creazione di modalità attraverso le quali a chi accede in rete sia possibile
associare, nel rispetto della legge sulla privacy, i diritti di accesso e visibilità di classi di
informazioni e servizi.
Infrastrutture informative – finalizzate alla valorizzazione del patrimonio
informativo regionale attraverso tecnologie di knowledge management, alla
integrazione interno/esterno per la realizzazione dei servizi, alla estrazione di dati
rilevanti per la attività di governo
page 4/53
Gli obiettivi che si intendono perseguire sono la realizzazione di:
a)
una infrastruttura di trasporto delle informazioni unitaria su tutto il territorio
regionale che colga pienamente le offerte di mercato e raccordi le iniziative
pubbliche di realizzazioni di reti, interconnettendole fra di loro tramite un
processo di accreditamento basato su livelli di servizio e fornendo uno o più
nodi di interconnessione.
b)
una infrastruttura per la sicurezza, che, implementata sulla infrastruttura di
trasporto dei dati, sia caratterizzata da una qualità idonea a garantire a tutti i
soggetti che la condividono, livelli di servizio adeguati ad estendere i concetto
della sicurezza dei singoli ad una sicurezza di sistema.
c)
una infrastruttura, articolata in funzioni centrali e locali, per la cooperazione
applicativa che abbatta le barriere tecnologiche rendendo possibile e naturale lo
scambio di informazioni e servizi fra i sistemi informativi di quelle
organizzazioni che condividono tale infrastruttura. La realizzazione di tale
infrastruttura garantirà inoltre la standardizzazione delle informazioni scambiate
fissandone anche i rispettivi livelli di qualità
d)
una infrastruttura per l’accesso autenticato e sicuro che consenta di
associare, attraverso l’utilizzo di strumenti di accesso certificati, al soggetto
che accede via rete, i servizi cui ha diritto o che può usufruire. Superando
quindi le difficoltà oggi presenti di interscambiabilità degli strumenti di accesso
(smart-card), di assenza di basamenti informativi che certifichino in maniera
sicura il “ruolo” dell’utente in rete.Il “ruolo” rappresentato dalle funzioni
esercitate (cittadino, avvocato, dirigente, medico..) ed il profilo rappresentato
dal livello di autorizzazione a svolgere specifiche azioni rispetto ad uno
specifico servizio rappresentano, gli elementi chiave per l’autenticazione e
l’accesso.
e)
Una infrastruttura informativa, intesa come insieme di procedure e standard
di trattamento, nonché dei modelli organizzativi per la loro gestione concordati
tra i soggetti interessati, capace di accrescere il valore d’uso dei patrimoni
informativi, di favorire la integrazione dei servizi e quindi il loro valore
aggiunto, di supportare l’azione di governo attraverso la disponibilità di uno
spettro ampio ma selettivo di informazioni
Il presente documento descrive l'infrastruttura per la cooperazione applicativa di
e.toscana.
page 5/53
2
IL M ODELLO
La realizzazione dell'infrastruttura di cooperazione applicativa intende realizzare uno
degli obiettivi principali contenuti nel Piano di e-government, secondo il quale
l’interoperabilità è uno dei cardini per poter erogare servizi ai cittadini e alle imprese in
modo coeso e partecipato da parte di tutta la pubblica amministrazione evitando
duplicazioni di comunicazioni, mancato aggiornamento di situazioni, ritardi ecc...
In particolare si propone di:
•
•
•
•
•
•
Fornire un’Infrastruttura per lo sviluppo e la pubblicazione di Servizi che
facilitino la cooperazione delle Pubbliche Amministrazioni della Regione
Toscana.
Utilizzare una Architettura aperta, fondata su standard, dalle specifiche
complete e pubblicamente disponibili, in cui sia garantita la libertà di
implementazione da parte di tutti i produttori di software e hardware.
Garantire Scalabilità, cioè fornire la possibilità di applicazione della soluzione
proposta sia alle amministrazioni di ridotte dimensioni sia a quelle di grandi
dimensioni .
Garantire Flessibilità, capacità della soluzione di adattarsi alle esigenze e alla
struttura esistente presente all'interno delle amministrazioni, e di evolvere
assieme alle tecnologie che la compongono.
Garantire la Sicurezza, per l'autenticità, integrità, la non ripudiabilità e la
riservatezza dei dati scambiati.
Enfatizzare l'estremo valore delle informazioni create e gestite dalle
applicazioni esistenti, riducendo al minimo l'impatto e le modifiche su queste
ultime.
I benefici attesi dalla realizzazione di una infrastruttura regionale aperta alla
interoperabilità con altre realtà, sono perciò la realizzazione di una cooperazione tra i
sistemi informativi degli Enti della Regione Toscana che non interferisca con le scelte e
le specificità nell’ambito delle scelte nel settore dell’Informaion Tecnology (I.T.) delle
singole amministrazioni. Le specifiche di progetto e la loro realizzazione consentono di
estrapolare i meccanismi di l’interoperabilità dalle applicazioni o sistemi informativi
locali. La separazione fra contesti applicativi locali e servizi di cooperazione costituisce
uno dei principali benefici dell’architettura di cooperazione realizzata in quanto
consente di collocare a livello di rete tutte quelle funzioni indipendenti dal aprticoalre
contesto applicativo e finalizzate alla piena interoperabilità e cooperazione. Ogni
Applicazione vecchia o nuova dovrà pertanto preoccuparsi del collegamento alla
infrastruttura di cooperazione che garantirà ad essa tutti quei servizi necessari per
l’inserimento all’interno delal rete di applicazioni costituite da tutte quelle applicazioni
che a loro volta sono collegate all’infrastruttura. L’infrastruttura di cooperazione
applicativa consente di poter parlare di reti di applicazioni nell’ambito degli stessi
page 6/53
paradigmi che si usa per le reti di computer nel mondo internet.
La Regione Toscana ha i questa logica disegnato ed implementato un sistema di
cooperazione applicativa (il Sistema di Cooperazione Applicativa eToscana) che
permette lo scambio d'informazione tra i diversi enti ed amministrazione pubbliche, sia
nella modalità di cooperazione per eventi sia nella modalità d'invocazione di servizi.
Il sistema di cooperazione applicativa eToscana è stato disegnato per evitare le criticità
delle soluzioni basate su approcci applicativi e/o proprietari.
Si segna dunque il passaggio da un approccio applicativo basato su un prodotto ad un
approccio per componenti, la cui integrazione è realizzata mediante l'adozione di
standard, centrando l'obiettivo fondamentale della indipendenza sia da specifici
produttori, sia da soluzioni realizzate ad hoc.
Nel disegnare le varie componenti che compongono il sistema si sono tenuti presenti
alcuni principi fondamentali che di seguito si illustrano e si declinano:
•
Fondamento sugli open standard ovvero tutto ciò che è stato e che
sarà realizzato deve essere conforme agli open standard
•
Fondamento sulla scelta multipiattaforma ovvero la soluzione deve
poter essere implementata su piattaforme diverse
•
La soluzione è potenzialmente distribuita su più layer fisici distinti
interoperanti mediante open standard
•
Speciale attenzione alla componente di sicurezza globale del sistema:
sicurezza applicativa, sicurezza di rete, sicurezza dei dati
VISTA DI INSIEME SULLE DIVERSE MACROCOMPONENTI (LAYERS)
Il Modello adottato per la realizzazione della cooperazione applicativa eToscana è
basata su una visione capace di contemplare le esigenze di innovazione.
La realizzazione di un nuovo rapporto tra le diverse amministrazioni si basa sulla
possibilità di realizzare un layer di intermediazione tra le richieste di queste e le
elaborazioni residenti sui sistemi informativi degli enti.
L’architettura coniuga nell’ambio di un sistema unitario le funzionalità tipiche della
cooperazione basata su eventi (Event Driven Architecture) e di quella orientata ai
servizi (Services Oriented Architecture) al fine di fornire molteplici soluzioni alle
diverse esigenze applicative e adattabilità alle diverse implementazioni di livello
regionale e interregionale.
SOA rappresenta la corretta tipologia di architettura (architecture pattern) per la
realizzazione di applicazioni interoperanti secondo la modalità “richiesta e risposta”
(request/reply) nell’ambito della quale è necessario un accoppiamento di tipo debole.
Tale architecture pattern risulta non utile ed è da evitare per comunicazioni di tipo
page 7/53
asincrono del tipo one-way, sia punto punto che multipunto, per le quali l’architettura
EDA risulta più efficiente e robusta.
Il modello prefigura un sistema composto da un insieme di entità che interoperano
secondo una modalità ad accoppiamento debole (loosley-coopled), ovvero non
transazionale.
Le componenti basilari del modello definito sono:
Il Back End Service Layer che è deputato alla gestione del dato di produzione
all'interno del sistema informativo esistente.
I Sistemi Informativi Locali attuali si collocano quindi sotto lo strato di Back End
Service Layer e sono identificati nel presente documento con l’acronimo di SIL
Il Virtual Service Layer che implementa i meccanismi di cooperazione applicativa, si
compone di moduli di servizio e moduli di base.
Le caratteristiche proprie del Virtual Layer sono quelle di:
•
assicurare la disponibilità dei servizi esposti
•
fornire un ambiente transazionale e sicuro
•
garantire la 'quality of service' dei servizi esposti
•
prevenire attacchi quali ad esempio il 'denial of service'
Sono inoltre resi disponibili i servizi per:
• la gestione centralizzata delle risorse
•
la gestione dei dati, la persistenza degli eventi e la gestione dello stato
del processo;
•
la gestione della firma digitale dei documenti;
•
il monitoraggio applicativo e la software distribution
Fanno parte anche di questo layer le applicazioni d'integrazione centralizzate che
forniscono un'interfaccia verso il Front End Service Layer che costituisce il punto
d'ingresso dall'esterno.
Il Virtual Layer è il punto centrale di scambio e un aggregatore di servizi o
intermediario; in questa logica svolge tra gli altri compiti anche il ruolo di registry o
broker per mantenere la descrizione dei servizi che vengono erogati e di requestor
Nel ruolo di requestor garantisce la certezza della gestione della interfacciamento tra
le richieste e i servizi offerti.
L modello proposto è in grado di salvaguardare le autonomie dei singoli soggetti (ad
esempio comunale, provinciali o regionali) proponendo un sistema per sua natura
federato ma che colloca a livello di rete molte funzioni ottenendo vantaggi in termini di
standardizzazione, affidabilità e costo.
page 8/53
2.1.1 VIRTUAL SERVICE LAYER
Il Virtual Service Layer rappresenta il cuore del sistema di cooperazione applicativa
eToscana.
Il VSL viene logicamente scomposto in una componente centralizzata (CRIC), e una
dislocata sul territorio (NAL).
Front End
Service
Layer
TIX
CRIC
DMZ
DMZ
NAL
SIL 1
SIL n
Ente 1
SIL 1
SIL n
NAL
SIL 1
Ente 2
SIL n
Ente n
Alla componente centralizzata è demandato il compito di garantire i servizi ai soggetti
della rete telematica regionale toscana e gli adeguati livelli di cooperazione ed
interoperabilità con le altre pubbliche amministrazioni del Paese attraverso
l’infrastruttura del Sistema Pubblico di Connettività cui è connessa la RTRT e gli altri
centri nazionali e regionali per la cooperazione e l’interoperabilità,,
I soggetti aderenti alla Rete telematica regionale e partecipanti al progetto eToscana in
modo singolo o associato disporranno di un sistema, denominato Nodo Applicativo
Locale (NAL), dedicato e finalizzato alla interazione con il Centro Regionale per la
Interoperabilità e la Cooperazione applicativa. Il nodo applicativo interagisce da un
lato con il centro regionale e dall’altro con i sistemi informativi locali del soggetto o
soggetti a cui garantisce i servizi di cooperazione applicativa.
La natura dei messaggi scambiati è varia, tuttavia il formato dei messaggi è XML
SOAP with attachment. L’elemento caratterizzante i messaggi per la cooperazione
applicativa è infatti la completa definizione del contenuto e del formato di codifica: la
page 9/53
busta eToscana.
Il NAL rappresenta la componente di disaccoppiamento fra i sistemi locali e la
infrastruttura di cooperazione applicativa offrendo servizi standard dal punto di vista
sia sistemistica che applicativo.
Al fine del raggiungimento di tali obiettivi la componente NAL si compone a sua volta
di un framework di cooperazione applicativa (Framework CA) che assicura i servizi di
base e di una o più componenti che si occupano del livello applicativo della
cooperazione, tali componenti vengono individuate con il termine Proxy Applicativo.
Ogni sistema informativo locale o contesto applicativo comunicherà con l’infrastruttura
di cooperazione applicativa attraverso un proxy applicativo utilizzando i servizi di base
messi a disposizione dalla componente framework CA.
Il Framework CA al fine di assolvere ai suoi compiti prevede oltre alla componente
allocata nel NAL anche una componente allocata sul CRIC.
Usando come riferimento il modello affermatosi con internet il NAL svolge
nell’ambito delle reti di applicazioni quello che un router assicura nel contesto delle reti
di computer. Le applicazioni grazie ai servizi assicurati con modalità standard dal
NAL interoperano e cooperano con un livello di astrazione garantito, rispetto alle
problematiche di rete che sarebbe ro altrimenti rappresentate dal dover conoscere dove
una applicazione risiede, quale modalità di cooperazione utilizza, quali siano i formati
dei dati accettati e scambiati, quali livelli di sicurezza sono implementati, ecc..
Il CRIC stesso rappresenta una componente che può prevedere a livello di rete una o
più istanze sulla base di considerazioni quali assicurare una gestione di un condominio
di applicazioni di enti federati sotto il profilo organizzativo, efficienza del sistema, ecc..
Oltre alle componenti specifiche del CRIC e del NAL finalizzate alla cooperazione
applicativa, si rende necessario assicurare all’interno del modello proposto alcune
funzionalità trasversali, quali:
r
Sicurezza La gestione delle politiche di sicurezza legate allo scambio dei dati e
alla cooperazione tra i vari domini presuppone per ogni richiesta :
•
L’identificazione dei soggetti che richiedono i servizi
•
L’autenticazione della provenienza delle richieste
•
L’autorizzazione selettiva all’accesso ai servizi in base al richiedente
•
Il mantenimento della privatezza delle informazioni scambiate sulla rete
•
La garanzia dell’autenticità, dell’integrità e della non ripudiabilità delle
informazioni scambiate
•
Il mantenimento di un file di log con la registrazione degli accessi ai
servizi
Per garantire questo dovranno essere sempre utilizzati meccanismi di sicurezza quali la
firma digitale, la comunicazione su canali con protocollo SSL con autenticazione
page 10/53
attraverso certificato digitale.
Per quest’ultimo tipo di servizio il modello proposto prevede l’utilizzo
dell’infrastruttura per la gestione dei certificati digitali di sicurezza e di firma (Public
Key Infrastructure) della RTRT.
q
Aggiornamento software
q
Monitoraggio
q
Gestione degli errori e logging
2.1.2 IL BACK END SERVICE LAYER
Il Back End Service Layer è il layer che consente la comunicazione tra il Back Office
,inteso come l’insieme delle applicazioni che debbono entrare nel sistema di
cooperazione applicativa e il Virtual Service Layer .
Nel Back Office coesistono mondi applicativi e piattaforme diversificate che
tipicamente non espongono livelli di interoperabilità nativi. Alla soluzione di questa
problematica risponde la Porta di Dominio. Infatti la Porta di Dominio svolge il ruolo
di omogeneizzatore dei vari sistemi presenti nell'Ente, fornendo la capacità di rendere
trasparente il tipo di applicativo utilizzato e la sua tecnologia di base.
L'esposizione di interfacce standard pubbliche sulla porta di dominio consente inoltre
l'evoluzione dei sistemi informativi esistenti nel back office fornendo ad ogni
implementatore una modalità standard di connessione.
Fanno parte di questa interfaccia i componenti che permettono alla porta di dominio di
colloquiare con il Back Office, vale a dire prendere e spedire dati da questo al back
office.
2.1.3 FRONT END SERVICE LAYER
Il Front End service Layer, nell’architettura proposta, è il livello di esposizione dei
servizi sviluppati verso gli utenti 'umani' o verso le eventuali applicazioni del mondo
esterno al condominio rapresentato da tutti gli enti toscan e non appartenenti alla Rete
Telematica Regionale Toscana.
Le funzionalità di competenza di questo layer possono sostanzialmente essere
raggruppate in due tipologie:
r
Esposizione
r
Aggregazione
Il FSL, è immaginabile come un insieme di componenti che interagiscono sia con il
VSL che con alcuni servizi Trasversali (autenticazione e profiling, firma digitale, etc…)
L’interazione con il VSL è rappresentata dai componenti denominati “portlet” e
dall’invocazione di Servlet, che sono in grado di accettare su protocollo HTTP
parametri generati dall’interazione di un utente o da un altro sistema e inoltrarli verso il
page 11/53
componente di business addetto all’elaborazione.
L’accesso al FSL avviene attraverso un’interfaccia Utente tipica dei portali
Multicanale, quindi con il supporto di molteplici device d’accesso.
Il punto di contatto con untente/sistema (Service Interface) avviene esclusivamente a
livello di VSL attraverso le Porte di Dominio con tecnologia Web Service (SOAP).
Per la gestione di tutti quegli elementi che attengono alla Human Interface in questo
layer verranno collocati componenti e strumenti che consentiranno di gestire gli aspetti
legati alla usabilità e alla navigazione dell’accesso ai servizi, al deploy di nuovi servizi,
alla personalizzazione, alla pubblicazione di nuovi contenuti.
2.1.4 MODALITÀ DI COOPERAZIONE APPLICATIVA SUPPORTATE
Il modello di cooperazione applicativa di e.Toscana prevede le seguenti due modalità:
•
cooperazione per eventi (EDA)
•
invocazione di servizi (SOA)
Nell’ambito della modalità di cooperazione per eventi viene garantita l'identità del
pubblicatore e dei sottoscrittori, così come l'integrità dei dati mentre per le richieste di
servizio sono state previste due diverse tipologie :
a) Interrogazione: richiesta che non determina alcuna modifica sul Dominio
servente
b) Transazione: richiesta che determina una variazione applicativa su un
qualche oggetto del Dominio servente
2.1.4.1 Cooperazione applicativa per eventi
In tale modello la segnalazione o notifica di evento ha lo scopo di informare
dell’evento le applicazioni di uno o più domini destinatari che, sulla base del significato
del messaggio associato all’evento, producono un cambiamento permanente del valore
di propri oggetti applicativi. In questo modello cooperano domini che pubblicano o
notificano eventi e domini che sottoscrivono eventi. Gli attori di questo sistema sono: i
domini pubblicanti, quelli sottoscrittori ed il gestore del servizio di P&S.
page 12/53
Porta Applicativa
Riceve Notifiche
Porta Delegata
Pubblica Evento
Gestore
Eventi
Porta Applicativa
Riceve Notifiche
In questa tipologia di cooperazione, a fronte di una precedente registrazione nel
sistema di gestione eventi come dominio pubblicante e come dominio sottoscrittore, il
messaggio viene formato dal sistema informatico presso il dominio pubblicante e viene
inviato dalla porta delegata presso il sistema di gestione eventi. Il sistema di gestione
eventi quindi notificherà (con il protocollo dichiarato al momento della sottoscrizione)
sulla porta applicativa del dominio sottoscrittore l’esistenza di un nuovo evento.
Si tratta di un meccanismo di tipo Event Driven. Il pubblicatore non indirizza il
messaggio a nessuno. Il consumatore recupera i messaggi a lui indirizzati in base a
regole definite nella fase di subscribe (rule-based routing), in base al loro contenuto
(content-based) o in base a informazione contenute nell’header (subject-based).
Sono possibili più soluzioni. Per esempio, il consumatore può restare in attesa degli
eventi inviati su iniziativa del gestore (logica push); può interrogare il gestore circa
l’arrivo di nuovi eventi a lui destinati (polling); può interrogare il gestore circa l’arrivo
di determinati tipi di eventi (polling selettivo); può segnalare al gestore la propria
disponibilità a ricevere gli eventi a lui destinati (push sollecitato), oppure a ricevere
solo certi tipi di eventi (push sollecitato e selettivo); ecc.
I sistemi di messaging possono operare secondo due modalità diverse per l'invio e la
ricezione dei messaggi:
•
point-to-point: il messaggio può avere uno o più destinatari, ma, una
volta inviato alla coda (queue) corrispondente, viene recuperato dal
primo che vi si collega, e poi cancellato.
•
publish & subscribe: il messaggio non contiene indicazioni circa i suoi
destinatari ma è semplicemente inviato rispetto ad un obiettivo (Topic), e
viene ricevuto da tutti i sottoscrittori per quell’obiettivo che si sono
registrati prima dell'invio.
Lo schema, rappresentato nell'immagine riportata sotto, mette in risalto la parte di
page 13/53
soluzione comune a tutte le amministrazioni locali, presentando come unico punto di
aggancio con i singoli sistemi lo scambio del messaggio SOAP conforme alla
implementazione di e.Toscana (busta di e.Toscana) del formato busta di
"eGovernment". Così, in un processo di pubblicazione in cui il NAL 'A' sia
pubblicatore e il NAL 'B' sottoscrittore, l'oggetto "envelope" rappresenta in un caso
l'input del sistema descritto, e nell'altro l'output.
2.1.4.2 Cooperazione per Richiesta di Servizio
Il modello proposto si basa su un'architettura altamente distribuita e orientata ai
servizi, indicata in letteratura come SOA, Service Oriented Architecture. Ogni
servizio facente parte di questo 'ecosistema' può comunicare direttamente con un
gruppo di processi o funzioni, oppure può partecipare in un processo di business più
complesso che coinvolge altri servizi, denotato con il nome di coreografia.
page 14/53
Service
Registry
Find
Service
Requestor
Publish
Bind
Service
Provider
Un SOA può essere utilizzato sia attraverso Internet, sia privatamente all'interno di una
singola componente applicativa e anche tra un insieme finito di soggetti prestabiliti.
Nel modello SOA vengono distinti un service platform e un service provider.
Per service platform si intende un ambiente utilizzato per ospitare uno o più servizi.
Questo può includere uno o più SOAP server, zero o più broker, i servizi di sicurezza
e transazionali utilizzati dai servizi ospitati ed altri sistemi di infrastruttura.
Un service provider è il middleware utilizzato, ad esempio un ORB, un MOM o un
application server J2EE.
SOA rappresenta un nuovo approccio, utilizzato per pubblicare ed esporre i servizi
autoconsistenti che sono ospitati su una piattaforma. Questi servizi, normalmente,
presentano caratteristiche di tipo 'enterprise' quali sicurezza, transazionalità, pooling,
clustering e batch processing. I servizi in se stessi non forniscono queste possibilità
infrastrutturali, ma semplicemente espongono le interfacce che lo fanno.
La Service Oriented Architecture offre l'opportunità agli intermediari di costruire nuovi
servizi aggregandone altri. Il nuovo servizio non fornisce nuovo valore di per sé, ma
raggruppa i servizi che vengono forniti da altri, nel nostro caso sia dal front end sia dal
back office.
I provider sono centri di 'business process', ossia espongono i servizi accedendo ad un
insieme di applicazioni in grado di eseguire un intero processo di business. Le
caratteristiche proprie di un provider, che si propone come aggregatore di servizi,
sono:
•
assicurare la disponibilità dei servizi esposti
•
fornire un ambiente transazionale e sicuro
page 15/53
I componenti del SOA sono i servizi. Ogni servizio è composto da due parti:
•
Service. L'implementazione del servizio. Il requisito chiave del servizio è che deve
essere ospitato all'interno di un service platform e fornito da un service provider.
•
Service description. L'interfaccia del servizio. L'interfaccia viene espressa in XML
e descrive in modo astratto tipi di dati, operazioni, binding su protocolli di trasporto
e locazioni di rete.
Il SOA è basato sulle interazioni tra 3 ruoli: un provider, un registry o broker e un
requestor.
Il provider è il possessore del servizio e decide come il servizio viene esposto. Il
servizio può essere implementato con un protocollo sincrono di tipo richiesta/risposta,
o può ricevere messaggi e spedire risposte asincrone. Il servizio può essere acceduto
tramite diverse tecnologie tra cui 'SOAP over HTTP' o 'ebXML Message Service'.
Il registry gestisce il repository delle informazioni sui providers. Tali informazioni
possono includere dati di identificazione così come dati di descrizione del business.
Normalmente un registry fornisce possibilità di ricerca e classificazione delle
informazioni. I registry risolvono un problema molto concreto: permettono di ricercare
un servizio e quindi di trovare la sua interfaccia programmatica.
Il requestor è un business che scopre e invoca servizi o inizia un'interazione con un
provider. Tale ruolo può essere ricoperto sia da una persona che utilizza un web
browser, sia da entità software senza interfaccia utente, come, ad esempio un altro
servizio.
Publishing
I provider pubblicano le informazioni o i metadati sui servizi in un repository e le
rendono disponibili tramite un registry server. Il meccanismo utilizzato viene chiamato
'dynamic discovery'. La descrizione dei servizi viene pubblicata in modo
programmatico utilizzando un insieme specializzato di API. Le interfacce fornite dai
registry server sono conformi a specifiche predefinite, come ad esempio UDDI .
Finding
I requestor trovano la descrizione di un servizio utilizzando un registry. Il meccanismo
utilizzato viene chiamato 'service location'. La ricerca viene effettuata
programmaticamente, utilizzando un insieme specializzato di API. Le query di ricerca
sono formattate secondo un determinato standard XML e trasmesse utilizzando un
protocollo specifico, come ad esempio SOAP.
Binding
Il binding è ciò che un'applicazione effettua quando usa una descrizione del servizio
per creare un messaggio da spedire al provider. La descrizione di un servizio è
formattata in un determinato standard XML (quasi tutti i linguaggi di definizione dei
processi di business, ossia BPML, XLANG e WSFL, sono basati su WSDL) e
specifica il protocollo di trasporto (per esempio HTTP) e tutto ciò che serve ad un
page 16/53
requestor per utilizzare un servizio.
L'implementazione delle Richieste di Servizio nella Cooperazione Applicativa di
e.Toscana si basa sui “Web Services Document Style” per i seguenti motivi:
•
L'utilizzo dei Web Services permette un tipo di comunicazione “loosely-coupled”
tra sistemi eterogenei, specialmente quelli che si sono evoluti nel tempo.
•
L'esposizione di servizi esistenti, tramite Web Service, permette l'utilizzo da una
grande varietà di client web-enabled aumentando l'interoperabilità tra piattaforme
eterogenee.
•
I modelli di interazione dei Web Service si possono mappare sui “Profili di
Collaborazione” dalla Cooperazione Applicativa
•
Un vantaggio chiave nell'utilizzo dei Web Services è l'abilità di comunicare
richieste e messaggi attraverso i firewalls comunemente configurati per
permettere il solo passaggio del protocollo http.
2.1.4.3 Modelli di processing dei Web Service
Per “modello di processing” si intende la modalità in cui come un Web Service
processa le richieste lato server. I modelli si possono dividere in “RPC style” e
“Document style”.
RPC style
Tale modello è guidato da una serie di chiamate ai metodi di business.
Queste chiamate applicano la logica del servizio ad un insieme di business
object che contengono le informazioni necessarie per processare la
richiesta. I metodi e i parametri invocati sul servizio si mappano
direttamente ad una specifica logica di business.
Document style
In questo modello la logica di business è mantenuta separata dal
contenuto del documento. Il servizio riceve un documento XML e non
comporta alcun legame specifico alla logica di business da applicare. Non
c'è nessun mapping diretto tra la richiesta e la logica di business, ossia sul
servizio non viene invocato alcun metodo specifico. Il Web Service
applica la sua business logic al documento XML il cui contenuto
determina il flusso del processo.
2.1.4.4 Modelli di interaction dei Web Service
Per “modello di interaction” si intende come un client invoca e usa un Web Service. I
m
odelli si possono dividere in sincroni e asincroni.
Nel modello sincrono, i consumer invocano una richiesta sul servizio e sospendono la
page 17/53
loro esecuzione in attesa della risposta.
Nel modello asincrono, i consumer spediscono una richiesta al servizio e
successivamente continuano la loro esecuzione senza aspettare l'arrivo di una risposta.
Il servizio elabora la richiesta e restituisce la risposta in un altro momento. Il consumer
riceve la risposta e procede con la sua elaborazione. La richiesta del consumer viene
spedita come messaggio. Il Web Service riceve il documento e ne effettua il parsing
per determinare come processare la richiesta.
Naturalmente la maggior parte dei Web Services utilizzano un mix dei modelli appena
elencati. La differenza sostanziale tra i due modelli di processing riguarda la
dipendanza dal protocollo XML (trasparente nel caso dei Web Service RPC style, dato
che viene gestita dalla piattaforma) e dalla definizione delle interfacce del servizio
(trasparente nel caso dei WebService Document style, dato che il workflow è definito
nel contenuto del documento).
2.1.5 SICUREZZA
In base ai requisiti di alto livello espressi nella Cooperazione Applicativa, definiti nel
documento “Rete Nazionale Architettura Applicativa Linee Guida Prima edizione 6
novembre 2001” e all'analisi dell'ambiente Amministrazione Locale sono stati
individuati i seguenti requisiti non funzionali relativi alla sicurezza:
1. I messaggi comunicati tra NAL e CRIC non possono essere osservati da terzi
mentre viaggiano sulla rete.
2. Il nodo applicativo che riceve i messaggi è in grado di determinare da chi
proviene il messaggio verificando che il mittente sia chi sostiene di essere.
3. Il nodo applicativo che riceve i messaggi è in grado di accertare che i dati
trasmessi non siano stati alterati.
Il requisito non funzionale 1 viene risolto utilizzando i protocolli di trasporto
HTTPS/SSL. I nodi applicativi (CRIC e NAL) su cui viaggiano i messaggi non
modificano il dato in modo sostanziale e non utilizzano altri fornitori di servizio per
comunicarli. Questa caratteristica permette di scartare l'idea di cifrare a livello di
messaggio: il beneficio guadagnato nell'utilizzo della crittografia per cifrare tutto o la
parte di un messaggio SOAP non è abbastanza per giustificare il costo e la complessità
di sviluppo della struttura necessaria.
I requisiti non funzionali 2 e 3 vengono risolti utilizzando la firma e i certificati digitali.
Quando si utilizza questo approccio, il nodo applicativo che invia il messaggio deve
posseder un certificato digitale firmato da una Certification Authority. Il mittente
utilizza il certificato per asserire la propria identità e firma digitalmente il messaggio
SOAP in modo che la propria identità e l'integrità del messaggio possa essere
verificata. Una volta ricevuto, il messaggio viene memorizzato con un timestamp
associato. A questo punto la firma digitale può essere validata. Il processo di
validazione assicura che il messaggio proviene dal mittente e verifica che il contenuto
del messaggio non sia stato modificato da quando è stato firmato dal mittente. Il log
page 18/53
del messaggio SOAP viene utilizzato dal ricevente per scopi di non ripudio.
page 19/53
3
L’ARCHITETTURA
Lo scopo di questo documento è presentare e descrivere l'architettura che realizza il
modello descritto nel precedente capitolo.
ASPETTI GENERALI
Il raggiungimento del requisito di interoperabilità si basa sulla definizione di un insieme
di componenti architetturali che vanno a realizzare i layer di intermediazione tra le
pubbliche amministrazioni e tra le amministrazioni e il cittadino/utente, al fine di
realizzare uno scambio di informazioni senza soluzioni basate su approcci applicativi
e/o proprietari, così come definito nel modello descritto nel precedente capitolo.
L’architettura proposta non impone la creazione di soluzioni basate su specifici
prodotti adattati alle necessità della comunicazione tra le pubbliche amministrazioni
ma, partendo da queste, identifica componenti architetturali che implementino
tecnologie e protocolli standard di mercato, naturalmente multipiattaforma.
Si segna dunque il passaggio da un approccio applicativo basato su un prodotto ad un
approccio per componenti, la cui integrazione è realizzata mediante l'adozione di
standard, centrando l'obiettivo fondamentale della indipendenza da specifici produttori
e da soluzioni realizzate ad hoc.
Questa impostazione ha reso Java, ed in particolare J2EE, la piattaforma di riferimento
che consente di impostare la soluzione come framework piuttosto che come prodotto,
lasciando alla scelta delle singole amministrazioni la selezione dei prodotti specifici.
Nel disegnare le varie componenti che consentono la realizzazione di un sistema
capace di rendere i servizi fondamentali per la completa erogazione dei servizi al
cittadino si sono tenuti presenti alcuni principi fondamentali qui di seguito illustrati:
•
Conformità agli open standard
•
La soluzione deve poter essere implementata su piattaforme diverse
(Microsoft, Unix, Linux)
•
La soluzione deve essere potenzialmente distribuita su più layer fisici distinti
interoperanti mediante open standard
•
La soluzione deve poter essere installata su prodotti commerciali o “open
Source” diversi, con il minimo costo di porting o di modifiche strutturali
Tali considerazioni, unite ai principi di scalabilità e affidabilità hanno condotto alla
scelta della piattaforma Java.
L'architettura proposta è un sistema composto da un insieme di entità che interoperano
secondo una modalità ad accoppiamento lasco (loosley-coopled),ovvero non
transazionale.
Tale capacità di comunicazione, basata sulla trasmissione dei messaggi, è implementata
page 20/53
in forma assolutamente naturale disponendo della tecnologia J2EE che offre una
collaudata esperienza di interoperabilità.
La struttura di tale architettura viene decsritta sulla base delle componenti individuate
dal modello:
•
Il Front End Service Layer
•
Il Virtual Service Layer
•
Il Back End Service Layer
Queste tre componenti sono tra di loro complementari e allo stesso tempo, sono viste
come elementi di uno stack fortemente disaccoppiato sia tecnologicamente che dal
punto di vista della distribuzione fisica delle risorse.
L'implementazione dei suddetti layer da un punto di vista architetturale è rappresentata
nello schema seguente.
FRONT END
SERVICE
LAYER
Interfaccia
UDDI
C
R
I
C
ebXML
Directory
Server
P&S
Broker
RDBMS
Servizi
applicativi
centrali
Registrydei servizi
Application
Server
J2EE
http/
SOAP
Server
Gateway
verso altri
Centri
Servizi
Servizio di monitoraggio Cruscotto di
applicazioni
amministrazione
Servizio di distribuzione
software
VIRTUAL
SERVICE
LAYER
Framework Cooperazione Applicativa
Framework Cooperazione
Applicativa
Proxy
Applicativo
E
N
T
I
L
O
C
A
L
I
SIL
Proxy
Applicativo
SIL
Framework Cooperazione
Applicativa
Proxy
Applicativo
Proxy
Applicativo
SIL
SIL
BACK END
SERVICE
LAYER
Tali componenti operative consentono la realizzazione di una infrastruttura cooperante
page 21/53
in cui ciascun layer può svolgere il ruolo del provider secondo i dettami della Event
Driven Architecture e della Services Oriented Architecture.
FRONT END SERVICE LAYER
Il Front End service Layer, nell’architettura proposta, è il livello di esposizione dei
servizi sviluppati all’interno del progetto verso gli utenti 'umani' o verso le eventuali
applicazioni del mondo esterno al CART.
Le funzionalità di competenza di questo layer possono sostanzialmente essere
raggruppate in due tipologie:
•
Esposizione
•
Aggregazione
Il FSL, è immaginabile come un insieme di componenti che interagiscono sia con il
VSL che con alcuni servizi Trasversali (autenticazione e profiling, firma digitale, etc…)
L’interazione con il VSL è rappresentata dai componenti denominati “portlet” e
dall’invocazione di Servlet, che sono in grado di accettare su protocollo HTTP
parametri generati dall’interazione di un utente o da un altro sistema e inoltrarli verso il
componente di business addetto all’elaborazione.
L’accesso al FSL avviene attraverso un’interfaccia Utente tipica dei portali
Multicanale, quindi con il supporto di molteplici device d’accesso.
Il punto di contatto con untente/sistema (Service Interface) avviene esclusivamente a
livello di VSL attraverso le Porte di Dominio con tecnologia Web Service (SOAP).
Per la gestione di tutti quegli elementi che attengono alla Human Interface in questo
layer verranno collocati componenti e strumenti che consentiranno di gestire gli aspetti
legati alla usabilità e alla navigazione dell’accesso ai servizi, al deploy di nuovi servizi,
alla personalizzazione, alla pubblicazione di nuovi contenuti.
VIRTUAL SERVICE LAYER
Questo strato rappresenta il cuore del sistema informativo della nostra soluzione
poiché in questo layer si dispone di una componente capace di trasformare le richieste
provenienti dal front end (Human Interface / Service Interface) in azioni e processi
comprensibili dalle componenti applicative residenti nei backend.
Il Virtual Service Layer rappresenta un middleware che assume la componente di
provider quando le richieste provengono dal front end e il ruolo di requestor quando
si rivolge al backend.
L’utilizzo delle Porte di Dominio, consente l’interazione con domini diversi
page 22/53
(cooperazione applicativa) e l’interazione con lo strato di Back End Service Layer.
La porta di dominio basa lo scambio di messaggi o attraverso le API JMS, qualora il
Back End Service Layer sia dotato di un broker JMS che supporti HTTP, oppure
direttamente con scambio di messaggi SOAP sincroni. Questo garantirà ancora una
volta il più basso livello di accoppiamento e la massima interoperabilità dei sistemi.
Il VSL è aperto verso sistemi applicativi esterni realizzati con tecnologia non Java.
L'uso di SOAP su HTTP permette a qualunque altra piattaforma hardware/software di
implementare servizi di backend e, viceversa, di sfruttare i servizi offerti dal VSL. Tutti
i servizi base integrati nel VSL, infatti, sono esposti agli enti esterni come web-services
mediati dalla cosiddetta Porta di Dominio.
Per organizzare l'accesso ai servizi di backend da parte del VSL, la loro descrizione
sarà registrata nel repository ebXML.
Il BSL dovrà interporre dei listener realizzati attraverso servlet per implementare verso
il VSL i protocolli prima esposti, che costituiscono la Porta di Dominio.
Grazie all'utilizzo di un'architettura J2EE, i servizi forniti da un provider possono
soddisfare alcune caratteristiche che permettono all'architettura di evolvere in un
ambiente di distributed computing basato sulla tecnologia Internet:
r
efficienza nell'effettuazione del servizio
r
scalabilità per gestire un grande volume di richieste
r
supporto al versioning e alla 'online self-reparation'
r
supporto come parte del workflow
r
alta affidabilità
Il VSL è un aggregatore di servizi o intermediario. Questo svolge tra gli altri compiti
anche il ruolo di registry e broker per mantenere la descrizione dei servizi che vengono
erogati.
Il VSL svolge anche il ruolo di requestor. Nel ruolo di requestor il VSL, garantisce la
certezza della gestione della interfacciamento tra le richieste utente e i servizi offerti
dal sistema informativo esistente.
Lo stesso ruolo è assunto anche dal Back End Service Layer nei confronti dei servizi
del Backend implementati a livello delle singole amministrazioni.
Il VSL rappresenta il punto centrale di scambio e le funzionalità che svolge possono
essere erogate da un ente che opera come intermediario.
Il modello della infrastruttura di cooperazione applicativa di e.toscana prevede il
Centro Regionale per l'Interoperabilità e la Cooperazione (CRIC) ed il Nodo
Applicativo Locale (NAL).
page 23/53
BACK END SERVICE LAYER
Il backend svolge le funzioni di trattamento dei dati e servizi che devono essere
scambiatie per questo sono rese disponibili tre tipi di interfacce:
Upload/download Il back boffice quando ha dei dati che devono essere spediti
usa un’applicazione Web presente sulla porta di dominio per scaricare i dati
sulla porta di dominio stessa
Message Listener Viene usato in questo caso una tipologia di Enterprise Java
Bean, il Message Driver Bean, che è in grado di ricevere e processare messaggi
spediti da un client applicativo, da un componente Web, da un’applicazione
JMS o da un sistema che non utilizza tecnologia J2EE.
Code di messaggi In questo caso il backend, quando deve inviare dei dati, li
invia attraverso un messaggio JMS su una coda della porta di dominio
ARCHITETTURA PER LA MODALITÀ PUBLISH&SUBSCRIBE (EDA)
La Cooperazione Applicativa ad eventi si basa sullo scambio asincrono di messaggi tra
Domini diversi.
In un sistema di messaging ad invocazione asincrona i partecipanti non devono restare
connessi in attesa di una risposta dal destinatario, ma possono limitarsi ad inviare il
messaggio affidandolo ad un'infrastruttura di servizio (Framework CA) che ha il
compito di gestirne la consegna rendendola affidabile nonché indipendente dai vincoli
che si avrebbero se i soggetti interessati dovessero comunicare direttamente tra loro
per lo scambio di informazioni.
I sistemi di messaging possono operare secondo due modalità diverse per l'invio e la
ricezione dei messaggi:
•
point-to-point: il messaggio può avere uno o più destinatari, ma, una volta
inviato alla coda (queue) corrispondente, viene recuperato dal primo che vi si
collega, e poi cancellato.
•
publish&subscribe: il messaggio non contiene indicazioni circa i suoi destinatari
ma è semplicemente inviato su un certo topic, e viene ricevuto da tutti i
sottoscrittori di quel topic che si sono registrati prima dell'invio.
La soluzione proposta utilizza un modello di gestione dei messaggi di tipo “publish &
subscribe”, data la necessità di diffondere gli eventi di variazione a tutte le
amministrazioni e gli enti interessati.
Lo schema, rappresentato nell'immagine seguente, mette in risalto la parte di soluzione
comune a tutte le amministrazioni locali, presentando come unico punto di aggancio
con i singoli sistemi lo scambio del messaggio SOAP conforme al formato busta di
"eToscana" (nell'immagine, "eToscana envelope"). Così, in un processo di
pubblicazione in cui il NAL 'A' sia pubblicatore e il NAL 'B' sottoscrittore, l'oggetto
"eToscana envelope" rappresenta in un caso l'input del sistema descritto, e nell'altro
page 24/53
l'output.
Work flow descritto dal Deploy Diagram
Analizzando la figura sopra riportata, definiamo il nodo NAL 'A' come pubblicatore e il
NAL 'B' come sottoscrittore allo stesso evento. Il nodo NAL 'A', tramite il
componente “Message Control CA” reperisce la busta di “eToscana”, controlla il
mittente tramite la firma digitale (autenticazione), verifica se il mittente ha il ruolo per
pubblicare il relativo evento (autorizzazione) andando a reperire le informazioni sul
repository presente sul CRIC, valida il formato del messaggio SOAP secondo la busta
di "eToscana" e risponde al componente “Message Handler CA” se ogni passo è
andato a buon fine. Nel caso in cui ogni controllo eseguito dal “Message Control CA”
sia andato a buon fine, il componente “Message Handler CA” incapsula la busta di
“eToscana” in un messaggio JMS, si collega al componente “JMS Provider” del CRIC
autenticandosi e spedisce (relazione di “communicates”) al CRIC il messaggio. Il
componente “JMS Provider”, che avrà il compito di gestire i messaggi tra il NAL 'A' e
'B', riceve il messaggio JMS e si occupa di spedirlo (relazione "communicates") al
NAL 'B'. Il componente "Message Handler CA" del NAL 'B', una volta ricevuto il
messaggio JMS, traccia l'avvenuta ricezione, estrae la busta di “eToscana” dal
messaggio JMS e la consegna al relativo “Message Control CA”. Quest'ultimo ne
valida il formato, inserisce al suo interno gli identificativi dei sottoscrittori al relativo
evento, reperendoli sul repository del CRIC, e la rende disponibile al sistema con cui
si integrerà.
page 25/53
Il colloquio con il Framework CA presente sul CRIC avviene in modalità JMS sicuro o
anche via SOAP su https con caratteristiche di sicurezza e affidabilità.
ARCHITETTURA PER LA MODALITÀ RICHIESTA DI SERVIZIO (SOA)
L'architettura generale, scelta dal modello per l'implementazione delle Richieste di
Servizio, si basa essenzialmente sul modello Document Style.
In questo modello la logica di business è mantenuta separata dal contenuto del
documento. Il servizio riceve un documento XML e non comporta alcun legame
specifico alla logica di business da applicare. Non c'è nessun mapping diretto tra la
richiesta e la logica di business, ossia sul servizio non viene invocato alcun metodo
specifico. Il Web Service applica la sua business logic al documento XML il cui
contenuto determina il flusso del processo.
Il software Framework CA è comunque in grado di supportare il modello RPC Style
sincrono, nel caso i requisiti o i vincoli dell'ambiente operativo lo permettano.
Framework CA utilizza un insieme di tool e di API Java standard costruite
appositamente per questo modello.
Il modello RPC Style sincrono è guidato da una serie di chiamate ai metodi di business.
Queste chiamate applicano la logica del servizio ad un insieme di business object che
contengono le informazioni necessarie per processare la richiesta. I metodi e i
parametri invocati sul servizio si mappano direttamente ad una specifica logica di
business.
Riguardo ai modelli di interazione dei Web service sono possibili due modelli:
q
Modello sincrono, in cui i consumer invocano una richiesta di servizio e
sospendono la loro esecuzione in attesa della risposta
q
Modello asincrono, in cui i consumer spediscono una richiesta al servizio e
successivamente continuano la loro esecuzione senza aspettare l’arrivo della
risposta. Il servente elabora la richiesta e restituisce la risposta in un secondo
momento.
Il software Framework CA supporta entrambi i modelli di interazione. In questo modo
è possibile scegliere la modalità a seconda del tipo di servizio richiesto: sincrona
quando il servizio è in grado di processare la richiesta in tempo reale o quando il
consumer necessita una immediata risposta a seguito di un richiesta; asincrona quando
il consumer non vuole attendere il completamento dell'elaborazione della richiesta in
quanto potrebbe comportare un'attesa troppo lunga.
La modalità asincrona spesso si scontra con il fatto che il consumer del servizio non è
in grado di poter ricevere la risposta dal servizio. Per questo motivo, il Framework
CA, è in grado di supportare due differenti modalità di interazione asincrona,
denominate simmetrica e asimmetrica.
page 26/53
Nella modalità di interazione asincrona simmetrica, il consumer è esso stesso un Web
Service, quindi il servizio richiesto è in grado di svolgere il ruolo di consumer per
quanto rigurada il risultato della richiesta originale. La correlazione tra richiesta e
risposta avviene attraverso l'ID del messaggio.
Nella modalità di interazione asincrona asimmetrica, il consumer che ha invocato il
servizio controlla periodicamente lo stato della richiesta utilizzando l'ID del messaggio,
fornito al momento della richiesta. (Questa modalità è conosciuta anche con il nome di
polling). Solo dopo il completamento della richiesta, il consumer è in grado di
recuperare la risposta.
Nello scenario illustrato di seguito, un'applicazione sul SIL1(x) chiede al Proxy
applicativo presente sul NAL X un servizio esposto dal SIL3(y) ed esposto sul NAL
Y.
Il proxy applicativo comunica questa richiesta alla Porta di dominio del NAL X.
La porta di dominio del NAL X accede al CRIC ed effettua la richiesta di servizio.
Il CRIC accede al Registry al fine di individuare la locazione del servizio richiesto e le
sue modalità di invocazione.
Sull'XML registry presente nel CRIC è descritto il servizio richiesto, la sua interfaccia
e la sua locazione (il servizio è collocato, ad esempio, sul NAL Y).
La componente applicativa Web Service Orchestrator presente sul CRIC comunica,
dopo aver reperito le informazioni suddette necessarie alla comunicazione, con la porta
di dominio del NAL Y.
Questa si rivolge al Proxy applicativo del NAL Y che si occuperà di accedere al
database presente sul SIL 3(Y) (o eventualmente esportato sul NAL Y) ed
estrapolarne l'informazione richiesta.
Nel flusso di ritorno, il Proxy applicativo restituisce il valore alla porta di dominio che
lo comunica al Web service orchestrator sul CRIC, il quale si occupa di fornire
l'informazione al proxy applicativo del NAL X.
Infine il Proxy applicativo del NAL X restituisce, al SIL1(x) che aveva innescato la
richiesta iniziale, l'informazione richiesta.
CRIC
Web Service
orchestrator
XML
Registry
2
3
NAL X
NAL Y
4
Proxy
applicativo
Proxy
applicativo
5
1
Rete Telematica
SIL1(x)
SIL 2(x)
DB
Regionale Toscana
SIL 3(y)
page 27/53
I Nodi Applicativi Locali contengono la componente del Framework che implementa la
Porta Di Dominio (Delegata e Applicativa) e i Proxy Applicativi specifici per il tipo di
applicazione. Nel caso in cui il SIL non sia in grado di implementare un particolare tipo
di servizio, il NAL può farsi carico di fornire un provider del servizio per quel
determinato SIL tramite normalizzazione dei dati o altre tecniche specifiche per quel
dominio applicativo.
Il Sistema Informativo Locale contiene il consumer ed eventualmente il provider di un
servizio. Entrambi questi componenti devono essere in grado di comunicare con un
proxy applicativo (presente sul NAL) in un modo specifico al dominio applicativo.
La componente Framework CA presente sui NAL implementa la Porta di Dominio. E'
in grado di:
•
accettare richieste/risposte, nel formato standard definito, provenienti dal proxy
applicativo e di inviarle in modo reliable al CRIC
•
accettare richieste/risposte, nel formato standard definito, provenienti dal CRIC
e di inviarle in modo reliable al proxy applicativo corrispondente.
•
effettuare il lookup dell'endpoint fisico della Porta Di Dominio, utilizzando il
registry & repository XML presente sul CRIC
La componente Framework CA sul Centro Regionale svolge il ruolo di registry e
repository XML (le due tipologie attualmente supportate sono UDDI ed ebXML).
Tale componente viene utilizzata in design-time dai tool di sviluppo per ricercare la
descrizione delle interfacce dei servizi (WSDL o schema XML) e in run-time dai
componenti del Framework CA presenti sui NAL per determinare l'endpoint del
servizio.
page 28/53
CRIC
Framework CA
XML Registry/Repository
NAL X
Proxy
applicativo
Framework CA
NAL Y
Framework CA
Proxy
applicativo
Ente locale1 -SIL
Consumer
Work flow descritto dal Deploy Diagram
L'applicazione residente sul SIL richiede al suo Proxy applicativo di riferimento
presente sul NAL X la sua richiesta in formato XML. Il proxy applicativo imbusta la
richiesta in un messaggio conforme alla busta e-toscana e redirige la richiesta alla
componente Framework CA (Porta di Dominio) presente sul NAL. Quest'ultimo la
invia alla componente Framework CA presente sul CRIC il quale contiene al proprio
interno una componente di Web Service orchestrator in grado di:
•
inviare e ricevere le richieste di servizio da parte delle porte di dominio dei NAL
•
inviare e ricevere le risposte da parte delle porte di dominio dei NAL
Questa effetta il lookup del servizio sul registry presente sul CRIC e effettua la
richiesta al Framework CA presente sul NAL Y il quale a sua volta passa la richiesta
al proxy applicativo che si occuperà di elaborare la richiesta e ritornare i dati di
risposta al Framework che li ripasserà a sua volta al Web Service orchestrator e
quindi al NAL X che ha effettuato la richiesta.
I N ODI APPLICATIVI LOCALI
Le componenti di accesso ai servizi di interoperabilità e cooperazione devono essere
page 29/53
definite in modo standard per tutti gli Enti connessi alla rete. Tali componenti vengono
rese disponibili su un Server dedicato denominato Nodo Applicativo Locale (NAL). Il
NAL svolge quindi la funzione di Porta di Dominio per ciascun ente connesso
direttamente alla rete, includendo sia le funzioni di Porta Delegata che di Porta
Applicativa.
La funzione principale del NAL è quella di ricevere e spedire messaggi al fine di
rendere disponibili i propri servizi. Le due funzioni di spedizione e ricezione messaggi
implicano che la porta sia in grado di:
•
Ricevere e pre-elaborare i messaggi in arrivo per il Sistema Informativo
Locale
•
Creare i messaggi da spedire verso l’esterno
•
Fornire servizi di supporto alla cooperazione (es. log dello stato della
comunicazione) e gestire funzionalità di sicurezza, protocollazione ecc.
Il NAL agisce quindi sia come client, quando riceve informazioni e servizi, sia come
server, quando fornisce informazioni e servizi.
La natura dei messaggi scambiati è varia, tuttavia il formato dei messaggi è XML:
l’elemento caratterizzante i messaggi per la cooperazione applicativa è infatti la
completa definizione del contenuto e del formato di codifica.
La struttura dei messaggi dovrà essere definita secondo un formato standard che
costituirà la busta e-toscana.
page 30/53
“Message Handler CA” è il componente che si occupa della
pubblicazione e ricezione degli eventi nel formato “busta di
eToscana” verso e dal CRIC.
L’interfaccia verso il CRIC, in particolare verso il Framework CA, avviene attraverso il
componente Message Handler CA che ingloba al suo interno il componente Message
Control CA.
Il NAL è quindi costituito da una parte infrastrutturale comune a tutti sulla quale si
installano i diversi proxy applicativi, specifici per ogni diversa applicazione, i quali
presentano una interfaccia verso il Framework della Cooperazione Applicativa
presente sul CRIC e una verso il Sistema Informativo Locale dell’Ente.
I componenti software che implementano la soluzione proposta per la gestione degli
eventi di Cooperazione Applicativa e delle richieste di servizio sono:
•
Package per interfaccia verso il CRIC
•
Message Handler CA e Message Control CA che si basano su:
•
•
API JMS per la gestione dei servizi di comunicazione JMS
•
API JAXM/JAXRPC/JAXP per la gestione dei messaggi XML
•
SOAP with Attachments API for Java (SAAJ)
•
API per la gestione della firma e della sicurezza
Proxy Applicativo si basa su
4. Package Message Handler per la formattazione secondo lo
page 31/53
standard della busta e-toscana e l’invio e/o la ricezione del
messaggio
5. API JDBC per l’interfacciamento verso l’RDBMS
•
Package per interfaccia verso il Sistema Informativo Locale che può usare ( a
seconda delle diverse modalità)
•
API JAXR-JAXRPC nel caso in cui l’interfaccia sia un Web service
•
API JMS nel caso in cui l’interfaccia sia ottenuta tramite code del JMS
Provider fornito dall’Application Server presente sul NAL
•
Servizi di supporto allo sviluppo e alla gestione dei Proxy Applicativi
3.1.1 MESSAGE HANDLER CA
Questo componente software permette sia la pubblicazione e la ricezione degli eventi
secondo gli standard determinati dalla cooperazione applicativa sia la richiesta di
servizio. In particolare tale componente implementa la funzione di collaborazione della
porta di dominio.
La funzione di cooperazione ad eventi viene realizzata pubblicando e ricevendo
messaggi conformi alla “busta di eToscana” in modalità asincrona e affidabile come
specificato dall'architettura proposta.
La funzione di richiesta di servizio viene effettuata inviando la richiesta imbustata
secondo il formato conforme alla busta di eToscana.
Questo componente espone un’interfaccia utilizzabile dai Proxy applicativi per
l’imbustamento secondo la busta e-toscana e l’invio e/o la ricezione degli eventi e delle
richieste di servizio.
3.1.2 MESSAGE CONTROL CA
Il Message Handler internamente usa un package denominato Message Control CA al
quale sono demandate le funzionalità che garantiscono la sicurezza delle transazioni
nella gestione degli eventi di Cooperazione Applicativa:
1. Protezione del canale. Il canale di comunicazione tra NAL e CRIC deve
essere protetto tramite encryption.
2. Validazione. I messaggi conformi alla busta di eToscana vengono validati. La
validazione avviene in due punti: prima di essere inviati al CRIC e, una volta
ricevuti dal CRIC, prima di essere inviati al SIL.
3. Autenticazione. I messaggi conformi alla busta di eToscana, inviati e ricevuti
tra i NAL, conterranno la firma digitale in modo da poter effettuare
l'autenticazione del mittente e di accertare che i dati trasmessi non vengano
alterati.
4. Autorizzazione. I messaggi conformi alla busta di eToscana, inviati e ricevuti
page 32/53
tra i NAL, dovranno, una volta autenticati, verificare le rispettive
autorizzazioni. Le informazioni di autorizzazione sono contenute nel
repository del CRIC. Il controllo di autorizzazione avviene: prima di inviare il
messaggio al CRIC, verificando il mittente, e prima di inviare il messaggio al
SIL, verificando il ricevente.
Tali funzionalità non sono rilasciate dal Message Handler ai Proxy applicativi ma sono
al servizio del Message Handler.
3.1.3 PROXY APPLICATIVO
Per ogni applicazione che deve parlare in questo contesto di cooperazione applicativa
dovrà essere installato sul NAL un componente software denominato Proxy
applicativo.
Compito del proxy applicativo è, nel caso di un NAL pubblicatore di une evento,
quello di ricevere i dati dal Sistema Informativo Locale, validarli, imbustarli secondo la
busta e-toscana e passarli poi al componente Message Handler per l’invio sul CRIC.
Analogamente, nel caso di un NAL sottoscrittore di un evento, riceve l’evento dal
Message Handler e lo invia al Sistema Informativo Locale destinatario del messaggio.
Il Proxy è un'applicazione Java sviluppata con le API Java 2 Platform Standard Edition
che usa le funzionalità messe a disposizione dal Message Handler per l’imbustamento e
l’invio e/o ricezione degli eventi, usa le API standard per la propria logica applicativa e
l’interfacciamento verso l’RDBMS (API JDBC) e presenta un’interfaccia verso il
Sistema Informativo locale in modo da poter ricevere i dati necessari per la
pubblicazione dell’evento e da poter inviare l’evento ricevuto dal CRIC.
In base alle capacità dei singoli Sistemi Informativi locali si possono ipotizzare diverse
modalità di colloquio:
1. File Upload su https. Il S.I. Locale prepara i dati in formato XML ed
effettua una POST su https sul NAL per passare i file preparati.
2. Web services. I proxy applicativi presenti sul NAL espongono il
servizio di ricezione dati sotto forma di Web service che viene
invocato dal Sistema Informativo Locale
3. JMS Provider. In questo caso il S.I.L., quando deve inviare dei dati, li
invia attraverso un messaggio SOAP su http su una coda sul NAL da
dove viene passato al proxy applicativo. Lo stesso meccanismo al
contrario viene seguito nel caso in cui il S.I.L. debba ricevere i dati.
3.1.4 SERVIZI DI SUPPORTO ALLO SVILUPPO, MONITORAGGIO E
AGGIORNAMENTO DEI PROXY APPLICATIVI
Per lo sviluppo e la gestione dei Proxy applicativi sul NAL sono presenti :
•
API JMS per la gestione dei servizi di comunicazione JMS
•
HTTP Server
page 33/53
Infrastruttura per la Cooperazione Applicativa – CART•
API JAXM/JAX-RPC per la gestione dei messaggi XML
•
API per la gestione della firma e della sicurezza
•
API JDBC per l’interfaccia verso il database
•
RDBMS Contiene copie dei dati oggetto della cooperazione applicativa e garantisce
la persistenza degli eventi oggetto della cooperazione applicativa.
•
Application Server J2EE
•
Provider JMS Componente che permette il colloquio con il sistema informativo
locale attraverso code di messaggi. Nel caso in cui si decida di mettere un
Application Server J2EE compliant sul NAL questo contiene già al suo interno
un’implementazione di un JMS provider.
Sul NAL sono presenti anche Servizi di gestione remota che consentono di monitorare
e gestire i NAL in remoto da un centro di gestione regionale permettendo anche
l’aggiornamento del software presente sui NAL.
CENTRO REGIONALE PER L ’INTEROPERABILITÀ E LA COOPERAZIONE
Il modello architetturale che si è stato realizzato attraverso il progetto eToscana
prevede la attivazione di un centro regionale per la interoperabilità e la cooperazione
(CRIC) cui è demandato il compito di garantire i servizi ai soggetti della rete
telematica regionale toscana e gli adeguati livelli di cooperazione ed interoperabilità
con le altre pubbliche amministrazioni del Paese attraverso l’infrastruttura della Rete
nazionale cui è connessa la RTRT e gli altri centri nazionali e regionali per la
cooperazione e l’interoperabilità.
I soggetti aderenti alla Rete telematica regionale e partecipanti al progetto eToscana in
modo singolo o associato disporranno di un sistema, denominato Nodo Applicativo
Locale (NAL), dedicato e finalizzato alla interazione con il centro regionale per la
interoperabilità e la cooperazione applicativa. Il nodo applicativo interagisce da un lato
con il centro regionale e dall’altro con i sistemi informativi locali del soggetto o
soggetti a cui garantisce i servizi di cooperazione applicativa.
Vediamo a questo punto in dettaglio i componenti sul CRIC necessari per la
realizzazione dei diversi tipi di cooperazione.
page 34/53
UDDI
ebXML
Directory
Server
http/
SOAP
Server
P&S
Broker
Servizi
applicativi
centrali
Registry dei servizi
Application
Server
Servizio di monitoraggio
applicazioni
Cruscotto di
amministrazione
RDBMS
Gateway
verso altri
Centri
Servizi
Gateway
verso altri
Enti
Servizio di distribuzione
software
Il CRIC è un Centro Servizi Regionale che ospita i servizi di rete comuni e condivisi da
più amministrazioni che saranno di supporto alla cooperazione applicativa:
r
Framework per la Cooperazione Applicativa
•
JMS Provider
•
RDBMS
•
Diretcory Server
•
Cruscotto di amministrazione del Framework
r
Registry dei servizi
r
Servizi di Directory accessibili via LDAP
r
Servizi Applicativi centrali, cioè la componente centrale di servizi applicativi
che prevedono un punto centrale di coordinamento o di accesso
r
Servizi di Web server
r
Servizi per la distribuzione, l’aggiornamento e il monitoraggio delle
componenti software remote sui NAL
r
Cruscotto di amministrazione di sistema
r
Gateway verso altri Centri Servizi e/o verso altri Enti
Questo centro può essere replicato e distribuito a livello sub-regionale (per esempio a
livello provinciale) per rispondere a requisiti di efficienza e di prestazioni.
3.1.5 FRAMEWORK CA
Il Framework per la cooperazione applicativa ha il compito di gestire la consegna dei
messaggi rendendola affidabile e indipendente dai vincoli che si avrebbero se i soggetti
page 35/53
interessati dovessero comunicare direttamente tra loro per lo scambio di informazioni.
Il “Framework Ca” contiene i componenti:
r
Componente JMS Provider in modalità “Publish & Subscribe”. Questo si
occupa della autenticazione da parte dei NAL, della ricezione dei messaggi
JMS spediti dal NAL e della spedizione dei relativi messaggi ai NAL
sottoscrittori dell’evento
r
Componente Configuration Manager CA che fornisce la funzionalità di
amministrazione per l’assegnazione dei ruoli ai diversi NAL
r
Componente Repository che contiene i dati persistenti necessari allo
svolgimento delle funzionalità sopra descritte. Questo repository può essere un
Directory Sever o un RDBMS
r
Componente Registry dei Servizi necessaria per la cooperazione di tipo
sincrono
Il software “Framework CA” consente la cooperazione applicativa tra i sistemi
informativi degli Enti della Regione Toscana. Tale software interagisce con il
componente Message Handler presente sui NAL.
Il “Framework CA”, in seguito alla ricezione di ogni messaggio da parte del NAL, si fa
carico di effettuare tutti i controlli e le verifiche necessarie al proseguimento della
pubblicazione. Quindi,in caso di esito positivo, inoltra il messaggio ai NAL e quindi ai
SIL sottoscrittori del corrispondente evento. L'individuazione dei NAL e del o dei SIL
sottoscrittori avviene tramite un apposito repository in cui sono contenute le
informazioni di instradamento.
Il sistema proposto è fornito delle seguenti funzionalità:
•
Ricezione e instradamento dei messaggi pubblicati dai componenti software
presenti sul NAL.
•
Autenticazione. Il sistema verifica l'identità del componente software presente sul
NAL che deve inviare il messaggio.
•
Autorizzazione. Il sistema verifica che i componenti software presenti sul NAL
siano autorizzati a pubblicare o ricevere il messaggio in base alle informazioni
contenute in una ACL (Access Control List).
•
Gestione del messaggio. Il sistema, in caso di esito negativo, in una delle fasi di
autenticazione e autorizzazione dovrà inviare un messaggio di risposta al
pubblicatore dell'evento. Nel caso in cui tutti i controlli abbiano esito positivo, il
sistema processerà il messaggio instradandolo verso i componenti software
sottoscrittori dell'evento corrispondente presenti sui NAL.
•
Funzioni di amministrazione relative alla assegnazione e gestione dei ruoli di
pubblicatore e sottoscrittore dei SIL (e quindi dei NAL corrispondenti). Il
sistema fornisce un'interfaccia attraverso la quale l'amministratore registra i SIL
nel ruolo di pubblicatori e/o sottoscrittori. Ogni registrazione conterrà
page 36/53
l'identificativo del SIL, il ruolo (pubblicatore o sottoscrittore), il tipo di evento e
il periodo di attivazione.
•
Gestione delle problematiche relative alla sicurezza. Oltre a effettuare le verifiche
necessarie per l'autenticazione e l'autorizzazione, il sistema garantisce che il
messaggio sia protetto mediante crittografia. A questo scopo viene utilizzato un
canale protetto per la trasmissione dei messaggi.
I componenti software utilizzati per implementare la soluzione proposta sono:
u
u
Broker (Provider JMS):
•
Ricezione messaggi
•
Autenticazione
•
Autorizzazione
•
Gestione del messaggio
•
Consegna messaggi
•
Sicurezza
Configuration Manager CA
u
u
Configurazione degli Enti SIL coinvolti nella cooperazione
Repository utilizzato dal sistema per reperire le informazioni necessarie alla
autenticazione e amministrazione dei ruoli degli Enti SIL.
3.1.6 REGISTRY DI SERVIZI
Il registry ebXML 2.0 registra servizi e documenti. La tipologia di servizi e documenti
è personalizzabile.
Il registry fornisce il supporto per pubblicare e ricercare i servizi amministrativi in rete,
poiché è costituito da un elenco consultabile di descrizioni di servizi fornite dalle
rispettive amministrazioni fornitrici . Dal punto di vista degli utilizzatori del registry,
essi ricercano il servizio e, una volta ottenuti i dettagli tecnici, possono iniziare la
comunicazione.
Dato che fornisce una interfaccia di accesso, il registry si comporta esso stesso come
un servizio di rete, questa volta relativo alla pubblicazione e ricerca di altri servizi.
In un’architettura di tipo SOA (Service Oriented Architecture) per il registry si
definiscono un certo numero di operazioni fondamentali :
Publish I provider pubblicano le informazioni sui servizi in un repository e le rendono
disponibili tramite il registry. Il meccanismo utilizzato è chiamato dynamic discovery.
Le interfacce fornite dai registry server sono conformi alle specifiche UDDI o ebXML.
L’utilizzo delle API JAXR (Java API for XML Registry) permette di operare in
page 37/53
maniera uniforme e standard sui differenti tipi di registry.
Find: interrogazione del Repository da parte di un Web Service Client per localizzare
il servizio. Il meccanismo utilizzato è il service location. La ricerca si effettua sempre
attraverso le API JAXR. Le query di ricerca sono formattate secondo un determinato
standard XML e trasmesse utilizzando SOAP o ebXML Message Service.
Bind: negoziazione da parte di un Service Client con un Service Repository e un
Service Provider, per l'utilizzo del servizio. E’ il processo che un’applicazione effettua
quando usa la descrizione del servizio per creare un messaggio da spedire al provider.
La descrizione è formattata in uno standard XML, usando dei linguaggi basati su
WSDL.
Il Registry deve avere inoltre le seguenti caratteristiche:
•
REPOSITORY DOCUMENTALE. Il contenuto del Registry può
essere costituito da schemi XML, documenti, descrizione di processi,
modelli UML, informazioni circa gli attori e anche componenti software.
•
GESTIONE DELLA SICUREZZA. Gli utenti del repository devono
poter gestire chi ha accesso alle loro informazioni, devono poter
impostare differenti livelli di accesso, identificando chi può leggere,
modificare o cancellare i dati.
•
SERVIZI DI QUERY. Fornisce funzioni di ricerca dei servizi, dei
documenti e degli oggetti memorizzati.
•
GESTIONE DELLE VERSIONI. Il controllo delle versioni permette
che gli utenti conservino traccia delle versioni successive dello stesso
documento, evitando che possano essere soprascritte versioni precedenti
del documento.
•
CHECK-IN/CHECK-OUT. Gestione di accessi concorrenti in lettura e
aggiornamento multipli sullo stesso documento. Quando un utente
esamina un documento, l'aggiornamento deve essere impedito da parte
di altri utenti, ma deve essere possibile leggere la versione corrente
La specifica UDDI non fornisce la funzionalità di repository documentale, cosa invece
che viene fornita dalle specifiche ebXML (Electronic Business XML ).
Con un registry ebXML avrei entrambe le funzionalità ma per compatibilità anche con
il mondo esterno che usa UDDI la cosa migliore è averli entrambi e usare UDDI per i
servizi e un registry ebXML che consente anche la pubblicazione e la condivisione di
documenti XML che formalizzano non solo l’interfaccia del servizio proposto da una
Pubblica Amministrazione ma anche l’eventuale successione di scambi tra gli
interlocutori
Il registry deve essere comprendere inoltre le seguenti funzionalità:
•
Possibilità per un’amministrazione di iscriversi al registro come publisher
e/o subscriber di un evento
page 38/53
Infrastruttura per la Cooperazione Applicativa – CART•
•
Gestione della pubblicazione di un servizio:
ˆ
Gestione del repository (insert, find, delete)
ˆ
Gestione della definizione del file WSDL
ˆ
Bind dell’amministrazione locale al servizio
ˆ
Verifica della specifica del servizio inserita nel registry con l’effettiva
implementazione del servizio stesso sia nel caso di servizio sincrono
che nel caso dei servizi asincroni (P&S)
Interfaccia per la definizione eventi/servizi. Un nodo locale o centrale
definisce l’evento, crea la coda e crea i requisiti
3.1.7 SERVIZIO DI DIRECTORY
All’interno del CRIC è presente un servizio di Directory accessibile via LDAP.
Contiene le informazioni relative agli utenti attori della cooperazione applicativa. Sono
inoltre presenti le informazioni relative al ruolo che l’utente riveste in base al quale può
o meno accedere a determinati servizi
3.1.8 PUBLISH&SUBSCRIBE BROKER
Le funzionalità del broker Sun ONE Message Queue, provider JMS presente sul
CRIC, sono:
•
Ricezione messaggi
•
Autenticazione
•
Autorizzazione
•
Gestione del messaggio
•
Consegna messaggi
•
Sicurezza
3.1.9 AGGIORNAMENTO SOFTWARE DEI NAL
L’aggiornamento delle componenti software sui NAL avviene attraverso la rete ed è
gestito da un cruscotto di controllo residente sul CRIC. Tale cruscotto permette di
visualizzare le versioni e i moduli presenti su ciascun NAL, di monitorarne le
funzionalità principali, di aggiornare la versione del software.
3.1.10 MONITORAGGIO
Similmente a quanto accade per l'aggiornamento software, così anche lo stato di un
processo amministrativo viene sottoposto a monitoraggio mediante un cruscotto di
controllo presente sul CRIC. Dalla lettura delle informazioni di log e dall'utilizzo delle
page 39/53
specifiche di processo amministrativo, il sottosistema e' in grado di fornire all'operatore
le indicazioni circa le amministrazioni coinvolte, le fasi già concluse del processo e le
eventuali condizioni di errore.
3.1.11 INTERFACCE VERSO IL MONDO ESTERNO
Sul CRIC saranno realizzate delle applicazioni che permetteranno agli Enti dotati di
NAL di colloquiare sia con altri Centri di Cooperazione Applicativa dotati di un NAL
che segua gli stessi standard di CART sia con altri Enti e a volte con i cittadini dotati di
un personal Computer. Rientrano in quest'ultima categoria per esempio i medici che
devono prelevare i referti dei propri pazienti pubblicati dalle Aziende Sanitarie
attraverso l'architettura di CART.
Dal momento che il singolo utente non può sottoscrivere eventi, verranno realizzate
delle applicazioni sul CRIC che si sottoscriverranno a questi eventi e li depositeranno
in un apposito repository a cui il singolo PC si collegherà e, previa autenticazione,
preleverà i messaggi a lui destinati.
Le interfacce che verranno messe a disposizione in questi casi saranno Web Services
che permetteranno di inviare e/o ricevere dati e/o eventi.
La comunicazione tra i NAL avviene sempre attraverso i CRIC in entrambe le modalità
di notifica eventi e richiesta di servizio. Il CRIC svolgerà quindi il ruolo di nodo
centrale nella comunicazione, sia per l'erogazione di Web Service sia per la gestione di
eventi.
4
COOPERAZIONE APPLICATIVA CON ALTRI CODOMINI NON E .TOSCANA
L'architettura di riferimento per il sistema di interoperabilità con altri domini non
e.Toscana è basata su una federazione di Centri Regionali nei quali vengono gestiti i
Registry dei servizi. In questa vengono proposti due possibili scenari: il Registry
Primario e i Registry Federati.
Il processo di attuazione di tale modello può prevedere una prima fase nella quale si
attua un Registry Primario, creato con l'intento di eliminare le ridondanze esistenti tra i
Registry attuali e di fornire un mezzo per poter giungere in modo graduale, ma
scalabile, ad uno scenario “misto” in cui avremmo uno o più Registry Primari federati
tra loro.
I repository primari federati agiscono come repository per amministrazioni che non
intendano realizzare in tempi brevi un repository proprio.
Gli scenari descritti sono confortati dalla piena completezza degli standard definiti e
dalla fattibilità tecnologica essendo basati sulla disponibilità di interfacce pubbliche
nell'ambito del registry UDDI e nell'ambito del registry/repository ebXML, che
page 40/53
consentono l'interoperabiltà tra i registri/repository secondo le due più classiche
modalità di interazione tra due sistemi, quella del Publish&Subscribe e quella HTTP
request-response.1
Di seguito vengono descritti tecnologicamente tali scenari secondo una puntuale
visione tecnologica che consente di definire, ad un consistente livello di disegno logico,
l'architettura che realizza il modello di Cooperazione Applicativa interregionale.
La soluzione scelta contempla i due modelli architetturali Service Oriented e Event
Driver (SOA e EDA), applicati ai due scenari previsti dalla cooperazione applicativa
interregionale.
page 41/53
MODELLI DI COOPERAZIONE
COOPERAZIONE
TRA
CENTRI
DI INTEROPERABILITÀ E
Il modello proposto consente la costituzione di più Centri per l'Interoperabilità e la
Cooperazione Applicativa che costituiscono i punti di contatto fra i diversi aggregati
di soggetti che condividono una stessa infrastruttura.
Secondo tale modello, i Centri di territori diversi potranno interoperare attraverso le
modalità di notifica di eventi o di invocazione di servizio, così come i nodi applicativi
di una stessa Regione ad esempio cooperano tra loro.
Gli Enti che utilizzano una comune infrastruttura di Cooperazione Applicativa
realizzano le proprie Porte di Dominio attraverso un Nodo Applicativo (il concetto di
Nodo Applicativo è un'astrazione, può essere implementato da uno specifico server o
attraverso l'adeguamento di sistemi interni all'Ente stesso).
La comunicazione tra Nodi Applicativi di aggregati diversi, avviene sempre attraverso i
Centri in entrambe le modalità di notifica eventi e richiesta di servizio. Il Centro di ogni
aggregazione svolgerà quindi il ruolo di nodo centrale nella comunicazione, sia per
l'erogazione di Web Service sia per la gestione di eventi. Nello scenario di richiesta di
servizio, in un esempio di infrastrutture regionali diverse, il Nodo Applicativo 1 della
Regione A richiederà il servizio al CRIC della propria Regione, che si occuperà di
richiedere il servizio al CRIC della Regione B che esporrà il servizio implementato dal
Nodo Applicativo 2.
page 42/53
Nodo
applicativo 1
Nodo
applicativo 2
REG
Primario
Nodo
applicativo n
Nodo
applicativo 1
SOAP/HTTP
Nodo
applicativo 2
CRIC
Regione B
CRIC
Regione A
Nodo
applicativo n
Reg b
Reg a
SOAP/HTTP
Nodo
applicativo 1
Nodo
applicativo 2
CRIC
Regione C
Nodo
applicativo n
Reg c
“Nota: Nella trattazione che segue faremo riferimento per semplicità ad aggregazioni
di enti o soggetti facenti parti di territori regionali diversi ma il modello consente
ovviamente aggregazioni sia subregionali che sovraregionali.”
Le modalità di cooperazione tra Regioni o territori diversi avverranno attraverso i
meccanismi di notifica eventi e richiesta di servizio.
Per entrambe le modalità sarà possibile comunicare tramite la combinazione dei due
capisaldi:
• un Registry in cui sono contenute le informazioni sui servizi disponibili, siano essi di
pubblicazione/sottoscrizione eventi, siano essi Web Services
• l'invio e la ricezione di un messaggio SOAP su HTTP, sia esso usato per
pubblicazione/sottoscrizione eventi, sia esso contenente richieste di servizio
4.1.1 COOPERAZIONE APPLICATIVA PER EVENTI
La Cooperazione Applicativa ad eventi si basa sullo scambio asincrono di messaggi tra
Domini diversi.
In un sistema di messaging ad invocazione asincrona i partecipanti non devono restare
connessi in attesa di una risposta dal destinatario, ma possono limitarsi ad inviare il
page 43/53
messaggio affidandolo ad un'infrastruttura di servizio che ha il compito di gestirne la
consegna rendendola affidabile nonché indipendente dai vincoli che si avrebbero se i
soggetti interessati dovessero comunicare direttamente tra loro per lo scambio di
informazioni.
Nello scenario rappresentato nella figura seguente, la Regione A dispone di un CRIC
dotato di un sistema di P&S (la cui tecnologia dipende dalla piattaforma scelta dalla
Regione) e un SOAP Service per esporre i servizi pubblicati sulla coda del motore di
MQ, come Web Service.
La Regione B effettua un discovery sul Registry Primario o sul Registry Federato del
servizio a cui è interessata, reperendo informazioni su di esso (quali la Regione
erogatrice del servizio e la modalità di invocazione dello stesso), indipendentemente
dalla natura del servzio, (notifica evento piuttosto che web service).
La Regione B invia una richiesta HTTP al SOAP Service, per esempio di
sottoscrizione ad un evento, presente sul CRIC della Regione A (erogatrice del
servizio).
La Regione A, attraverso il suo sistema di P&S, per esempio un Message Broker
J2EE, prenderà in carico la richiesta e la gestirà secondo le regole interne al suo CRIC.
Alla pubblicazione dell'evento ( al quale si era sottoscritta la Regione B) da parte della
Regione A, sarà inviato un messaggio SOAP su HTTP alla Regione B, la quale sarà in
grado di riceverlo tramite il suo SOAP Service, gestendone poi l'invio agli opportuni
nodi applivativi, attraverso il meccanismo prescelto.
page 44/53
Nodo
applicativo 1
Nodo
applicativo 2
REG
Primario
Nodo
applicativo n
Nodo
applicativo 1
Nodo
applicativo 2
Reg b
SOAP/HTTP
CRIC
Regione A
CRIC
Regione B
Nodo
applicativo n
SOAP Service
SOAP Service
Sistema
P&S
Reg a
SOAP/HTTP
Nodo
applicativo 1
Nodo
applicativo 2
Reg c
CRIC
Regione C
SOAP Service
Sistema
P&S
page 45/53
Nodo
applicativo n
4.1.2 COOPERAZIONE APPLICATIVA PER INVOCAZIONE DI SERVIZIO
Il “modello di interaction” attraverso cui un client invoca e usa un Web Service può
essere sincrono e asincrono.
Nodo
applicativo 1
Nodo
applicativo 2
REG
Primario
Nodo
applicativo n
Nodo
applicativo 1
Nodo
applicativo n
Reg b
SOAP/HTTP
CRIC
Regione B
CRIC
Regione A
SOAP Service
Nodo
applicativo 2
SOAP Service
Reg a
SOAP/HTTP
Nodo
applicativo 1
Nodo
applicativo 2
Reg c
CRIC
Regione C
Nodo
applicativo n
SOAP Service
Sistema
P&S
Nello scenario rappresentato in figura, la Regione A dispone di un CRIC dotato di un
SOAP Service per inviare e ricevere servizi di tipo sincrono, tramite messaggi SOAP
su HTTP.
La Regione B effettua un discovery sul Registry Primario o sul Registry Federato del
servizio a cui è interessata, reperendo informazioni su di esso (quali la Regione
erogatrice del servizio e la modalità di invocazione dello stesso), indipendentemente
dalla natura del servzio, (notifica evento piuttosto che web service).
La Regione B invia una richiesta HTTP al SOAP Service, per esempio di richiesta
sincrona (ad esempio un'interrogazione), presente sul CRIC della Regione A
(erogatrice del servizio).
La Regione A, attraverso il suo SOAP Service, prenderà in carico la richiesta e la
gestirà secondo le regole interne al suo CRIC.
page 46/53
Qualora le informazioni richieste alla Regione A non risiedano sul suo CRIC, il CRIC
effettuerà una richiesta sincrona di servizio al suo nodo applivativo di competenza, una
volta ricevuta la risposta la reindirizzerà al CRIC richiedente della Regione B.
La descrizione di un Web Service consiste in una descrizione WSDL e degli schemi
XML referenziati dalla descrizione del servizio.
La pubblicazione del Web Service viene fatta su un “XML registry” utilizzando le API
JAXR che permettono la pubblicazione e la ricerca delle descrizione. Attualmente
JAXR è in grado di supportare gli standard UDDI ed ebXML.
Sul CRIC esiste una componente software che svolge il ruolo di registry e repository
XML (le due tipologie proposte sono UDDI ed ebXML). Tale componente viene
utilizzata a design-time dai tool di sviluppo per ricercare la descrizione delle interfacce
dei servizi (WSDL o schema XML) e a run-time dai componenti software presenti sui
centri per determinare l'endpoint del servizio.
Questi modelli di cooperazione interregionale sono perseguibili grazie all'introduzione,
in uno dei CRIC delle Regioni coinvolte nella cooperazione, di un Registry
centralizzato, atto esclusivamente a contenere la descrizione dei servizi che ogni
Regione mette a disposizione delle altre.
Saranno poi i CRIC di ogni Regione ad instaurare la comunicazione tra loro,
richiedendo o meno, conformemente alla tipologia di servizio richiesto o evento
invocato, l'innescarsi di una comunicazione interna alla Regione con il nodo applivativo
di competenza del servizio/evento.
page 47/53
REGISTRY DEI SERVIZI
Il Registry dei servizi costituisce il cuore del sistema di interoperabilità interregionale e
per la sua implementazione è possibile ipotizzare due scenari: Registry Primario e
Rete di Registry.
I due scenari non sono mutuamente esclusivi ma anzi si può prevedere una prima fase
nella quale si attua un unico Registry Primario, creato con l'intento di eliminare le
ridondanze esistenti tra i Registry attuali e successivamente estendere il modello ad
uno scenario “misto” in cui avremmo più Registry Primari in rete.
4.1.3 REGISTRY PRIMARIO
In questo capitolo viene descritto lo scenario di interazione interregionale che prevede
l'utilizzo di un Registry Primario. Le funzionalità di Registry Primario possono essere
ospitate all'interno di uno dei CRIC attualmente attivi.
All'interno del registry primario sono contenute le descrizioni dei servizi, siano essi di
tipo notifica evento o richiesta di servizio, che le Regioni mettono a disposizione
nell'ambito del sistema di cooperazione ed, eventualmente, gli schema XML relativi, ad
esempio, alle specifiche della busta di egovernment. Ad esso accederanno i CRIC
Regionali al fine di reperire i dettagli sui servizi da invocare, secondo le modalità
descritte nel capitolo 0.
Un registry XML è un'infrastruttura che abilita la costruzione, il deploy e il discovery
di Web services ed eventi. Rappresenta una terza parte neutrale che facilita interazioni
business-to-business in modalità dinamica, a runtime e loosely coupled. Un registry è
reso disponibile alle organizzazioni come risorsa condivisa, spesso sotto la forma di un
servizio web-based.
Le specifiche dei registry XML includono:
• Lo standard ebXML Registry/Repository, sponsorizzato dall'Organization for the
Advancement of Structured Information Standards (OASIS) e dal United Nations
Centre for the Facilitation of Procedures and Practices in Administration,
Commerce and Transport (U.N./CEFACT)
• Il progetto Universal Description, Discovery, and Integration (UDDI), realizzato da
un consorzio di vendor
Un registry provider è un'implementazione di un business registry che aderisce alle
specifiche dei registry XML.
Il registry fornisce il supporto per pubblicare e ricercare i servizi amministrativi in rete,
poiché è costituito da un elenco consultabile di descrizioni di servizi fornite dalle
rispettive amministrazioni fornitrici. Dal punto di vista degli utilizzatori del registry,
essi ricercano il servizio e, una volta ottenuti i dettagli tecnici, possono iniziare la
comunicazione.
Dato che fornisce una interfaccia di accesso, il registry si comporta esso stesso come
page 48/53
un servizio di rete, questa volta relativo alla pubblicazione e ricerca di altri servizi.
4.1.4 RETE DI REGISTRY E MODALITÀ DI COLLOQUIO
L'interoperabilità e le interazioni tra i registry possono avvenire attraverso tre modalità
incrementali (anche oggetto di un progetto nel U.S. Federal CIO Council’s XML Web
Services Working Group).
4.1.4.1 Allineamento reciproco automatico
In questa modalità è prevista una capacità di allineamento reciproco automatico in cui
ogni registry (UDDI ed ebXML) può raggiungere l'altro registry per accedere ad un
oggetto (per esempio la descrizione di un Web Service) che risiede su quest'altro tipo
di registry. Ciò è possibile senza l'aggiunta di meccanismi di middleware,
semplicemente utilizzando le caratteristiche esistenti dei registry coinvolti.
Uno scenario possibile consiste in un ente che possiede un registry ebXML contenente
le descrizioni dei servizi che l'ente riesce ad erogare, per esempio documenti WSDL
relativi a tali servizi o indicazioni sulle code di messaggi, pubblicatori e sottoscrittori e
in un secondo ente che possiede il registry UDDI che, tramite il meccanismo di
allineamento automatico accede alla descrizione dell'evento o del Web Service
contenuta nell'ebXML, registrando un record di quella descrizione nel suo registry
Regione A
Regione B
effettivo
UDDI
reale
Documento WSDL
Informazioni code
ebXML Registry
UDDI e accede al registry ebXML, quando necessario.
page 49/53
Il risultato finale consiste in un accesso da parte della Regione A alle informazioni sulle
code o al documento WSDL che è registrato nel registry ebXML – comunque il
risultato effettivo è come se la Regione A accedesse direttamente al registry ebXML.
Nella maggior parte dei casi ciò implica un accesso read-only alle informazioni e ai
documento da parte del registry UDDI.
4.1.4.2 Comunicazione Publish & Subscribe
Questa seconda modalità aggiunge alla precedente la capacità di mantenere
rappresentazioni locali di oggetti in ogni registry, con oggetti duplicati tra registry. Un
amministratore di registry può preferire questo approccio al fine di possedere maggior
controllo sulla descrizione del servizio (evento o web service che sia).
Cosa accade però se viene effettuata una modifica ad un oggetto? Come si può
notificare una modifica al registry che possiede una rappresentazione locale
dell'oggetto originario? In questa situazione la modalità publish/subscribe può essere
valutata.
Un cambiamento alla descrizione di un evento o di un Web Service all'interno di un
registry UDDI scatena automaticamente una notifica di tipo publish/subscribe non solo
agli altri registry UDDI che conservano una loro rappresentazione locale di quella
descrizione, ma anche ai registry ebXML coinvolti (lo stesso concetto risulta valido
nella direzione inversa ebXML registry-to-UDDI registry).
Regione A
Regione B
Documento WSDL
Informazioni code
Documento WSDL
Notifiche Publish&Subscribe
UDDI
Informazioni code
ebXML Registry
page 50/53
Ogni ente conserva la propria versione delle informazioni sulle code e documento
WSDL nel suo registry. Una versione viene designata al ruolo di versione master,
mentre le altre vengono considerate repliche. Se la versione master è oggetto di
modifiche, tutti i registry aventi le repliche, a prescindere dal tipo di registry,
riceveranno una notifica di tale evento. A quel punto, gli utenti/amministratori del
registry decideranno l'operazione appropriata da compiere (inglobare gli aggiornamenti
o non considerarli).
4.1.4.3 Federazione di Registry
L'ultima modalità consiste in una federazione di registry, in cui i registry coinvolti
possono essere di tipo UDDI ed ebXML e le operazioni sui registry possono avvenire
in modo trasparente al tipo di registry.
Le seguenti operazioni sui registry possono essere effettuate:
• Seamless Query: la possibilità di cercare un oggetto in qualsiasi registry della
federazione, a prescindere dal tipo di registry
• Seamless Synchronization: la sincronizzazione di oggetti tra tutti i registry della
federazione, a prescindere dal tipo di registry, per esempio una modifica su un
oggetto in un registry può scatenare notifiche publish/subscribe a tutti gli altri
registry, a prescindere dal tipo di registry
• Seamless Relocation: la riallocazione di oggetti da un registry nella federazione
ad un altro, a prescindere dal tipo di registry
ebXML
UDDI
UDDI
ebXML
ebXML
page 51/53
page 52/53
Acronimi e Abbreviazioni
•
Framework CA (Framework di Cooperazione Applicativa) : componente software
presente sul CRIC e sul NAL.
•
CRIC: Centro Regionale per l'Interoperabilità e la Cooperazione Applicativa
•
NAL: Nodo Applicativo Locale
•
SIL: Sistema Informativo Locale
•
Proxy Anagrafe CA: componente software presente sul NAL.
•
Configuration Manager CA: componente software presente sul CRIC
•
Repository: componente software presente sul CRIC
•
JMS Provider: componente software presente sul CRIC
•
busta di eToscana = messaggio SOAP costruito secondo le specifiche definite nel
documento "D10.2-DefinizioneBusta e-Toscana"
•
HTTP: Hyper Text Transfer Protocol
•
HTTPS: HTTP con supporto della sicurezza
page 53/53

Infrastruttura per la Cooperazione Applicativa - C.A.R.T. –

Transcript

Documenti analoghi

agrikulturae_10_dicembre_2011

n. 2 IT System Specialist - Application Profilo posizione

Controllo di gestione.

Numero di accessi per giorno della settimana e

curriculum vitae

Informazioni tecniche TI-006-034

Il sistema ItalgiureWeb - Ministero della Giustizia

Curriculum Marco Di Pilla - Ordine ingegneri della Provincia di Roma