Specifiche tecniche lotto 3

Transcript

1 Specifiche tecniche lotto 3 ALLEGATO AL CAPITOLATO TECNICO PER L ESPLETAMENTO DI SERVIZI INFORMATICI PER LA PROGETTAZIONE, REALIZZAZIONE E MANUTENZIONE DI PRODOTTI SOFTWARE PER IL SISTEMA INFORMATIVO RETE dei SUAP

2 SOMMARIO INTRODUZIONE...3 NECESSITÀ DI SVILUPPARE IL SISTEMA...3 Il progetto Rete dei SUAP si pone i seguenti obiettivi... 3 BENEFICI ATTESI:...3 Per le Aziende... 3 Per gli Enti Locali...4 Per la Regione... 4 ANALISI DEI RISCHI...4 DOCUMENTI DI RIFERIMENTO...5 ANALISI...6 ATTORI...6 Glossario...7 CASI D USO...8 Use cases diagram INTERACTION DIAGRAM Costruzione e mantenimento del catalogo (Int1) Attivazione di un procedimento (Int2) Notifica autorizzazione/richiesta parere (Int3) Monitoraggio del procedimento (Int4) Gestione Utenza Servizio di monitoraggio accessi ed operazioni Descrizione funzionalità delle classi PIATTAFORMA TECNOLOGICA Component diagram Deployment diagram Firenze Pagina 2 di 36

3 INTRODUZIONE Il sistema Con la messa in opera degli sportelli SUAP i comuni hanno assolto agli obblighi di legge (art. 24, comma 2, decreto legislativo n. 112/98), ma il loro esercizio ha reso evidenti le carenze di un sistema disegnato stand-alone verso un problema che oramai è diventato un problema di rete. Infatti è sempre fatto più comune che le Aziende tendano a distribuire le loro attività industriali e commerciali compatibilmente con le esigenze del territorio ma con criteri sempre più orientati alla ricerca della redditività. Quindi la Regione Toscana ha deciso di superare le carenze intrinseche della logica dei SUAP istituzionali impostando un progetto che aiuti gli enti e le associazioni di categoria a superare i problemi fin qui incontrati. Obiettivi coordinare i progetti SUAP territoriali allargati alla gestione delle autorizzazioni commerciali: identificare e normalizzare un Protocollo procedurale con gli enti terzi; identificare e pubblicare le Best Practices sui procedimenti amministrativi; costituzione di un tavolo di verifica e competenze per procedimenti; Benefici attesi I benefici che si potranno trarre sono di facile comprensione: per le Aziende possibilità di avere un unico punto di contatto con l amministrazione pubblica possibilità di poter valutare contestualmente opportunità di localizzazione industriale/commerciale e finanziamenti ottenibili Firenze Pagina 3 di 36

4 per gli Enti Locali: fornire un servizio di qualità alle aziende; semplificare l interazione con gli enti terzi; poter attingere ad un repository di end o procedimenti ( template ) da personalizzare in base alle proprie esigenze; poter scambiare le loro esperienze al tavolo delle competenze; per la Regione Controllare il flusso e la qualità degli investimenti regionali; Supportare il management con report di qualità; Incrementare la propria competenza applicativa ; Analisi dei rischi nodo critico\livello di problematicità basso medio alto Organizzativo: disattesa delle implementazioni tecnologiche Organizzativo: disattesa degli impegni organizzativi X X Firenze Pagina 4 di 36

5 Documenti di riferimento 1. E-government Progetto C4 Rete Regionale dei SUAP reperibile alla url: 2. Documento Infrastruttura per la cooperazione operativa CART (allegato 2) 3. Documento Standard regionali per le tecnologie dell informazione (allegato 2) Firenze Pagina 5 di 36

6 ANALISI Questo capitolo analizza i processi relativi al progetto "Rete dei SUAP". Per la descrizione di questi processi faremo uso della notazione UML (Unified Modeling Language). Acronimi SUAP: Sportello Unico per le Attività Produttive SIL: Sistema Informativo Locale CRIC: Centro Regionale per l'interoperabilità e la Cooperazione NAL: Nodo Applicativo Locale CAC: Componente Applicativo Centrale Attori Prima di modellare il processo, definiamo il contesto in cui esso opera, identificando gli attori che dovranno interagire a vario titolo con il sistema. Con il termine Attore intendiamo una qualunque entità (persona, ente, ufficio, sistema informatico) che dovrà interagire con il sistema in esame. I principali attori sono riportati nella seguente tabella Nome acronimo descrizione Impresa o Delegato IM Soggetto che attiva presso il SUAP del comune territorialmente competente la richiesta di una pratica autorizzativa. Ente Terzo ET Ente pubblico titolare per competenza territoriale di un endoprocedimento. Regione RE Ente che si occupa di monitorare lo stato della rete dei SUAP. Firenze Pagina 6 di 36

