Certificazione di Proxy Applicativi e di applicazioni e servizi di cooperazione di Sistemi Informativi Locali

Transcript

1 Certificazione di Proxy Applicativi e di applicazioni e servizi di cooperazione di Sistemi Informativi Locali Ver Gennaio 2006 Riferimenti Documentazione CART - Regione Toscana [RT-PDK] Proxy Developer Kit Ver. 1.3, Infrastruttura per la Cooperazione Applicativa, Regione Toscana, Maggio 2004; [RT-DeployNAL] Deploy di una applicazione in ambiente NAL, versione 1.9, CART Regione Toscana Altri Documenti [Gornik-UML] The UML and data Modeling, Davor Gornik, Rational Software Corp., 2003 [W3C-WSDL] Web Services Description Language (WSDL) 1.1, W3C Note, March 2001, 1 di 34

2 Indice generale 1. Introduzione Certificazione di Proxy Applicativi Requisiti di conformità di Proxy Applicativi Requisiti di interoperabilità relativi ai proxy applicativi Interfaccia Proxy Applicativo CRIC: Accesso al Sistema di Cooperazione Interfaccia Proxy Applicativo CRIC: Monitoraggio Interfaccia Proxy Applicativo SIL Requisiti architetturali Modelli di cooperazione per eventi e per richieste di servizio Organizzazione delle componenti applicative Requisiti di documentazione Documentazione del software Documentazione di installazione, configurazione, esercizio Documentazione relativa all interfaccia SIL - Proxy Applicativo Scheda riassuntiva dei requisiti per la certificazione di Proxy Applicativi (checklist) Requisiti di Interoperabilità Interfaccia Proxy Applicativo CRIC: Accesso al Sistema di Cooperazione Interfaccia Proxy Applicativo CRIC: Monitoraggio Interfaccia Proxy Applicativo SIL Requisiti Architetturali Modelli di cooperazione per eventi e per richieste di servizio Organizzazione delle componenti applicative Requisiti di Documentazione Documentazione del Software Documentazione di installazione, configurazione, esercizio Documentazione relativa all interfaccia SIL - Proxy Applicativo Modalità di consegna del software e della documentazione dei Proxy Applicativi Struttura dell'archivio Proxy Applicativo Test Suite SIL Reference Implementation Certificazione di applicazioni e servizi di cooperazione di Sistemi Informativi Locali Requisiti di conformità per Sistemi Informativi Locali Requisiti di interoperabilità Requisiti relativi all'uso di servizi del proxy applicativo Requisiti relativi ai servizi esposti dal SIL Tracciamento dello stato della applicazione Requisiti di documentazione Casi d'uso del sistema Scenari Dislocazione dei componenti della applicazione SIL Scheda riassuntiva dei requisiti per la certificazione di SIL (Checklist) Requisiti di Interoperabilità Requisiti relativi all'uso di servizi del proxy applicativo Requisiti relativi ai servizi esposti dal SIL Tracciamento dello stato della applicazione Requisiti di documentazione Casi d'uso del sistema Scenari Dislocazione dei componenti della applicazione SIL di 34

3 4. Processo di verifica di conformità per Proxy Applicativi e componenti di cooperazione di Sistemi Informativi Locali Verifica di conformità di Proxy Applicativi Verifica delle caratteristiche del software applicativo e della documentazione Verifica di operatività in ambiente di test Verifica di operatività in ambiente di produzione Verifica di conformità di componenti di cooperazione dei Sistemi Informativi Locali Verifica delle caratteristiche del software applicativo e della documentazione Verifica di operatività in ambiente di test Verifica di operatività in ambiente di produzione Appendici Appendice A Formato XML del log di livello sistemistico Appendice B - Esempio di documento XML Schema annotato Appendice C Esempio di descrizione di use case Glossario di 34

4 1. Introduzione L'infrastruttura di cooperazione applicativa del CART permette la partecipazione di enti regionali diversi ad un sistema di cooperazione che abilita l integrazione di servizi e l allineamento delle informazioni. L integrazione nel sistema di cooperazione deve rispettare le peculiarità di ciascun ente e deve avvenire armonizzando componenti sviluppate da una molteplicità di amministrazioni e fornitori. L eterogeneità dei sistemi informativi degli enti partecipanti richiede pertanto la definizione di elementi di coerenza per quanto riguarda le modalità di comunicazione e il formato delle informazioni scambiate. In aggiunta, l evoluzione nel tempo dei servizi e l incremento del numero dei partecipanti alla cooperazione richiede che le componenti della infrastruttura presentino caratteristiche che permettano di gestire in modo agile l evoluzione, facilitando il riuso e l adattamento alle nuove esigenze di servizi e del software che li realizza. In questo scenario i requisiti di cooperazione e il processo di certificazione hanno, congiuntamente, l'obiettivo di supportare i fornitori nello sviluppo di applicazioni per enti di pubblica amministrazione e per specifici domini applicativi nel rispetto di un quadro comune che abilita la cooperazione. Questo coinvolge aspetti diversi quali la modalità di definizione delle interfacce di cooperazione, l'utilizzo della infrastruttura di cooperazione, l'organizzazione delle componenti applicative, la documentazione del software. In questo documento sono descritti in dettaglio i requisiti per la corretta integrazione di applicazioni e servizi con la infrastruttura di cooperazione applicativa CART e i requisiti di documentazione che hanno l'obiettivo di garantire a Regione Toscana il mantenimento nel tempo di una visione complessiva e omogenea sull'insieme di applicazioni sviluppate per il sistema di cooperazione regionale. Il documento è così organizzato nel seguito: nelle sezioni 2 e 3 sono riportati i requisiti per la certificazione di Proxy Applicativi e SIL, rispettivamente. I requisiti sono anche riassunti in una scheda di certificazione che è utilizzata dal centro tecnico per la etoscana Compliance durante la certificazione. E' anche descritto in dettaglio il formato di consegna del codice sorgente e della documentazione a Regione Toscana per la certificazione. Infine, in sezione 4 è descritto il processo di certificazione di conformità ai requisiti presentati. 4 di 34

