e.Toscana Compliance
Request for Comments:
Del: 20/11/2006
Categoria: Infrastrutturale

	Ciclo di vita di un Servizio CART

Abstract
========
La disponibilit di un nuovo servizio e.Toscana sulla piattaforma CART
richiede di stabilire un certo numero di accordi tra le parti e di
configurare adeguatamente i vari sistemi in gioco nella piattaforma. 
Si tratta di un processo estremamente critico, impattando fortemente
sull'interoperabilit, sulla flessibilit e sulla manutenibilit dei
servizi nel tempo.

Obiettivo di questo rfc e' quello di contribuire a formalizzare
l'intero ciclo di vita del servizio CART, aiutando a garantire
l'esecuzione delle procedure corrette in fase di progettazione,
predisposizione ed attivazione dei servizi CART.

Indice
======
1. Introduzione
2. Convenzioni
3. Definizioni
4. Fasi
5. Riferimenti
6. Note
7. Autori

1. Introduzione
===============
Obiettivo di questo documento  stabilire il ciclo di vita di un
servizio CART. Il processo si articola nelle seguenti fasi.
FASE  1 : definizione RFC Applicativo e.Toscana Standard
FASE  2 : produzione ASPC
FASE  3 : implementazione del servizio lato erogatore
FASE  4 : esposizione interfaccia server del servizio
FASE  5 : registrazione disponibilit del servizio (ASPC)
FASE  6 : (opzionale) negoziazione SLA, Sicurezza
FASE  7 : implementazione del servizio lato fruitore
FASE  8 : esposizione interfaccia client del servizio
FASE  9 : produzione ASPS
FASE  10 : registrazione attivazione del servizio
FASE  11: esercizio del servizio 
FASE  12: dismissione del servizio

Nel seguito del documento, indicheremo in dettaglio come realizzare
ognuna di queste fasi.

2. Convenzioni
==============
Da completare.

3. Definizioni
==============
Da completare

4. Fasi del ciclo di vita del Servizio
======================================

4.1. FASE  1: definizione RFC Applicativo e.Toscana Standard
------------------------------------------------------------
Questa fase  interamente descritta nell'RFC #17 "RFC Applicativo e.Toscana"
disponibile sul portale http://web.rete.toscana.it/eCompliance. Obiettivo
dellRFC Applicativo e.Toscana Standard  definire il protocollo di cooperazione
tra due o piu organizzazioni nellambito di un tema di interesse comune (Es. il
Protocollo informatico, il SUAP, la Sanita).

4.2. FASE 2: definizione ASPC 
----------------------------
Il primo documento che il soggetto Erogatore di un servizio deve produrre  il
documento ASPC (Accordo di Servizio Parte Comune). Obiettivo primario di ASPC 
descrivere (in modo non formale) e definire (in modo formale) le interfacce dei
servizi di cooperazione che devono essere realizzati per un certo dominio
applicativo.

La parte formale dellaccordo di servizio in particolare include:
- la descrizione del formato XML dei messaggi scambiati in ogni scenario di
cooperazione. Questa descrizione e effettuata attraverso un XMLSchema detto
WSDL definitorio (che rappresenta la sezione types di un WSDL).
- Un WSDL concettuale che descrive i servizi sia dal lato client che dal lato
server.
- Un WSDL logico dellerogatore e un WSDL logico fornitore che, partendo dal
WSDL concettuale, descrivono separatemente i servizi che devono essere
realizzati dallapplicazione erogatore e quelli che devono essere realizzati dal
fruitore. (Questi WSDL riferiscono il WSDL definitorio e aggiungono ad esso le
sezioni WSDL message e portType.)

Il contenuto e il formato dell'ASPC  descritto in dettaglio nell'RFC #1
"Accordo di Servizio Parte Comune" disponibile sul portale
http://web.rete.toscana.it/eCompliance.
 
