Architettura di sistema

Transcript

1 1 di 33 Regione Toscana Architettura di sistema Livelli di approvazione RTI Redazione Revisione Approvazione/Emissio ne Funzione Firma P.L. Componente il Project G. Renzini Office P.L. Componente il Project R. Bonsignori Office Capo Progetto A. Rossi Livelli di approvazione Cliente Funzione Firma Verifica Responsabile Tecnico di G. Ugolini contratto Approvazione Responsabile di Servizio Dirigente Resp. Approvazione Responsabile di contratto Dirigente Resp. LISTA DI DISTRIBUZIONE Componenti il Project Office per Regione Toscana ed R.T.I.

2 2 di 33 AGGIORNAMENTI N. Paragrafi Versione Modificati Motivo della modifica /04/04 -- Prima emissione /12/04 2 Inserimento paragrafi /12/04 3 Nuovo schema componenti applicativi /12/04 3 Dettaglio Gestione Modulistica /12/ Dettaglio architettura proxies /06/05 3 Aggiunto paragrafo /11/05 3 Aggiornato lo schema del paragrafo 3 Componenti Applicativi

3 3 di 33 SOMMARIO 1 PREMESSA SCOPO E APPLICABILITÀ DOCUMENTI DI RIFERIMENTO E DOCUMENTI APPLICABILI Documenti di riferimento Documenti applicabili VALIDITÀ REQUISITI GENERALI E VINCOLI DEL SISTEMA SIGLE E ABBREVIAZIONI OVERVIEW DELLA RETE DEGLI U.R.P SCHEMA FUNZIONALE DEI SERVIZI OFFERTI DALLE RETE DEGLI URP S.I.L. TOOL RETE DEGLI U.R.P S.I.L. TOOL COMPATIBILI STRUTTURA CENTRALE DI REGIONE TOSCANA STRUTTURA DI COOPERAZIONE APPLICATIVA C.A.R.T COMPONENTI APPLICATIVI COMUNICAZIONE TRA COMPONENTI COMPONENTE SISTEMA INFORMATIVO LOCALE - TOOL RETE DEGLI U.R.P COMPONENTE INFORMATION RETRIEVAL Utilizzo dai S.I.L - Tool Rete degli U.R.P Utilizzo dai S.I.L. compatibili Utilizzo dal portale centrale COMPONENTE GESTIONE MODULISTICA Utilizzo dai S.I.L - Tool Rete degli U.R.P Le funzioni di Back Office Funzioni indipendenti dal Tool della Rete degli URP Funzioni collegate al Tool della Rete degli URP Le funzioni di Front Office LA COOPERAZIONE APPLICATIVA IDENTIFICAZIONE DELLE FUNZIONALITÀ USE CASE DIAGRAM CA_F1_Aggiorna_Store CA_F2_Alimenta_IR CA_F3_Monitor CA_F4_Sicurezza MODELLO DINAMICO CA_F1_Aggiorna_Store CA_F2_Alimenta_IR CA_F3_Monitor CA_F4_Sicurezza Sicurezza tra Front end del Proxy e SIL/SIR Sicurezza tra Back end del Proxy e Message Handler MODELLO STATICO package it.jada.reteurp.ca package it.jada.reteurp.ca.pubproxy package it.jada.reteurp.ca.storeproxy package it.jada.reteurp.ca.irproxy... 33

4 4 di 33 1 Premessa 1.1 Scopo e applicabilità Il presente documento ha lo scopo di illustrare il le Specifiche Funzionali per l espletamento delle attività richieste dal CAPITOLATO TECNICO ALLEGATO N. 1A al C.S.A per il Progetto Rete degli U.R.P., nell ambito del Piano di azione e.toscana. In particolare il documento fa riferimento alla realizzazione del Progetto rete degli URP, il quale si configura come un progetto di integrazione di sistemi informativi locali agli Enti (Tool della rete degli URP, Tool compatibili ed altri Tool locali) con le componenti centrali del sistema, ovvero il Portale ed i Tools della rete degli URP presenti in Regione Toscana, il Modulo Information Retrieval ed Modulo Gestione Modulistica. 1.2 Documenti di riferimento e documenti applicabili Documenti di riferimento Scheda progetto presentata il 4/6/2002 per il primo bando di E-goverment Progetto D2 Sportello informativo del cittadino: Rete degli U.R.P. della Toscana. Documento Infrastruttura per la cooperazione applicativa CART Il modello e l architettura Documento Schemi di classificazione per il Progetto rete degli URP Documenti applicabili Capitolato Tecnico Progetto Rete degli URP emesso dalla Regione Toscana. Allegato 2 al CSA per il Progetto Rete degli U.R.P. e successivi dettagli tecnici. Offerta tecnico-economica per il Progetto Rete degli URP prodotta dall RTI composto da: Caribel Programmazione s.r.l., Centrica s.r.l., Codices s.r.l., Pos s.r.l.. Documentazione amministrativa trasmessa da Caribel Programmazione S.r.l. (capogruppo R.T.I.) in data 16/02/ Validità Il presente documento è valido a partire dalla data di emissione riportata in copertina. 1.4 Requisiti generali e vincoli del sistema L obiettivo primario del progetto è la realizzazione di un front end di guida a tutte le attività afferenti ai cosiddetti eventi della vita che vedono il cittadino e/o l impresa interagire con la Pubblica Amministrazione. Il progetto vuole pertanto fornire al cittadino uno strumento evoluto di supporto alle tradizionali funzioni di URP quali: Rispondere a tutte le domande sulle strutture ed i servizi di ciascun ente. Fornire la modulistica sotto forma di moduli cartacei od elettronici con possibilità di apposizione di firma digitale. Accesso alle informazioni documentarie ed alle basi dati. Tutti i servizi erogati dal sistema opereranno nell ambito degli standard architetturali regionali per la sicurezza e la cooperazione applicativa definiti nel Piano di azione e.toscana. Tali standard di e- government saranno utilizzati per integrare in un unico sistema i servizi attualmente erogati dagli URP locali e Regionali ed i nuovi servizi di Information Retrieval e di Gestione della Modulistica definiti nel progetto. Il progetto si configura quindi come un progetto di integrazione in cui saranno utilizzati gli standard di cooperazione applicativa definiti dalla Regione Toscana nell ambito del piano regionale di e- government.

