Servizi di Registro

Il quadro tecnico di riferimento per attuare la cooperazione applicativa tra le amministrazioni pubbliche nell’ambito del Sistema Pubblico di Connettività e Cooperazione è stato definito con l’approvazione, avvenuta nell’ottobre del 2004 da parte delle associazioni dei fornitori, delle amministrazioni partecipanti alla loro stesura e del Tavolo Congiunto Permanente della Conferenza Unificata Stato Regioni Città e Autonomie Locali, dei documenti che ne delineano l’architettura, l’organizzazione e le tecnologie standard da adottare.

Tali documenti hanno definito il “giusto” livello di condivisione che consente sia la maggiore stabilità nel tempo del modello rispetto al contesto organizzativo e tecnologico di riferimento, sia i necessari gradi di libertà per la sua implementazione. Il decreto legislativo

n.42 del 28 febbraio 2005 che istituisce il Sistema Pubblico di Connettività e Cooperazione, ne stabilisce i valori fondanti, la validità giuridica, nonché il modello di governo strategico ed operativo ed i ruoli del CNIPA e delle Regioni in tali ambiti.

I suddetti documenti tracciano un primo quadro di evoluzione del modello e definiscono gli ulteriori documenti di maggiore dettaglio da produrre per l'implementazione dei servizi previsti. La redazione di questi ultimi, come concordato, è stata portata avanti dal CNIPA ed ha dato luogo ai documenti di cui alla seguente tabella 1. Quest’ultimo insieme di documenti rappresenta le specifiche per la realizzazione e gestione dei servizi di cooperazione SPC e delle procedure di qualificazione, come già definito nei documenti approvati.

	Titolo Documento	Stato e Data Pubblicazione
1.	Sistema Pubblico di Cooperazione: QUADRO TECNICO D’INSIEME	Pubblicato V. 1.1 del 25/07/2011
2.	Sistema Pubblico di Cooperazione: TERMINI E DEFINIZIONI	Pubblicato V. 1.1 del 25/07/2011
3.	Sistema Pubblico di Cooperazione: ACCORDO DI SERVIZIO	Pubblicato V. 1.1 del 25/07/2011
4.	Sistema Pubblico di Cooperazione: PORTA DI DOMINIO	Pubblicato V. 1.1 del 25/07/2011
5.	Sistema Pubblico di Cooperazione: BUSTA DI E-GOV	Pubblicato V. 1.2 del 25/07/2011
6.	Sistema Pubblico di Cooperazione: SERVIZI DI REGISTRO	Pubblicato V. 1.1 del 25/07/2011
7.	Sistema Pubblico di Cooperazione: SERVIZI DI SICUREZZA	Pubblicato V. 1.1 del 25/07/2011
8.	Sistema Pubblico di Cooperazione: Convenzioni di nomenclatura e semantica	Pubblicato V. 1.1 del 25/07/2011
9.	Sistema Pubblico di Cooperazione: ESERCIZIO E GESTIONE	Pubblicato V. 1.1 del 25/07/2011

Tabella 1. Documenti di specifica del SPCoop

2.1.Scopo del documento

Il presente documento definisce dal punto di vista tecnico i Servizi di Registro SICA, delineandone i requisiti all’interno del modello di cooperazione applicativa. Per un inquadramento d’alto livello del modello di cooperazione applicativa da un punto di vista dettagliato e tecnico, si rimanda il lettore al documento QUADRO TECNICO D’INSIEME.

La redazione è stata ad opera di:

Xxxxxxx Xxxxxxx (Università di Roma “La Sapienza”); Xxxxxxx Xxxxxxx (CNIPA);

Xxxxxxx Xxxxxxx (Università di Roma “La Sapienza”); Xxxxxxxxx Xxxxxxxxxx (CNIPA).

2.2. Note di lettura del documento

Nella definizione dei requisiti, delle specifiche e delle regole descritte nei documenti precedentemente indicati sono utilizzate le parole chiave DEVE, NON DEVE, OBBLIGATORIO, VIETATO, DOVREBBE, CONSIGLIATO, NON DOVREBBE,

SCONSIGLIATO, POTREBBE, OPZIONALE che devono essere interpretate in conformità con [RFC2119]. In particolare:

DEVE, OBBLIGATORIO significano che la definizione è un requisito assoluto, la specifica deve essere implementata, la consegna è inderogabile.

DOVREBBE, CONSIGLIATO significano che in particolari circostanze possono esistere validi motivi per ignorare un requisito, non implementare una specifica, derogare alla consegna, ma che occorre esaminare e valutare con attenzione le implicazioni correlate alla scelta.

PUÒ, OPZIONALE significano che un elemento della specifica è a implementazione facoltativa.

NON DOVREBBE, SCONSIGLIATO significano che in particolari circostanze possono esistere validi di motivi per cui un elemento di specifica è accettabile o persino utile, ma, prima di implementarlo, le implicazioni correlate dovrebbero essere esaminate e valutate con attenzione.

NON DEVE, VIETATO significano che c’e proibizione assoluta di implementazione di un determinato elemento di specifica.

2.3. Note sul Copyright

Il presente documento ed i suoi contenuti sono di proprietà del Centro nazionale per l’informatica nella pubblica amministrazione (CNIPA) e sono protetti dalle norme sul diritto d’autore e dalle altre norme applicabili.

Il presente documento ed i suoi contenuti sono messi a disposizione sulla base dei termini della licenza d’uso disponibile al seguente indirizzo:

xxxx://xxx.xxxxxxx.xxx.xx/xxxxx/xxxxxxx/xxxxx/xxxxxxxx_xxx/Xxxxxxx_xxxx_xxxxxxxxx_XXX oop_v.2.0.pdf

3. Concetti di Base

In questa sezione sono riportati e riassunti per completezza alcuni concetti introdotti e sviluppati negli altri documenti SPC (§ 2), a cui il lettore è invitato a riferirsi ogniqualvolta sia necessario approfondire specifici dettagli. Il modello di cooperazione identifica due elementi base SICA1:

Servizi di registrazione e ricerca (Servizi di Registro SICA); Servizi di infrastruttura a chiave pubblica (AC SICA).

Si tratta di servizi multi-erogatore ad implementazione distribuita, erogati da sistemi di cui

sono responsabili soggetti della comunità SPCoop qualificati dal Comitato di gestione SPC. Il Comitato di gestione SPC è titolare e responsabile della erogazione di servizi SICA di valenza nazionale generale:

Registro SICA Generale;

Autorità di Certificazione (AC) Generale.

Le altre occorrenze dei Servizi di Registro SICA e AC SICA sono chiamate, per opposizione, Registri SICA Secondari e AC SICA Secondarie.

L’obiettivo del presente documento è la specifica dei servizi di registrazione e ricerca, così come la definizione dell’architettura del Registro SICA Generale e dei Registri SICA Secondari.

3.1.Requisiti dei Servizi di Registrazione e Ricerca

I Servizi di Registrazione e Ricerca, indicati brevemente anche come Servizi di Registro SICA, devono gestire le informazioni sullo stato delle risorse seguenti:

soggetti organizzativi2 (indicati brevemente come soggetti) della comunità SPCoop,

servizi presentati su SPCoop, di cui i soggetti sono titolari, con i relativi accordi di servizio ed i punti di accesso a tali servizi,

domini di cooperazione, con i relativi soggetti partecipanti e gli accordi di cooperazione.

1 Gli elementi base del SICA sono quelli senza i quali l’intero modello di cooperazione non può essere realizzato. Pertanto essi saranno realizzati sin da subito e la loro specifica viene fornita in modo dettagliato (negli opportuni documenti); gli altri elementi invece, come è descritto nel documento QUADRO TECNICO D’INSIEME, verranno approfonditi successivamente alla realizzazione degli elementi base, e realizzati in maniera evolutiva in un secondo momento.

2 In questo documento si utilizza il termine specifico soggetto organizzativo, e non quello generico di soggetto, per distinguere l’Indice a cui si fa qui riferimento dal Servizio di Indice dei Soggetti, che è un elemento infrastrutturale SICA. In quello infatti i soggetti sono gli utenti umani/operatori delle PA centrali, mentre nei Servizi di Registro SICA il termine soggetto deve essere utilizzato come sinonimo di organizzazione/dominio che eroga/fruisce di servizi applicativi.

Ogni modifica sugli stati di tali risorse deve essere persistente e durevole, e la relativa transizione di stato deve essere non decomponibile (atomica) ed isolata: i Servizi di Registro SICA devono pertanto assicurare la coerenza degli stati delle risorse attraverso una gestione transazionale.

L’architettura SPCoop specifica un accordo di servizio per i Servizi di Registro SICA, indicato nel proseguo del documento come AS di Registro; esso, coerentemente con la specifica degli accordi di servizio, è costituito da una parte comune e da una parte specifica, che sarà differente in ognuna delle differenti implementazioni (occorrenze) dei Servizi di Registro SICA.