4.3. FASE  3: implementazione del servizio lato erogazione
----------------------------------------------------------
Il soggetto erogatore del servizio adatta o realizza il software che implementa l'erogazione del servizio conformemente a quanto dichiarato nell'ASPC.
Il Soggetto Erogatore partendo dai documenti WSDL riportati nellASPC (WSDL definitorio e WSDL logico erogatore) dovr realizzarne l'implementazione e dovr generare il WSDL di implementazione che aggiunge al WSDL di ASPC le sezioni binding e service. 
Il soggetto erogatore dovr quindi fornire il software che implementa la parte di fruizione del servizio in accordo a quanto espresso nell'ASPC.
 

4.4. FASE  4: esposizione interfaccia server del servizio (Porta Applicativa)
-----------------------------------------------------------------------------
Il soggetto erogatore del servizio comunica al Gestore delle Componenti infrastrutturali periferiche le informazioni necessarie per esportare il servizio sull'infrastruttura.
Le informazioni necessarie per l'esportazione dell'interfaccia del servizio sull'infrastruttura sono:

  Parametro		Descrizione
  ------------------------------------------------------------
  Servizio (+)	nome del Servizio SPCoop
  ------------------------------------------------------------
  Nome (+)		nome della Porta Applicativa (identificativo del Service Provider)
  ------------------------------------------------------------
  Trasporto		il tipo di trasporto utilizzato per la consegna del messaggio (in generale https, a meno di specifiche eccezioni)
  ------------------------------------------------------------
  Tipo messaggi	tipo dei messaggi utilizzati (in generale soap, in accordo
			allo standard WS-I, a meno di specifiche eccezioni)
  ------------------------------------------------------------

In tabella con '*' sono indicati quei parametri che possono
avere pi di un valore, con '+' i parametri obbligatori.


4.5. FASE  5: registrazione disponibilit del servizio (ASPC)
------------------------------------------------------------
A questo punto il servizio  fruibile quindi l'ASPC viene registrato sul
Registro SICA Secondario. Il soggetto erogatore del servizio comunica al Gestore
delle Componenti infrastrutturali periferiche l'ASPC. Il Gestore delle
Componenti infrastrutturali periferiche provvede alla verifica del documento e
all'eventuale pubblicazione sul Registro SICA Secondario.

4.6. FASE  6: negoziazione SLA
------------------------------
Da completare