5 2. Certificazione di Proxy Applicativi 2.1. Requisiti di conformità di Proxy Applicativi In questa sezione sono elencati i requisiti di conformità per le componenti software del sistema di cooperazione dislocate sui Nodi Applicativi Locali (NAL). I requisiti sono classificati distinguendo tre linee attraverso le quali essi intendono favorire la cooperazione: 1. I requisiti di interoperabilità sono orientati a garantire le condizioni che facilitano la integrazione di componenti sviluppati in momenti diversi da parti diverse. Questo coinvolge sia i proxy applicativi che le componenti di cooperazione dislocate sui SIL: un proxy deve creare condizioni che facilitino la successiva integrazione di componenti SIL e deve garantire il corretto utilizzo delle funzionalità esposte dalla infrastruttura centrale di cooperazione applicativa; da parte sua, un SIL deve garantire il corretto funzionamento dei servizi che espone verso la infrastruttura di cooperazione. 2. I requisiti architetturali sono orientati a raggiungere condizioni di coerenza nella organizzazione dei singoli proxy applicativi con l'obiettivo di favorire nel tempo la integrazione e il riuso di componenti e servizi. Gli aspetti salienti del requisito riguardano il prevalente uso di schemi di cooperazione basata su eventi e la strutturazione dei singoli proxy secondo schemi che separino le loro diverse responsabilità. 3. I requisiti di documentazione sono orientati a permettere una visione su più livelli di astrazione e dettaglio sulla architettura e la implementazione dei singoli proxy applicativi e del sistema che essi vanno a costituire Requisiti di interoperabilità relativi ai proxy applicativi I proxy applicativi sono soggetti a requisiti diversi che attengono alla doppia interfaccia verso: il sistema centrale del Centro Regionale per l Interoperabilità e la Cooperazione Applicativa (CRIC); i sistemi informativi locali. Figura 1: CART, componenti del sistema di cooperazione regionale e della loro dislocazione sui nodi di calcolo. 5 di 34

6 Interfaccia Proxy Applicativo CRIC: Accesso al Sistema di Cooperazione Il proxy applicativo deve accedere al CRIC esclusivamente attraverso la componente del framework di cooperazione applicativa presente sul NAL. In particolare, il proxy applicativo non deve effettuare accessi diretti ad alcuno dei servizi esposti da componenti del sistema centrale quali ad esempio directory server (LDAP), code di messaggi, servizi web. Le funzionalità di accesso al sistema centrale che possono essere impiegate nel Proxy applicativo sono tutte e sole quelle esposte dalla componente del framework di cooperazione applicativa del NAL e presentate nel documento [RT-PDK]. In particolare il proxy applicativo deve avvalersi del framework per ogni operazione relativa a: 1. invio dei messaggi nelle code degli eventi sul message server; 2. invocazione di servizi; In modo analogo, è necessario utilizzare le funzionalità del framework per operazioni complementari: 1. costruzione di messaggi SOAP conformi alla busta etoscana e contenenti eventi da pubblicare; 2. lettura e cancellazione di messaggi presenti nel repository degli eventi sul NAL; 3. propagazione di richieste a provider di servizi dislocati sui SIL; Interfaccia Proxy Applicativo CRIC: Monitoraggio Il proxy applicativo deve esporre funzionalità che lo rendono monitorabile a livello sistemistico, ovvero che rendono possibile in ogni momento la verifica dello stato di attività del proxy. A tal fine, il proxy deve implementare un servizio, nel modo descritto dal documento [RT-PDK], che restituisce lo stato del proxy applicativo. Lo stato del proxy è indicato da una stringa contenente un codice: OK: il proxy applicativo è in servizio e si trova in uno stato di funzionamento corretto; WARNING: il proxy applicativo è in servizio ma si trova in uno stato di funzionamento che potrebbe non essere corretto e pertanto richiede un intervento di verifica; TROUBLE: si sono verificati eventi critici che rendono il funzionamento del sistema certamente non corretto; In aggiunta, il proxy deve tenere traccia del suo stato in un apposito log in formato xml. Il log, periodicamente aggiornato dal proxy stesso, deve riportare l indicazione dello stato attraverso un valore numerico (0 = OK, 1 = WARNING, 2 = TROUBLE) ed informazioni di dettaglio sullo stato della applicazione. Il formato XML del log è descritto dallo schema riportato in Appendice A Interfaccia Proxy Applicativo SIL Il proxy applicativo rappresenta il punto di accesso al sistema di cooperazione per i sistemi informativi locali. Nello scenario più comune, molteplici SIL fanno riferimento ad un unico proxy. Al fine di permettere lo sviluppo di componenti di cooperazione dei SIL che abilitano l uso delle funzionalità del proxy, si rende necessaria una definizione non ambigua delle caratteristiche della interfaccia di comunicazione. Nello schema di cooperazione per eventi, il formato XML degli eventi trattati dal proxy applicativo deve essere definito e documentato dal fornitore che realizza il proxy stesso. In particolare: il formato degli eventi deve essere definito attraverso XMLSchema; il significato dei singoli campi deve essere documentato attraverso una descrizione testuale. La descrizione è inserita direttamente nello schema XML attraverso campi di annotazione XMLSchema. L'esempio riportato in Appendice B illustra il concetto. A seguito di ogni richiesta di pubblicazione di eventi da parte del SIL, il proxy deve validare il formato degli eventi in relazione allo schema XML definito. In caso di incongruenza la risposta del proxy applicativo al SIL deve riportare notifica del fallimento. 6 di 34

