ALLEGATO N.2 Al C.S.A. - Standard Tecnologici: Ambienti di sviluppo e produzione - C.A.R.T - Sistema per la gestione dei profili

Transcript

1 ALLEGATO N.2 Al C.S.A - Standard Tecnologici: Ambienti di sviluppo e produzione - C.A.R.T - Sistema per la gestione dei profili

2 Dipartimento dell Organizzazione Servizio I.I.T.R. Ambienti di sviluppo e produzione Standard tecnologici

3 DOCUMENTO: Documento illustrativo Ambienti di sviluppo e produzione- Standard Tecnologici EMISSIONE - VERIFICA - APPROVAZIONE Funzione Nome firma Emissione Specialista Tecnico Laura Castellani LISTA DI DISTRIBUZIONE AGGIORNAMENTI Versione Data Paragrafi Modificati Motivo Modifica Prima stesura

4 Ambienti di sviluppo e produzione Sommario Analisi e produzione documentazione...4 Database...4 Sviluppo applicazioni...4 Gestione e pubblicazione banche dati...4 Applicazioni distribuite Java...5 Piattaforma J2EE...5 Sviluppo applicazioni sicure...6 Data warehouse...7 Portali dinamici...7 Servizi di Directory...8 Manutenzione applicazioni esistenti...8 Glossario...9 A cura di Laura Castellani

5 Ambienti di sviluppo e produzione... Analisi e produzione documentazione L ambiente di analisi scelto è un ambiente object-oriented che supporta l UML, in particolare Rational Rose. Per quanto riguarda il disegno entity-relationship viene usato Erwin32 della Logic Works. Per quanto riguarda quindi la documentazione prodotta i formati supportati attualmente sono il formato Rose 2000 per i documenti di analisi e i formati pdf,rtf e doc per la documentazione generica. Database Il motore RDBMS usato è Informix Dynamic Server. Questo, attraverso dei moduli aggiuntivi (i datablade) permette di avere delle estensioni al motore RDBMS classico tra cui la possibilità di costruire pagine html con dei tag particolari che permettono di scrivere le istruzioni SQL all'interno delle pagine stesse. Sviluppo applicazioni Le applicazioni che vengono sviluppate in Regione Toscana sono di vari tipologie e a seconda di queste ultime vengono usate tecnologie diverse. Gestione e pubblicazione banche dati Rientrano in questa categorie le applicazioni che permettono di gestire (inserimento, cancellazione, aggiornamento, pubblicazione ) basi dati. L'ambiente che viene usato per scrivere applicazioni di questo tipo è il Data Director for Web fornito da IBM: l ambiente permette di scrivere pagine Web in maniera semplice e veloce sfruttando le potenzialità del Web-datablade, estensione che consente di inserire costrutti SQL all interno di pagine HTML. L applicazione in questo caso risulta composta da una serie di pagine Web per cui il client non richiede altro che il semplice browser. Questa tecnologia presenta però lo svantaggio di essere proprietaria per cui applicazioni di questo tipo vengono sviluppate anche usando il linguaggio PHP con il modulo di interfacciamento a Informix o attraverso pagine JSP. Per la produzione di JSP viene usato Multimedia Dreamweaver Ultradev, strumento che permette di comporre in maniera visuale le pagine stesse e di effettuarne il loro deployment in modo semplice. A cura di Laura Castellani

6 Ambienti di sviluppo e produzione Applicazioni distribuite Java Per quanto riguarda applicazioni più complesse la tecnologia usata è quella J2EE con produzione quindi di servlets, JSP, Java Bean e Enterprise Java Bean: lo strumento di sviluppo scelto per scrivere applicazioni Java è JBuilder della Borland. Piattaforma J2EE Per lo sviluppo di applicazioni distribuite lo standard adottato è la piattaforma J2EE vers. 1.3 secondo le cui specifiche abbiamo: 1. Componenti client, vale a dire pagine HTML e applets 2. Java servlets e Java Server Page (JSP) 3. Enterprise Java Bean components Fig. 1 Schema della architettura J2EE Nel caso di Regione Toscana il Web Container usato è Tomcat, i server Web supportati sono Iplanet e Apache 1.3.x /Apache 2. A cura di Laura Castellani

