e.Toscana Compliance 
Request for Comments: 32.4
Del: 14/02/2007 
Categoria: Applicativa
Destinatari: Regione Toscana, Comuni, Amministrazioni locali, Ditte fornitrici

Certificazione e.Toscana Compliance di Proxy Applicativi
 
Indice
------
1. Contesto di riferimento ed obiettivi
2. Certificazione di Proxy Applicativi
2.1. Requisiti di conformit di Proxy Applicativi	
2.1.1. Requisiti di interoperabilit relativi ai proxy applicativi
2.1.2. Requisiti di documentazione
2.2. Scheda riassuntiva dei requisiti per la certificazione di 
     Proxy Applicativi (checklist)
2.2.1. Requisiti di Interoperabilit
2.2.2. Requisiti di Documentazione
2.3. Formato di consegna del proxy e della documentazione
2.3.1. Proxy Applicativo
2.3.2. Test Suite
3. Il processo di certificazione dei Proxy Applciativi
4. Appendici
5. Bibliografia


1. Contesto di riferimento ed obiettivi
=======================================
=======================================
L'infrastruttura di cooperazione applicativa 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, il formato delle informazioni scambiate, 
la documentazione del software.

Il processo e.Toscana Compliance [RT-eCompliance] [RT-eComp-VisioneInsieme] 
ha l'obiettivo di definire e sostenere l'applicazione di questi elementi 
attraverso gli strumenti "RFC e.Toscana" e il "processo di accreditamento 
e.Toscana Compliance".
Gli RFC e.Toscana in particolare, definiscono lo standard aperto 
che descrive le specifiche della cooperazione applicativa in termini di 
tecniche, modalit, standard tecnologici e informativi, e che riguardano 
l'infrastruttura e i singoli domini applicativi. 
Il processo di accreditamento  lo strumento che ha l'obiettivo di supportare 
i fornitori nello sviluppo di applicazioni di cooperazione sostenendo 
l'attuazione dei requisiti posti dagli RFC e verificando e certificando 
il rispetto dello standard.

In questo documento RFC sono descritti in dettaglio i requisiti per la corretta 
integrazione di Proxy Applicativi con l'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. 

Si osserva che i requisiti qui riportati si riferiscono alla 
integrazione di Proxy Applicativi con l'infrastruttura CART attuale che utilizza
il Framework di Cooperazione Applicativa (FCA) come componente di integrazione e 
SoleFacade come facciata per esporre in modo unificato le funzionalit di 
cooperazione.
I requisiti per l'integrazione di componenti applicativi con la nuova 
infrastruttura saranno riportati in versioni successive di questo RFC.


2. Certificazione di Proxy Applicativi
=======================================
=======================================

2.1. Requisiti compliance e.Toscana di Proxy Applicativi
========================================================
In questa sezione sono elencati i requisiti di conformit per i componenti 
software del sistema di cooperazione dislocate sui Nodi Applicativi Locali 
(NAL).
I requisiti sono classificati distinguendo due linee attraverso le quali essi 
intendono favorire la cooperazione:

  1. I requisiti di interoperabilit sono orientati a garantire le condizioni 
  che facilitano l'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 di documentazione sono orientati a permettere una descrizione 
  delle funzionalit di cooperazione realizzate dai proxy applicativi 
  ed esposte ai Sistemi Informativi Locali in relazione anche ai casi d'uso 
  e agli scenari descritti dagli RFC (applicativi) di riferimento.
   
2.1.1. Requisiti di interoperabilit
------------------------------------ 
I proxy applicativi sono soggetti a requisiti diversi che attengono alla doppia 
interfaccia verso:
  - il sistema centrale del Centro Regionale per lInteroperabilit e la 
  Cooperazione Applicativa (CRIC);
  - i sistemi informativi locali.

2.1.1.1. 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 dal 
Proxy applicativo nello svolgimento delle operazioni previste dall'RFC del 
dominio applicativo di riferimento, 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 presenti sul CRIC;
  2. invocazione di servizi;

In modo analogo,  necessario utilizzare le funzionalit del framework per 
operazioni complementari:
  1. costruzione di messaggi SOAP conformi alla busta di eGovernment che 
  trasportano gli eventi attraverso l'infrastruttura;
  2.lettura e cancellazione di messaggi presenti nel repository degli eventi sul 
  NAL;
  3. propagazione di richieste a provider di servizi dislocati sui SIL;

2.1.1.2. 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 
lindicazione 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 Sezione 3.1.