Una occorrenza dei Servizi di Registro SICA deve essere accessibile, oltre che ai sistemi delle organizzazioni della comunità SPCoop, agli utenti afferenti alle organizzazioni della comunità SPCoop, per mezzo di una interfaccia utente. L’interfaccia utente può essere utilizzata dagli amministratori - utenti che agiscono sotto la responsabilità dei soggetti della comunità SPCoop - per inserire, aggiornare e cancellare le informazioni sulle risorse di cui tali soggetti sono responsabili. L’interfaccia utente è utilizzata dai responsabili e dai progettisti dei sistemi fruitori attuali e potenziali dei servizi, nelle fasi di analisi e progettazione, per ottenere informazioni sui soggetti, i servizi, gli erogatori, gli accordi di servizio e gli indirizzi dei punti di accesso.

La specifica SPCoop e l’AS di Registro non contengono alcuna specifica del “look & feel” (aspetto visuale) dell’interfaccia utente dei Servizi di Registro SICA. Si osservi però, che la specifica SPCoop e l’AS di Registro dettagliano le funzionalità offerte dai Servizi di Registro SICA, da rendere disponibili tramite tale interfaccia utente, e la loro articolazione.

La concezione e l’implementazione di tale interfaccia è lasciata alla libera scelta dei singoli titolari delle occorrenze dei Servizi di Registro SICA. Le specifiche dell’interfaccia utente del Registro SICA Generale verranno prodotte dal Comitato di gestione SPC e potranno essere utilizzate per implementare le interfacce utente dei Registri SICA Secondari. Al solo scopo di evitare confusioni, la presentazione visiva dell’interfaccia utente di un Registro SICA Secondario deve poter essere distinta facilmente dalla presentazione del Registro SICA Generale, la cui riproduzione esatta e completa in un Registro SICA Secondario è comunque rigorosamente vietata.

Dal punto di vista funzionale, i Servizi di Registro SICA devono offrire le seguenti funzionalità (che saranno dettagliate nel proseguo del documento):

gestione dell’indice dei soggetti (organizzativi) della comunità del SPCoop;

gestione del catalogo degli accordi di servizio e cooperazione sottoscritti e implementati su SPCoop;

gestione dell’elenco degli erogatori presenti suSPCoop;

gestione della rubrica degli indirizzi dei punti di accesso dei sistemi erogatori e fruitori.

Indice dei Soggetti Organizzativi. Il primo passo nella costruzione dei Servizi di Registro SICA è la costruzione dell’indice dei soggetti organizzativi. L’identificazione di tali soggetti organizzativi pubblici e privati è un compito svolto dal Comitato di gestione SPC, che rilascia al soggetto un codice identificatore unico (formato URI/URN) nell’ambito di SPCoop. Il dominio di un soggetto è rappresentato dal soggetto stesso (c’è identità tra soggetto e dominio). L’attuale Indice delle Pubbliche Amministrazioni (IPA) deve essere assunto come base di partenza per la realizzazione di tale struttura.

Catalogo degli Accordi di Servizio e Cooperazione. L’accordo di servizio e/o di cooperazione è rappresentato da un insieme di documenti, così come specificato nell’apposito documento. L’accordo ha un codice identificatore in formato URI/URN in conformità con lo standard SPCoop; tale codice identificatore è unico in ambito SPCoop, formato secondo le regole SPCoop. L’accordo di servizio/cooperazione deve essere registrato nei Servizi di Registro SICA, in cui viene effettuato un controllo di universalità del codice identificatore in ambito SPCoop (nei fatti tale controllo riguarda la possibilità che un soggetto responsabile possa registrare due accordi con lo stesso nome).

A partire dalla registrazione dell’accordo di servizio, è possibile poi registrare le occorrenze di erogazione del servizio conforme all’accordo.

L’insieme dei documenti di un accordo di servizio/cooperazione è composto da documenti in testo libero e da documenti XML. La base documentaria che implementa il catalogo degli accordi permette delle ricerche sul contenuto dei documenti (in full text per i documenti in testo libero e utilizzando XQuery / XPath per i documenti XML), in maniera da ottenere logicamente un catalogo degli schemi.

Elenco delle Occorrenze dei Servizi. La costituzione dell’indice dei soggetti e del cataloghi degli accordi permette in seguito la registrazione delle occorrenze di erogazione dei servizi. Le occorrenze dei servizi possono essere identificate se il titolare è identificato e registrato. Le occorrenze di erogazione dei servizi SPCoop sono dotate di un codice identificatore unico in formato URI/URN standard SPCoop, costruito combinando l’identificatore universale del soggetto SPCoop (titolare dell’occorrenza di erogazione del servizio) e l’identificatore del relativo accordo di servizio (registrato nel catalogo degli accordi). Ne consegue che un servizio SPCoop può essere registrato solo dopo la registrazione del soggetto SPCoop titolare e dell’accordo di servizio, in accordo con le regole del ciclo di vita dei servizi che indicano che la presentazione del servizio applicativo su SPCoop è successiva alla registrazione dell’accordo di servizio.

Rubrica degli Indirizzi dei Punti d’Accesso. Per ogni occorrenza di servizio, il titolare può registrare più punti di accesso (punti d’accesso SPCoop). La struttura di registrazione3 contiene come elemento l’indirizzo del punto di accesso principale e degli eventuali punti d’accesso secondari a cui rivolgersi in caso di malfunzionamenti, errori, periodi di manutenzione, ecc .

3.2. Utilizzo a “design-time” ed a “run-time”

I Servizi di Registro SICA vengono utilizzati durante la fase di progettazione e realizzazione

dei servizi applicativi SPCoop, dai progettisti dell’erogatore e del fruitore, al fine di:

registrare l’accordo di servizio (eventualmente l’accordo di cooperazione nel caso di servizio offerto da un dominio di cooperazione) affinché assuma valore di riferimento,

accedere alle informazioni necessarie allo sviluppo dei Web Service lato erogatore e lato fruitore.

3 Si ricorda che gli indirizzi dei punti d’accesso sono mantenuti nella parte specifica dell’accordo che regola il servizio stesso.

Proprio al fine di supportare il “design-time” di nuovi servizi applicativi SPCoop, i Servizi di Registro SICA permettono di effettuare richieste del tipo (il seguente elenco ha solo uno scopo esemplificativo):

ricercare tutti i servizi di cui è titolare un determinato soggetto (ciò corrisponde al Dominio dei Servizi Applicativi – DSA – del soggetto in questione),

ricercare l’accordo di servizio (comprensivo di tutte le sue parti) di un servizio, ricercare l’insieme dei soggetti erogatori di un servizio (servizio multi-erogatore), ricercare il soggetto responsabile dell’accordo di servizio di un servizio multi-erogatore,

ricercare l’insieme dei punti di accesso dei soggetti erogatori di un servizio multi- erogatore,

ricercare, a partire da un accordo di cooperazione, l’insieme degli accordi di servizio indipendenti (a cui l’accordo di cooperazione fa riferimento),

ricercare le coordinate dell’utente responsabile di una porta di dominio, ricercare il coordinatore e i soggetti componenti di un dominio di cooperazione,

che sono tutte operazioni che permettono di recuperare informazioni che possono essere utili

durante la fase di progettazione e realizzazione di un servizio.

Durante la fase di esecuzione di un servizio (per essere precisi dei Web Service lato erogatore e lato fruitore), il Servizio di Registro SICA non offre meccanismi di supporto automatizzato, in quanto la comunicazione è diretta tra i due soggetti.

In particolare, durante il “run-time” dei servizi applicativi SPCoop, eventuali errori dovuti ad indisponibilità dei porti di accesso dell’erogatore vengono gestiti in modo differente a seconda della causa che ha provocato il malfunzionamento:

(a) Il lato erogatore non è temporaneamente disponibile (ad es., a causa di una manutenzione programmata); in questo caso, la parte specifica dell’accordo di servizio che lo descrive dovrebbe contenere non solamente l’indirizzo del porto d’accesso principale, ma anche quelli di eventuali porti secondari da contattare in casi del genere 4; in tal caso, è la logica applicativa del lato fruitore (sviluppata coerentemente con l’accordo di servizio recuperato a suo tempo durante il relativo design-time) che gestisce l’eventuale meccanismo di recupero. Emerge come i Servizi di Registro SICA non hanno impatto sul funzionamento attuale dei due soggetti, i quali hanno costruito i loro sistemi coerentemente con l’accordo di servizio a suo tempo recuperato dai Servizi di Registro SICA5.