7 Ambienti di sviluppo e produzione Per quanto riguarda gli EJB containers essi forniscono il supporto run-time per i componenti dell applicazione. Questi devono avere un ambiente run-time Java compatibile, come definito dalle specifiche Java 2 Standard Edition vers Gli Applet container possono usare il Java Plug-in per fornire questo ambiente o lo possono fornire nativamente. Inoltre i tools dei container devono riconoscere i formati di file usati per il packaging delle applicazioni per il loro deployment. Inoltre devono avere un set di servizi standard dettati dalle specifiche di Sun. Web datablade Informix Ambiente di sviluppo / client Data Director for Web Ambiente di sviluppo / server Motore Informix con Web datablade PHP/Informix Semplice editor -Server Web con estensione per PHP -Modulo PHP JSP/Servlet -Macromedia Ultradev per JSP -JBuilder -Server Web -Tomcat J2EE/EJB JBuilder -Server Web -Web container -EJB container Ambiente Run-time Browser Browser Browser Browser (Plug-in Java) Vantaggi -Semplicità di utilizzo -Rapidità nello sviluppo Ambiente Open-Source -Semplicità di programmazione -Indipendenza dalla piattaforma Realizzazione di applicazioni distribuite Svantaggi Ambiente proprietario e legato alla piattaforma Ambiente legato alla piattaforma Realizzazione di applicazioni piuttosto semplici Realizzazione più complessa che richiede programmatori esperti Sviluppo applicazioni sicure In Regione Toscana è disponibile una PKI in grado di emettere certificati digitali usati per l autenticazione. Per lo sviluppo di applicazioni Java con uso di autenticazione attraverso certificato digitale e di firma digitale viene usata la libreria IAIK PKCS#11 Wrapper per accedere ai moduli PKCS#11: questa usa la Java Native Interface per accedere ai moduli PKCS#11 delle smart cards. Nel caso di Regione Toscana accede ai moduli PKCS#11 per le smart card e ai moduli PKCS#11 per le cd-card (usate in Regione Toscana in alternativa alle smart-card). In figura lo schema di funzionamento del wrapper A cura di Laura Castellani

8 Ambienti di sviluppo e produzione Data warehouse In Regione Toscana è presente un architettura per la costruzione di data warehouse a partire da dati gestionali. L ambiente scelto per la costituzione di data mart e data warehouse è composto da: Data Stage della Ardent come strumento ETL Business Object come ambiente di analisi OLAP e produzione reportistica interattiva anche via Web (Web Intelligence) L architettura di riferimento è basata su metodologia di ROLAP e modello a star schema o snowflake schema ; il DBMS relazionale su cui poggia l architettura è IBM Informix IIF2000. Portali dinamici Lo strumento utilizzato per la costruzione di portali dinamici di tipo documentale generalista è IReach di Informix che permette di costruire portali Web dinamici mettendo a disposizione una parte di author per l inserimento e la pubblicazione di oggetti e una parte reader per la loro visualizzazione. A cura di Laura Castellani

9 Ambienti di sviluppo e produzione Servizi di Directory In Regione Toscana è presente un servizio di Directory accessibile attraverso il protocollo LDAP dove sono memorizzate informazioni relative ai dipendenti regionali e le informazioni relative ai servizi di cooperazione applicativa. I servizi di Directory vengono implementati usando Iplanet Directory Server. Infrastruttura per la cooperazione applicativa Per garantire l interoperabilità tra diverse applicazioni è stata realizzata una infrastruttura di cooperazione applicativa che supporta le due modalità principali della cooperazione: Invocazione sincrona di servizi Scambio asincrono di messaggi Per ulteriori approfondimenti su questa infrastruttura si rimanda al documento CART Infrastruttura per la Cooperazione applicativa. Manutenzione applicazioni esistenti Alcune applicazioni sviluppate per gli uffici regionali, attualmente in gestione, sono sviluppate nei seguenti ambienti: ACCESS 2 e ACCESS 7, per varie procedure in monoutenza, o con accesso via ODBC a data base INFORMIX FOXPRO per DOS e per WINDOWS, per procedure in monoutenza (piani di lavoro, ruolo sanitario, incarichi legge 108,...) o per procedure in architettura di rete (contenzioso amministrativo, protoc ollo) POWER BUILDER 6.5 per le procedure previste nel Progetto 241 (atti, protocollo,gare, lavori pubblici, albo fornitori) VISUAL BASIC 4 a 16 e a 32 bit per varie procedure in architettura client-server, con accesso via ODBC a data base INFORMIX. Questo tipo di architettura non è attualmente più usata per lo sviluppo di nuove applicazioni che vengono invece sviluppate in tecnologia Web. A cura di Laura Castellani