2.1.1.3. 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  definito attraverso documenti XML Schema annotati (si 
veda sez. 3.2) inclusi nei documenti RFC che descrivono il contesto applicativo 
per il quale il proxy  sviluppato. 
A seguito di ogni richiesta di pubblicazione di eventi da parte del SIL, il 
proxy deve quindi validare il formato degli eventi in relazione allo schema XML 
definito negli RFC. In caso di incongruenza, la risposta del proxy applicativo 
al SIL deve riportare notifica del fallimento.

Nel caso 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 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 anche documentare il corretto interfacciamento tra proxy 
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 (eventi xml nel formato definito dagli RFC applicativi). 

Il fornitore deve rilasciare a Regione Toscana anche il codice sorgente della 
applicazione di test che deve essere rilasciato con una licenza "open" che ne 
consente la distribuzione ai fornitori di applicazioni SIL che si interfacciano 
col proxy.


2.1.2. Requisiti di documentazione
----------------------------------
2.1.2.1. 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 di cooperazione realizzate. 
Per 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) riportare il riferimento agli RFC applicativi del dominio per il quale
    il proxy  sviluppato;
    (iii) evidenziare gli aggiornamenti rispetto all'ultima versione rilasciata; 
    (iv) 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 casi d'uso che documentano le funzionalit significative 
  esposte dal sistema verso gli attori (sistemi e utenti) che interagiscono col 
  sistema stesso, e in modo particolare le funzionalit di cooperazione 
  documentate negli RFC applicativi di riferimento; nella descrizione il 
  fornitore deve anche indicare quali funzionalit sono realizzate secondo 
  il modello ad eventi (modello Event Driven - EDA) e quali secondo il modello 
  a richieste di servizio (modello Service Oriented  - SOA).
  - descrizione testuale dei casi d'uso secondo il formato riportato in Sez.3.3.
  - diagrammi di sequenza e/o di collaborazione relativi agli scenari operativi 
  descritti dagli RFC di riferimento e comunque ritenuti significativi per 
  illustrare il funzionamento del proxy.
  Nella desctizione degli scenari in particolare occorre mostrare:
      - quali sono le funzionalit del Framework di cooperazione applicativa 
        invocate durante lo svolgimento dello scenario di cooperazione;
      - gli scenari di errore e il modo in cui essi sono gestiti;

Si osserva che i diagrammi devono focalizzare sulle interazioni che avvengono 
tra proxy applicativo e FCA (pubblicazione di eventi, ricezione di risposte, 
invocazione di servizi,  etc.) piuttosto che riportare il dettaglio delle 
interazioni che avvengono tra componenti interne al proxy.
   
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; 

2.1.2.2. 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 dell'Application Server 
  richiesta dal proxy applicativo a partire da una nuova installazione. 
  Questo include lindicazione di eventuali librerie richieste, certificati per 
  lautenticazione, impostazioni relative alla sicurezza;
  
  - un documento che descrive linstallazione, la configurazione e il formato 
  delle tabelle del database eventualmente utilizzato dal proxy; la descrizione 
  delle tabelle del database pu essere realizzata attraverso 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 linstallazione, la configurazione e il 
  funzionamento della applicazione di test che emula il SIL;
  
  - script di shell o descrittori Ant per la compilazione e l'esecuzione della 
  applicazione di test, (o per la creazione di archivi WAR/EAR nel caso si 
  tratti di una applciazione web).
  
  
2.1.2.3. Documentazione relativa allinterfaccia SIL - Proxy Applicativo
------------------------------------------------------------------------
Il fornitore del proxy applicativo deve provvedere documentazione che descrive 
linterfaccia 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];


2.2. Scheda riassuntiva dei requisiti per la certificazione di Proxy Applicativi 
(checklist)
================================================================================

2.2.1. Requisiti di Interoperabilit
------------------------------------
2.2.1.1. Interfaccia Proxy Applicativo  CRIC: Accesso al Sistema di 
Cooperazione
--------------------------------------------------------------------
Verfica 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?

2.2.1.2. 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 Sez.3.1?

2.2.1.3. Interfaccia Proxy Applicativo  SIL
--------------------------------------------
2.2.1.3.1. Scenario di Cooperazione per eventi
----------------------------------------------
Il formato XML degli eventi trattati dal proxy applicativo deve essere conforme 
a quello definito dagli RFC del dominio applicativo nel quale il proxy si 
colloca.
A seguito di ogni richiesta di pubblicazione di eventi da parte del SIL, il 
proxy deve pertanto validare il formato degli eventi in relazione allo schema 
XML descritto negli RFC di riferimento. 
  [] Il proxy effettua la validazione? 
  [] Inviando un evento non conforme al formato, il proxy notifica lerrore?
  