7 Nel caso di cooperazione per richieste di servizio 1, qualora un SIL afferente al proxy applicativo sia anche provider di servizi, il proxy deve intercettare ogni richiesta indirizzata al SIL e ogni risposta proveniente dal SIL stesso nel modo descritto dal documento [RT-PDK] (sezione relativa all utilizzo dei proxy per la richiesta di servizio). Il proxy deve validare il formato della richiesta e della risposta verificandone la conformità a quello dichiarato dal fornitore del servizio (si veda la sezione relativa ai requisiti sui Sistemi Informativi Locali). Ne consegue che è da considerarsi non corretto lo scenario in cui il framework di cooperazione applicativa del NAL contatta direttamente il provider del servizio sul SIL senza l intermediazione del proxy applicativo. Per permettere la verifica di corretta operatività delle funzioni del proxy applicativo e il corretto interfacciamento tra proxy applicativo e SIL, il fornitore deve provvedere una applicazione di test che emula la componente di cooperazione di un SIL. L applicazione deve colloquiare col proxy richiedendo lo svolgimento di operazioni di pubblicazione, ricezione di eventi, richieste di servizio. L applicazione di test deve includere anche un insieme di dati da utilizzare a scopo di simulazione (e.g. eventi xml nel formato atteso dal proxy e documentato dallo XMLSchema). Per guidare lo sviluppo delle componenti di cooperazione dei SIL che si interfacciano col proxy applicativo, il fornitore del proxy deve anche realizzare una implementazione di riferimento di un sistema informativo locale. Lo scopo della implementazione di riferimento è quello di rappresentare un modello (per quanto possibile astratto da dettagli non significativi) che mostra le modalità con cui un SIL può interagire in maniera corretta col proxy applicativo per accedere ai servizi della infrastruttura. Il fornitore deve rilasciare a Regione Toscana il codice sorgente della applicazione che deve poter essere distribuito ai fornitori delle applicazioni di cooperazione dei SIL che ne fanno richiesta Requisiti architetturali Modelli di cooperazione per eventi e per richieste di servizio L infrastruttura di cooperazione della RTRT prevede due modelli di cooperazione: basato su eventi (modello Event Driven - EDA) e basato su richieste di servizio (modello Service Oriented - SOA). In particolare, la componente del framework di cooperazione applicativa dislocata sul NAL permette ai proxy applicativi e alle componenti di cooperazione dei SIL di utilizzare entrambi gli schemi per realizzare le proprie funzionalità. In una prospettiva di sviluppo incrementale di funzionalità e servizi all interno della infrastruttura della RTRT, si attende tuttavia una propensione verso schemi di cooperazione basati sul modello ad eventi. È pertanto opportuno che funzionalità e servizi dei proxy applicativi e dei SIL siano realizzati in massima parte su schemi di cooperazione basati su scambio di messaggi piuttosto che su richieste di servizio. Pertanto, qualora il proxy applicativo o la componente applicativa di cooperazione di un SIL facciano uso di schemi di interazione basati su richieste di servizio, il fornitore deve procurare documentazione che motiva la necessità della scelta per la particolare applicazione Organizzazione delle componenti applicative Lo sviluppo di proxy applicativi deve per quanto possibile avvalersi del riuso di componenti 1 Nel documento si usa il termine cooperazione per eventi per indicare un modello cooperazione talvolta indicato come asincrono. Le caratteristiche principali di questo modello sono: (i) la cooperazione avviene per scambio di messaggi in maniera unidirezionale; (ii) la comunicazione può essere del tipo molti-a-molti; (iii) la comunicazione è tipicamente non bloccante. La cooperazione per richieste di servizio, indicata talvolta come sincrona al contrario è caratterizzata da: (i) comunicazione di tipo richiesta/risposta bidirezionale; (ii) connessioni uno-a-uno; (iii) richiesta di servizio tipicamente bloccante. 7 di 34

8 software e di servizi già esistenti, qualora questi siano disponibili, al fine di evitare ridondanza di codice e funzionalità. Al fine di abilitare il riuso, è opportuno che ogni implementazione dei proxy applicativi presenti una organizzazione strutturale interna che individua e disaccoppia componenti con responsabilità differenti, quali l interfaccia verso i SIL, la logica specifica del dominio applicativo del proxy, la logica di accesso alle basi dati, l interfacciamento col framework di cooperazione sul NAL. Questo può essere concretamente ottenuto attraverso strategie diverse che possono includere: (i) adozione di schemi architetturali stratificati; (ii) introduzione di interfacce intermedie (componenti di facciata) per la semplificazione delle viste sui sottosistemi e la minimizzazione delle dipendenze; (iii) organizzazione delle classi in package per la separazione di componenti con responsabilità differenti Requisiti di documentazione Documentazione del software Ogni rilascio del software che realizza il proxy applicativo e le implementazioni di riferimento per i SIL deve essere accompagnato con opportuna documentazione che ne descrive le funzionalità e la struttura interna del codice. Al fine di semplificare la gestione dei differenti rilasci del prodotto è opportuno che la documentazione presenti le caratteristiche che seguono: ogni release e la relativa documentazione devono essere identificate con un numero progressivo (lo stesso per il software e la documentazione) che ne indica la versione; ogni rilascio di documentazione deve essere sostitutivo delle precedenti versioni e deve pertanto: (i) riportare la descrizione completa del prodotto rilasciato; (ii) evidenziare gli aggiornamenti rispetto all ultima versione rilasciata; (iii) includere un breve storico dei nuovi elementi o cambiamenti rilevanti introdotti in ogni precedente versione. Ne consegue che non si considerano conformi a quanto richiesto documenti di tipo integrativo che riportano esclusivamente modifiche e aggiunte a versioni precedenti. La documentazione deve evidenziare aspetti del software a livello di dettaglio diverso utilizzando diagrammi UML. In particolare: diagrammi di packages e di classe. La documentazione deve escludere dettagli non significativi ai fini della comprensione della struttura interna del software. Pertanto deve essere orientata alla descrizione di aspetti di specifica, ovvero descrizione di interfacce e relazioni tra classi. Per tale motivo si ritiene opportuno evitare la generazione automatica a partire dal codice; diagrammi di casi d uso che documentano le funzionalità significative esposte dal sistema verso gli attori (sistemi e utenti) che interagiscono col sistema stesso; diagrammi di sequenza e/o di collaborazione relativi a scenari operativi significativi; eventuale documentazione di particolari schemi architetturali e di design che permettono di desumere alcune caratteristiche rilevanti ai fini della conformità direttamente dalla struttura delle classi o dalla organizzazione dei moduli; dove motivato dalla complessità del caso, si richiedono inoltre: viste di deploy che mostrano le dislocazione dei componenti nei differenti nodi (SIL, NAL) e i protocolli che realizzano la comunicazione (ad esempio http, SOAP, JMS); schemi architetturali complessivi che evidenziano i sottosistemi componenti e le relazioni tra essi; Documentazione di installazione, configurazione, esercizio La documentazione del software deve essere accompagnata da descrizioni di dettaglio relative a procedure di installazione, deploy, configurazione e manutenzione. In particolare il fornitore deve provvedere: descrizione relativa alla configurazione di Sun One Application Server 7 richiesta dal proxy 8 di 34