4 In particolare, le possibili cause di interruzione programmate (ad es. manutenzione) sono dichiarate nella sezione dell’accordo di servizio relativa alla specifica dei livelli di servizio, ed i porti (sia quello principale che gli eventuali secondari) nella parte relativa ai porti di accesso.

5 Si osservi come eventuali cambi dei porti di accesso dovuti a sostituzioni/dismissioni degli elaboratori presso cui erano in precedenza dispiegati i Web Service non dovrebbero, in caso di buona progettazione e gestione, essere visibili a questo livello. Infatti la porta di dominio funge da proxy applicativo, e pertanto maschera l’effettivo dispiegamento interno degli elaboratori: a fronte di un indirizzo di un porto d’accesso (che è espresso come una URL/URN specifica in formato “simbolico”), essa opera una traduzione in indirizzi fisici, interni al dominio, dell’effettivo elaboratore di dispiegamento del servizio, mascherandolo quindi completamente verso l’esterno. Nelle parti opportune degli accordi di servizio non devono essere visibili tali indirizzi fisici, ma quelli “simbolici”. Analogamente, nei casi in cui i soggetti cooperanti

(b) Il lato erogatore non rende più disponibile il dato servizio, in quanto esso è stato dismesso (insieme al relativo accordo di servizio) e sostituito da una versione successiva (a cui corrisponde un nuovo accordo di servizio, cfr. § 5). In tal caso, i soggetti interessati devono recuperare dai Servizi di Registro SICA 6 le nuove versioni dell’accordo di servizio, e sulla base di queste sviluppare nuovamente (quindi nuova fase di “design-time”) i rispettivi Web Service.

Al fine di supportare il più possibile questo scenario, i Servizi di Registro SICA offrono dei meccanismi di notifica, attraverso cui i soggetti interessati vengono a conoscenza della dismissione di un accordo di servizio (e della registrazione di una nuova versione) e possono di conseguenza attivare le opportune procedure per lo sviluppo dei rispettivi Web Service.

3.3. Differenza tra Repository e Registry

Un aspetto che va sottolineato è la differenza che esiste in letteratura tra il concetto di

repository e quello di registry:

Un repository è un contenitore di informazioni, che offre funzionalità (i) di indicizzazione su tali informazioni, e (ii) di accesso e gestione delle stesse. Ad esempio, nel caso in cui le informazioni siano Accordi di Servizio, un repository memorizzerebbe i documenti stessi che costituiscono un Accordo di Servizio, indicizzandoli e permettendo accessi “avanzati” ad essi (e.g., la ricerca di tutti gli accordi di servizio che trattano servizi con una macchina a stati del loro comportamento di forma specifica).

vogliano rendere disponibili più porti d’accesso, essi sono “simbolici” e rappresentano punti alternativi (in cui il significato di alternativo è dato dall’accordo di servizio stesso, in particolare dalla specifica dei livelli di qualità) presso cui il servizio è fruibile.

6 Si noti che questo processo è manuale, eseguito da operatori umani, e non automaticamente eseguito da particolari software adattivi.

Repository

(contenuto ed indici gestiti da un unico soggetto omogeneo)

Registry

(contenuto controllato da soggetti differenti ed eterogenei rispetto al gestore degli indici)

indici contenuto (accordi di servizio)

contenuto (accordi di servizio) in sistemi eterogenei

indici

Figura 1. Differenza fra repository e registry

Un registry invece non è un contenitore di informazioni, ma di soli “puntatori” a tali informazioni, e pertanto può offrire solo funzionalità di indicizzazione a tali informazioni. Ad esempio, nel caso in cui le informazioni siano Accordi di Servizio, un registry memorizzerebbe i riferimenti ai documenti che costituiscono un Accordo di Servizio, indicizzandoli; i documenti dovrebbero poi essere ospitati altrove (e.g., presso l’erogatore stesso del servizio) e l’accesso “avanzato” ad essi sarebbe molto più macchinoso (in quanto dovrebbe risolvere un’indirezione presso il sistema di memorizzazione, in generale eterogeneo rispetto al registry stesso).

In Figura 1 è mostrata intuitivamente la differenza tra repository e registry. In base alle considerazioni suddette, emerge che a dispetto del nome i Servizi di Registrazione e Ricerca SICA richiedono un repository e non dei semplici registry7.

7 Si ricorda inoltre che lo standard UDDI prescrive l’interfaccia applicativa per un registry di descrizioni di Web Service. Questo però non proibisce una possibile realizzazione di un repository attraverso un registry UDDI, esteso (i) con il supporto alla memorizzazione presso lo stesso soggetto che ospita il registry, e (ii) adeguati livelli software che permettano ricerche basate sul contenuto e nascondano completamente l’indirezione.

4. ARTICOLAZIONE DEI SERVIZI DI REGISTRO SICA

I Servizi di Registro SICA sono organizzati in modo distribuito attraverso un’architettura

master-slave con replicazione dell’informazione, come rappresentato in Figura 2. In particolare:

esiste un’occorrenza dei Servizi di Registro SICA, indicata brevemente come Registro SICA Generale, che contiene la totalità delle informazioni necessarie all’erogazione delle funzionalità;

esistono un numero N di occorrenze dei Servizi di Registro SICA, indicate brevemente come Registri SICA Secondari, che contengono delle viste (i.e., sottoinsiemi, non necessariamente disgiunti) di tali informazioni, definite secondo differenti criteri (e.g., localizzazione geografica, per affinità funzionale, per affinità rispetto all’erogatore, ecc.)8: un’informazione presente in un Registro Secondario è sicuramente presente nel Registro Generale, ma non necessariamente il viceversa (possono esserci informazioni mantenute nel solo Registro Generale e non replicate in nessun Registro Secondario).

Sia il Registro Generale che i Registri Secondari offrono, attraverso opportune interfacce, due differenti categorie di funzionalità:

funzionalità specifiche di registrazione e ricerca, attraverso cui i client possono eseguire interrogazioni sull’informazione mantenuta nel registro ed operare gli opportuni aggiornamenti all’informazione di propria pertinenza ( ad es., quando un nuovo servizio viene offerto);

funzionalità di gestione e monitoraggio, attraverso cui i soggetti gestori dei registri e/o soggetti di controllo e garanzia possono (i) recuperare informazioni di tracciatura di tutte le operazioni effettuate, statistiche varie, ecc. necessarie a risolvere eventuali controversie, e (ii) eseguire operazioni di gestione ed amministrazione del Servizio di Registro SICA a valenza generale (cfr. § 5.1.2). Tra queste una particolarmente significativa per il Registro Generale è quella di iscrizione di un nuovo Registro Secondario, che abilita quest’ultimo alle operazioni necessarie per mantenere la sincronizzazione della vista offerta.

Entrambe le categorie di funzionalità vengono offerte attraverso due interfacce, (i) una applicativa, dispiegata come un Web Service, ed (ii) una utente per client umani, dispiegata attraverso un’opportuna interfaccia Web/HTML. Le interfacce applicative di tipo Web Service per entrambe le categorie di funzionalità verranno esaminate in § 5, mentre si rimanda a successivi documenti l’indicazione di linee guida per l’interfaccia utente di tipo Web/HTML.

8 Un Registro Secondario può essere definito da opportune organizzazioni quando si sceglie di aggregare un insieme di informazioni; tipici esempi potrebbero essere:

una Regione che definisce un Registro Secondario per offrire i servizi di registrazione e ricerca su tutti i servizi offerti da soggetti situati sul proprio territorio (vista definita per localizzazione geografica);

una Pubblica Amministrazione con uffici sia centrali che periferici che definisce un Registro Secondario per offrire una vista su tutti i servizi offerti dalle proprie strutture (e.g., il Ministero dell’Interno con tutte le Prefetture);

una terza parte accredita che offre un Registro Secondario con tutti i servizi che sono utili su una particolare tematica (vista definita per affinità funzionale).

Funzionalità specifiche di registrazione e ricerca, offerte:

- in modalità applicativa (Web service)

- attraverso un’interfaccia utente di tipo Web

Funzionalità di gestione e monitoraggio, offerte:

- in modalità applicativa (Web service)

- attraverso un’interfaccia utente di tipo Web

Registro Generale

gestore

notifiche di cancellazioni e dismissioni (push)

Registro Secondario 1

… … …

propagazione

(pull)

estrazione

(pull)

Registro Secondario N

client

Figura 2. Articolazione complessiva dei Servizi di Registro SICA.

L’architettura interna dei vari registri verrà dettagliata in Figura 9 e Figura 10

Si osservi che un client che voglia accedere alle funzionalità specifiche di registrazione e ricerca (per effettuare inserimenti/aggiornamenti/cancellazioni) può scegliere se operare presso il Registro Generale ovvero presso uno dei Registri Secondari, selezionato secondo suoi esclusivi criteri9. Nel caso in cui un client decida di operare un inserimento presso un Registro Secondario, il Registro Secondario stesso assume il ruolo di steward (“responsabile”) per l’informazione in esame: questo significa che quando il client voglia operare una successiva operazione di aggiornamento/cancellazione, esso può operare o presso il Registro Generale o presso il Registro Secondario steward, e non può più rivolgersi agli altri Registri Secondari10.