2.2.1.3.2. 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. Lapplicazione deve colloquiare col proxy richiedendo lo 
svolgimento di operazioni di pubblicazione, ricezione di eventi, richieste di 
servizio. Lapplicazione di test deve includere anche un insieme di dati da 
utilizzare a scopo di simulazione (e.g. eventi xml nel formato descritto dagli 
RFC). 
  [] Lapplicazione  presente?
  [] Lapplicazione svolge le operazioni di pubblicazione, ricezione eventi, 
  richieste di servizio?


2.2.2. 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) riportare il riferimento agli RFC applicativi del 
dominio per il quale il proxy  sviluppato; (iii) evidenziare gli aggiornamenti 
rispetto allultima versione rilasciata; (iv) includere un breve storico dei 
nuovi elementi o cambiamenti rilevanti introdotti in ogni precedente versione. 
  [] La documentazione / laggiornamento sono conformi?


2.2.2.1. Documentazione del Software
------------------------------------
2.2.2.1.1. Documentazione della interfaccia Proxy - CRIC
--------------------------------------------------------
Diagrammi UML di casi duso, diagrammi di sequenza e/o collaborazione, che 
illustrano gli scenari di cooperazione descritti dagli RFC e in particolare: 
  [] pubblicazione di eventi;
  [] invocazione di servizi; 
  [] accesso al repository degli eventi (ricezione, cancellazione di eventi.

I diagrammi devono focalizzare sulle interazioni che avvengono 
tra proxy applicativo e SoleFacade (pubblicazione di eventi, ricezione di risposte, 
invocazione di servizi,  etc.) piuttosto che riportare il dettaglio delle 
interazioni che avvengono tra componenti interne al proxy.

2.2.2.1.2. Documentazione del servizio di monitoraggio
------------------------------------------------------
La documentazione prodotta ai fini della certificazione dovr riportare:
  [] 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...).

2.2.2.1.3. Documentazione della architettura del proxy
------------------------------------------------------
Al fine della certificazione, dovr essere prodotta una documentazione che 
include:
  [] diagrammi di casi duso che documentano le funzionalit descritte negli 
  RFC di riferimento e comunque ogni funzionalit significativa esposta dal 
  proxy verso gli attori esterni (sistemi e utenti);
  [] Esiste indicazione del modello architetturale (EDA/SOA) con cui  
  realizzata ogni funzionalit di cooperazione?
  [] diagrammi di sequenza e/o di collaborazione relativi a scenari operativi 
  significativi;
    - [] Sono riportati i diagrammi relativi agli scenari descritti negli RFC?
    - [] Sono mostrate le interazioni tra proxy applicativo e componenti del 
    Framework di Cooperazione Applicativa (Sole Facade)?

Dove motivato dalla complessit, si richiedono inoltre:
  [] viste di deploy che mostrano la dislocazione dei componenti e i protocolli 
  di comunicazione;
  [] schemi architetturali complessivi che evidenziano i sottosistemi componenti 
  e le relazioni tra essi;
  
2.2.2.2. Documentazione di installazione, configurazione, esercizio
-------------------------------------------------------------------
Verificare che la documentazione riporti:
  [] descrizione relativa alla configurazione dell' Application Server 
  richiesta dal proxy applicativo a partire da una nuova installazione. 
  [] Eventuali librerie aggiuntive richieste, 
  [] certificati per lautenticazione, 
  [] impostazioni relative alla sicurezza;
  [] un documento che descrive linstallazione, la configurazione e il formato 
  delle tabelle del database eventualmente utilizzato del proxy; 
  [] un documento che descrive la procedura di deploy del proxy applicativo 
  sullApplication 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 linstallazione, 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.

2.2.2.3. Documentazione relativa allinterfaccia SIL - Proxy Applicativo
------------------------------------------------------------------------
Il fornitore del proxy applicativo deve provvedere documentazione che descrive 
linterfaccia 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.

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



2.3. Modalit di consegna del software e della documentazione dei Proxy 
Applicativi
=======================================================================
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 due directory principali:

  - ProxyApplicativo: contiene il proxy e la documentazione;
  - TestSuite: contiene la applicazione di test e la relativa documentazione 
  come descritto nella sezione relativa ai requisiti;
  
Nelle sezioni seguenti  riportato l'elenco dettagliato del contenuto delle 
directory.