7 Comune CO Ente titolare del SUAP. Tavolo Tecnico TT Organo collegiale preposto alla definizione e al mantenimento del catalogo dei procedimenti Portatori di Interessi diffusi PI Soggetto singolo o associazione che è interessata alla conoscenza delle procedure amministrative L'esposizione degli attori ha introdotto una serie di termini spiegati di seguito. Glossario Pratica: insieme dei documenti relativi ad uno stesso caso. Procedimento: insieme di endoprocedimenti volto a produrre un atto autorizzativo finale. Endoprocedimento: attività svolta da un ente terzo o struttura interna al comune diversa dal SUAP che produce un atto. Firenze Pagina 7 di 36

8 Casi d uso I casi d'uso rappresentano processi supportati dal sistema o funzioni del sistema stesso. Per ogni caso d uso, per agevolare la comprensione del testo, sono riportate tra parentesi attività non sono supportate direttamente dal caso d'uso stesso. nome obiettivi attori dati in ingresso attività Costruzione e mantenimento del Catalogo Il processo si pone l'obiettivo della strutturazione di un Repository nel quale vengono raccolti tutti i procedimenti amministrativi in capo ad un tipico SUAP; tale strutturazione prevede anche la definizione delle informazioni che vengono scambiate per il monitoraggio del procedimento. TT Normativa specifica sul set di attività produttive; regolamenti applicativi di livello Comunale, Regionale e Nazionale. Per ogni procedimento gestisce: risultati prodotti Repository: note 1. il set di endoprocedimenti; 2. la modulistica correlata 3. il set di dati per la comunicazione tra enti. dei procedimenti e della modulistica correlata del protocollo di colloquio INTERSUAP ; tale protocollo regola la notifica degli eventi amministrativi che intervengono tra Comune e l insieme degli Enti Terzi per il rilascio di un autorizzazione. degli stati di avanzamento (Meta-iter) Firenze Pagina 8 di 36

9 nome obiettivi attori dati in ingresso attività Notifica attivazione di un procedimento Questo processo supporta l'attivazione di una pratica al SUAP, per quanto concerne la notifica da parte del Comune (SUAP) a Regione dell attivazione di una pratica. CO, RT, (IM) Istanza del protocollo INTERSUAP specifico per l'avvio della singola pratica 1. (IM presenta una pratica presso CO); 2. CO cerca il procedimento nel catalogo; 3. (CO avvia il procedimento scelto); 4. CO comunica l'inizio del procedimento a RT; risultati prodotti Popolamento del repository Meta-iter. note Nel punto 2. si individua un punto di interfaccia (profiling e identificativo del procedimento) con il sistema informativo locale allo specifico SUAP. nome obiettivi attori dati in ingresso attività risultati prodotti note Notifica richiesta parere Questo processo supporta richiesta di parere del Comune ad un Ente Terzo, per quanto concerne la notifica da parte del Comune a Regione della richiesta di un parere CO, RT,(ET) Istanza del protocollo INTERSUAP specifico per la richiesta di pareri. 1) CO cerca il procedimento/endoprocedimento nel catalogo; 2) (CO avvia l'endoprocedimento scelto ); 3) (CO invia la comunicazione a ET ); 4) CO comunica la richiesta di parere 5) RT che registra gli estremi della richiesta Popolamento del repository meta-iter. Firenze Pagina 9 di 36