9 È però ipotizzabile che un client, nel caso opti per l’acceso ad un Registro Secondario, ne selezioni uno che realizza una vista particolarmente significativa ai fini del client stesso; ad es., è ipotizzabile che un Comune che voglia registrare un nuovo servizio che verrà fruito prevalentemente a livello regionale, lo registri presso un eventuale Registro Secondario con vista definita su criteri geografici regionali. Ovviamente il client può sempre optare per registrare il servizio sul Registro Generale ed affidarsi ai meccanismi nel seguito descritti per avere massima diffusione della cosa.

10 Questo significa che le scelte possibili per un client sono (assumendo di avere N Registri Secondari):

Come indicato in Figura 2, esiste inoltre un meccanismo di sincronizzazione tra il Registro Generale ed i Registri Secondari, in particolare:

(a) Un Registro Secondario può recuperare l’informazione aggiornata dal Registro Generale, necessaria a realizzare e mantenere aggiornata la propria vista; tale operazione di estrazione avviene in due casi: (i) su iniziativa del Registro Secondario, secondo modalità di sua esclusiva competenza, oppure (ii) quando esso viene notificato (vedere oltre per dettagli) che una modifica di aggiornamento/cancellazione è stata eseguita nel Registro Generale; è necessario che un Registro Secondario tenga traccia del timestamp dell’ultima estrazione effettuata, e permetta ai suoi client di accedere a tale informazione.

(b) Quando un inserimento/aggiornamento/cancellazione viene effettuato in un Registro Secondario:

1. questi è vincolato a propagare l’informazione verso il Registro Generale, che per sua natura deve essere sempre aggiornato ed è il punto di riferimento dell’architettura; tale operazione di propagazione avviene su iniziativa del Registro Secondario presso cui è stata effettuata l’operazione di modifica dell’informazione, che è però vincolato ad eseguirla contestualmente all’operazione stessa11;

2. a sua volta, il Registro Generale, dopo aver ricevuto la propagazione dell’inserimento/aggiornamento/cancellazione, notifica ai Registri Secondari interessati l’evento;

3. i Registri secondari possono o meno eseguire un’operazione di estrazione: questa è obbligatoria nel caso di aggiornamenti/cancellazioni che riguardano informazioni presenti nella propria vista, ed è opzionale (cioè su iniziativa esclusiva del Registro Secondario) in caso di inserimenti.

Mentre l’operazione di inserimento può avvenire in qualsiasi Registro Secondario, le operazioni di aggiornamento/cancellazione devono avvenire presso il Registro Secondario steward dell’informazione in esame.

(c) Quando un inserimento/aggiornamento/cancellazione viene effettuato nel Registro Generale, esso lo notifica a tutti; a loro volta i Registri Secondari:

1. nel caso di inserimento, possono operare un’estrazione, oppure non eseguirla ed eventualmente recuperare la nuova informazione quando eseguiranno un’estrazione secondo la loro organizzazione;

2. in caso di aggiornamento/cancellazione, e l’informazione è mantenuta anche nella loro vista, necessariamente devono eseguire una nuova estrazione al fine di offrire una vista corretta in base alle modifiche intercorse.

1 + N in caso di inserimento (può rivolgersi al Registro Generale od ad uno qualsiasi dei Registri Secondari);

2 (= 1 + 1) in caso di aggiornamento/cancellazione (può rivolgersi al Registro Generale od al Registro Secondario steward).

11 Da un punto di vista funzionale, il client del Registro Secondario presso cui è stata eseguita l’operazione di modifica, non può ricevere una conferma di operazione effettuata fino a quando la propagazione con il Registro Generale non sia andata a buon fine.

(d) Non si ha mai il caso del Registro Generale che vada ad estrarre informazioni dai Registri Secondari, in quanto questo è sempre aggiornato automaticamente in base al vincolo di propagazione.

L’operazione di estrazione può avvenire sia (i) in modalità incrementale che (ii) in modo completo: nel primo caso viene estratto un Δ informativo che permette, applicandolo alla vecchia, di costruire la nuova vista, ovvero (intuitivamente):

nuova vista = vecchia vista + Δ

mentre nel secondo caso viene riestratta completamente la nuova vista che sovrascrive la vecchia. I Servizi di Registro SICA (ed in particolare l’occorrenza Registro Generale) offrono interfacce applicative per supportare entrambe.

Si osservi che la vista di un Registro Secondario è costituita dalla definizione della vista stessa (tecnicamente intensione della vista), e dai valori effettivamente contenuti in un dato momento nel Registro Secondario (tecnicamente estensione della vista); ad es., supponendo12 che il Registro Generale sia una base di dati relazionale, la definizione della vista è una query complessa 13, che quando eseguita sul Registro Generale, ritorna un insieme di tuple (organizzate in tabelle relazionali) – i valori della vista – che viene materializzato/memorizzato nel Registro Secondario. La definizione della vista viene decisa al momento della creazione del Registro Secondario, e non può essere modificata durante il ciclo di vita del Registro Secondario 14; viceversa i valori cambiano nel tempo, secondo i meccanismi qui definiti.

Emerge quindi come il rapporto che si instaura tra Registro Generale e Registri Secondari sia di tipo master-slave, in cui il Registro Generale funge da master (riferimento) per l’informazione, ed i Registri Secondari possono replicare (parti di) tale informazione; in sostanza, è come se il Registro Generale fosse la memoria principale di un elaboratore, ed i Registri Secondari fossero la cache: la memoria principale è sempre il riferimento, ed ogniqualvolta vi è un’operazione di scrittura in cache, questa deve essere propagata verso la memoria principale; analogamente, talvolta la cache viene invalidata ed è necessario riaccedere alla memoria principale per recuperarne la versione più aggiornata. L’analogia si completa tenendo conto che se un client di un Registro Secondario ricerca informazioni su un servizio e non le trova, non ha la certezza che il servizio non esista (ad esempio, il servizio è stato appena inserito dall’erogatore interagendo con il Registro Generale, ma il Registro Secondario non ha ancora operato – o secondo le sue policy non ha voluto operare - un’estrazione per aggiornarsi); tale certezza è possibile solo dopo aver verificato anche nel Registro Generale; analogamente avviene in caso di “miss” nella cache.

Al fine di realizzare questi meccanismi di sincronizzazione, un’opportuna infrastruttura applicativa (mostrata sempre in Figura 2) interconnette tutti i Registri. Tale interfaccia per le operazioni di estrazione, propagazione e notifica è di tipo Web Service, e non ha un equivalente per utenti umani. In base ai differenti ruoli che hanno nell’architettura, tale interfaccia (e la relativa porzione dell’Accordo di Servizio) del Registro Generale sarà differente da quelle (e

12 Si tratta ovviamente di un esempio fittizio, in quanto i Servizi di Registro SICA contengono prevalentemente documenti XML (le varie parti degli Accordi di Servizio) e non è definito un linguaggio di interrogazione generico “a-la” SQL, ma verranno offerte opportune operazioni applicative (che, proseguendo la metafora, equivale a dire che sono offerte delle “query SQL” prestabilite).

13 Ad es., per il Registro Secondario della Regione X, sarebbe “seleziona tutti gli accordi di servizio in cui l’erogatore è situato nella Regione X”.

14 Questo perché non esistono ancora metodi maturi per risolvere il problema della consistenza tra diverse definizioni di viste, ma l’argomento è tuttora oggetto di attività di ricerca. Nel sistema SPCoop, cambiare la definizione di una vista, equivale a creare un nuovo Registro Secondario.

dalle relative porzioni degli Accordi di Servizio) dei Registri Secondari. In particolare, le operazioni di notifica non saranno realizzate attraverso dei middleware specifici, ma per omogeneità con l’interfaccia di tipo Web Service che viene utilizzata per l’estrazione e la propagazione, saranno anch’esse realizzate attraverso delle opportune operazioni di callback offerte dall’interfaccia di tipo Web Service.

In § 6 (in particolare Figura 9 e Figura 10) verrà dettagliata l’architettura dei Registri SICA, come emerge dalle considerazioni precedenti.

In base ai meccanismi precedentemente descritti, dal punto di vista esterno del client i Servizi di Registro SICA sono unici (indipendentemente dal Registro di accesso) e possono essere descritti in modo unitario; questo è il motivo della particolare forgia della Figura 2 in cui il client è raffigurato esternamente a tutti i Registri. La specifica di queste funzionalità di accesso dal punto di vista esterno del client saranno l’oggetto della § 5.