2.3.1. ProxyApplicativo
--------------------------
La cartella "ProxyApplicativo" contiene la release del proxy e i documenti 
richiesti per la certificazione secondo quanto richiesto nella sezione relativa 
ai requisiti. In particolare essa dovr contentere tre files:
    
    - Proxy_<Nome-Proxy> - vers <XX> : archivio che contiene la release del 
    proxy applicativo nel formato descritto nel documento "Deploy di una 
    applicazione in ambiente NAL" [RT-DeployNAL]
    
    - 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.

2.3.2. TestSuite
-----------------
La cartella "TestSuite" include il codice e la documentazione per la suite di 
test come descritto  nella sezione relativa ai requisiti. Contiene due files: 
  
  - Documentazione_test_suite_<Nome-Proxy> - vers <XX>
    che descrive: i prerequisiti dellambiente di test (che dovr essere 
    facilmente riproducibile a partire dal server NAL nella sua configurazione 
    standard); come inizializzare lambiente di test sia con i dati di 
    simulazione forniti assieme alla test suite che con i dati reali 
    desercizio; come avviare la test suite; come valutare la correttezza o meno 
    dei risultati.
  
  - Suite:  un archivio internamente cos struttrato in 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;
      > data: directory che contiene gli eventi (in formato XML) da utilizzare 
      con la suite di test per lo svolgimento di operazioni di pubblicazione e 
      gli altri eventuali dati necessari;
      > conf: directory che contiene gli script di compilazione e di avvio della 
      applicazione e gli eventuali file di configurazione della applicazione.
      
La struttura della cartella TestSuite  quindi la seguente:

  TestSuite
  |
  |____ Documentazione
  |____ Suite(.zip, .tgz, .jar ... )
        |_____src
        |_____bin
        |_____lib
        |_____data                        
        |_____conf
              |____ compile.sh
              |____ run.sh
              |____ build.xml

oppure, nel caso in cui la test suite sia una applicazione web: 

  TestSuite  
  |
  |____ Documentazione
  |____ Suite(.zip, .tgz, .jar ... )
        |_____src
        |_____web (o bin)  
        |_____data        
        |_____conf
              |____ build.xml

dove "web"  la directory che contiene il contenuto (scompattato) dell'archivio
war dell'applicazione.


3. Il processo di certificazione di Proxy Applicativi
=====================================================
=====================================================
In questa sezione  descritto il processo con il quale si opera l'accertamento 
di conformit dei proxy applicativi ai requisiti presentati nelle sezioni 
precedenti. 
In particolare, la verifica di conformit attuata attraverso il processo ha un 
duplice obiettivo: 
- valutare la corretta operativit di applicazioni e servizi all'interno della
  infrastruttura di cooperazione di Regione Toscana. Questo include la verifica 
  di conformit ai requisiti imposti dal contesto applicativo e dalla 
  infrastruttura (documentati dagli RFC applicativi e infrastrutturali) e la 
  verifica di corretta operativit delle funzionalit realizzate dalla 
  applicazione;
- verificare la presenza di elementi di coerenza tra prodotti diversi dal punto 
  di vista della  organizzazione architetturale e della documentazione. 
  In questo senso, l'obiettivo della verifica di conformit  promuovere
  l'integrazione e il riuso di componenti e servizi; allo stesso tempo si 
  propone di abilitare la creazione di un archivio documentale di prodotti 
  forniti che descriva in maniera omogenea le funzionalit e la architettura dei 
  differenti applicativi.

Di seguito si presenta la procedura di certificazione del prodotto che include 
la descrizione in dettaglio delle attivit da svolgere da parte di fornitori, 
Comitato e.toscana Compliance e Centro tecnico per la e.Toscana Compliance.

3.1. Verifica di conformit di proxy applicativi
====================================================================
Il processo si divide in due fasi:
  1. Verifica di conformit del software applicativo attraverso il controllo 
  delle caratteristiche del codice sorgente e della qualit della 
  documentazione;
  2. Verifica di corretta operativit attraverso test di funzionamento  
  effettuati (anche in modo ridondante) in ambiente non critico (CRIC di test 
  dislocato sul TIX) allo scopo di individuare tempestivamente eventuali 
  malfunzionamenti e limitare l'impatto sull'ambiente di produzione; 
  A questa fase pu seguire (secondo le esigenze del Centro Tecnico e di 
  Regione Toscana) un monitoraggio in ambiente di produzione che 
  include: verifica di corretta integrazione e operativit con il sistema di 
  cooperazione; verifica di corretta operativit con il carico reale generato 
  dal sistema di cooperazione;
  