10 nome obiettivi attori dati in ingresso attività risultati prodotti note Notifica espressione di parere Questo processo supporta la fornitura di un parere dell Ente Terzo ad un Comune, per quanto concerne la notifica da parte dell Ente Terzo a Regione dell espressione di un parere ET, RT, (CO) Lista dei procedimenti su cui ET deve esprimere un parere. 1) ET sceglie un procedimento che ha in carico; 2) (ET esprime un parere); 3) ET comunica l espressione del parere ad RT 4) RT registra gli estremi del parere Popolamento del repository meta-iter. Gli ET possono non essere dotati di un SIL ; ne consegue che l'espressione del loro parere deve avvenire tramite strumenti forniti loro dalla infrastruttura regionale. E' opportuno prevedere modalità alternative di erogazione del servizio quali tipicamente i servizi Web - based. nome obiettivi attori dati in ingresso attività Notifica conclusione di un procedimento Questo processo supporta l'attivazione di una pratica al SUAP, per quanto concerne la notifica da parte del Comune (SUAP) a Regione della conclusione di una pratica. CO, RT Istanza del protocollo INTERSUAP specifico per la conclusione della singola pratica 1 CO cerca il procedimento nel catalogo; 2 CO comunica la fine del procedimento a RT; risultati prodotti Popolamento del repository Meta-iter. note Nel punto 1 si individua un punto di interfaccia (profiling e identificativo del procedimento) con il sistema informativo locale allo specifico SUAP. Firenze Pagina 10 di 36

11 nome obiettivi attori dati in ingresso Monitoraggio del procedimento Supporto alle funzioni conoscitive relative ai procedimenti attivati sul territorio regionale. RT, PI, IM, ET, CO Repository: dei procedimenti della modulistica correlata del protocollo di colloquio INTERSUAP di colloquio Comune con un altro Comune; degli stati di avanzamento (meta-iter) ; i dati saranno corredati del relativa georeferenziazione. Credenziali di accesso al sistema per la definizione del ruolo svolto dall'attore. attività 1. IM (PI,RT) cerca un set di procedimenti presso RT; 2. ottiene informazioni sull'iter dei procedimenti individuati. risultati prodotti Servizio di reporting, in funzione del profilo e del ruolo dell'attore. Le modalità con cui il servizio verrà reso sono di tipo on-line o batch. note Firenze Pagina 11 di 36

12 nome obiettivi attori dati in ingresso Gestione Utenza Supporto al procedimento di gestione delle utenze dei loro profili e ruoli ed eventuali meccanismi di delega. RT - Dati identificativi contenuti nel certificato digitale - Database utenze del sistema attività 1. definisce gli utenti ed i profili del sistema 2. associa ad ogni utente un profilo 3. eventualmente gli delega (totale o parziale) funzionalità di un altro utente risultati prodotti Popolamento e gestione del database utenze del sistema. note Firenze Pagina 12 di 36

13 nome obiettivi attori dati in ingresso attività Servizio di monitoraggio accessi ed operazioni. Monitoraggio degli aspetti tecnici del sistema informativo RT - log del nodo che ospita il sistema informativo 1. sceglie un utente (profilo) del sistema; 2. visualizza il numero di accessi e operazioni associate all'utente (profilo). risultati prodotti Report e sistema di segnalazioni di anomalie e/o malfunzionamenti. note Firenze Pagina 13 di 36

14 USE CASES DIAGRAM TT costruzione e mantenimento del catalogo PI monitoraggio del procedimento IM Notifica attivazione di un procedimento Notifica richiesta parere CO Notifica espressione parere RT ET Notifica conclusione di un procedimento gestione utenza servizio di monitoraggio accessi e operazioni Firenze Pagina 14 di 36

15 INTERACTION DIAGRAM Al fine di introdurre l'architettura software di riferimento si produce per ogni caso d'uso un interaction diagram. L'interaction diagram introduce a sua volta le classi chiave che descrivono il sistema e i messaggi che vengono scambiati tra questi durante lo svolgimento del caso d'uso. COSTRUZIONE E MANTENIMENTO DEL CATALOGO (INT1) utente gestore sicurezza dizionario procedimento profilo=presenta( credenziali) [profilo=tt]crea(endoprocedimento,modulistica,dati) Firenze Pagina 15 di 36

16 NOTIFICA DI ATTIVAZIONE DI UN PROCEDIMENTO (INT2) utente gestore sicurezza SUAP Regione Toscana profilo=presenta( credenziali) [profilo=co] idpratica=nuovapratica( pratica) procedimento=nuova( pratica) registrazione( procedimento) Firenze Pagina 16 di 36

17 NOTIFICA RICHIESTA PARERE (INT3) utente gestore sicurezza SUAP Regione Toscana profilo=presenta(credenziali) [profilo=co]completa(pratica,procedimento) notifica(pratica, procedimento) registrazione(procedimento) Firenze Pagina 17 di 36

18 NOTIFICA ESPRESSIONE DI PARERE (INT4) utente gestore sicurezza Ente terzo Regione Toscana profilo=presenta(credenziali) [profilo=et]completa(pratica,procedimento) notifica(pratica, procedimento) registrazione(procedimento) Firenze Pagina 18 di 36