10 Ambienti di sviluppo e produzione Glossario RDBMS SQL HTML JSP Applet J2EE OLAP ROLAP JMS SOAP WDSL UDDI UML Unified Modeling Language Linguaggio per specificare, visualizzare e documentare sistemi software Relational Database Management System Database relazionali Structured Query Language Linguaggio di interrogazione database HyperText Markup Language Linguaggio per la pubblicazione di hypertext nel mondo Internet Java Server Page Applicazione scritta in Java che viene scaricata dal server Web e gira sul client all interno del browser Java 2 Enterprise Edition On-line Analytical Processing Sistema che permette di effettuare analisi multidimensionale su dati provenienti da diverse fonti Relational On-line Analytical Processing Sistema che permette di effettuare analisi multidimensionale basato su database relazionale Java Message Services API Java per la gestione della messaggistica Simple Object Access Protocol Protocollo basato su XML/HTTP per accedere a servizi, oggetti e server indipendenti dalla piattaforma Web Service Definition Language Linguaggio per la definizione di web services Universal Description, Discovery and Integration Servizio per la localizzazione degli Web Services A cura di Laura Castellani

11 Dipartimento dell Organizzazione Area Ingegneria dei Sistemi Informativi e della Comunicazione Servizio I.I.T.R. CART Infrastruttura per la cooperazione applicativa di e.toscana Cooperazione di tipo asincrono (P&S) 1 di 27

12 1. PREMESSA 4 Definizioni, Acronimi e Abbreviazioni 5 2. SISTEMA DI COOPERAZIONE APPLICATIVA 7 Visione d insieme 7 Descrizione software dei nodi 10 Motivazione delle scelte DESCRIZIONE DEL MODELLO ARCHITETTURALE 12 Architettura del Centro Regionale per l Interoperabilità e la cooperazione (CRIC) Framework per la cooperazione applicativa Registry dei servizi Servizio di Directory Aggiornamento software dei NAL Monitoraggio Gateway verso altri Centri Servizio e/o verso altri Enti 20 Architettura dei Nodi Applicativi Locali (NAL) 20 Message Handler CA 23 Message Control CA 23 Proxy applicativo 24 Servizi di supporto allo sviluppo, monitoraggio e aggiornamento dei Proxy Applicativi 25 2 di 27

13 3 di 27

14 Infrastruttura per la cooperazione applicativa 1. Premessa Il programma e.toscana 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 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 4 di 27

15 Infrastruttura per la cooperazione applicativa 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 progetto CART, oggetto del presente documento, intende realizzare l infrastruttura per la cooperazione applicativa. In particolare, con tale progetto si intende : Fornire una 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 del progetto 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 dell IT delle singole amministrazioni. Definizioni, Acronimi e Abbreviazioni Nodo: intendiamo le componenti hardware che costituiscono il sistema, così come definito dal deployment diagram UML. Componente software: intendiamo i programmi eseguibili distribuiti sui vari nodi, così come definito dal deployment diagram UML. Attore: intendiamo un ruolo assunto da una persona, processo o entità esterna al sistema che interagisce con esso, così come definito dal use case diagram UML. Web Services: intendiamo la definizione data dal W3C Web Services Architecture Working Group : A Web Service is a software application identified by a URI, whose interfaces and binding are capable of being defined, described, and discovered by XML artifacts and that supports direct interactions with other software applications using XML-based messages via Internet-based 5 di 27

16 Infrastruttura per la cooperazione applicativa protocols. In particolare non limitiamo questa definizione al solo utilizzo degli standard SOAP, WSDL e UDDI. SIL. Sistema informativo locale. NAL. Nodo applicativo locale CRIC. Centro Regionale per l'interoperabilità e la Cooperazione Applicativa. 6 di 27