3.1.1. Verifica delle caratteristiche del software applicativo e della 
documentazione
----------------------------------------------------------------------
L'azienda fornitrice sviluppa il proxy applicativo presso la propria struttura 
utilizzando come riferimento la documentazione resa disponibile da Regione 
Toscana attraverso gli RFC. 

Quando una versione del proxy applicativo viene rilasciata, il fornitore deve 
provvedere:
 - il codice della applicazione;
 - la documentazione del progetto e del codice, entrambe allineate alla versione 
 rilasciata;

Documentazione e codice vengono validati da membri Centro Tecnico per la e.
Toscana Compliance in relazione ai requisiti di interoperabilit, di 
documentazione e architetturali.

3.1.2.   Verifica di operativit in ambiente di test
----------------------------------------------------------------------
L'ambiente di test  costituito dal CRIC di test e da due NAL (Carttestnal e il 
NAL del Centro Tecnico) su cui viene installato il proxy applicativo soggetto a 
verifica. Il test avviene attraverso la simulazione delle attivit che il proxy 
dovr svolgere nell'ambiente di produzione atteso esercitando almeno 
gli scenari documentati negli RFC del dominio applicativo per il quale il proxy 
 sviluppato.
In base alle indicazioni riportate nella documentazione allegata alla release 
del proxy applicativo, si effettua l'installazione di un ambiente operativo su 
CRIC di test e sul NAL Cartestnal e NAL del Centro Tecnico al fine di verificare 
le seguenti funzionalit: 
 - pubblicazione, ricezione e gestione di eventi immagazzinati nel repository 
   del NAL;
 - ricezione, soddisfacimento, inoltro di richieste di servizio;
 - validazione dei formati di eventi, richieste di servizio e messaggi di 
   risposta;
 - monitoraggio a livello sistemistico;

Le funzionalit sopra elencate sono verificate anche in relazione alla stima di 
utilizzo del sistema di cooperazione da parte del proxy e dei SIL che ad esso si 
riferiscono, come indicato dal fornitore nella documentazione allegata o 
richiesto da Regione Toscana.

In ogni fase del processo di verifica, la mancanza di conformit ai requisiti 
richiede tipicamente una fase di revisione del prodotto da parte del fornitore a 
cui seguir il rilascio di una nuova versione. Nel caso in cui, a seguito di una 
verifica, si ritiene che la revisione sia non conveniente e/o possibile, il 
prodotto  dichiarato definitivamente non conforme.
Nel caso in cui il fornitore sottoponga una nuova release, la procedura di 
certificazione descritta pu essere rilassata (la decisione  a discrezione del 
Comitato e Centro Tecnico e.toscana Compliance) evitando la ripetizione di 
alcune o tutte le attivit di  test superate con successo dalla release 
precedente. In tale caso il fornitore dovr provvedere opportuna documentazione 
con la quale dichiara che le modifiche apportate alla nuova release non hanno 
influenza sulle funzionalit gi testate.

 

              
4. Appendici
=======================================
=======================================

4.1. Formato XML del log di livello sistemistico
================================================
Lo schema xml riportato di seguito definisce il formato del log a livello 
sistemistico di un proxy applicativo.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="
qualified" attributeFormDefault="unqualified">
	<xs:element name="log">
     <xs:complexType>
			<xs:sequence>
       <xs:element name="log-entry" minOccurs="0" maxOccurs="unbounded">	
				<xs:complexType>
					<xs:sequence>
						<xs:element name="time" type="xs:dateTime"/>	
						<xs:element name="status" type="xs:string"/>
						<xs:element name="info" type="xs:string"/>
					</xs:sequence>
				</xs:complexType>
			</xs:element>	
     </xs:sequence>	
		</xs:complexType>
	</xs:element>
</xs:schema>

Un esempio di log conforme allo schema  riportato di seguito:

<?xml version="1.0" encoding="ISO-8859-1"?>
<log xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:noNamespaceSchemaLocation="log.xsd">
	<log-entry>
		<time>2004-08-01T13:20:00+01:00</time>
		<status>0</status>
		<info>Il proxy funziona correttamente</info>
	</log-entry>
	<log-entry>
		<time>2004-08-01T13:25:00+01:00</time>
		<status>2</status>
		<info>Fallito invio evento</info>
	</log-entry>
</log>