19 NOTIFICA CONCLUSIONE PROCEDIMENTO (INT5) utente gestore sicurezza SUAP Regione Toscana profilo=presenta(credenziali) [profilo=co]concludi(pratica,procedimento) notifica(pratica, procedimento) registrazione(procedimento) Firenze Pagina 19 di 36

20 MONITORAGGIO del procedimento (INT6) utente gestore sicurezza Regione Toscana profilo=presenta(credenziali) [profilo=im,rt] set_procedimenti=ricerca( criterio) GESTIONE UTENZA (INT7) utente gestore sicurezza Regione Toscana profilo=presenta( credenziali) [profilo=rt]definisci(utente,profilo,delega) Firenze Pagina 20 di 36

21 SERVIZIO DI MONITORAGGIO ACCESSI ED OPERAZIONI (INT8) utente gestore sicurezza Regione Toscana profilo=presenta( credenziali) [profilo=rt]informazioni=getinformazioni() Firenze Pagina 21 di 36

22 DESCRIZIONE FUNZIONALITÀ DELLE CLASSI Le specifiche componenti oggetto di descrizione nel presente documento sono: Componenti a livello di Nodo Applicativo Locale (NAL) Proxy Locale: 1. modulo per la sicurezza 2. modulo per interfacciamento verso i Sistemi Informativi Locali (SIL) 3. modulo per interfacciamento verso agente locale 4. modulo di monitoraggio Componenti a livello di Centro Regionale per l'interoperabilità e la Cooperazione Applicativa (CRIC) CAC: 1. modulo di interfacciamento verso il CRIC 2. modulo di interfacciamento verso il Data Base 3. modulo di monitoraggio complessivo della rete dei Proxy Applicativi WWW: 1. modulo per la gestione della sicurezza; 2. modulo per la gestione del Repository e Registry dei procedimenti; 3. modulo per la ricerca di pratiche con criteri di ricerca sensibili al profilo utente (Metaiter); 4. modulo per la gestione di procedimenti Descriviamo di seguito le classi destinate a realizzare i componenti sopra elencati. Firenze Pagina 22 di 36

23 UTENTE Rappresenta un generico utente del sistema. Rappresenta un generico utente tramite gli attributi relativi alla sicurezza che identificano : un NAL o un utente Web l'operazione che dovrà essere effettuata. rispondendo perciò all esigenza di individuare l identità dell attore e le sue necessita. Gli attributi di sicurezza necessari per identificare gli utenti sono quelli identificati attraverso il modulo di Gestione Sicurezza. Tutte le volte che il SIL interagisce con il "Proxy Locale" dovrà presentare un messaggio XML contenente le credenziali. Il "Proxy Locale" crea il corrispondente oggetto, esamina le le credenziali esibite e se opportuno prosegue il colloquio; ovvero se le informazioni relative alla sicurezza sono compatibili con quelle relative alla operazione da invocare effettua l'operazione richiesta interagendo con un oggetto della classe "SUAP". Viceversa, quando il "Proxy Locale" riceve dati dal NAL crea un oggetto di classe Utente il quale istanzia a sua volta un messaggio XML secondo il formato concordato con il SIL. L'oggetto della classe Utente trasmette il messaggio XML creato rendendolo disponibile secondo una delle modalità di interfacciamento previste dal CART. Di fatto, questo oggetto risulta essere l'unico punto di contatto tra SIL e NAL e dovrà essere implementato sia nel componente Proxy Locale sia nel componente WWW. Firenze Pagina 23 di 36

24 Gestione Sicurezza Rappresenta la gestione del processo di autenticazione ed autorizzazione. La classe in questione implementa tutte le funzionalità necessarie al processo di autenticazione e di autorizzazione realizzando le interfacce che consentono di interagire con il NAL. Al momento della creazione di un oggetto della classe "Utente" verrà utilizzato un oggetto della classe "Gestore Sicurezza" per stabilire se l'operazione richiesta è congruente con la politica di sicurezza. Questo oggetto dovrà essere realizzato sia nel componente "Proxy Locale" che nel componente "WWW". Dizionario Procedimento Rappresenta la gestione del catalogo dei procedimenti e della modulistica associata. (Int1) La creazione e la successiva gestione del catalogo procedimenti dovrà avvenire in modalità on-line erogata quindi via Web. La modalità on-line dovrà consentire le operazioni di inserimento, gestione e consultazione e provvedere ad eventuali modifiche al Registry dei Procedimenti. La modalità on-line verrà realizzata nel componente "WWW" in collaborazione con la componente "CAC". SUAP È la classe che realizza le funzionalità di notifica dello stato dell endoprocedimento al fine di aggiornare il Meta-iter dei procedimenti. Essa sarà implementata sia nel componente "Proxy Locale" che nel componente "WWW". La classe SUAP resa anche nel contesto del componente "WWW" consente la fruibilità del Sistema anche in contesti organizzativi in cui non è previsto l utilizzo della modalità di cooperazione applicativa. Notifica Attivazione di un Procedimento. (Int2) La presentazione della pratica autorizzativa avviene allo sportello SUAP presso il Comune. Firenze Pagina 24 di 36