5 5 di Sigle e abbreviazioni Back Office CART CSV Digimoduli E-R Front Office G.M. I.R. I.S. NAL SIL W.A. R.P.C. insieme delle funzioni dei Tools della Rete degli URP destinate ad essere usate dagli operatori dell URP per la predisposizione delle informazioni da pubblicare su web. Cooperazione Applicativa Regione Toscana. Comma Separated Values, formato di importazione ed esportazione dati basato su file di testo in cui le righe rappresentano i record e elencano i valori dei campi separati dal carattere virgola o altro carattere da definire. Applicativo per la definizione e la gestione della modulistica Entity Relationship, indica un diagramma che evidenzia le correlazioni tra entità di database. insieme delle funzioni dei Tools della Rete degli URP destinate ad essere usate da chi intende consultare le informazioni predisposte per il singolo URP mediante le funzioni di Back Office. Gestione Modulistica, applicativo per la definizione e la gestione della modulistica degli Enti (sigla Digimoduli). Information Retrieval, sistema di archiviazione e indicizzazione di documenti digitali. Invocazione metodi mediante protocollo SOAP. Nodo Applicativo Locale. Sistema Informativo Locale. Web Application. Remote Procedure Call. Invocazione remota di servizi basata su scambio di file XML con protocollo http/https (Soap)

6 6 di 33 2 Overview della Rete degli U.R.P. L obiettivo primario del progetto è la realizzazione di un front-end di guida a tutte le attività afferenti ai cosiddetti Eventi della vita che vedono il cittadino e/o l impresa interagire con la P.A. Il progetto vuole pertanto fornire uno strumento evoluto di supporto alle tradizionali funzioni degli URP quali: Rispondere a tutte le domande sulle strutture e i servizi di ciascun ente Quali sono i tipi di servizi e prestazioni dell ente Quale struttura/ente eroga un servizio Dove sono localizzate le strutture e come contattarle Come ottenere una data prestazione Istruzioni dettagliate per l esecuzione di ciascuna attività/sotto attività Fornitura della modulistica sotto forma di moduli cartacei o elettronici con possibilità di apposizione di firma digitale Accesso alle informazioni Documentazione informativa di aiuto al cittadino che deve effettuare un attività o che debba approfondire un tema Accesso strutturato alle basi dati gestite da Enti Regionali o rese disponibili da Regione Toscana L accesso del cittadino ai servizi oggetto del progetto potrà avvenire da più porte di accesso : direttamente dal front-end dell Ente di interesse per il cittadino dal front-end unificato ( di seguito indicato con il termine Portale rete degli Urp ), strumento per l accesso ai servizi ed alle informazioni a carattere generale, nonché per l accesso agli URP locali dal front-end di uno degli Enti della rete e utilizzando l opportuno servizio informativo per l individuazione del front-end dell Ente di interesse