17 Infrastruttura per la cooperazione applicativa 2. Sistema di cooperazione applicativa Visione d insieme La realizzazione della infrastruttura per la Cooperazione Applicativa realizza uno degli obiettivi principali contenuti nel Piano di e-government regionale e-toscana: costituire l infrastruttura abilitante sulla quale erogare i servizi a valore aggiunto in ambito regionale e nazionale. L interoperabilità, infatti, è uno dei cardini per poter migliorare l organizzazione e la qualità dei servizi ai cittadini e alle imprese. La messa a disposizione di questa infrastruttura da parte della Regione Toscana costituisce la base per tutte le realizzazioni di servizi in rete delle amministrazioni integrabili in e-toscana. La cooperazione applicativa può essere ricondotta a due modalità: Invocazione sincrona di servizi Scambio asincrono di messaggi La richiesta sincrona di servizio consiste in un messaggio scambiato tra un Dominio richiedente e un Dominio servente che determina, in base ai parametri inviati, l esecuzione sul Dominio servente di una procedura e il ritorno di una risposta al Dominio richiedente. La richiesta di servizio può essere di due tipi: Interrogazione: richiesta che non determina alcuna modifica sul Dominio servente Transazione: richiesta che determina una variazione applicativa su un qualche oggetto del Dominio servente Questo tipo di cooperazione verrà dettagliato in uno specifico documento CART Infrastruttura per la cooperazione applicativa di e.toscana. Cooperazione di tipo sincrono L altro tipo di interazione applicativa basata sullo scambio asincrono di messaggi è la notifica di un evento. Tale modalità prevede l implementazione delle due tipologie di comunicazione asincrona: Point To Point (PTP) e Publish & Subscribe (P&S). In questo caso l interazione è la notifica di un evento, vale a dire ogni volta che avviene un cambiamento del valore di un oggetto in un Dominio viene generato un evento e comunicato ad altri Domini sottoscrittori di questo evento. In questo caso abbiamo due tipologie di comunicazione asincrona: 1. Point-to-Point (PTP):si basa sul concetto di code di messaggi, sender e receiver. Ogni messaggio viene inviato in una coda specifica e i client riceventi estraggono i messaggi dalla coda a loro assegnata. Caratteristiche: a. Ogni messaggio possiede un solo consumer b. Il messaggio può essere prelevato in maniera asincrona dalla coda c. Il receiver notifica l avvenuto processing del messaggio 7 di 27

18 Infrastruttura per la cooperazione applicativa 2. Publish&Subscribe (P&S):l interazione tra due interlocutori avviene in maniera asincrona e mediata da un infrastruttura di servizio che offre la possibilità di pubblicare un evento e di sottoscriversi al servizio per ricevere l evento stesso. a. Ogni messaggio può avere diversi consumer b. Grazie al meccanismo di durable subscriptions offerto dalle API JMS il pubblicatore e il sottoscrittore non hanno una dipendenza temporale per cui i sottoscrittori possono non essere attivi al momento in cui viene pubblicato l evento. La soluzione proposta predilige 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. Le due componenti operative che consentono di realizzare tale infrastrutture di interoperabilità sono il Centro Regionale per l'interoperabilità e la Cooperazione Applicativa (CRIC) e i Nodi Applicativi Locali (NAL) collocati presso gli Enti. Lo schema, rappresentato nell'immagine riportata sotto, 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 l'output 8 di 27

19 Infrastruttura per la cooperazione applicativa 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à. 9 di 27