25 Tale evento amministrativo dà luogo alla Notifica dell attivazione di un procedimento ovvero il "Proxy Locale" cerca la descrizione del corrispondente procedimento nel "Registry dei Procedimenti"; genera il messaggio XML con gli appropriati contenuti, e lo trasmette alla corrispondente componente centrale. Questa operazione sarà invocata da un oggetto della classe "Utente" ad un oggetto della classe "SUAP". Notifica richiesta parere/autorizzazione (Int3). La richiesta da parte di un Comune ad un Ente Terzo di un parere o autorizzazione si traduce nella notifica di un evento da Comune a Ente Terzo. Per fare ciò il "Proxy Locale" cerca la descrizione del corrispondente endoprocedimento nel "Registry dei Procedimenti"; genera il messaggio XML con gli appropriati contenuti, e lo trasmette alla corrispondente componente centrale. Questo operazione sarà invocata da un oggetto della classe "Utente" ad un oggetto della classe "SUAP". Notifica conclusione procedimento. (Int5) Quando un Comune completa il procedimento, indipendentemente dall'esito, deve notificare l'evento relativo ad RT. Per fare ciò il "Proxy Locale" cerca la descrizione del corrispondente endoprocedimento nel "Registry dei Procedimenti"; genera il messaggio XML con gli appropriati contenuti, e lo trasmette alla corrispondente componente centrale. Questo operazione sarà invocata da un oggetto della classe "Utente" ad un oggetto della classe "SUAP. Regione Toscana È la classe che realizza le funzionalità di registrazione degli stati di avanzamento dei procedimenti/endoprocedimenti in un database. Essa sarà implementata sia nel componente "CAC" che nel componente "WWW". La classe RegioneToscana resa anche nel contesto del componente "WWW" consente la fruibilità del Sistema anche in contesti organizzativi in cui non è previsto l utilizzo della modalità di cooperazione applicativa. Notifica Attivazione di un Procedimento. (Int2) I messaggi XML, ricevuti dalla componente centrale, contenenti la notifica di attivazione di un procedimento vengono elaborati da oggetti della classe "Regione Toscana" al fine di aggiornare il Metaiter. Firenze Pagina 25 di 36

26 Il "CAC" dovrà implementare le interfacce del CRIC per l'utilizzo della cooperazione applicativa e registrare l'evento in un Data Base predisposto. Il procedimento dovrà essere individuabile anche tramite l'identificativo della pratica. Notifica richiesta parere/autorizzazione (Int3). I messaggi XML, ricevuti dalla componente centrale, contenenti la notifica di richiesta parere/autorizzazione vengono elaborati da oggetti della classe "Regione Toscana" al fine di aggiornare il Metaiter. Il "CAC" dovrà implementare le interfacce del CRIC per l'utilizzo della cooperazione applicativa e registrare l'evento in un Data Base predisposto. Notifica conclusione procedimento. (Int5) I messaggi XML, ricevuti dalla componente centrale, contenenti la notifica di conclusione di un procedimento vengono elaborati da oggetti della classe "Regione Toscana" al fine di aggiornare il Metaiter. Il "CAC" dovrà implementare le interfacce del CRIC per l'utilizzo della cooperazione applicativa e registrare l'evento in un Data Base predisposto. Monitoraggio del procedimento. (Int6) Tramite criteri di ricerca concordati e sensibili al ruolo dell'utente si effettua la ricerca di un set di pratiche. Questa funzionalità dovrà essere realizzata nel componente WWW. Gestione utenza (Int7) Le funzionalità di gestione degli utenti saranno realizzate dal componente WWW utilizzando le interfacce predisposte sul CRIC. Servizio di monitoraggio accesso ed operazioni (Int8) I report statistici dovranno consentire il monitoraggio : 1. dello stato dell'applicazione dal punto di vista sistemistico interfacciandosi con apposite funzionalità poste sul CRIC; 2. una misura dell'utilizzo dell'applicazione da parte di ogni singolo NAL utilizzando apposite funzionalità poste sul NAL; 3. una misura dell'utilizzo dell'applicazione da parte di ogni Ente Terzo e Comune. Firenze Pagina 26 di 36