7 7 di Schema funzionale dei servizi offerti dalle Rete degli URP Cooperazione Applicativa 2.2 S.I.L. Tool Rete degli U.R.P. I Tool della Rete degli U.R.P. hanno due funzionalità di base distinte: il front office, che offre servizi e informazioni sull U.R.P., e il back office che contiene le funzionalità di amministrazione e di gestione delle informazioni e dei servizi esposti dal singolo U.R.P. Per accedere a una di queste funzionalità è necessario essere autenticati e autorizzati da SRTY. SRTY è stato integrato all interno dell applicazione ma dispone di tool di amministrazione propri. Tali tool sono in grado sia di gestire una base dati locale (SRTY locale) che provvedere al suo allineamento con il modulo SRTY centralizzato attraverso cooperazione applicativa (si veda 2.5). Per maggiori informazioni inerenti SRTY si faccia riferimento alla documentazione ufficiale resa disponibile dalla Regione Toscana. Solamente alcune informazioni applicative che riguardano l utente sono gestite e amministrate dai Tool. 2.3 S.I.L. Tool compatibili Qualunque Tool realizzato da terze parti si dice compatibile in quanto usa le stesse convenzioni sugli eventi gestiti attraverso la cooperazione applicativa. 2.4 Struttura centrale di Regione Toscana Ci sono dei servizi centralizzati, presso la Regione Toscana, che raccolgono e trattano in maniera omogenea le informazioni generate e gestite in periferia dai diversi Tool. La centralizzazione dei dati permette di eseguire ricerche, catalogazioni e gestione dei moduli in maniera efficiente e con strumenti di amministrazione unici. I servizi centralizzati sono:

8 8 di 33 modulo IR: permette di accedere alle basi di dati documentali indicizzate e offre servizi per la gstione e l accesso alle funzionalità di information retrieval store centrale: raccoglie le basi dati di interesse esposte dai singoli Tool DigiModuli: servizi centralizzati per la definizione, creazione e compilazione di moduli Gli scenari d uso dei diversi servizi sono esplicitati nel capitolo Struttura di cooperazione applicativa C.A.R.T. Il progetto utilizza le componenti standard del CART, l infrastruttura per la cooperazione applicativa della Regione Toscana. L obiettivo alla base delle scelte del modello di cooperazione della Regione Toscana è quello di implicare, ai fini della cooperazione, modifiche nulle o minime all architettura dei Sistemi Informativi Locali (SIL). Poichè l interazione diretta dei SIL con i servizi di rete necessari alla cooperazione applicativa (Directory e Registry Services - Notifica di evento Invocazione di servizio) avrebbe comportato significative modifiche ai SIL, la Regione Toscana ha disegnato nel progetto CART una architettura cooperativa in cui i servizi di rete necessari alla cooperazione dei SIL sono concentrati a livello centrale sulla piattaforma del CRIC. Inoltre i servizi cooperativi del CRIC non sono acceduti direttamente dai SIL bensì da Nodi Applicativi Locali (NAL), infrastrutture hardware-software locali al singolo dominio applicativo che fungono da Porta Delegata (P.D.) e Porta Applicativa (P.A.) per i SIL dei domini. Infine nell architettura CART i SIL di domini diversi interagiscono tra loro (sia per la richiesta di servizio che per la comunicazione di evento) tramite servizi semplificati esportati dai rispettivi NAL e forniti su protocolli standard; è quindi a carico dei NAL prendersi carico, per conto dei SIL, della interazione con i complessi servizi cooperativi del CRIC. Il tutto è sintetizzato nella seguente figura. Dominio X NAL NAL Dominio Y SIL P.D. P.A. CRIC P.A. P.D. SIL Nel seguito del documento, quando le componenti software che svolgono le funzioni di SIL e NAL saranno localizzate internamente al dominio regionale, queste saranno indicate rispettivamente con il termine SIR (Sistema Informativo Regionale) e NAR (Nodo Applicativo Regionale). In particolare saranno modellati come SIR e, ai fini della cooperazione applicativa, si interfacceranno con il NAR lo Store centrale, il Modulo IR ed il Modulo GM. Questo è sintetizzato nella seguente figura.

9 9 di 33 Dominio X Dominio Regionale DB DB SIL Proxy CRIC Proxy SIR Monitor Monitor NAL NAR Ai fini di questo progetto non esiste quindi differenza dal punto di vista architetturale tra SIL e SIR e tra NAL e NAR. In particolare i Proxy applicativi di NAL e NAR presentano le stesse macro funzionalità per l interfaccia verso i SIL-SIR, per l interfaccia verso il CRIC, per l interfaccia verso il data base locale, per il monitoraggio ed, in generale, per la sicurezza. I servizi di cooperazione del CART che saranno utilizzati nel progetto sono quelli necessari per: Consentire ad un SIL/SIR, tramite il NAL/NAR, di Pubblicare e Sottoscrivere eventi pubblicati da un altro SIL/SIR per mantenere la consistenza delle basi dati locali e centrali. Monitorare il corretto funzionamento dei Proxy applicativi e delle componenti centrali del sistema. Gestire con i dovuti livelli di sicurezza le richieste di servizio e di accesso a tutti i livelli del sistema. La soluzione proposta intende realizzare gli scenari funzionali richiesti dal bando attraverso il sistema di cooperazione applicativa presente in Regione Toscana, ossia ove possibile, le comunicazioni tra le componenti architetturali previste ed i relativi flussi saranno implementati sfruttando l infrastruttura di servizio CART esistente e le tecnologie da essa masse a disposizione.

10 10 di 33 3 Componenti Applicativi