20 Infrastruttura per la cooperazione applicativa Descrizione software dei nodi Segue una descrizione dei componenti software operanti sui vari nodi del sistema nell'ambito della cooperazione applicativa. Descrizione funzionalità dei componenti applicativi: Nodo NAL : Componente Message Handler CA : Funzione di pubblicatore della busta di etoscana : quando il corrispondente NAL emette un evento, il Message Handler CA riceve il relativo messaggio SOAP in formato busta di etoscana dal componente "Message Control CA" e lo incapsula in un messaggio JMS per poi inviarlo alla parte del sistema operante sul CRIC. Funzione di sottoscrittore della busta di "etoscana": se il corrispondente NAL ha il ruolo di sottoscrittore, il componente è in grado di ricevere dal CRIC i messaggi JMS corrispondenti agli eventi di variazione e di estrarne la busta di etoscana per consegnarla al componente "Message Control CA". Funzioni di log: tiene traccia, su opportuni supporti di log, dei messaggi spediti (fuzione di pubblicazione) e ricevuti (funzione di sottoscrizione). Componente Message Control CA : Funzione di autenticazione in fase di pubblicazione di un evento: effettua il parsing del messaggio SOAP secondo la busta etoscana per estrarre la firma digitale del mittente e riconoscerne così l'identità, verificando inoltre l'integrità dei dati. Funzione di autorizzazione in fase di pubblicazione di un evento: una volta individuato il mittente, ne verifica il ruolo per controllare che sia abilitato alla pubblicazione dell'evento in questione, reperendo le informazioni sul repository del CRIC. Funzione di validazione della busta di etoscana in fase di pubblicazione o sottoscrizione di un evento: effettua un controllo sul formato del messaggio per accertarne la conformità alla busta di etoscana. Funzione di ricerca dei sottoscittori di un determinato evento: è una funzionalità utilizzata quando il sistema opera come sottoscrittore, infatti dopo aver validato il messaggio SOAP, il componente ricerca sul repository del CRIC i SIL sottoscritti al relativo evento. Artifact etoscana envelope : messaggio SOAP conforme alla busta di etoscana (vedi documento Busta e-toscana ); non è un componente ma un Artifact, in questo caso un prodotto non persistente del sistema. Nodo CRIC : Componente Framework CA : contiene i componenti JMS Provider, Configuration Manager CA e Repository. Componente JMS Provider in modalità publish & subscribe. Il componente si occupa della autenticazione dei NAL, della ricezione dei messaggi JMS spediti dai NAL e della spedizione dei relativi messaggi ai NAL sottoscrittori dell'evento. Componente Configuration Manager CA : fornisce una funzionalità di amministrazione per 10 di 27

21 Infrastruttura per la cooperazione applicativa l'assegnazione dei ruoli ai vari SIL. Componente Repository : contiene i dati persistenti necessari allo svolgimento delle funzionalità sopra elencate appoggiandosi su un database Motivazione delle scelte Le specifiche SOAP, fino alla versione 1.2, sono quasi esclusivamente finalizzate ad esporre applicazioni esistenti come web services attraverso l'utilizzo di semplici interfacce. Tali interfacce permettono di nascondere la complessità delle applicazioni che devono interoperare. L'utilizzo di tale approccio pone le difficoltà nella costruzione di sistemi distribuiti che usano i web services come parte integrante delle loro operazioni, più che nella costruzione di applicazioni web-based. L'approccio più semplice nella costruzione di questo tipo di sistemi distribuiti, assume che i web services siano affidabili quanto i servizi intranet-based. I problemi che questo tipo di approccio presenta riguardano: la natura sincrona delle chiamate SOAP RPC, che implicano un tempo di attesa della risposta equivalente al tempo di esecuzione del servizio l'incertezza dello stato dell'applicazione remoto dovuta a failure nella richiesta o nella risposta. Tali problemi sono amplificati nel caso si utilizzino più round-trip per completare una singola transazione. Un approccio più realistico propone l'utilizzo di un message-oriented middleware (MOM). Tale approccio presenta, fondamentalmente, due opzioni: 1.L'utilizzo di JMS come protocollo di trasporto per i messaggi SOAP. 2.La suddivisione delle chiamate SOAP su HTTP in due parti: richieste e risposte JMS fatte da o verso un componente proxy (chiamato Adapter) e una chiamata SOAP su HTTP fatta dall'adapter verso il web service. Le specifiche SOAP, anche se definite in modo indipendente dal particolare protocollo di trasporto dei messaggi, descrivono come incapsulare i messaggi SOAP in uno stream HTTP. Anche se i messaggi SOAP possono essere incapsulati in messaggi JMS e quindi inviati a un web service, tale soluzione è tipicamente vendor-proprietary. Anche il protocollo su cui i messaggi JMS vengono trasportati non è descritto da alcuna specifica. Queste condizioni portano ad avere sia il client SOAP che il server web service dipendenti dall'ambiente di runtime di uno stesso vendor. Per non introdurre delle dipendenze dai specifici vendor, l'approccio scelto riguarda un'architettura a tendere basata su JMS ed Adapter. 11 di 27