9 applicativo a partire da una nuova installazione di S1AS. Questo include l indicazione di eventuali librerie richieste, certificati per l autenticazione, impostazioni relative alla sicurezza; un documento che descrive l installazione, la configurazione e il formato delle tabelle del database eventualmente utilizzato del proxy; la descrizione delle tabelle del database può essere realizzata attraverso schemi diagrammi entità/relazione o UML profile for data modeling [Gornik-UML]; un documento che descrive la procedura di deploy del proxy applicativo sull Application Server; un manuale di esercizio che documenta le procedure di gestione e manutenzione del proxy applicativo necessarie a mantenerne la corretta operatività nel tempo (ad esempio, nel caso di un sistema di log, quali sono i requisiti di gestione che evitano la saturazione del disco). una stima qualitativa del livello di utilizzazione del sistema di cooperazione in uno scenario operativo reale, in relazione al tempo e alla quantità di eventi (inviati e ricevuti) e servizi (richiesti e offerti); un documento che descrive l installazione, la configurazione e il funzionamento della applicazione di test che emula il SIL; script di shell o descrittori Ant per la compilazione della applicazione, e per la creazione di archivi WAR/EAR Documentazione relativa all interfaccia SIL - Proxy Applicativo Il fornitore del proxy applicativo deve provvedere documentazione che descrive l interfaccia col SIL. In particolare la documentazione deve riportare: URL a cui è possibile invocare i servizi esposti dal proxy, modalità di interazione e protocolli usati; note relative ad aspetti di sicurezza e autenticazione nella comunicazione SIL-Proxy. In particolare, nel caso in cui il proxy applicativo esponga web services verso i SIL, il fornitore deve documentare i servizi includendo: descrizione testuale di servizi e operazioni esposte. La descrizione deve contenere dettagli sul significato dei parametri di ingresso e dei valori di ritorno delle operazioni; definizione della interfaccia di servizio attraverso descrittori in formato WSDL [W3C-WSDL]; 9 di 34

10 2.2. Scheda riassuntiva dei requisiti per la certificazione di Proxy Applicativi (checklist) Requisiti di Interoperabilità Interfaccia Proxy Applicativo CRIC: Accesso al Sistema di Cooperazione Verfifica che il proxy applicativo acceda al CRIC solo attraverso il framework di cooperazione applicativa. Verifica che non siano effettuati accessi diretti ad alcun componente del sistema centrale (LDAP, Code di messaggi, servizi web) [ ] Il proxy effettua accessi al CRIC che non sfruttano il frameworkca? Le funzionalità del Framework di Cooperazione Applicativa utilizzabili dal Proxy sono solo quelle di SoleFacade. Tali funzionalità devono essere usate per: 1. invio dei messaggi nelle code degli eventi sul message server; 2. invocazione di servizi; 3. costruzione di messaggi SOAP conformi alla busta etoscana e contenenti eventi da pubblicare; 4. lettura e cancellazione di messaggi presenti nel repository degli eventi sul NAL; 5. propagazione di richieste a provider di servizi dislocati sui SIL; [ ] Il proxy usa metodi di SoleFacade non riportati nella documentazione del PDK? Interfaccia Proxy Applicativo CRIC: Monitoraggio Il proxy applicativo deve esporre funzionalità che lo rendono monitorabile a livello sistemistico, implementando un servizio, che restituisce lo stato del proxy applicativo. [ ] Il servizio esiste? [ ] Il servizio restituisce un risultato corretto [OK, WARNING, TROUBLE]? Il proxy deve tenere traccia del suo stato in un apposito log in formato xml. [ ] Il log esiste? [ ] Il formato del log è conforme allo schema riportato in Appendice A? Interfaccia Proxy Applicativo SIL Scenario di Cooperazione per eventi Il formato XML degli eventi trattati dal proxy applicativo deve essere definito e documentato dal fornitore. In particolare: il formato degli eventi deve essere definito attraverso XMLSchema; [ ] Lo schema XML è stato fornito? Il significato dei singoli campi deve essere documentato attraverso una descrizione testuale. La descrizione è inserita direttamente nello schema XML attraverso campi di annotazione XMLSchema. 10 di 34

11 [ ] Il formato segue quanto indicato in Appendice B? A seguito di ogni richiesta di pubblicazione di eventi da parte del SIL, il proxy deve validare il formato degli eventi in relazione allo schema XML definito. [ ] Il proxy effettua la validazione? Esiste un metodo (o più metodi) di validazione invocato alla ricezione di un evento? In caso di incongruenza la risposta del proxy applicativo al SIL deve riportare notifica del fallimento. [ ] Inviando un evento non conforme al formato, il proxy notifica l errore? Scenario di Cooperazione per richieste di servizio Qualora un SIL afferente al proxy applicativo sia anche provider di servizi, il proxy deve intercettare ogni richiesta indirizzata al SIL e ogni risposta proveniente dal SIL stesso. [ ] Il proxy è registrato per la ricezione di tutte le richieste di servizio (escluso il monitoraggio)? Il proxy deve validare il formato della richiesta e della risposta. [ ] Il proxy effettua la validazione? Il fornitore deve provvedere una applicazione di test che emula la componente di cooperazione di un SIL. L applicazione deve colloquiare col proxy richiedendo lo svolgimento di operazioni di pubblicazione, ricezione di eventi, richieste di servizio. L applicazione di test deve includere anche un insieme di dati da utilizzare a scopo di simulazione (e.g. eventi xml nel formato atteso dal proxy e documentato dallo XMLSchema). [ ] L applicazione è presente? [ ] L applicazione svolge le operazioni di pubblicazione, ricezione eventi, richieste di servizio? Requisiti Architetturali Modelli di cooperazione per eventi e per richieste di servizio Qualora il proxy applicativo o la componente applicativa di cooperazione di un SIL facciano uso di schemi di interazione basati su richieste di servizio, il fornitore deve procurare documentazione che motiva la necessità della scelta per la particolare applicazione. [ ] Il proxy applicativo fa uso della richiesta di servizio? [ ] Se il proxy usa la richiesta di servizio, esiste opportuna documentazione che motiva la scelta? Organizzazione delle componenti applicative È opportuno che ogni implementazione dei proxy applicativi presenti una organizzazione strutturale interna che individua e disaccoppia componenti con responsabilità differenti, quali l interfaccia verso i SIL, la logica specifica del dominio applicativo del proxy, la logica di accesso alle basi dati, l interfacciamento col framework di cooperazione sul NAL. [ ] Il proxy presenta una strutturazione interna che mostra separazione delle responsabilità? 11 di 34