11 11 di Comunicazione tra componenti Le differenti politiche di sicurezza nella comunicazione fra le varie sezioni applicative sono illustrate nel seguente diagramma: Il filtro cui si fa riferimento in figura è un java filter relativo all applicazione centralizzata. La client authentication viene effettuata tramite il certificato relativo all ente proprietario del nodo applicativo. Sarà l applicazione sul nodo ad accedere a tale certificato, che sarà quindi esportabile in Formato p12 ed importato in un keystore locale al SIL. 3.2 Componente Sistema Informativo Locale - Tool Rete degli U.R.P. Le informazioni vengono memorizzate in maniera persistente utilizzando un database (db locale) per quanto riguarda le informazioni relazionali e utilizzando un file system di archiviazione per i documenti. Entrambe queste strutture sono oggetto di cooperazione applicativa verso i servizi centralizzati.

12 12 di Componente Information Retrieval Il modulo di information retrieval espone le proprie funzionalità come servizi SOAP. Tali servizi sono invocabili da chiunque sia autenticato e autorizzato da parte di un modulo centrale, fornito dalla Regione Toscana e sotto il suo controllo, per la verifica degli accessi. Le funzionalità di information retrieval esposte riguardano sia la catalogazione di documenti nelle basi di dati documentali, sia l interrogazione delle basi dati documentali. I servizi veri e propri sono espletati utilizzando un motore di information retrieval (focuseek searchbox) acceduto e configurato dal modulo stesso attraverso chiamate SOAP. I documenti ricevuti dall esterno sono esposti al motore di information retrieval attraverso una directory condivisa da web server interno su cui il motore di information retrieval eseguirà periodiche attività di crawl. Il modulo si appoggia ad un datasse per la memorizzazione permanente della configurazione e delle caratteristiche del motore di information retrieval. La configurazione e il monitoraggio avvengono attraverso l uso della tecnologia JMX Utilizzo dai S.I.L - Tool Rete degli U.R.P. I Tool della Rete degli URP utilizzano direttamente i servizi di information retrieval per l interrogazione, dal front office, sulle basi dati documentali. Tali interrogazioni sono di due tipi: semplici o avanzate. La prima forma di interrogazione prevede l immissione di un testo da ricercare e il modulo di information retrieval lo ricerca all interno dei documenti indicizzati. Nella ricerca avanzata l utente può affinare la ricerca specificando, in maniera puntuale, diverse ricerche sulle informazioni previste, siano esse informazioni esplicite del documento (contenute in esso) sia informazioni implicite (informazioni che sono inferite dal sistema o assegnate dagli operatori attraverso l uso di meta-dati). Le basi dati documentali possono essere alimentate in molti modi diversi. In particolare è possibile che i documenti siano inviati dai Tool utilizzando la cooperazione applicativa, esposti su pagine Web accessibili su Internet oppure inviati attraverso l uso dei servizi SOAP esposti dal modulo di information retrieval, previa autenticazione e autorizzazione del servizio Utilizzo dai S.I.L. compatibili I Tool compatibili si comportano esattamente come i Tool della Rete degli U.R.P. per l alimentazione delle basi dati documentali (anche per essi è possibile utilizzate la cooperazione applicativa, pubblicare i dati su pagine Web oppure invocare via SOAP i servizi centrali), fermo restando che possano utilizzare i servizi di information retriveal di ricerca e catalogazione nel modo più consono ai loro scopi Utilizzo dal portale centrale I servizi di Information Retrieval da parte del portale centrale avvengono in maniera analoga a quanto descritto in 3.2.1, con la differenza che l interrogazione (di tipo avanzato) prevede la possibilità di localizzare (sia specificando la tipologia che la localizzazione geografica) le sorgenti dell informazione ricercata. 3.4 Componente Gestione Modulistica L obiettivo di questa componente applicativa è quello di fornire un nuovo modello di gestione della modulistica, disegnando il sistema in tutte le sue fasi dalla produzione, alla diffusione, alla conservazione dei moduli, e non ultimo offrire al cittadino modalità semplici di interazione con la pubblica amministrazione. La Gestione della modulistica garantisce le funzioni di produzione, gestione e distribuzione della modulistica sia in forma cartacea che in forma elettronica. La compilazione on-line del modulo può essere eventualmente affiancata dalla firma digitale delle informazioni. Ciascun ente può creare i propri moduli e distribuirli in forma cartacea o elettronica ai propri cittadini. E inoltre possibile definire una casistica di moduli template, personalizzabili dagli operatori dei singoli URP. Da un punto di vista strettamente tecnologico la componente di gestione della modulistica verrà