4.7. FASE  7: implementazione del servizio lato fruitore
--------------------------------------------------------
Il Soggetto Fruitore dovr realizzare:
 - il client che si interfaccia al servizio erogatore partendo dal WSDL di implementazione della parte di competenza dellerogatore a livello di scambio elementare dei messaggi (secondo quanto indicato nell'RFC #1)
- l'implementazione del servizio dalla parte del fruitore generando anche il WSDL di implementazione lato fruitore.

4.8 FASE  8: esposizione interfaccia client del servizio (Porta Delegata)
---------------------------------------------------------------------
Al momento della registrazione, per ogni porta delegata, andranno specificati i seguenti dati:

  Parametro		Descrizione
  ------------------------------------------------------------
  Servizio (+)		nome del Servizio SPCoop
  ------------------------------------------------------------
  Nome (+)		nome della Porta Delegata 
  ------------------------------------------------------------
  Trasporto		il tipo di trasporto utilizzato per la consegna del messaggio (in
			generale https, a meno di specifiche eccezioni)
  ------------------------------------------------------------
  Opzioni Dinamiche	eventuale presenza di opzioni dinamiche sulla porta
			delegata (url-based o content-based)
  ------------------------------------------------------------
  
L'interazione tra PdD e SIL puo avvenire in modalit passiva o attiva.
Nella modalit passiva la PdD contatta il SIL per consegnargli l'eventuale risposta all'invocazione di un servizio.
In modalit attiva  il SIL a richiedere alla PdD l'esito della richiesta di un servizio.
  
Nella modalit passiva il fruitore dovr registrare il proprio servizio di consegna indicando i seguenti dati:

  Parametro		Descrizione
  ------------------------------------------------------------
  URL Consegna		la URL del servizio esposto dal SIL a cui effettuare la consegna della risposta. 
  			Lurl sar utilizzato per la consegna di :
				- Risposte di tipo asincrone;
				- Sottoscrizione di eventi;
				- Risposte di tipo sincrono, in cui il SIL non sia riuscito a recuperare la risposta durante la stessa connessione http della richiesta (a causa di timeout o errori di altro tipo);

Nel caso, invece, in cui linterazione con il SIL sia attiva, al momento della
registrazione non dovr essere fornita ne unURLConsegna ne una ModalitConsegna.
Sar il SIL che dovr recuperare le buste arrivate, usando uno speciale servizio
offerto dal NAL. 
Questo servizio getMessage , illustrato nel seguito del documento, dovr essere utilizzato anche dal SIL che ha registrato una porta delegata con interazione passiva, qualora il servizio di consegna registrato diventi non pi disponibile al NAL (ad es. nel caso di una caduta momentanea del server http su NAL). 

Nella modalit attiva dovranno essere indicati i seguenti parametri:

  Parametro		Descrizione
  ------------------------------------------------------------
  ModalitConsegna 	Il tipo  specificato dalla ModalitConsegna e pu assumere i valori :
  				- WSDL. In questo caso il servizio di consegna  un WebService, e quindi la URL permette di ottenere lassociato WSDL;
				- HTTP_POST. In questo caso il servizio di consegna  un http Server, e la url ne identifica lindirizzo di accesso.


4.9 FASE  9 : produzione ASPS
-----------------------------
Il primo documento che il soggetto Fruitore di un servizio deve produrre  il documento ASPS (Accordo di Servizio Parte Specifica). 
Obiettivo primario di ASPS  descrivere (in modo non formale) e definire (in modo formale):
-	le interfacce dei servizi di cooperazione a livello implementativi che devono essere realizzati per un certo dominio applicativo
-	gli aspetti relativi ai livelli di servizio da rispettare (SLA)
-	gli aspetti relativi alla sicurezza

Il contenuto e il formato dell'ASPS  descritto in dettaglio nell'RFC #18 "Accordo di Servizio Parte Specifica" disponibile sul portale http://web.rete.toscana.it/eCompliance.


4.10 FASE  10 : registrazione attivazione del servizio
------------------------------------------------------
Il soggetto fruitore del servizio comunica al Gestore delle Componenti infrastrutturali periferiche le informazioni necessarie per esportare il servizio sull'infrastruttura.

Lerogatore del servizio deve comunicare al Gestore delle Componenti infrastrutturali periferiche un riferimento allASPC cui lASPS si riferisce e lintero ASPS.

Con questa fase terminano tutte le operazioni necessarie per limplementazione la pubblicazione di un servizio. A questo punto il servizio  erogabile e fruibile.
 
4.11 FASE  11: esercizio del servizio 
-------------------------------------
Questa  la fase di esercizio del servizio. Lerogatore e il fruitore cooperano scambiandosi informazioni in conformit a quanto dichiarato nellAS che  stato registrato. 


4.12 FASE  12: dismissione del servizio
---------------------------------------
La fase di dismissione (di una versione) del servizio prevede larchiviazione (della versione) del servizio e dellaccordo di servizio.
La fase di dismissione prevede la sottrazione (della versione) del servizio da
SPCoop, dopo annuncio preventivo ai titolari dei sistemi fruitori.

5. Riferimenti
==============
RFC pubblicati sul sito http://web.rete.toscana.it/eCompliance
- RFC #1, Accordo di Servizio Parte Comune (ASPC)
- RFC #17, RFC Applicativo e.Toscana
- RFC #18, Accordo di Servizio Parte Specifica (ASPS)

Documenti rilasciati dal Centro Nazionale per l'Informatica nella Pubblica Amministrazione (CNIPA): 
[CN1] SPC, Sistema pubblico di cooperazione: Architettura, Versione 1.0, CNIPA, 25 Novembre 2004
[CN2] SPC, Sistema pubblico di cooperazione: Porta di Dominio, Versione 1.0, CNIPA, 14 Ottobre 2005
[CN3] SPC, Sistema pubblico di cooperazione: Accordo di Servizio, Versione 1.0, CNIPA, 14 Ottobre 2005
[CN4] SPC, Sistema pubblico di cooperazione: Servizi di Registro, Versione 1.0, CNIPA, 14 Ottobre 2005

6. Note
=======
Nessuna

7. Autori
=========
Walter Volpi - walter.volpi@regione.toscana.i