12 Requisiti di Documentazione Ogni release e la relativa documentazione devono essere identificate con un numero progressivo (lo stesso per il software e la documentazione) che ne indica la versione; Ogni rilascio di documentazione deve essere sostitutivo delle precedenti versioni e deve pertanto: (i) riportare la descrizione completa del prodotto rilasciato; (ii) evidenziare gli aggiornamenti rispetto all ultima versione rilasciata; (iii) includere un breve storico dei nuovi elementi o cambiamenti rilevanti introdotti in ogni precedente versione. [ ] La documentazione / l aggiornamento sono conformi? Documentazione del Software Documentazione della interfaccia Proxy - CRIC Diagrammi UML di casi d uso, diagrammi di sequenza e/o collaborazione, che illustrano gli scenari: [ ] pubblicazione di eventi; [ ] invocazione di servizi; [ ] accesso al repository degli eventi (ricezione, cancellazione di eventi) [ ] Nella illustrazione dei dettagli di livello implementativo, i diagrammi dovranno mostrare gli oggetti coinvolti e i metodi invocati in tali scenari Documentazione della interfaccia del servizio di monitoraggio La documentazione prodotta ai fini della certificazione dovrà riportare: [ ] indicazione della classe che implementa il servizio di monitoraggio; [ ] indicazione della classe/i delegata alla scrittura del log sistemistico; [ ] percorso e nome del file di log; [ ] indicazione della modalità di generazione del log (una volta al giorno, ogni ora, ogni minuto, ad ogni operazione ) Documentazione della interfaccia Proxy SIL Nella documentazione del proxy applicativo, sarà necessario indicare quali classi, se esistono, operano come ascoltatori per ricevere richieste di servizio provenienti dalla infrastruttura di cooperazione applicativa Documentazione della architettura del proxy Al fine della certificazione, dovrà essere prodotta una documentazione che include: [ ] diagrammi di casi d uso che documentano le funzionalità significative esposte dal sistema verso gli attori (sistemi e utenti) che interagiscono col sistema stesso; [ ] diagrammi di sequenza e/o di collaborazione relativi a scenari operativi significativi; o [ ] Sono riportate le interazioni tra proxy applicativo e componenti del Framework di Cooperazione Applicativa (Sole Facade)? o [ ] Gli scenari riportano indicazione precisa delle classi e dei metodi coinvolti? [ ] La descrizione di ogni componente in cui l applicazione è strutturata; [ ] L elencazione dei package costituenti ogni componente; [ ] La descrizione delle classi e delle interfacce di ogni package con particolare riferimento a: 12 di 34

13 o o o classi che hanno la responsabilità di ricevere le richieste dai SIL; classi che hanno la responsabilità di accedere alle funzionalità di cooperazione; classi che hanno la responsabilità di accedere ad eventuali basi di dati; [ ] Le dipendenze esistenti a livello di interfaccia tra i componenti. [ ] È preferibile a livello di diagramma di package evidenziare la distinzione, se esiste, tra i package responsabili della logica specifica del NAL, i package dell interfaccia verso il SIL e quelli di interfaccia verso la infrastruttura di cooperazione applicativa. La distinzione esiste ed è documentata? [ ] Eventuale documentazione di particolari schemi architetturali e di design [ ] Dove motivato dalla complessità, si richiedono inoltre: o [ ] viste di deploy che mostrano la dislocazione dei componenti e i protocolli di comunicazione; o [ ] schemi architetturali complessivi che evidenziano i sottosistemi componenti e le relazioni tra essi; Documentazione di installazione, configurazione, esercizio Verificare che la documentazione riporti: [ ] descrizione relativa alla configurazione di Sun One Application Server 7 richiesta dal proxy applicativo a partire da una nuova installazione di S1AS. o [ ] Eventuali librerie aggiuntive richieste, o [ ] certificati per l autenticazione, o [ ] impostazioni relative alla sicurezza; [ ] un documento che descrive l installazione, la configurazione e il formato delle tabelle del database eventualmente utilizzato del proxy; [ ] un documento che descrive la procedura di deploy del proxy applicativo sull Application Server; [ ] un manuale di esercizio che documenta le procedure di gestione e manutenzione del proxy applicativo necessarie a mantenerne la corretta operatività nel tempo [ ] una stima qualitativa del livello di utilizzazione del sistema di cooperazione in uno scenario operativo reale, in relazione al tempo e alla quantità di eventi (inviati e ricevuti) e servizi (richiesti e offerti); [ ] un documento che descrive l installazione, la configurazione e il funzionamento della applicazione di test che emula il SIL; [ ] script di shell o descrittori Ant per la compilazione della applicazione, e per la creazione di archivi WAR/EAR Documentazione relativa all interfaccia SIL - Proxy Applicativo Il fornitore del proxy applicativo deve provvedere documentazione che descrive l interfaccia col SIL. In particolare la documentazione deve riportare: [ ] URL a cui è possibile invocare i servizi esposti dal proxy, modalità di interazione e protocolli usati; 13 di 34

14 [ ] note relative ad aspetti di sicurezza e autenticazione nella comunicazione SIL-Proxy. Nel caso in cui il proxy applicativo esponga web services verso i SIL la documentazione deve riportare: [ ] descrizione testuale di servizi e operazioni esposte includendo il significato dei parametri di ingresso e dei valori di ritorno delle operazioni; [ ] definizione WSDL della interfaccia del servizio 14 di 34