27 Di ausilio alle reportistica potranno essere usati i servizi di georeferenziazione attualmente implementati presso la Regione Toscana. Queste funzionalità saranno realizzate dal componente WWW (vedi apposito diagramma). Ente Terzo È una classe che realizza le funzionalità di notifica dello stato al fine di aggiornare il Metaiter dei procedimenti. Essa sarà implementata sia nel componente "Proxy Locale" che nel componente "WWW". La classe "Ente Terzo" resa anche nel contesto del componente "WWW" consente la fruibilità del Sistema anche in contesti organizzativi in cui non è previsto l utilizzo della modalità di cooperazione applicativa. Notifica espressione di parare (Int4). L'espressione di un parere da parte di un Ente Terzo ad un Comune si traduce nella notifica di un evento da Ente Terzo a Comune. Per fare ciò il "Proxy Locale" cerca la descrizione del corrispondente endoprocedimento nel "Registry dei Procedimenti"; genera il messaggio XML con gli appropriati contenuti, e lo trasmette alla corrispondente componente centrale. Questo operazione sarà invocata da un oggetto della classe "Utente" ad un oggetto della classe "Ente Terzo". Firenze Pagina 27 di 36

28 PIATTAFORMA ARCHITETTURALE La comunicazione delle richieste di pareri e/o autorizzazioni (da Comune verso Ente Terzo) e successiva comunicazione di risposta (da Ente Terzo verso Comune) si configura come un accoppiamento tra i rispettivi sistemi informativi. Da un punto di vista organizzativo si rileva la sostanziale asimmetria degli Enti terzi rispetto alle relazioni con un Comune. Un Ente può servire più comuni mediante gli stessi procedimenti ; ad esempio una ASL fornisce pareri o autorizzazioni a più comuni; un Comune al contrario ha relazioni con uno solo degli Enti sopracitati; ad esempio un Comune si riferisce ad una sola ASL. È quindi naturale per l Ente terzo in relazione con più Suap dotarsi di una unica interfaccia per adempiere ai suoi obblighi. Dal punto di vista dell architettura del Sistema il problema si configura come un colloquio applicativo tra sistemi informativi eterogenei. Il progetto prevede un architettura di base strettamente aderente con quanto previsto nel CART, del quale utilizza totalmente i servizi che hanno proprio come oggetto la realizzazione della infrastruttura di servizi per la cooperazione applicativa di livello regionale. Tutti i Domini cooperanti saranno dotati di un NAL ( Nodo Applicativo Locale) che realizza per il Dominio stesso sia la porta applicativa che la porta delegata. Le diversità tecniche dei sistemi cooperanti e le differenti caratteristiche organizzative interne del singolo Ente fanno si che la scelta si orienti verso modalità di cooperazione con caratteristiche di accoppiamento lasco in modo da ridurne la pervasività. La soluzione scelta si avvale di un modello di interazione message - based per le sue caratteristiche di responsabile, a livello infrastrutturale, della consegna garantita e certificata dell evento applicativo. La scelta di tale modello di cooperazione cooperativa è stata determinata dalle considerazioni seguenti. Il tipo di transazionalità richiesta al Sistema, implementato a un livello che fornisce solo informazioni di stato, è nulla e potrebbe divenire di tipo transactional queing nel caso in cui al Sistema venga richiesto di generare eventi applicativi necessari all evolvere del procedimento. Il livello di risposta applicativa che il Sistema deve fornire non è immediato ma può essere ritardata. Le tecnologie di comunicazione assunte sono di tipo connection-less, cosi che il richiedente non ha necessita di localizzare o connettersi a istanze specifiche dell applicazione ricevente per inoltrare un richiesta; né il ricevente ha bisogno di essere raggiungibile via una connessione di rete attiva. Descriviamo a questo punto la sequenza di operazioni compiute dalla Porta di Dominio del Comune per iniziare lo scambio di informazioni con la Porta di Dominio della Ente Terzo. Si noti che questa sequenza utilizza il meccanismo di handshaking. Firenze Pagina 28 di 36