22 Infrastruttura per la cooperazione applicativa 3. Descrizione del Modello architetturale Il modello architetturale che si andrà a realizzare attraverso il progetto etoscana prevede l 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. 12 di 27

23 Infrastruttura per la cooperazione applicativa TIX CRIC DMZ NAL DMZ NAL SIL 1 SIL n Ente 1 SIL 1 SIL n Ente 2 SIL 1 SIL n Ente n Il NAL viene installato presso l Ente e deve essere posizionato nella DMZ della rete dell Ente: quest ultimo deve avere una connessione permanente alla RTRT. Nel caso in cui un Ente non disponga di un collegamento di questo tipo o comunque non abbia i requisiti per poter avere il NAL installato presso la propri sede, potrà decidere di utilizzare un NAL in remoto, posizionato presso un altro Ente, a cui si collegherà solo al momento dell effettivo utilizzo. Oltre alle componenti specifiche del CRIC e del NAL si rendono necessarie alcune funzionalità trasversali, quali: Sicurezza La gestione delle politiche di sicurezza legate allo scambio dei dati e alla cooperazione tra i vari domini presuppone per ogni richiesta : o L identificazione dei soggetti che richiedono i servizi 13 di 27

24 Infrastruttura per la cooperazione applicativa o L autenticazione della provenienza delle richieste o L autorizzazione selettiva all accesso ai servizi in base al richiedente o Il mantenimento della privatezza delle informazioni scambiate sulla rete o La garanzia dell autenticità, dell integrità e della non ripudiabilità delle informazioni scambiate o 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 attraverso certificato digitale. Per questo tipo di servizio ci si appoggerà sul servizio di CA della RTRT. Aggiornamento software Monitoraggio Gestione degli errori e logging 14 di 27

25 Infrastruttura per la cooperazione applicativa Architettura del Centro Regionale per l Interoperabilità e la cooperazione (CRIC) UDDI ebxml Registry dei servizi Directory Server http/ SOAP Server P&S Broker Servizi applicativi centrali Gateway verso altri Centri Servizi Application Server Servizio di monitoraggio applicazioni Cruscotto di amministrazione RDBMS 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: Framework per la Cooperazione Applicativa a. JMS Provider b. RDBMS c. Directory Server d. Cruscotto di amministrazione del Framework Registry dei servizi Servizi di Directory accessibili via LDAP Servizi Applicativi centrali, cioè la componente centrale di servizi applicativi che prevedono un punto centrale di coordinamento o di accesso Servizi di Web server Servizi per la distribuzione, l aggiornamento e il monitoraggio delle componenti software remote sui NAL Cruscotto di amministrazione di sistema 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. 15 di 27

26 Infrastruttura per la cooperazione applicativa 1. Framework per la cooperazione applicativa 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 interessati dovessero comunicare direttamente tra loro per lo scambio di informazioni. Il Framework Ca contiene i componenti: 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 Componente Configuration Manager CA che fornisce la funzionalità di amministrazione per l assegnazione dei ruoli ai diversi NAL Componente Repository che contiene i dati persistenti necessari allo svolgimento delle funzionalità sopra descritte. Questo repository può essere un Directory Sever o un RDBMS 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à 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. 16 di 27

27 Infrastruttura per la cooperazione applicativa I componenti software utilizzati per implementare la soluzione proposta sono: Broker (Provider JMS): Ricezione messaggi Autenticazione Autorizzazione Gestione del messaggio Consegna messaggi Sicurezza Configuration Manager CA 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. 2. Registry dei servizi 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 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. 17 di 27

28 Infrastruttura per la cooperazione applicativa 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. Service Registry Find Publish Service Requestor Bind Il Registry presenta avere inoltre le seguenti caratteristiche: Service Provider Repository documentale.il contenuto del Registry puo' 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 Le specifiche ebxml (Electronic Business XML ) coprono le funzionalità sopra descritte, compreso il repository documentale. 18 di 27