15 2.3. Modalità di consegna del software e della documentazione dei Proxy Applicativi Struttura dell'archivio Il proxy applicativo e la relativa documentazione dovranno essere consegnati a Regione Toscana in un archivio (.jar /.zip / tar.gz) il cui contenuto sarà strutturato in tre directory principali: Proxy Applicativo: contiene il codice sorgente del proxy e la documentazione; Test Suite: contiene la applicazione di test e la relativa documentazione come descritto nella sezione relativa ai requisiti; SIL Reference Implementation: contiene una applicazione che emula la componente di cooperazione di un sistema informativo locale. Include la documentazione che descrive l'installazione e il funzionamento della applicazione e i sorgenti; Nelle sezioni seguenti è riportato l'elenco dettagliato del contenuto delle directory Proxy Applicativo La cartella Proxy Applicativo contiene il codice, la documentazione e gli script di configurazione del proxy applicativo. É strutturata in due sottocartelle: Documentazione e Proxy Documentazione La cartella Documentazione contiene i documenti richiesti per la certificazione del proxy secondo quanto richiesto nella sezione relativa ai requisiti. In particolare essa dovrà contentere due files: Documentazione_proxy_applicativo_<Nome-Proxy> - vers <XX> : documentazione del proxy applicativo; Documentazione_installazione_configurazione_esercizio - vers <XX> : manuale che descrive le procedure di installazione, configurazione, deploy del proxy. Il manuale include anche indicazioni per la manutenzione in esercizio del proxy applicativo Proxy La cartella Proxy contiene il codice sorgente del proxy applicativo e i vari script per la compilazione, la creazione dell'archivio war e la attivazione sul server, così come richiesto nel documento [RT-DeployNAL]. Il contenuto della cartella Proxy è strutturato in tre sottocartelle: JavaSource WebContent Nal Figura 2: Struttura delle sottodirectory della cartella Proxy JavaSource É la directory di base in cui si trovano i sorgenti del proxy applicativo. All'interno i files.java saranno organizzati in directory secondo il nome del package delle classi Java. 15 di 34

16 Figura 3: Cartella JavaSource. In figura è mostrata la struttura delle sottodirectory nel caso di abbiano due classi MyServlet.java e MyWebService.java entrambe appartenenti al package it.etoscana.proxy WebContent La cartella contiene tutte le risorse utilizzate per creare l'archivio war organizzate in sottocartelle secondo una struttura di directory analoga a quella di un archivio war. Esempio di risorse che sono tipicamente contenute in WebContent sono: pagine html, jsp e immagini; risorse di vario tipo (es. file di proprietà utilizzati dal proxy in avvio o durante l'esecuzione); il descrittore di deploy web.xml; descrittori aggiuntivi (es. descrittori dipendenti dal server o eventualmente richiesti dalle librerie utilizzate dal proxy); le eventuali librerie aggiuntive utilizzate dal proxy; Figura 4: Cartella WebContent: ha struttura analoga a quella di un archivio War. A differenza di un archivio war, la directory Web Content non include i binari compilati (.class) che saranno inclusi solo nel war a seguito della compilazione o in una apposita cartella di distribuzione Nal La cartella Nal contiene gli script per la compilazione e la creazione dell'archivio war. In particolare, come indicato nel documento [RT-DeployNAL] essa include: uno script d'installazione/disinstallazione, denominato setup ; uno script d'attivazione/disattivazione, denominato service ; un descrittore di Ant build.xml; Le caratteristiche degli script setup e service sono riportate nel documento [RT-DeployNAL] in sezione 2.1 e 2.2. Il descrittore di Ant build.xml deve presentare almeno i seguenti due target: target compile per la compilazione della applicazione 16 di 34

17 target war per la creazione dell'archivio war da utilizzare per il deploy della applicazione sul server. L'archivio war dovrà contenere i binari compilati, le pagine della interfaccia web eventualmente presente (jsp, html), le librerie esterne. Figura 5: Cartella Nal: include gli script setup e service, il descrittore di Ant e i relativi file di proprietà (esempio in figura ant-build.properties) Test Suite La cartella Test Suite include il codice e la documentazione per la suite di test come descritto nella sezione relativa ai requisiti. É strutturata in due sottocartelle: Documentazione Suite Documentazione La cartella Documentazione contiene il documento: Documentazione_test_suite_<Nome-Proxy> - vers <XX> Il documento dovrà descrivere: i prerequisiti dell ambiente di test; in particolare l'ambiente di test deve essere facilmente riproducibile a partire dal server NAL nella sua configurazione standard; come inizializzare l ambiente di test sia con i dati di simulazione forniti assieme alla test suite che con i dati reali d esercizio; come avviare la test suite; come valutare la correttezza o meno dei risultati Suite La cartella Suite dovrà contenere il codice sorgente della suite di test, gli script per la compilazione, gli script per l'avvio dei test di singole funzionalità e di un test complessivo. La cartella Suite è organizzata nelle seguenti sottodirectory: src: directory di base in cui devono trovarsi i sorgenti della test suite; lib: directory in cui si trovano le librerie eventualmente necessarie al funzionamento della test suite; bin: directory radice in cui si trovano i binari compilati della suite di test; eventi: directory che contiene gli eventi (in formato XML) da utilizzare con la suite di test per lo svolgimento di operazioni di pubblicazione; conf: directory che contiene gli script di compilazione e di avvio e gli eventuali file di configurazione della applicazione. 17 di 34

18 Figura 6: Struttura della directory Test Suite. E' mostrato in particolare il contenuto della sottocartella conf che contiene gli script di compilazione e di avvio della suite di test SIL Reference Implementation La cartella contiene il codice sorgente e la documentazione di una implementazione di riferimento di un Sistema Informativo Locale che si interfaccia con il Proxy Applicativo per svolgere le operazioni di pubblicazione e ricezione di eventi. La cartella presenta una organizzazione interna in due sottocartelle: Documentazione SIL Documentazione La cartella contiene i files che documentano la applicazione. In particolare essa dovrà contenere due files: Documentazione Implementazione Riferimento SIL - vers <XX>: il documento deve contenere la descrizione della applicazione anche avvalendosi di diagrammi UML. In particolare dovrà essere descritto: le funzionalità accessibili dalla interfaccia della applicazione; la struttura del codice della applicazione attraverso diagrammi UML delle classi; Documentazione installazione configurazione - vers <XX>: manuale che descrive le procedure di installazione, configurazione ed avvio della applicazione SIL La cartella SIL contiene il codice sorgente della implementazione di riferimento del SIL e gli script per la compilazione, la configurazione e l'avvio. Il contenuto della cartella è organizzato in sottocartelle la cui struttura dipende dal tipo di applicazione SIL. Si distinguono in particolare due casi: SIL web app : SIL reference implementation è una applicazione web SIL simple java app: SIL reference implementation non è una applicazione web SIL web app In questo caso la cartella SIL è divisa in sottocartelle con una struttura analoga a quanto illustrato nel paragrafo In particolare dovranno essere presenti tre sottocartelle: JavaSource: directory in cui si trovano i sorgenti della implementazione di riferimento del SIL. All'interno i files.java saranno organizzati in directory secondo il nome dei package delle classi; WebContent: directory in cui si trovano le risorse utilizzate per creare l'archivio war della applicazione, organizzate in una struttura di directory analoga a quella di un archivio war. In 18 di 34