29 Il Comune / Ente Terzo apprende dell'esistenza sulla Rete telematica Regione Toscana del Registro di servizi amministrativi dedicato ai procedimenti che fanno capo ad un SUAP. Questo Registro consente la memorizzazione di documenti e applicazioni, permettendo la cd Cooperazione Collaborativa Il Comune / Ente Terzo decide pertanto di pubblicare sul Registro il proprio profilo e il proprio scenario di riferimento: cioè un insieme di documenti XML in cui vengono descritte le informazioni e i servizi che la Amministrazione è in grado di erogare assieme alle modalità amministrative e tecniche in cui è in grado di erogarle. Ogni amministrazione attraverso la partecipazione alle attività del Tavolo Tecnico pubblica in sostanza, via XML, il processo amministrativo a cui fa riferimento e i dettagli del proprio ruolo in tale processo, assieme alle definizioni tecniche dei protocolli di sicurezza con cui si aspetta di operare Si noti a questo punto un aspetto molto importante: le specifiche e i formati XML per la descrizione dei procedimenti autorizzativi, all'interno dei quali le amministrazioni dichiarano il proprio ruolo (ad es. come pubblicatore oppure fruitore di informazioni) sono pubblicati sul Registro dalla Regione,che quindi opera anche uno sforzo di normazione o almeno di traduzione della norma legislativa in codice XML e che fornisce così un unico documento di riferimento comprensibile anche a tutte le Porte di Dominio. Il vantaggio risiede comprensibilmente nell'avere un'unica interfaccia comune per tutti e garantita da un unico soggetto in maniera coordinata attraverso un Tavolo Tecnico con funzione di Ente Standardizzatore. COMPONENT DIAGRAM È un diagramma di massima della struttura fisica del codice in termini di componenti e di reciproche dipendenze. Il diagramma è qui utilizzato per illustrare le varie componenti e la loro disposizione sui nodi applicativi. Business Logic Mapping verso il DB Interfaccia verso il DB CRIC NAL WWW CAC Proxy Locale Firenze Pagina 29 di 36

30 NOTA: in shadow sono indicate le componenti infrastrutturali che pertanto non dovranno essere realizzate. Descrizione Di seguito vengono presentate le componenti software da realizzare. Proxy Locale Realizza le interfacce necessarie all'invio/ricezione di messaggi XML. In particolare per l'invio segue i seguenti passi: 1. riceve dei dati nel formato nativo del sistema informativo locale, 2. valida i dati, 3. costruisce il nuovo messaggio secondo le specifiche del protocollo applicativo, 4. utilizza il NAL per spedire il messaggio, Alternativa al passo 2. Se i dati ricevuti non sono corretti notifica al SIL l'errore. Per la ricezione di un messaggio segue i seguenti passi: 1. riceve dal NAL un messaggio, 2. valida i dati, 3. utilizza le informazioni per creare un messaggio fruibile dal SIL. Alternativa al passo 2. Se i dati ricevuti non sono corretti notifica al NAL l'errore. CAC Realizza le interfacce necessarie all'invio/ricezione di messaggi XML. In particolare: Firenze Pagina 30 di 36

31 1. riceve messaggi dal CRIC 2. registra i dati di interesse regionale. WWW Realizza le pagine web dinamiche con cui l'utente può interagire con il sistema. Firenze Pagina 31 di 36

32 Business Logic Componente che realizza la business logic. Mapping verso il DB Insieme di classi che realizzano la logica di ogni tabella che è posta sul DB. Interfaccia verso il DB Realizza le interfacce che forniscono metodi per l'accesso a basso livello verso il DB. E' un componente riutilizzabile oppure già esistente. NAL Nodo applicativo Locale. Ulteriori dettagli possono essere trovati nel seguito. CRIC Centro Regionale per l'interoperabilità e la cooperazione. Ulteriori dettagli possono essere trovati nel seguito. Firenze Pagina 32 di 36

33 DEPLOYMENT DIAGRAM I Deployment diagram mostrano l architettura hardware e software del sistema. In particolare vengono illustrati gli elementi fisici del sistema (computer, reti, device fisici, ) e i moduli software da installare su ciascuno di essi Client https CRIC DB Server SIL NAL Descrizione Di seguito vengono riportati i vari componenti architetturali e le rispettive componenti software che li utilizzano. Ulteriori dettagli si trovano nei seguenti allegati: "Infrastruttura per la cooperazione applicativa" "Ambienti di sviluppo adottati dalla Regione Toscana nell'ambito degli standard nel settore delle tecnologie dell'informazione e comunicazione" DB Server RDBMS Informix su piattaforma HP/UX Questo server è collocato all'interno della Intranet. Firenze Pagina 33 di 36