4.2. Esempio di documento XML Schema annotato
=============================================
Di seguito si riporta un esempio di un documento XML Schema che definisce un 
evento di tipo "nascita". Nel documento sono evidenziate le annotazioni che 
descrivono il significato dei tags previsti dallo schema.

Esempio: "nascita.xsd"

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="
qualified" attributeFormDefault="unqualified">
	<xs:element name="nascita">
		<xs:annotation>
      <xs:documentation xml:lang="IT">
      Descrizione dei dati relativi alla nascita
    </xs:documentation>
    </xs:annotation>
		<xs:complexType>
			<xs:sequence>
				<xs:element name="nome" type="xs:string">
					<xs:annotation>
           <xs:documentation xml:lang="IT">
              L'elemento contiene il nome del neonato
           </xs:documentation>
          </xs:annotation>
				</xs:element>
				<xs:element name="cognome" type="xs:string">
					<xs:annotation>
            <xs:documentation xml:lang="IT">
              L'elemento contiene il cognome del neonato
            </xs:documentation>
          </xs:annotation>
				</xs:element>
				<xs:element name="data" type="xs:date">
					<xs:annotation>
            <xs:documentation xml:lang="IT">
              Data di nascita
            </xs:documentation>
          </xs:annotation>
				</xs:element>
			</xs:sequence>
		</xs:complexType>
	</xs:element>
</xs:schema>

Un esempio di XML documento conforme allo schema riportato  il seguente:

<?xml version="1.0" encoding="ISO-8859-1"?>
<nascita xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:noNamespaceSchemaLocation="nascita.xsd">
	<nome>Giuseppe</nome>
	<cognome>Russo</cognome>
	<data>2004-02-29</data>
</nascita>


4.3. Esempio di descrizione di use case 
=======================================

   __________________________________________________________________________
  | ID Use Case           | USE_CASE_01                                      |
  |_______________________|__________________________________________________|
  | Nome Use Case         | Modifica Dati Residenza                          |
  |_______________________|__________________________________________________|
  | Attore Principale     | Applicazione SIL Anagrafe                        |
  |_______________________|__________________________________________________|
  | Attori Secondari      | Proxy Applicativo Anagrafe                       |
  |_______________________|__________________________________________________|
  | Descrizione           | ...                                              |
  |_______________________|__________________________________________________|
  | Precondizioni         | L'operatore ha inserito i dati di                |
  |                       |  residenza corretti nella interfaccia ...        |
  |_______________________|__________________________________________________|
  | Postcondizioni        | Il SIL ha ricevuto la notifica di accettazione   |  
  |                       |  dal proxy applicativo                           |                      
  |_______________________|__________________________________________________|
  | Scenario Principale   | 1. Il SIL valida i dati inseriti nella           |
  |                       |    interfaccia                                   |
  |                       | 2. Il SIL crea un Evento XML utilizzando i dati  |   
  |                       |    della interfaccia secondo il formato XMLSchema| 
  |                       |    "XMLSchema-comunicazione-variazione-          | 
  |                       |    anagrafica"                                   |
  |                       | 3. Il SIL invoca il servizio "PubblicaEventi"    |
  |                       |    del proxy                                     |
  |                       | 4. Il SIL riceve il messaggio "Acknowledge"      |
  |                       |    dal proxy                                     |
  |                       | 5. Il SIL visualizza sulla interfaccia l'esito   |
  |                       |    positivo della operazione                     |
  |_______________________|__________________________________________________|
  | Scenario Alternativo1 |                                                  |
  |_______________________|__________________________________________________|
  | Scenario Alternativo2 |                                                  |
  |_______________________|__________________________________________________|
  | Scenario Errore 1     | 1.a La validazione dei dati fallisce             |
  | "Fallimento           | 1.b L'applicazione mostra sulla interfaccia quali| 
  |  validazione dati"    | sono i campi non corretti                        |
  |                       | 1.c Lo use case termina                          |
  |_______________________|__________________________________________________|
  | Scenario Errore 2     |                                                  |
  |_______________________|__________________________________________________|



5. Bibliografia
=======================================
=======================================
[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 2.0, CART 
Regione Toscana
[RT-eCompliance] "Regione Toscana, Portale e.Toscana Compliance", 
http://web.rete.toscana.it/eCompliance
[RT-eComp-VisioneInsieme] "e.Toscana Compliance visione dinsieme", 
Direzione Generale Organizzazione e Sistema Informativo Area di Coordinamento 
Ingegneria dei Sistemi Informativi e della Comunicazione 

[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, 
http://www.w3.org/TR/wsdl 