19 essa sono contenuti pagine html, jsp, il descrittore di deploy web.xml, eventuali librerie utilizzate dalla applicazione. SIL: contiene uno script Ant che presenta almeno i seguenti due target: target compile per la compilazione della applicazione target war per la creazione dell'archivio war da utilizzare per il deploy della applicazione sul server. L'archivio war dovrà contenere i binari compilati, le pagine della interfaccia web eventualmente presente (jsp, html), le librerie esterne. Figura 7: Struttura della cartella SIL Reference Implementation nel caso in cui l'implementazione di riferimento sia una web application SIL simple java app Nel caso in cui la implementazione di riferimento del SIL non sia una web application, la struttura della sottodirectory SIL sarà simile a quella della directory Suite mostrata in sezione Essa sarà pertanto organizzata nelle seguenti sottodirectory: src: directory di base in cui devono trovarsi i sorgenti della applicazione; lib: directory in cui si trovano le librerie eventualmente necessarie al funzionamento della applicazione; bin: directory radice in cui si trovano i binari compilati della applicazione; eventi: directory che contiene i files XML che rappresentano gli eventi da utilizzare con la applicazione a scopo di simulazione; conf: directory che contiene gli script di compilazione e di avvio e gli eventuali file di configurazione della applicazione. 19 di 34

20 3. Certificazione di applicazioni e servizi di cooperazione di Sistemi Informativi Locali 3.1. Requisiti di conformità per Sistemi Informativi Locali La integrazione dei Sistemi Informativi Locali (SIL) degli enti partecipanti con l'infrastruttura avviene attraverso interfacce documentate e stabili esposte dalle applicazioni di cooperazione. Nel sistema di cooperazione regionale CART, i Nodi Applicativi Locali (NAL) e i Proxy Applicativi su essi dislocati realizzano le interfacce dal punto di vista fisico e logico. I Proxy in particolare sono le applicazioni che abilitano la cooperazione dei SIL. Essi da un lato utilizzano i servizi infrastrutturali del CART e dall'altro realizzano, per ogni dominio applicativo specifico, le funzionalità di scambio eventi e invocazione di servizi, fornendo per ciascuna di esse una specifica di interfaccia. Il ruolo dei componenti di cooperazione dei sistemi informativi locali è la realizzazione di un adattamento tra funzionalità del SIL e servizi di cooperazione esposti dai proxy, rispettando le specifiche della interfaccia del proxy applicativo e abilitando l'uso della cooperazione in modo trasparente rispetto alle procedure amministrative dell'ente. In questa sezione sono elencati i requisiti di conformità per i componenti di cooperazione dei Sistemi Informativi Locali. I requisiti sono classificati distinguendo due linee: Requisiti di interoperabilità : orientati a garantire la corretta integrazione dei SIL nel sistema di cooperazione e a facilitare l'integrazione di servizi sviluppati dai sistemi informativi locali stessi. I componenti di cooperazione dei sistemi informativi locali devono garantire un uso delle funzionalità esposte dai proxy conforme alle specifiche delle interfacce. Deve anche essere garantito il corretto funzionamento dei servizi eventualmente esposti verso la infrastruttura di cooperazione. Requisiti di documentazione : descrivono il tipo di documentazione richiesta per la interfaccia tra SIL e proxy applicativo. Include la descrizione delle funzionalità di cooperazione utilizzabili dagli operatori (o in maniera autonoma dal sistema SIL) e delle procedure che ne prevedono l'utilizzo Requisiti di interoperabilità I requisiti di interoperabilità per le componenti software di cooperazione presenti sui sistemi informativi locali attengono prevalentemente a due aspetti: l'uso di servizi 2 esposti dalla interfaccia del proxy applicativo. le caratteristiche della interfaccia di eventuali servizi realizzati dal SIL stesso ed esposti verso l infrastruttura di cooperazione. 2 Il termine "servizi" è qui usato con significato ampio, non limitato ai web services: si intende ogni funzionalità presentata dal proxy applicativo e realizzata con una qualsiasi tecnologia e protocollo. 20 di 34

21 Figura 8: Vista di deploy delle componenti del sistema di cooperazione CART Requisiti relativi all'uso di servizi del proxy applicativo Nell'utilizzo dei servizi esposti dal proxy applicativo, la componente di cooperazione del SIL deve garantire: l'uso di protocolli o tecnologie compatibili con quelli accettati dal proxy applicativo per accedere ai servizi da esso esposti; la generazione di richieste di servizio corrette dal punto di vista del nome del servizio e del numero e tipo dei parametri accettati dalla interfaccia di servizio; nel caso in cui siano utilizzati web services, le richieste SOAP devono essere conformi al formato dichiarato dal descrittore WSDL; la produzione di messaggi contenenti eventi di formato conforme a quanto dichiarato dal fornitore del proxy; in particolare, ogni evento prodotto deve essere valido rispetto allo XMLSchema fornito dal produttore del proxy e reso disponibile da Regione Toscana agli sviluppatori di applicazioni per i sistemi informativi locali. Al fine di limitare la latenza nella propagazione della informazione tra i sistemi partecipanti alla cooperazione, esistono anche requisiti (qualitativi) sulla tempificazione con cui avvengono le operazioni di pubblicazione eventi. In particolare, si richiede che il SIL introduca un ritardo minimo tra il verificarsi di un evento e l'invio del corrispondente messaggio verso il proxy applicativo. Fanno eccezione i casi in cui un messaggio non è direttamente collegato al verificarsi di un evento (ad esempio messaggi contenenti informazioni aggregate) e i casi in cui è conveniente o necessario ritardare la pubblicazione di messaggi per motivi legati alle prestazioni Requisiti relativi ai servizi esposti dal SIL Nel caso in cui il SIL, oltre ad utilizzare le funzionalità di cooperazione, sia esso stesso fornitore di servizi, deve essere prodotta una descrizione della interfaccia dei servizi offerti. In particolare, il fornitore deve provvedere la seguente documentazione: descrittore della interfaccia del servizio nel formato di RichiestaServizioData.xml riportato nel documento [RT-PDK]. In esso deve essere specificato: il nome del servizio; l identificativo del NAL a cui il fornitore del servizio afferisce; la URL del servizio; i parametri che compongono la richiesta; formato dei messaggi di richiesta e risposta attraverso un descrittore di tipo XMLSchema; il significato dei campi della richiesta e della risposta deve essere documentato attraverso una descrizione testuale. La descrizione è inserita direttamente nello 21 di 34