34 NAL (Nodo Applicativo Locale) È fisicamente collocato presso ET e CO, realizza un nodo applicativo locale per la comunicazione e la cooperazione applicativa. Le parti di cui è concettualmente composto un NAL sono: 1. Proxy applicativi 2. Agente Locale JMS 3. Agente Locale SOAP 4. Agente Locale JAX-RPC 5. RDBMS 6. Application Server J2EE/Servlet-JSP Engine 7. Provider JMS La componente software "Proxy Locale" si inserisce nel contesto NAL come un "Proxy Applicativo" pertanto deve interagire con il SIL tramite una delle modalità che il NAL mette a disposizione. Le modalità di interazione tra SIL e NAL supportate sono: 1. Get/Post: il SIL prepara i dati, secondo un formato specifico, che devono essere inviati sul NAL e li deposita in una directory del suo file system: successivamente effettuerà una POST sul NAL per passare i file preparati. Un modo per poter far questo potrebbe essere quello di utilizzare la utilità CURL (o libcurl se usata da programma) che permette di fare questo automaticamente; 2. Interfacce: i proxy applicativi presenti sul NAL esporranno delle interfacce che dovranno essere implementate sul SIL: in questo caso si avranno degli oggetti sul NAL che dovranno essere invocati come oggetti remoti dal SIL. 3. Message Listener: viene usato in questo caso una tipologia di Enterprise Java Bean il Message Driver Bean, che è in grado di ricevere e processare messaggi spediti da un client applicativo, da una componente Web, da un'applicazione JMS o da un sistema che non utilizza tecnologia J2EE. Quando arriva un messaggio il container dell' EJB invoca automaticamente il metodo OnMessage del Message Driver deputato a processare il messaggio. Nel caso specifico questo sarebbe in ascolto sul NAL per accettare i dati che provengono dal SIL sotto forma di messaggi. Firenze Pagina 34 di 36

35 4. Code di messaggi: in questo caso il SIL, quando deve inviare dei dati, li invia attraverso un messaggio SOAP su HTTP su una coda del NAL e da qui caricato sul DB normalizzato e poi inviato all'agente locale. Lo stesso meccanismo al contrario viene eseguito nel caso in cui il SIL debba ricevere i dati. Inoltre il "Proxy Locale" dovrà utilizzare il servizio della cooperazione applicativa fornita dal NAL per poter interagire con il CRIC. Il "Proxy Locale" deve quindi interfacciarsi con gli agenti locali (JMS, SOAP, JAX-RPC) presenti sul NAL ed utilizzare i servizi offerti dal CRIC. Firenze Pagina 35 di 36

36 CRIC Il CRIC è il Centro Servizi che ospita i servizi di rete comuni e condivisi da più amministrazioni. Il CRIC avrà al suo interno: 1. Registry dei servizi 2. Servizi di directory accessibili via LDAP 3. Gestione della Notifica degli Eventi (P&S) 4. Servizi applicativi centrali cioè la componente centrale di servizi applicativi che prevedono un punto centrale di coordinamento o di accesso. 5. Servizi di Web Server 6. Servizi di monitoraggio delle applicazioni 7. Servizi per la distribuzione e aggiornamento delle componenti software remote sui NAL 8. Application Server Java 9. cruscotto di amministrazione di sistema Quindi le componenti "CAC" e "WWW" si collocano nel contesto CRIC come "Servizi Applicativi Centrali". La componente "WWW" sarà collocata su Web Server ed accessibile tramite protocollo HTTPS. La componente "CAC" dovrà utilizzare i servizi per la gestione e notifica di eventi. Sia la componente "WWW" che "CAC" dovranno interagire con il Data Base. SIL Il SIL è il Sistema Informativo Locale presente presso un qualunque Ente o Comune. La descrizione è volutamente sfumata perché il nostro sistema deve essere il meno invasivo possibile quindi non dobbiamo porre alcun vincolo. Client Una qualunque macchina client. L'utente lavora in modalità interattiva. Per lavorare dispone di Browser e certificato digitale.. Firenze Pagina 36 di 36