13 13 di 33 utilizzata tramite due modalità: Modalità on line: la sezione di composizione grafica e le funzionalità ad essa strettamente correlate (ricerca e gestione dei layout grafici dei moduli e dei template) verranno utilizzate tramite un applicazione web residente su un server centralizzato di RT. Tale applicazione si compone essenzialmente dell applet di composizione grafica e di pagine html dinamiche per la ricerca e la gestione della modulistica e dei template. Accesso tramite web services Le funzionalità di aggancio dei moduli ad atti, schede, procedimenti e, in generale, le funzionalità di utilizzo della modulistica impostata e di gestione delle domande inoltrate saranno invece usufruibili attraverso opportuni web services (R.P.C.). Anche in questo caso i servizi saranno localizzati su un server centralizzato di RT Utilizzo dai S.I.L - Tool Rete degli U.R.P. Gli scopi principali della componente applicativa Gestione Modulistica, dal punto di vista funzionale, sono: offrire agli Enti uno strumento per la produzione e la gestione della modulistica di competenza dell U.R.P.; offrire agli Enti uno strumento per l associazione a procedimenti, schede, atti, della modulistica generata; permettere al cittadino di usufruire della modulistica all interno delle procedure relative ai procedimenti, schede, atti,. offrire agli Enti uno strumento per la gestione della domande inoltrate dai cittadini. I profili applicativi individuati (in questo caso coincidenti con gli attori descritti nei diagrammi UML presenti nei documenti di progetto relativi all analisi di Specifica Funzionale) sono i seguenti: Compositore di template Compositore di moduli Operatore di backoffice dei tool del singolo URP Operatore di frontoffice dei tool del singolo URP, ovvero il cittadino che interagisce con uno dei tool sopracitati.

14 14 di Le funzioni di Back Office Le funzioni di Back Office si articolano applicativamente come segue: Funzioni indipendenti dal Tool della Rete degli URP Produzione e gestione della modulistica tramite editor visuale

15 15 di Funzioni collegate al Tool della Rete degli URP Associazione moduli a procedimenti, schede, atti. Gestione delle richieste inoltrate dai cittadini

16 16 di Le funzioni di Front Office Le funzioni applicative di Front Office sono: Utilizzo della modulistica da parte del cittadino all interno delle procedure relative a procedimenti, schede, atti

17 17 di 33 4 La Cooperazione Applicativa 4.1 Identificazione delle funzionalità In questo capitolo è riportato l elenco di tutte le funzionalità individuate, previste dal sottosistema, così come concordate con il cliente sulla base della documentazione acquisita e degli impegni assunti in relazione alla fornitura. IDENTIFICATIVO FUNZIONALITA CA_F1_Aggiorna_Store CA_F2_Alimenta_IR CA_F3_Monitor CA_F4_Sicurezza DESCRIZIONE FUNZIONALITÀ Aggiornamento Store Centrale Alimentazione Piattaforma di gestione documentaria Monitoraggio Proxy applicativi e componenti centrali Sicurezza delle connessioni tra le componenti N.B. L identificativo della funzionalità consente una individuazione univoca della stessa e l associazione ad essa, attraverso dei progressivi numerici, di uno o più requisiti funzionali. 4.2 Use case diagram Di seguito, per ogni Funzionalità identificata al punto precedente, verrà data la descrizione dello Use Case diagram associato CA_F1_Aggiorna_Store Con Store centrale si identifica il DB centrale, cioè la base dati non documentale presente presso la Regione Toscana, ed il FS centrale, cioè il File System che sarà utilizzato per memorizzare centralmente i documenti inviati dalle BDD dei Tool compatibili. Tali documenti saranno utilizzati localmente dai Tool dalla rete degli URP presenti in Regione ed ai fini dell alimentazione del Modulo di Information Retrieval. IL DB centrale conterrà la totalità delle informazioni relative al complesso degli URP e, relativamente alle applicazioni sviluppate all interno del progetto, avrà una struttura identica a quelle operanti presso i singoli URP locali. Lo Use case è descritto dal seguente diagramma:

18 18 di 33 Nello Use case si identificano, oltre al CRIC al NAL ed al NAR, i SIL da cui partono gli aggiornamenti ed il SIR: Store centrale a cui gli aggiornamenti sono destinati. I SIL possono essere o SIL: DB (cioè SIL che gestiscono dati non documentari) o SIL: BDD (ovvero SIL che gestiscono dati documentari). I SIL: DB possono essere Tool rete degli URP o Tool compatibili. I SIL: BDD possono essere Tool rete degli URP o Tool compatibili. Con Tool compatibili si identificano Tool che gestiscono una BD e/o una BDD che tratta dati analoghi a quelli dei Tool della rete dell URP. Per i documenti gestiti dalle BDD compatibili, poiché non sono accedibili via Web come quelli dei Tool della Rete degli URP, sarà previsto un trattamento a parte.