22 schema XML attraverso campi di annotazione XMLSchema in modo analogo a quanto richiesto per gli eventi ed esemplificato in Appendice B; nel caso in cui i servizi siano offerti come web services, il fonitore deve anche provvedere una descrizione WSDL del servizio. La descrizione della interfaccia dovrà essere fornita a Regione Toscana che potrà distribuirla ad altri fornitori per permettere l accesso ai servizi del SIL da parte di altri partecipanti alla cooperazione Tracciamento dello stato della applicazione Le componenti di cooperazione dei SIL devono tenere traccia del loro stato di funzionamento in un opportuno log di sistema. In particolare deve essere tracciato l'esito di tutte le interazioni tra componenti di cooperazione del SIL e proxy applicativo, sia nel caso in cui il SIL utilizzi i servizi del proxy, sia nel caso in cui il proxy applicativo inoltri verso il SIL richieste di servizio provenienti da altri sistemi di cooperazione. Il formato del log è xml. Esso deve riportare l indicazione dello stato della applicazione attraverso un valore numerico (0 = OK, 1 = WARNING, 2 = TROUBLE) ed informazioni di dettaglio sullo stato rilevato. Il formato XML del log è descritto dallo schema riportato in Appendice A che include anche un esempio di log entry Requisiti di documentazione Ogni rilascio del software che realizza le componenti di cooperazione dei SIL deve essere accompagnato da opportuna documentazione che ne descriva le funzionalità, gli scenari d'uso e la modalità di interazione con i proxy applicativi con cui interagisce. Al fine di semplificare la gestione dei differenti rilasci del prodotto è opportuno che la documentazione presenti le caratteristiche che seguono: ogni release e la relativa documentazione devono essere identificate con un numero progressivo (lo stesso per il software e la documentazione) che ne indica la versione; ogni rilascio di documentazione deve essere sostitutivo delle precedenti versioni e deve pertanto: (i) riportare la descrizione completa del prodotto rilasciato; (ii) evidenziare gli aggiornamenti rispetto all ultima versione rilasciata; (iii) includere un breve storico dei nuovi elementi o cambiamenti rilevanti introdotti in ogni precedente versione. Ne consegue che non si considerano conformi a quanto richiesto documenti di tipo integrativo che riportano esclusivamente modifiche e incrementi di versioni precedenti. La documentazione deve evidenziare le caratteristiche della applicazione utilizzando diagrammi UML. Di seguito si riporta un elenco degli aspetti della applicazione che è necessario documentare Casi d'uso del sistema La documentazione deve includere la descrizione di tutte le funzionalità della applicazione SIL che comportano l'invio di eventi verso il proxy applicativo, la ricezione di eventi o l'invocazione di servizi di cooperazione. In particolare devono essere documentate: le funzionalità attivabili direttamente dall'operatore del SIL attraverso le interfacce della applicazione; le eventuali funzionalità attivate periodicamente e automaticamente da schedulatori; le funzionalità attivate indirettamente da altre applicazioni. La documentazione deve avvalersi di diagrammi UML di casi d uso che documentano le funzionalità significative esposte dal sistema verso gli attori (sistemi e utenti) che interagiscono col sistema stesso. 22 di 34

23 Figura 9: Tipologie di attori di SIL che utilizzano funzionalità di cooperazione Scenari Ogni diagramma di casi d'uso deve essere accompagnato da una descrizione testuale degli use case che include: descrizione dell'attore principale e degli attori secondari che partecipano allo scenario; pre-condizioni e post-condizioni relative alla esecuzione del caso d'uso; uno scenario di funzionamento principale; eventuali scenari alternativi e scenari che si verificano in condizioni di errore; (ad esempio cosa accade quando il proxy non è disponibile, quando si verifica un timeout di una richiesta di pubblicazione di un evento verso il proxy etc.); Nella descrizione deve essere indicato il tempo che intercorre tra il verificarsi dell'evento nel SIL e la pubblicazione di un messaggio in cooperazione (ad esempio: "il messaggio è inviato immediatamente come conseguenza dell'azione dell'operatore sulla interfaccia"; "il messaggio è memorizzato nel database e inviato a fine giornata"). In Appendice C è riportato un esempio di una descrizione testuale di un possibile caso d'uso. La documentazione degli scenari che richiedono l'uso di funzionalità di cooperazione deve anche includere diagrammi UML di sequenza o di collaborazione che illustrino: il modo in cui i componenti di cooperazione dei SIL e i proxy applicativi interagiscono per realizzare le funzionalità del sistema, indicando in particolare: quali sono i servizi del proxy (o del SIL) invocati durante la interazione; quali sono i messaggi (eventi) scambiati; gli scenari di errore e il modo in cui essi sono gestiti; Si osserva che i diagrammi devono focalizzare sulle interazioni che avvengono tra SIL e proxy applicativo (invocazione di servizi, pubblicazione di messaggi, ricezione di risposte etc.) e non sulle interazioni che avvengono tra componenti interne alla applicazione SIL o al proxy applicativo. 23 di 34