29 Infrastruttura per la cooperazione applicativa Il registry comprende inoltre le seguenti funzionalità: Possibilità per un amministrazione di iscriversi al registro come publisher e/o subscriber di un evento Gestione della pubblicazione di un servizio: o Gestione del repository (insert, find, delete) o Gestione della definizione del file WSDL o Bind dell amministrazione locale al servizio o 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. 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 4. 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. 5. Monitoraggio Similmente a quanto accade per l'aggiornamento software, cosi' 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 specifiche di processo amministrativo, il sottosistema e' in grado di fornire all'operatore le indicazioni circa le amministrazioni coinvolte, le fasi gia' concluse del processo e le eventuali condizioni di errore. 19 di 27

30 Infrastruttura per la cooperazione applicativa 6. Gateway verso altri Centri Servizio e/o verso altri Enti Sul CRIC saranno realizzati dei gateway che permetteranno di colloquiare con altri Centri di Cooperazione Applicativa dotati di un NAL che segua gli stessi standard di CART. Per altri soggetti che dovranno colloquiare con il Sistema di Cooperazione Applicativa verranno messe a disposizione delle interfacce sotto forma di Web Services che permetteranno di inviare e/o ricevere dati e/o eventi. Architettura dei Nodi Applicativi Locali (NAL) Le componenti Client per l accesso ai servizi di interoperabilità e Cooperazione sono 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 dati dal Sistema Informativo Locale, imbustare secondo la busta e-toscana e spedire il messaggio per la pubblicazione dell evento sul CRIC. 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 il CRIC 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. 20 di 27

31 Infrastruttura per la cooperazione applicativa Message Handler CA è il componente che si occupa della pubblicazione e ricezione degli eventi nel formato busta di etoscana verso e dal CRIC. Message Control CA è il componente che si occupa delle operazioni di validazione, autenticazione e autorizzazione dei messaggi nel formato busta di etoscana. 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. In particolare il Message Control CA riceve il messaggio formattato secondo la busta e-toscana, autentica il mittente attraverso la firma digitale, 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 e-toscana e risponde la componente Message Handler CA se ogni passo è andato a buon fine. Se tutto è a posto il componente Message Handler CA incapsula la busta e- toscana in un messaggio JMS, si collega al componente JMS Provider del CRIC autenticandosi e spedisce al CRIC il messaggio. Nel caso in cui il NAL è sottoscrittore di un evento, il messaggio verrà ricevuto dal componente Message Handler CA il quale traccia l avvenuta ricezione, estrae la busta e-toscana dal messaggio JMS e la consegna l relativo componente Message Control CA. Quest ultimo ne valida il formato, va a reperire sul repository del CRIC le informazioni relative a chi sono gli Enti sottoscrittori dell evento ( questo serve nel caso di NAL che servono più Enti) e inserisce gli identificativi dei sottoscrittori nell apposito campo della busta e-toscana che verrà poi inviata al Proxy Applicativo relativo. 21 di 27

32 Infrastruttura per la cooperazione applicativa Il colloquio con il Framework CA avverrà in modalità JMS sicuro o anche via SOAP su https con caratteristiche di sicurezza e affidabilità. 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 sono: Package per interfaccia verso il CRIC Message Handler CA e Message Control CA che si basano su: 22 di 27

33 Infrastruttura per la cooperazione applicativa API JMS per la gestione dei servizi di comunicazione JMS API JAXM/JAXRPC per la gestione dei messaggi XML API per la gestione della firma e della sicurezza Proxy Applicativo si basa su Package Message Handler per la formattazione secondo lo standard della busta e-toscana e l invio e/o la ricezione del messaggio 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 Message Handler CA Questo componente software permette la pubblicazione e la ricezione degli eventi secondo gli standard determinati dalla cooperazione applicativa. In particolare tale componente implementa la funzione di collaborazione della porta di dominio. La funzione di cooperazione viene realizzata pubblicando e ricevendo messaggi conformi alla busta di etoscana in modalità asincrona e affidabile come specificato dall'architettura proposta. L'implementazione dell'integrazione con il sistema presente avviene utilizzando l Adapter JMS- HTTP/S. 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. 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. 23 di 27

34 Infrastruttura per la cooperazione applicativa 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 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. 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 è una 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. Queste modalità sono descritte in modo dettagliato nel documento CART-Cooperazione di tipo asincrono- Linee guida per lo sviluppo d Proxy applicativi e relative interfacce - Regione Toscana. 24 di 27