19 19 di CA_F2_Alimenta_IR Il Caso di uso che modella l aggiornamento della piattaforma di gestione documentaria è illustrato nella figura seguente. La piattaforma di gestione documentaria è destinata a contenere i documenti del sistema in formato XML ai fini della loro indicizzazione ed Information Retrieval. Il Modulo IR sarà configurato, nel contesto dell architettura cooperativa, come un SIR che potrà cooperare con gli altri moduli dell architettura cooperativa attraverso il Nodo Applicativo locale della Regione (NAR). I proponenti svilupperanno per i servizi di base ed in particolare per il Modulo IR una interfaccia di servizi SOAP su HTTPS in modo da renderlo accedibile sia dal modulo Web del Portale della rete degli URP che dagli applicativi degli enti. Una seconda interfaccia SOAP su HTTPS sarà utilizzata per la cooperazione tra Modulo IR e NAR, in particolare per consentire al NAR di alimentare via web Services la base dati normalizzata di interscambio documenti tra il NAR ed il Modulo di IR. Alla base di questa ipotesi infatti c è la realizzazione di una base dati normalizzata (data base o file system) di servizio esclusivo per il Modulo IR. Tale base dati, interna al SIR: Modulo IR, è destinata a contenere tutti i dati documentari pubblicati dalle varie BDD periferiche tramite i meccanismi della cooperazione applicativa. q q q Il Modulo di IR necessita di essere alimentato con documenti provenienti dalle seguenti sorgenti di informazione: BDD di Tool della rete degli URP BDD di Tool compatibili BDD di altri Tool locali Le BDD dei Tool della rete dell URP, le BDD dei Tool compatibili e quelle dei Tool locali, utilizzando la modalità standard di richiesta di pubblicazione al NAL, pubblicano direttamente i dati documentari variati. (Per gli Enti locali che hanno solo un sito statico potrà essere realizzata una semplice

20 20 di 33 applicazione web con cui il gestore del sito potrà prelevare i nuovi documenti dal sito e pubblicarli via SOAP su HTTPS, secondo la modalità standard definita nel progetto per gli altri Tool dinamici) CA_F3_Monitor Tra le componenti a livello di CRIC vi è il Modulo di monitoraggio complessivo dei proxy applicativi. Il Modulo complessivo, interagendo secondo un protocollo da concordare con i Moduli di monitoraggio dei Proxy applicativi, è responsabile del monitoraggio complessivo della rete dei Proxy applicativi dedicati alla rete degli URP. Il Modulo rende disponibili informazioni di interesse quali il numero degli aggiornamenti inviati da ciascun proxy, il numero di errori etc. Il Modulo centrale è inoltre responsabile del monitoraggio delle componenti centrali del sistema Modulo IR ed Modulo GM. Questi scenari sono sintetizzati nel seguente Caso di uso CA_F4_Sicurezza Dovranno essere rispettati i seguenti requisiti non funzionali relativi alla sicurezza : Le comunicazioni SIL-NAL e NAL-CRIC non devono essere osservabili da terzi durante il loro transito nella rete; Ogni ricevitore di messaggi transitanti in rete deve essere in grado di determinare l identita del mittente; Ogni ricevitore di messaggi transitanti in rete deve essere in grado di accertare che i dati ricevuti non siano stati alterati nel trasferimento. Il requisito non funzionale 1 viene risolto utilizzando i protocolli di trasporto HTTPS/SSL 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 possedere 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

21 21 di 33 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 del messaggio SOAP viene utilizzato dal ricevente per scopi di non ripudio. Il Caso di uso che descrive questo scenario è illustrato di seguito. La sicurezza tra NAL e CRIC è garantita dalla componente standard del NAL, il Message Handler fornito dalla Regione Toscana che garantisce l autenticazione e l autorizzazione del Proxy applicativo. SIL e SIR utilizzano Client SOAP per richiedere servizi al Proxy. Il Proxy utilizza un Server SOAP per esportare servizi ai SIL ed ai SIR. Il Proxy utilizza un Client SOAP per consegnare ai SIL i messaggi da loro sottoscritti. I SIL SIR utilizzano un Server SOAP per esportare servizi al Proxy. La gestione di connessioni sicure tra SIL/SIR e Proxy applicativo è garantita dall uso del protocollo SOAP su HTTPS con uso di certificati. 4.3 Modello dinamico Facendo riferimento al deploy diagram seguente, vengono descritti le responsabilita dei componenti principali individuati per l'implementazione delle funzionalita' identificate al capitolo precedente.

22 22 di CA_F1_Aggiorna_Store 1. Per aggiornare lo Store Centrale, ogni SIL, sia esso un tool della rete degli URP, un tool compatibile o un tool locale, invoca un servizio JAX-RPC esposto dal proxy reteurp_publiservice presente sul NAL. 2. Dopo aver validato il messaggio ed aver adattato l'informazione al formato richiesto, il proxy consegna al framework CA il messaggio. 3. Il messaggio viene consegnato al broker sul CRIC, il quale provvede, tramite le componenti frameworkca presenti sui nodi applicativi, a diffonderlo a tutti i proxy che ne hanno richiesto la sottoscrizione. 4. La componente frameworkca presente sul NAR riceve il messaggio e lo consegna al proxy associato allo store centrale, reteurp_storeproxy. 5. reteurp_storeproxy ritrasforma l'informazione ottenuta nel suo formato originale, ne stralcia eventuali documenti allegati, e la consegna al modulo urpstorecentrale tramite l'invocazione di un servizio da esso esposto.