Per quanto riguarda la modalità di interazione tra un client ed i Servizi di Registro SICA, essa è di tipo asincrono basata su scambio di messaggi; questo è particolarmente significativo nel caso che un client richieda un inserimento/aggiornamento/cancellazione presso un Registro Secondario: esso non rimane bloccato in attesa della risposta durante tutto il lasso di tempo in cui viene operata la propagazione verso il Registro Generale (che in generale, a causa di guasti, fallimenti, ecc., potrebbe richiedere anche un tempo considerevole), ma riceverà in modo asincrono la notifica di avvenuta operazione.

Chiaramente i Servizi di Registro SICA devono essere opportunamente gestiti e monitorati. In Figura 2 questo è indicato dalla presenza di un attore di tipo Gestore che utilizza un’opportuna interfaccia offerta dal Registro Generale. Contrariamente all’attore Client, che dispone di un’interfaccia funzionale anche sui Registri Secondari, il Gestore deve sempre rivolgersi al Registro Generale per eseguire le proprio operazioni. Si osservi che tale gestione e monitoraggio non riguarda gli aspetti sistemistici dell’infrastruttura applicativa informatica (che chiaramente è disponibile anche sui Registri Secondari), ma quelle operazioni di gestione d’alto livello del sistema nella sua interezza. La gestione sistemistica è infatti parte di ogni Registro, ma essendo specifica della singola implementazione ed interna, non riguarda il presente documento. Tutti questi aspetti verranno affrontati in dettaglio in § 5.1.2 ed in § 6.

Come anticipato nella § 3.2, i Servizi di Registro SICA supportano lo sviluppo di nuovi servizi, e la rispettiva evoluzione, prevalentemente nella fase di progettazione (design -time). A tal riguardo, una funzionalità significativa dal punto di vista dei potenziali client (ovvero i progettisti all’interno dei vari soggetti organizzativi) è la possibilità di ricevere notifiche ogniqualvolta un nuovo servizio viene inserito/aggiornato/modificato. Tali notifiche, che devono essere fruibili da utenti umani, hanno il formato tipico della posta elettronica (HTML/MIME), e vengono veicolate al di sopra dei protocolli di posta elettronica (certificata). Pertanto i Servizi di Registro SICA, attraverso l’interfaccia di registrazione e ricerca, permettono ai client di sottoscriversi ad eventi di inserimento/aggiornamento/cancellazione di servizi, e di ricevere notifiche (sotto forma di e-mail) al verificarsi di tali eventi.

5. SPECIFICHE DEI SERVIZI DI REGISTRO SICA

In questo capitolo vengono analizzate le funzionalità dei Servizi di Registro SICA, derivando i processi di servizio che vengono supportati, i casi d’uso e l’informazione mantenuta. Questa analisi viene documentata attraverso diagrammi UML.

5.1.Processi di Servizio

I Servizi di Registro SICA supportano due processi fondamentali: quello di registrazione e ricerca, e quello di gestione e monitoraggio. Ognuno di questi si compone a sua volta di specifici sottoprocessi, che vengono considerati nel seguito e modellati come Activity Diagram UML.

5.1.1. Registrazione e Ricerca

Stesura Parte Comune Accordo di Servizio

Registrazione Parte Comune Accordo di Servizio

Stesura Parte Specifica Accordo di Servizio

... nel caso generale molte parti specifiche vengono prodotte e registrate

Registrazione Parte Specifica Accordo di Servizio

ps : Parte Specifica AS

pc : Parte Comune AS

Figura 3. Activity Diagram del sottoprocesso di Stesura e Registrazione di un AS

Per quanto riguarda il processo di registrazione e ricerca, in linea del tutto generale esso permette le operazioni fondamentali CRUD (CREATE, READ, UPDATE, DELETE) sugli oggetti principali contenuti nei Servizi di Registro SICA, ovvero l’Accordo di Servizio ed il Soggetto. Più in particolare però si osserva che queste quattro operazioni fondamentali avvengono in momenti distinti e con obiettivi ben definiti, come viene analizzato nel seguito attraver so l’analisi dei relativi sottoprocessi.

Erogatore

Fruitore

Ricerca e Recupero dell'Accordo di Servizio

Realizzazione Lato Erogatore del Servizio

Realizzazione Fruitore del Servizio

Dispiegamento Web Service Erogatore

Dispiegamento Web Service Fruitore

Registrazione

bf : Binding Fruitore

pc : Parte Comune AS

ps : Parte Specifica AS

be : Binding Erogatore

Figura 4. Activity Diagram del sottoprocesso di Realizzazione e Dispiegamento (per una coppia erogatore – fruitore)

Stesura e Registrazione della Parte Comune e Specifica di un Accordo di Servizio (ovvero CREATE). In Figura 3 viene mostrato il processo di stesura e registrazione di un Accordo di Servizio, nel caso più generale in cui differenti parti specifiche (dovute al fatto che il servizio è di tipo multi-erogatore e/o multi-fruitore) derivano dalla stessa parte comune. Inizialmente la parte comune deve essere stesa (secondo regole e modalità organizzative che esulano dagli scopi del presente documento) e registrata nei Servizi di Registro SICA. Successivamente, tutte le parti specifiche che da essa derivano, vengono stese (di nuovo secondo regole e modalità

organizzative che esulano dagli scopi del presente documento) e registrate. Nell’activity diagram, si è rappresentata questa fase in modo astratto ed ideale come un parallelo di tutte le attività di stesura e registrazione; nella realtà le stesure e registrazioni delle parti specifiche non necessariamente avvengono tutte contemporaneamente ed in parallelo, ecc.

Ricerca e Recupero dell'Accordo di Servizio