23 23 di Il modulo urpstorecentrale aggiorna lo store CA_F2_Alimenta_IR 7. Per aggiornare lo Store Centrale, ogni SIL, sia esso un tool della rete degli URP, un tool compatibile o un tool locale, invoca un servizio JAX-RPC esposto dal proxy reteurp_publiservice presente sul NAL. 8. Dopo aver validato il messaggio ed aver adattato l'informazione al formato richiesto, il proxy consegna al framework CA il messaggio. 9. Il messaggio viene consegnato al broker sul CRIC, il quale provvede, tramite le componenti frameworkca presenti sui nodi applicativi, a diffonderlo a tutti i proxy che ne hanno richiesto la sottoscrizione. 10. La componente frameworkca presente sul NAR riceve il messaggio e lo consegna al proxy associato allo modulo centrale IR, reteurp_irproxy. 11. reteurp_irproxy ritrasforma l'informazione ottenuta nel suo formato originale, ne estrae eventuali documenti allegati che consegna al modulo centrale IR tramite l'invocazione di un servizio che esso espone. 12. Il modulo centrale IR aggiorna la propria base di dati documentaria.

24 24 di CA_F3_Monitor Per realizzare il Sistema di monitoraggio complessivo si dovrà provvedere a strumentare gli oggetti da monitorizzare con compoenti software in grado di interagire con il Sistema centrale di monitoraggio secondo un protocollo da concordare. L architettura che implementa il Sistema di monitoraggio è descritta dal seguente Collaboration diagram.

25 25 di 33 Il Sistema di Monitoraggio, tramite una console centralizzata mette a disposizione funzioni di monitoraggio e controllo del Proxy Applicativo e dei sistemi centralizzati (Store centrale, Modulo IR e Modulo GM). Inoltre, mette a disposizione un sistema di notifica, per la comunicazione, da parte degli oggetti monitorati, di eventi significativi. I Proxy applicativi e le componenti centrali del sistema esporranno i propri servizi in modo che siano gestibili in maniera uniforme dal sistema centrale di monitoraggio, secondo gli standard attuali in materia di management di applicazioni. In particolare i Proxy applicativi e le componenti centrali del sistema: esporranno dati utili al monitoraggio preventivo (stato risorse, file di log, ecc.) solleveranno, quando opportuno, eventuali eventi di notifica di stato critico di una risorsa. potranno essere manipolati in remoto I servizi saranno esposti tramite JMX (Java Management extensions) in modo che possano essere monitorati (SNMP, JMX) e gestiti attivamente (JMX), tramite diversi protocolli, all'interno delle soluzioni standard di Regione Toscana (Petra + CART) CA_F4_Sicurezza La gestione della sicurezza del sistema riguarda sia la sicurezza degli accessi ai servizi del sistema da parte dei differenti attori che la sicurezza della cooperazione tra le componenti software del sistema. Le architetture che supportano la sicurezza degli accessi (autorizzazione ed autenticazione) ai servizi del sistema da parte dei differenti attori sono state illustrate precedentemente al paragrafo In quel paragrafo è stato descritto come l autenticazione sarà garantita dal Gestore centrale dei ruoli mentre l autorizzazione sarà garantita dal Sistema di profilazione del modulo SRTY con cui sarà implementato il Portale della rete degli URP. Per quamto concerne la sicurezza nella cooperazione tra le componenti software del sistema, si osserva che queste vengono concentrate in tre punti distinti del NAL-NAR: nel modulo di interfacciamento tra Front end del Proxy Applicativo e SIL, nel modulodi interfacciamento tra Back end del Proxy e Message Handler ed infine, nel modulo di interfacciamento tra NAL e CRIC, il Message Handler. La sicurezza tra NAL e CRIC è garantita dalla componente standard del NAL, il Message Handler fornito dalla Regione Toscana che garantisce l autenticazione del e l autorizzazione del Proxy applicativo. Rimane quindi da descrivere l architettura del modulo che garantisce la sicurezza delle connessioni tra Front end del Proxy Applicativo e SIL e tra Back end del Proxy applicativo e message Handler. Il Caso di uso che descrive questo scenario è illustrato di seguito.

26 26 di Sicurezza tra Front end del Proxy e SIL/SIR Il collaboration diagram è il seguente: SIL e SIR utilizzano Client SOAP per richiedere servizi al Proxy. Il Proxy utilizza un Server SOAP per esportare servizi ai SIL ed ai SIR. Il Proxy utilizza un Client SOAP per consegnare ai SIL i messaggi da loro sottoscritti. I SIL SIR utilizzano un Server SOAP per esportare servizi al Proxy. La gestione di connessioni sicure tra SIL/SIR e Proxy applicativo è garantita dall uso del protocollo SOAP su HTTPS con uso di certificati.