[specifiche funzionali non piu' valide]

Dismissione (invalidazione) Parte Comune Accordo di Servizio

[else (ovvero altre specifiche non più valide)]

Dismissione (invalidazione) Parte Specifica Accordo di Servizio

Dismissione Web Service Erogatore

Dismissione Web Service Fruitore

ps : Parte Specifica AS

pc : Parte Comune AS

Figura 5. Activity Diagram del sottoprocesso di Dismissione di un Servizio e del relativo

Accordo di Servizio

Realizzazione di un Servizio e suo Dispiegamento (ovvero UPDATE). In Figura 4 viene mostrato il sottoprocesso di realizzazione di un servizio e suo dispiegamento. Questo prevede in linea generale, per ogni coppia erogatore/fruitore, la realizzazione di due Web Service, uno sul lato erogatore ed uno sul lato fruitore, il loro dispiegamento e la registrazione nei Servizi di Registro SICA delle informazioni relative ai rispettivi punti di accesso. In generale, questo sottoprocesso non necessariamente è contestuale al precedente, per cui esso inizia con una ricerca e recupero dell’Accordo di Servizio, nelle parti comuni e specifiche, che regolano il servizio da realizzare e dispiegare. Nell’activity diagram, si è rappresentato il sottoprocesso in modo astratto ed ideale come un parallelo delle attività dei due soggetti; nella realtà potrebbero esserci combinazioni molto differenti, ad es. prima l’erogatore dispiega completamente il suo Web Service e solo dopo il fruitore provvede al suo (magari con il supporto tecnico dell’erogatore), ovvero l’esatto contrario; molto spesso questo dipenderà anche dalla procedura organizzativa che ha portato all’Accordo di Servizio ed agli accordi presi in tale sede.

[sottoprocesso] Stesura e Registrazione Nuovo AS

[sottoprocesso] Realizzazione e Dispiegamento Nuovo Servizio

[vecchio servizio e relativo AS non più valido]

[sottoprocesso] Dismissione Vecchio Servizio ed AS

Figura 6. Activity Diagram del sottoprocesso di Aggiornamento di un Accordo di Servizio

Dismissione di un Servizio e del relativo Accordo di Servizio (ovvero DELETE). In Figura 5 viene mostrato il sottoprocesso di dismissione di un servizio e dei relativi accordi di servizio. In generale, la dismissione di un servizio implica la dismissione (cancellazione “logica” 15) della parte specifica dell’accordo di servizio relativo, ma non necessariamente di quella comune: infatti se la dismissione è dovuta al fatto che le specifiche funzionali del servizio non sono più valide, allora vengono cancellate logicamente sia la parte comune che quella specifica dell’Accordo di Servizio relativo, mentre se a non essere più validi sono solo gli aspetti non funzionali e/o i porti di accesso, allora solo la parte specifica deve essere cancellata logicamente. Anche nel caso della dismissione, opportune procedure organizzative (che esulano dagli scopi del presente documento) saranno stabilite al fine di coordinare la contemporanea dismissione dei Web Service sia dell’erogatore che del fruitore, in modo da non avere applicazioni improvvisamente non più funzionanti.

Aggiornamento di una Nuova Versione di un Accordo di Servizio (ovvero UPDATE). Aggiornare un servizio, ed il relativo Accordo di Servizio, non significa modificarlo, bensì inserire un nuovo Accordo di Servizio il quale è semanticamente legato al precedente in quanto ne costituisce una versione più aggiornata. A seguito di questa operazione, la vecchia e la nuova versione possono poi coesistere, oppure la vecchia versione viene contestualmente dismessa e rimane valida solamente quella nuova. Pertanto, come mostrato in Figura 6, questo sottoprocesso di fatto è la composizione di quello di Figura 3 e Figura 4 (per la parte di

15 Un Accordo di Servizio effettivamente non viene mai cancellato dai Servizi di Registro SICA, ma viene indicato che esso è non più valido (cancellazione logica), pur continuando ad essere memorizzato; in questo modo, come verrà chiarito nel seguito, è possibile ricostruire la storia delle evoluzioni di un Accordo di Servizio, recuperando gli Accordi di Servizio non più validi che lo hanno preceduto.

creazione della nuova versione dell’Accordo di Servizio e di dispiegamento del nuovo servizio) e di Figura 6 nel caso che il vecchio vada dismesso.

Questo di fatto equivale a dire che i Servizi di Registro SICA sono un sistema in cui sono possibili solamente operazioni di creazione, e la creazione può essere effettuata “da zero”, oppure essere semanticamente correlata ad un oggetto preesistente.

Si osservi infine che l’operazione di read di fatto non ha mai una valenza propria, ma è sempre associata alle altre operazioni, in quanto le operazioni di ricerca di (parti di) un Accordo di Servizio sono funzionali al suo completamento/aggiornamento/cancellazione.

Creazione, Aggiornamento, Accesso e Cancellazione di un Accordo di Cooperazione. In analogia ai processi precedentemente descritti, ne esistono altrettanti (i cui diagrammi non vengono mostrati per brevità) che permettono le analoghe operazioni sugli Accordi di Cooperazione. Ricordando che un Accordo di Cooperazione si compone dell’Accordo di Servizio del nuovo servizio composto che viene offerto dal Dominio di Cooperazione, dai riferimenti agli Accordi di Servizio dei Servizi componenti, e dalla specifica dell’orchestrazione necessaria per realizzare il servizio composto, emerge come tali processi siano del tutto analoghi, in particolare nei significati dell’aggiornamento e della dismissione.

Creazione, Aggiornamento, Accesso e Cancellazione di un Soggetto. Le informazioni, e le modalità di gestione, relative ai Soggetti organizzativi sono descritte nell’apposito documento in cui è stato definito l’Indice delle Pubbliche Amministrazioni16. Si vuole qui sottolineare come in questo caso le operazioni CRUD assumano un significato intuitivo, in particolare la modifica delle informazioni relative ad un Soggetto SPCoop non richiede che venga mantenuta la storia degli aggiornamenti.

In generale, un Soggetto SPCoop deve essere presente nei Servizi di Registro SICA prima che un qualsiasi Accordo di Servizio ad esso relativo possa essere inserito. Merita particolare attenzione il caso in cui una modifica ad un Soggetto SPCoop (operazione UPDATE) induce una ristrutturazione organizzativa che porta un Servizio SPCoop ad essere erogato da un nuovo Soggetto SPCoop; in questo caso è necessario, proprio al fine di mantenere la coerenza, produrre nuove versioni degli Accordi di Servizio che facciano riferimento al nuovo/i Soggetto/i SPCoop, e contemporaneamente dismettere i precedenti (Figura 6).

Sottoscrizione e Notifica di Eventi. Un client può sottoscriversi ad eventi particolari a cui è interessato; tali sottoscrizioni specificano la tipologia di evento (ovvero uno degli eventi corrispondenti ai processi precedentemente descritti) ed eventuali condizioni di filtro. Al verificarsi di tali eventi, i Servizi di Registro SICA notificano l’evento tramite un’opportuna e - mail in formato HTML/MIME, il cui contenuto dettaglia la tipologia dell’ evento tramite opportuni documenti XML.

5.1.2. Gestione e Monitoraggio

I processi di gestione e monitoraggio riguardano quelle operazioni che hanno significato di gestione e monitoraggio complessivo del “sistema” Servizi di Registro SICA, e non

16 Cfr. Centro Tecnico. Guida ai Servizi di Indice delle Amministrazioni Pubbliche e delle Aree Organizzative Omogenee e Posta Elettronica Certificata. Centro Tecnico per la Rete Unitaria della Pubblica Amministrazione - Area Rete Unitaria - Sezione Interoperabilità, 13 Giugno 2003. Disponibile on-line: xxxx://xxx.xx.xxxx.xx/XXXX-XXXX/Xxxxx-Xxxx/xxxxx.xxx .

riguardano operazioni sistemistiche sui singoli sistemi software. Per quanto riguarda queste ultime, infatti, i singoli soggetti gestori dei Registri (Generale e/o Secondari) adotteranno le modalità operative più consone ed appropriate, ma queste non devono essere visibili ai client del Servizio di Registro SICA. Viceversa particolari soggetti istituzionali, agendo come client dei Servizi di Registro SICA, potrebbero essere interessati a particolari operazioni di valenza complessiva che pertanto devono essere offerte.

Tali operazioni, identificate nel seguito, saranno rese accessibili attraverso il Registro SICA Generale, che nella loro realizzazione si avvarrà però di opportune interfacce applicative offerte dai Registri Secondari. Per loro natura, questi ultimi non potranno quindi esportare tale operazioni di gestione e monitoraggio.

Va inoltre aggiunto che allo stato attuale, i processi di monitoraggio non sono ancora compiutamente delineati, pertanto, anche se la loro presenza è prevista, di essi non si forniranno ulteriori dettagli. Successive versioni della documentazione e delle specifiche dei Servizi di Registro SICA forniranno la specifica dettagliata di tali aspetti.

Per quanto riguarda la gestione, allo stato attuale sono stati individuate tre operazioni fondamentali (ognuna delle quali è indipendente ed autonoma rispetto alle altre 17):

Iscrizione/cancellazione Registro Secondario. Con questa attività viene autorizzato un nuovo Registro Secondario ad eseguire operazioni di estrazione, propagazione, sottoscrizione per notifiche. Ovviamente in qualsiasi momento esso può essere rimosso, in quanto nel Registro SICA Generale sono mantenute tutte le informazioni, e di conseguenza l’eliminazione di una vista non produce nessun effetto negativo (fatto salvo quello per i client abituati ad utilizzare il Registro Secondario eliminato). Affinché il nuovo Registro Secondario interoperi correttamente con il Registro Generale, esso deve realizzare correttamente l’interfaccia di sincronizzazione, che si assume essere stata collaudata e validata prima della registrazione.

Sincronizzazione forzata. I Registri Secondari eseguono operazioni di estrazione della loro vista su iniziativa propria od in seguito alla ricezione di una notifica, ognuno in assoluta autonomia; inoltre essi sono vincolati ad eseguire operazioni di propagazione ogni volta che vengono eseguite inserimenti/modifiche/cancellazioni (nell’accezione precedentemente indicata in § 5.1.1) alle informazioni pertinenti la propria vista. E’ possibile però avviare una sincronizzazione forzata, con il seguente significato:

(1) il Servizio di Registro SICA (quindi sia l’occorrenza Generale che quelle Secondarie) è indisponibile ai client per tutta la durata della sincronizzazione forzata;

(2) viene creata una sorta di super-vista dei Registri SICA Secondari, andando a calcolare l’unione delle rispettive viste e risolvendo eventuali duplicazioni/conflitti in modo ad hoc, sotto supervisione di appositi operatori umani coadiuvati da tool di supporto;

(3) il contento del Registro Generale viene archiviato come backup;

(4) tale super-vista (che a questo punto non contiene duplicati/conflitti) 18 viene imposta al Registro Generale, divenendo di fatto il nuovo contento del Registro Generale;

17 Quindi di fatto sono individuati tre sottoprocessi estremamente banali, costituiti da una sola attività: questo è il motivo per cui non vengono in questo caso riportati gli activity diagram, che sarebbero estremamente banali.

(5) ognuno dei Registri Secondari esegue un’estrazione a partire dal Registro Generale appena “rinfrescato”.

Emerge come tale operazione, estremamente potente, abbia però un costo altrettanto elevato, e vada quindi eseguita solamente in casi di effettiva necessità.

Controllo di consistenza. L’operazione per controllare la consistenza del Servizio di Registro SICA permette di fatto di capire se è necessario o meno avviare una sincronizzazione forzata. Essa calcola la super-vista del punto (2) precedente, e nel caso in cui emergano conflitti/duplicazioni, segnala la presunta assenza di consistenza; nel caso in cui non si verifichino conflitti/duplicazioni, la super-vista viene confrontata con il contenuto del Registro Generale, e in caso di non coincidenza viene segnalata la presunta assenza di consistenza. Se invece entrambi i controlli danno esito negativo, il Servizio di Registro SICA viene assunto consistente.

5.2. Modello dei Casi d’Uso

In Figura 7 viene riportato il Modello dei Casi d’Xxx, così come emerge dalla discussione precedente. Si noti come è possibile identificare un ruolo particolare, Gestore, interessato alle funzionalità/casi d’uso Verifica Consistenza, Sincronizzazione Forzata, Registrazione Registro Secondario e Cancellazione Registro Secondario.

Due casi d’uso, Ricerche Accordi di Servizio/Cooperazione e Ricerche Soggetti SPCoop, nella realtà consistono in tantissime modalità differenti di interrogare il sistema, per ottenere in generale una lista (eventualmente vuota o con un solo elemento) di elementi che soddisfano l’interrogazione.

Si noti come tutti i sottoprocessi precedentemente analizzati possono essere ottenuti a partire da due casi d’uso di Inserimento Accordo di Servizio e Dismissione Accordo di Servizio, che includono quelli di Inserimento Parte Comune AS e Inserimento Parte Specifica AS (quest’ultimo include il precedente in quanto non si può inserire una parte specifica senza aver inserito la parte comune) e Dismissione Parte Specifica AS e Dismissione Parte Comune AS (quest’ultimo include il precedente in quanto non si può dismettere una parte comune senza aver dismesso la parte specifica).

18 Si osservi che nell’ipotesi che dall’ultima operazione di sincronizzazione forzata non si siano verificati errori, la super- vista calcolata non deve contenere duplicati/inconsistenze e deve coincidere esattamente con il contenuto del Registro Generale.

Verifica Consistenza

Sincronizzazione Forzata

Registrazione Registro Secondario

Cancellazione Registro Secondario

Gestore

Inserimento Accordo di Servizio

<<include>>

Inserimento Soggetto SPCoop

<<include>>

Inserimento Parte Comune AS

<<include>>

Aggiornamento Soggetto SPCoop

<<include>>

Notifica Evento

Inserimento Parte Specifica AS

Cancellazione Soggetto SPCoop

<<include>>

Ricerche su Accordi di Servizio / Cooperazione

<<include>>

Ricerche su Soggetti SPCoop

Dismissione Accordo di Servizio

<<include>>

Per semp<l<iciintàcl,undoen>>vengono enucleate tutte le possibili ricerche che possono essere effettuate sugli Accordi di Servizio/Cooperazione e sui Soggetti.

Queste verranno dettagliate direttamente nella § 10.

<<i

nclude>>

<<include>>

Dismissione Parte Specifica AS

<<include>>

Inserimento Accordo di Cooperazione

Dismissione Parte Comune AS

Dismissione Accordo di Cooperazione

Sottoscrizione Evento

Client

Figura 7. Modello dei Casi dei Servizi di Registro SICA. Il fatto che la linea che origina da

Client vada sul bordo tratteggiato indica che tutti i casi d’uso interni al bordo sono per

l’attore

In analogia, sono presenti i casi d’uso Inserimento Accordo di Cooperazione e Dismissione Accordo di Cooperazione. Per semplicità grafica, non si è mostrata la relazione di inclusione tra questi casi d’uso e quelli di

inserimento/cancellazione di un Accordo di Servizio, in particolare quello del nuovo servizio composto, mentre si è invece mostrata la relazione d’inclusione con il caso d’uso Ricerche Accordi di Servizio/Cooperazione, in quanto necessario per recuperare (i riferimenti a)gli Accordi di Servizio dei servizi componenti. Analogamente, sempre per non avere troppe linee nella figura, non si è mostrata la relazione di inclusione del caso d’uso Notifica Evento.

Si noti infine la presenza dei casi d’uso Sottoscrizione Evento e Notifica Evento e per la sottoscrizione e la ricezione della notifica degli eventi di inserimento/aggiornamento/cancellazione.

5.3. Modello Concettuale dell’Informazione

In Figura 8 viene mostrato il modello concettuale, rappresentato con un class diagram UML, dell’informazione che deve essere mantenuta da un’occorrenza dei Servizi di Registro SICA. La maggior parte dei concetti e delle associazioni deriva direttamente dalla struttura dell’Accordo di Servizio e dell’Accordo di Cooperazione, così come descritto nel relativo documento.

Merita invece un’attenzione particolare l’associazione aggiornare tra Accordi di Servizio/Cooperazione, per cui un Accordo ha al più un predecessore (cfr. la cardinalità 0..1) e un numero qualsiasi di successori (cfr. la cardinalità 0..*); questo significa che l’associazione di aggiornamento tra Accordi (e quindi anche tra i relativi servizi) produce una struttura ad albero.

Si noti infine come il concetto Soggetto SPCoop in realtà racchiude tutte le informazioni relative ai soggetti, così come analizzate e disponibili nell’Indice delle Pubbliche Amministrazioni. Questo significa che le due associazioni che ci sono tra Soggetto SPCoop e Servizio di fatto attraversano due sistemi eterogenei, rispettivamente l’IPA ed il meccanismo di storage degli Accordi (cfr. § 6): opportuni identificatori in uno dei sistemi permettono di gestire l’associazione con l’informazione mantenuta nell’altro. In particolare, il campo LDIF descrizioneS della struttura dell’IPA conterrà il riferimento all’Accordo che descrive il servizio, mentre all’interno della struttura di memorizzazione dell’Accordo ci saranno due campi contenenti i valori dei campi LDIF o e aoo contenente il codice unico del soggetto (e della specifica AOO che offre il servizio).

Sistema Pubblico di Cooperazione

Servizi di Registro

predecessore 0..1 1..*

1..1

Servizio Offerto da Dominio di Cooperazione

successore Accordo di Servizio

descrivere (esternamente)

Tutte le informazioni relative ai Soggetti sono già modellate e mantenute nell'IPA (Indice delle Pubbliche Amministrazioni).

0..*

Specifica Processo 1

specificare

1..1

Soggetto SPCoop

1..* 1..1

caratterizzare

dettagliare

Descrizione Semi-Formale

Documento di Specifica

1..1

0..*

1..1

1 Parte Comune AS

Parte Specifica AS

1..1

descrivere

Queste due associazioni "attraversano" due sistemi eterogenei, l'IPA ed il sistema di storage degli Accordi di Servizio, Esse pertanto sono qui rappresentate concettualmente, ma di fatto andranno realizzate in modo specifico

1..1

erogare

specificare

0..*

Servizio

fruire

0..*

specificare

1..1

1..*

0..*

Un Servizio Applicativo SPCoop è quello offerto da un Dominio

1..1

Specifica Interfaccia

Specifica Porti Accesso

1..1

Servizio Applicativo SPCoop

1..1

Specifica Livelli di Servizio

WSDL Logico Fruitore 1..1 WSDL Logico Erogatore

1..1

Specifica Conversazioni

Specifica Caratteristiche di Sicurezza

1..1

1 1

0..*

1..1

WSBL Logico Fruitore

Documentazione in accordo con WSSF

WSL

Descrizione Semi-Formale

Binding Erogator

WSDL Concettuale

Servizio SICA

aggiornare descrivere (internamente)

Documento di Specifica

Binding Fruitore

1 1..1

WSBL Concettuale

WSBL Logico Erogatore

Figura 8. Modello concettuale dell’informazione mantenuta dai Servizi di Registro SICA

6. ARCHITETTURA DEI SERVIZI DI REGISTRO SICA

In questo capitolo viene delineata l’architettura modulare dei Servizi di Registro SICA, individuandone i componenti fondamentali sulla base delle considerazioni precedentemente descritte, e distinguendo tra Registro SICA Generale e possibili Registri SICA Secondari. Figura

9 e Figura 10 dettagliano l’architettura dei Registri, e rimpicciolite ad uso icona sono state utilizzate in Figura 2 per rappresentare il Registro Generale a quelli Secondari.

6.1.Servizi di Registro SICA Generale

vice	WWW
logica applicativa CRUD

interfaccia applicativa

llogogicicaa applappliicativacativa CRCRUDUD

interfaccia utente WWW/HTML

Web Ser

interfaccia utente

interfaccia applicativa Web Service

/HTML

llogogicicaa applappliicativacativa monitormonitoragaggiogio

interfaccia applicativa Web Service

logica applicativa monitoraggio

DBMS con estensioni/supporto XML

llogogicicaa applappliicativacativa sinsincronizcronizzzazazionionee GGeneeneralralee SSeecondaricondari

logica applicativa sincronizzazione Generale -- Secondari

interfaccia applicativa Web Service

IPA

lologgicaica ddii inteintegrazgraziioonene ee sisincrncroonizzaznizzaziioonene tratra ii 22 stostorere

llogogicicaa applappliicativacativa gestgestioneione

interfaccia utente WWW/HTML

logica applicativa gestione

logica di integrazione e sincronizzazione tra i 2 store

(Indice delle Pubbliche Amministrazioni)

Gestione sistemistica (proprietaria e specifica - non pertinente per questo documento)

Figura 9. Architettura del Registro SICA Generale

In Figura 9 viene mostrata l’architettura del Registro SICA Generale, ottenuta a partire dalle considerazioni fin qui presentate. Il Registro SICA Generale è costituito dai seguenti componenti:

Un DBMS con estensioni e supporto XML, per la memorizzazione e gestione degli Accordi di Servizio/Cooperazione e dei relativi indici.

L’IPA (Indice delle Pubbliche Amministrazione), sistema preesistente e che viene inglobato al fine di memorizzare e mantenere tutte le informazioni relative ai Soggetti.

Questi due componenti insieme costituiscono il livello di gestione della persistenza del Registro SICA Generale; ovviamente, il concetto Soggetto SPCoop in Figura 8 costituisce il punto di contatto tra i due, e devono valere vincoli di consistenza ed allineamento tra i due componenti; pertanto una logica di integrazione e sincronizzazione tra i due componenti si occupa del mantenimento dell’allineamento e della consistenza tra il DBMS con estensioni XML che gestisce gli Accordi e l’IPA che gestisce i soggetti erogatori e fruitori di tali accordi.

Un componente di logica applicativa CRUD si occupa delle operazioni CRUD (CREATE, READ, UPDATE e DELETE, così come descritte in § 5) per l’accesso e l’interrogazione delle informazioni relative agli Accordi ed ai Soggetti. La necessità di tale componente è dovuta al fatto che le tecnologie attualmente disponibili per realizzare il livello di persistenza non garantiscono la disponibilità in modo nativo di tutte le operazioni necessarie per l’accesso alle informazioni (in particolare ricerche avanzate sul contenuto dei documenti XML che costituiscono gli Accordi). Tale logica applicativa è fruibile dai client del Registro SICA Generale sia attraverso un’interfaccia applicativa da dispiegare come Web Service che attraverso un’interfaccia utente di tipo WWW/HTML. Il sottoinsieme delle operazioni che hanno un equivalente nello standard UDDI viene offerto attraverso una segnatura aderente al suddetto standard.

Un componente di logica applicativa di gestione si occupa delle operazioni di gestione del Registro SICA Generale. Tale logica applicativa è fruibile dai client del Registro SICA Generale sia attraverso un’interfaccia applicativa da dispiegare come Web Service che attraverso un’interfaccia utente di tipo WWW/HTML.

Un componente di logica applicativa di monitoraggio si occupa delle operazioni di monitoraggio del Registro SICA Generale. Tale logica applicativa è fruibile dai client del Registro SICA Generale sia attraverso un’interfaccia applicativa da dispiegare come Web Service che attraverso un’interfaccia utente di tipo WWW/HTML. Al momento della scrittura del presente documento, non sono state ancora definite le componenti e le informazioni interessanti ai fini di monitoraggio, pertanto questa componente di monitoraggio viene prevista ma non verranno forniti nel presente documento ulteriori dettagli sulle operazioni che essa deve offrire. Successive versioni delle specifiche dei Servizi di Registro SICA forniranno indicazioni su questa componente.

Infine, in base all’articolazione distribuita dei Servizi di Registro SICA, così come descritta in § 4, è necessario un opportuno componente con la logica di sincronizzazione Registro Generale – Registri Secondari, che offra le operazioni per la propagazione, l’estrazione, l’invio/ricezione delle notifiche. Tale logica è dispiegata come un Web Service, attraverso il quale, in modo completamente automatico, i Registri si sincronizzano tra di loro.

Ovviamente il Registro SICA Generale, come qualsiasi sistema informatico, dovrà essere gestito ed amministrato da un punto di vista sistemistico. Tutte le operazioni necessarie a tale gestione ed amministrazione sono da considerarsi operazioni “interne” del sistema, e pertanto

non devono essere accessibili esternamente; esse vengono mostrate tratteggiate nella Figura 9. Viceversa, le operazioni di gestione e monitoraggio che vengono esposte “esternamente” sono quelle che hanno una valenza di gestione ed amministrazione complessiva dei Servizi di Registro SICA nella loro interezza, fruibili da soggetti istituzionali e da organismi preposti (ad es., il Comitato di gestione). Ad esempio, l’operazione di shutdown e di riavvio del Registro SICA Generale, che è un’operazione interna, non viene considerata nelle interfacce di gestione e monitoraggio, viceversa l’operazione con la quale utenti autorizzati possono forzare una sincronizzazione (non prevista in quel particolare momento) tra tutte le istanze (la Generale e le varie Secondarie) dei Servizi di Registro SICA appare significativa in termini di gestione dell’intero “sistema”, e pertanto viene offerta nell’interfaccia di gestione.

Come emerge nel proseguo, tutte le operazioni di gestione e monitoraggio con validità complessiva esterna sono accessibili tramite il Registro Generale 19, e pertanto non vi sono degli analoghi nei Registri Secondari, ma solo il supporto applicativo a tali operazioni.

6.2. Servizi di Registro SICA Secondario

vice	WWW
logica applicativa CRUD

interfaccia applicativa

llogogicicaa applappliicativacativa CRCRUDUD

Web Ser

interfaccia utente

/HTML

interfaccia applicativa Web Service

DBMS con estensioni/supporto XML

llogogicicaa applappliicativacativa sinsincronizcronizzzazazionionee GGeneeneralralee SSeecondaricondari

logica applicativa sincronizzazione Generale -- Secondari

interfaccia applicativa Web Service

IPA

lologgicaica ddii inteintegrazgraziioonene ee sisincrncroonizzaznizzaziioonene tratra ii 22 stostorere

llogogicicaa applappliicativacativa peperr supportosupporto allealle opeoperazrazioniioni ddii ggeeststioneione ee mmononitoragitoraggiogio

logica applicativa per supporto alle operazioni di gestione e monitoraggio

logica di integrazione e sincronizzazione tra i 2 store

(Indice delle Pubbliche Amministrazioni)

Gestione sistemistica (proprietaria e specifica della singola occorrenza - non pertinente per questo documento)

19 Per sua natura, il Registro Generale è l’unica occorrenza dei Servizi di Registro SICA che può offrire operazioni di monitoraggio e gestione complessiva del “sistema”; i Registri Secondari, proprio per il fatto di essere “secondari”, non possono e non devono offrire tali operazioni, che perderebbero altrimenti di significato.

Figura 10. Architettura del generico Registro SICA Secondario

In Figura 10 viene mostrata l’architettura del generico Registro SICA Secondario, che è analoga a quella del Generale, con l’unica eccezione che non offre un’interfaccia per la gestione ed il monitoraggio, ma solamente un componente di logica applicativa per il supporto alla gestione ed al monitoraggio, che realizza le operazioni necessarie alla gestione ed al monitoraggio del “sistema complessivo” dei Servizi di Registro SICA. Come precedentemente discusso, le operazioni di gestione e monitoraggio di valenza “esterna” e complessiva vengono offerte ai client attraverso il Registro SICA Generale, ma i vari Registri SICA Secondari devono appunto offrire delle opportune interfacce applicative per supportarle. Tale logica applicativa viene dispiegata come un Web Service. Si rimarca che le operazioni “sistemistiche” necessarie al funzionamento interno del singolo Registro SICA Secondario non vengono in questo documento considerate, e non devono essere offerte esternamente a nessun client del sistema, e pertanto sono mostrate tratteggiate nella Figura 10.

Va rimarcato come un Registro SICA Secondario dovrebbe essere realizzato solamente quando un’opportuna vista, significativa in determinati contesti 20, viene definita a partire dagli Accordi di Servizio/Cooperazione e dai Soggetti mantenuti nel Registro SICA Generale. È in fase di costruzione del Registro Secondario che viene definita tale vista, le operazioni necessarie a mantenerla, incluse le definizioni delle sottoscrizioni necessarie. Ovviamente tutte queste operazioni, che come precedentemente discusso sono peculiari della vista/Registro Secondario e non cambiano mai durante il suo ciclo di vita, non devono essere accessibili tramite le interfacce esterne del Registro, ma di nuovo sono assimilabili ad operazioni di gestione sistemistica dello stesso.

20 Ad es., geografici (un Registro SICA regionale), funzionali (un Registro SICA per i Servizi SPCoop in materia fiscale), amministrativi (un Registro SICA per i Servizi SPCoop offerti da una particolare amministrazione con uffici centrali e periferici).

Document Metadata

Table of Contents

Servizi di Registro

Document Metadata