27 27 di Sicurezza tra Back end del Proxy e Message Handler Sicurezza del Back end 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: messaggi comunicati tra NAL e CRIC non possono essere osservati da terzi mentre viaggiano sulla rete. 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. 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 possedere 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 del messaggio SOAP viene utilizzato dal ricevente per scopi di non ripudio. Message Control CA Sono stati individuati i seguenti punti che, implementati durante il progetto, garantiscono la sicurezza delle transazioni nella gestione degli eventi di Cooperazione Applicativa: Protezione del canale. Il canale di comunicazione tra NAL e CRIC deve essere protetto tramite encryption. 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. 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. 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. I messaggi ricevuti dovranno essere memorizzati dal NAL ricevente in modo da poter assicurare il non ripudio del messaggio stesso. Pubblicazione Eventi Il Proxy Applicativo, per ogni variazione estrapolata, prepara un messaggio in formato SOAP e lo consegna al Message Handler CA (appartenente al FrameWork CA). Tale messaggio è conforme al contenuto della busta di e-toscana e contiene inoltre il certificato digitale del NAL. Il Message Handler CA, per ogni messaggio ricevuto, ritornerà l'acknowledge indicante la presa in

28 28 di 33 carico dell'evento. Il Proxy Applicativo consegna il messaggio alla componente del Framework CA denominata Message Handler CA. Il Message Handler CA effettua tutti i controlli necessari relativi al messaggio. Successivamente, in caso di esito positivo, si occupa di inviare al CRIC il contenuto SOAP mediante JMS. Il JMS Broker (componente del Framework CA), a seguito della ricezione di un messaggio di evento da parte di un NAL si occupa di reperire l'insieme dei NAL destinatari (subscriber dell'evento) e di spedire ad essi tale messaggio. Ogni Message Handler CA ricevente il messaggio attiva la procedura di controllo del messaggio pervenuto. In caso di responso positivo il messaggio SOAP viene consegnato al Proxy Applicativo. Quest'ultimo si occupa di inviare ai SIL destinatari il messaggio. Controllo Messaggio Un primo flusso (scenario Invio ) è relativo alla consegna del messaggio SOAP al Message Handler da parte del Proxy Applicativo. Il primo, una volta preso in consegna il messaggio SOAP chiama in causa la componente Message Control CA che effettuerà le seguenti attività: Elaborazione del messaggio pervenuto estrapolando la firma digitale. Verifica dell'autenticità del sender (controllo sulla firma). Verifica se il SIL, relativamente all'evento in questione, è autorizzato (utilizzando il repository presente sul CRIC). Validazione del contenuto della busta di e-toscana. Il secondo flusso (scenario Ricezione ) riguarda invece l'attività di ricezione di un evento da parte del Message Handler CA. In tal caso il messaggio ricevuto dal CRIC è destinato a controllo mediante l'utilizzo della componente Message Controller CA che compierà i seguenti passi: Verifica del contenuto della busta e-toscana. Reperimento dell'insieme dei SIL destinatari dell'evento (mediante utilizzo del Repository presente sul CRIC). Arricchimento del contenuto SOAP originale dell'elenco dei destinatari. Il contenuto SOAP arricchito è finalmente restituito al Message Handler. Notifica eventi Il nodo NAL pubblicatore, 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 al CRIC il messaggio. Il componente JMS Provider, che avrà il compito di gestire i messaggi tra il NAL pubblicatore e NAL sottoscrittore, riceve il messaggio JMS e si occupa di spedirlo al NAL sottoscrittore. Il componente "Message Handler CA" del NAL sottoscrittore, 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à. 4.4 Modello statico Il modulo della cooperazione applicativa della rete degli URP e costituito da quattro packages. it.jada.reteurp.ca, che contiene classi di uso comune degli altri tre packages; it.jada.reteurp.ca.pubproxy che costituisce il proxy pubblicatore dislocato sui NAL a disposizione dei tools della rete degli URP e dei tools compatibili;

29 29 di 33 it.jada.reteurp.ca.irproxy che costituisce il proxy sottoscrittore dislocato sul NAR e associato al modulo centrale IR; it.jada.reteurp.ca.storeproxy che costituisce il proxy sottoscrittore dislocato sul NAR e associato allo store centrale. Nel diagramma seguente viene sintetizzato il contesto programmativo in cui si colloca il modulo :

30 30 di package it.jada.reteurp.ca Questo package definisce alcune classi usate dagli altri packages. In particolare viene definito uno schema comune di proxy predisposto per il monitoraggio (AbstractProxyMonitor) con associato un AbstractMBean. Da queste classi verranno derivate le classi principali che realizzano i proxy della rete degli URP. Vengono inoltre definite alcune classi minori usate da piu di uno degli altri packages package it.jada.reteurp.ca.pubproxy Costituisce il proxy pubblicatore dislocato sui NAL a disposizione dei tools della rete degli URP e dei

31 31 di 33 tools compatibili. Espone il servizio di pubblicazione in due forme. Una forma base, publish, per pubblicare un evento, ed una forma estesa, publishwattach, per pubblicare un evento nel caso che esso debba essere corredato da un certo numero di allegati.

32 32 di package it.jada.reteurp.ca.storeproxy

33 33 di package it.jada.reteurp.ca.irproxy