Universita degli Studi di Pisa
Facolta di Scienze Matematiche Fisiche e Naturali
Dipartimento di Informatica
TESI DI LAUREA
La Gestione degli Accordi di
Cooperazione nel progetto
OpenSPCoop
Relatori
prof. Andrea Corradini
prof. Tito Flagella
Controrelatore
prof. Vincenzo Gervasi
Candidato
Aldo Lezza
Anno Accademico 2006-2007
Indice
1 Introduzione 1
1.1 Obiettivi della tesi . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Contenuto della tesi . . . . . . . . . . . . . . . . . . . . . . . 7
2 Le Architetture basate su Web Service 9
2.1 Architetture Orientate ai Servizi (SOA) . . . . . . . . . . . . 9
2.2 Web Service: una Tecnologia per SOA . . . . . . . . . . . . . 11
2.2.1 Cos’e un Web Service? . . . . . . . . . . . . . . . . . . 12
2.2.2 Agenti e Servizi . . . . . . . . . . . . . . . . . . . . . . 12
2.2.3 Fornitori e Richiedenti . . . . . . . . . . . . . . . . . . 12
2.2.4 Descrizione del Servizio . . . . . . . . . . . . . . . . . 13
2.2.5 La Semantica . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.6 Schema di Attivazione di un Web Service . . . . . . . 14
2.3 Tecnologie per Web Service . . . . . . . . . . . . . . . . . . . 14
2.3.1 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.2 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.3 WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.4 XPath . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.5 Il Protocollo di Comunicazione per i Web Service . . . 19
3 La specifica SPCoop del CNIPA 23
3.1 La Specifica SPCoop di Cooperazione Applicativa . . . . . . . 24
i
INDICE ii
3.2 I Componenti Infrastrutturali previsti in SPCoop . . . . . . . 26
3.2.1 La Porta di Dominio . . . . . . . . . . . . . . . . . . . 28
3.2.2 La Busta eGov . . . . . . . . . . . . . . . . . . . . . . 28
3.2.3 Il Registro Servizi . . . . . . . . . . . . . . . . . . . . 29
3.2.4 Il Gestore Eventi . . . . . . . . . . . . . . . . . . . . . 29
3.2.5 I Componenti di Integrazione . . . . . . . . . . . . . . 31
3.2.6 I Web Service come Soluzione per l’Integrazione . . . 32
4 OpenSPCoop 33
4.1 L’Architettura generale del Progetto . . . . . . . . . . . . . . 34
4.2 La Porta di Dominio OpenSPCoop . . . . . . . . . . . . . . . 36
4.3 Un Esempio d’Uso di Servizi in OpenSPCoop . . . . . . . . . 38
4.4 Il Registro Servizi di OpenSPCoop . . . . . . . . . . . . . . . 39
4.4.1 Il Registro XML . . . . . . . . . . . . . . . . . . . . . 40
4.4.2 Il Registro UDDI . . . . . . . . . . . . . . . . . . . . . 41
4.4.3 Il Gestore Eventi di OpenSPCoop . . . . . . . . . . . 42
4.4.4 Gli Aspetti di Sicurezza in OpenSPCoop . . . . . . . . 42
5 Linguaggi per Workflow 44
5.1 Cos’e un Workflow . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2 I Workflow per Applicazioni di Rete . . . . . . . . . . . . . . 45
5.3 Programmazione Orientata ai Grafi (GOP) . . . . . . . . . . 46
5.3.1 Orchestrazione e Coreografia . . . . . . . . . . . . . . 48
5.3.2 GOP a confronto con Reti di Petri . . . . . . . . . . . 48
5.4 BPEL e WS-BPEL . . . . . . . . . . . . . . . . . . . . . . . . 49
5.4.1 Breve Presentazione del Linguaggio BPEL . . . . . . . 53
5.5 Altri Linguaggi per Orchestrazione . . . . . . . . . . . . . . . 55
5.5.1 Windows Workflow Foundation . . . . . . . . . . . . . 56
5.5.2 YAWL . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
INDICE iii
6 Dagli Accordi di Servizio agli Accordi di Cooperazione 60
6.1 L’Accordo di Servizio (AS) . . . . . . . . . . . . . . . . . . . 60
6.1.1 L’Identificazione delle Parti . . . . . . . . . . . . . . . 62
6.1.2 La Descrizione delle Funzionalita . . . . . . . . . . . . 63
6.1.3 Struttura dell’Accordo di Servizio . . . . . . . . . . . 65
6.1.4 Descrizione della Parte Comune . . . . . . . . . . . . . 65
6.1.5 Descrizione degli Aspetti relativi al Protocollo SPCoop 66
6.1.6 Descrizione della Parte Specifica . . . . . . . . . . . . 68
6.2 L’Accordo di Cooperazione . . . . . . . . . . . . . . . . . . . 69
6.3 L’Accordo di Cooperazione nel Registro Servizi OpenSPCoop 74
6.3.1 Accordo di Cooperazione nel Registro Servizi . . . . . 76
6.3.2 Esempio di Configurazione del Registro Servizi con un
Accordo di Cooperazione . . . . . . . . . . . . . . . . 78
7 Implementazione dei casi d’uso 83
7.1 JBoss Application Server . . . . . . . . . . . . . . . . . . . . 83
7.2 JBPM (java Business Process Management) . . . . . . . . . . 84
7.2.1 JBPM . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
7.2.2 JBPM per la gestione dei processi produttivi . . . . . 86
7.3 Realizzare workflow in JBPM-BPEL . . . . . . . . . . . . . . 88
7.3.1 Struttura dei File per un Servizio Workflow . . . . . . 88
7.3.2 Deploy del Servizio Workflow . . . . . . . . . . . . . . 90
7.4 I Casi di Prova in BPEL . . . . . . . . . . . . . . . . . . . . . 92
7.4.1 Il Caso d’Uso ElevaQuadrato . . . . . . . . . . . . . . 92
7.4.2 Routing Semplice e Routing Elaborato . . . . . . . . . 100
7.4.3 Uso di Tipi XML e Query XPath 1.0 . . . . . . . . . . 102
7.4.4 Indirizzamento Dinamico dei Servizi . . . . . . . . . . 102
7.5 Implementazione dei Casi d’Uso per il Formato degli Accordi
di Cooperazione . . . . . . . . . . . . . . . . . . . . . . . . . . 104
7.5.1 La porta di dominio OpenSPCoop come proxy SOAP 105
INDICE iv
7.5.2 Caso d’Uso Hello . . . . . . . . . . . . . . . . . . . . . 106
7.5.3 Caso d’Uso Transazione . . . . . . . . . . . . . . . . . 114
7.5.4 Caso d’Uso Sportello . . . . . . . . . . . . . . . . . . . 118
8 Conclusioni e sviluppi futuri 123
Elenco delle figure
2.1 Il procedimento generico di ingaggiare un Web Service. . . . . 15
2.2 Web Service: L’organizzazione dell’architettura. . . . . . . . . 16
3.1 I principali componenti dell’infrastruttura SPCoop. . . . . . . 28
3.2 Il Gestore Eventi. . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3 Integrazione di SPCoop. . . . . . . . . . . . . . . . . . . . . . 31
4.1 Architettura OpenSPCoop . . . . . . . . . . . . . . . . . . . . 35
4.2 La porta di dominio OpenSPCoop . . . . . . . . . . . . . . . 37
4.3 OpenSPCoop: esempio d’uso . . . . . . . . . . . . . . . . . . 37
4.4 OpenSPCoop: Registro Servizi XML . . . . . . . . . . . . . . 40
4.5 OpenSPCoop: Registro Servizi UDDI . . . . . . . . . . . . . 41
4.6 OpenSPCoop: WS Security . . . . . . . . . . . . . . . . . . . 43
5.1 Rappresentazione grafica e generazione automatica di codice. 47
5.2 .NET 3 Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.1 L’Accordo di Servizio in SPCoop. . . . . . . . . . . . . . . . . 63
6.2 Accordo di Servizio:Parte Comune . . . . . . . . . . . . . . . 68
6.3 Esempio di Manifesto della parte comune di un AS . . . . . . 68
6.4 Documento semiformale con informazioni e-gov . . . . . . . . 69
6.5 Accordo di Servizio:Parte Specifica . . . . . . . . . . . . . . . 71
6.6 Esempio di Manifesto della parte specifica di un AS . . . . . 71
6.7 Dominio di Cooperazione in SPCoop . . . . . . . . . . . . . . 73
v
ELENCO DELLE FIGURE vi
6.8 Dominio di Cooperazione . . . . . . . . . . . . . . . . . . . . 77
6.9 Visione Logica dell’Accordo di Cooperazione . . . . . . . . . . 78
7.1 Il linguaggio a processi e la sua collocazione . . . . . . . . . 88
7.2 Panoramica sui componenti jPDL . . . . . . . . . . . . . . . . 88
7.3 La separazione dei ruoli nei processi produttivi . . . . . . . . 90
7.4 I ruoli nell’implementazione e gestione dei workflow . . . . . . 91
7.5 ElevaQuadrato in BPEL . . . . . . . . . . . . . . . . . . . . . 95
7.6 Routing in BPEL . . . . . . . . . . . . . . . . . . . . . . . . . 104
7.7 Hello World in OpenSPCoop:Lo scambio delle buste eGov. . . 116
Capitolo 1
Introduzione
L’informatizzazione della Pubblica Amministrazione (PA) e iniziata sponta-
neamente negli ultimi decenni grazie alla diffusione dei calcolatori nel nostro
Paese. Questo processo e stato dettato inoltre dall’esigenza di migliorare le
procedure che riguardano ogni tipo di pratica della PA. Come per ogni altra
istituzione o azienda, anche per la PA il risparmio di tempo e l’ottimizza-
zione delle risorse equivale ad un notevole risparmio di denaro. Questo puo
auspicabilmente portare ad un minore carico fiscale per i contribuenti chia-
mati a finanziare l’amministrazione statale. Un risparmio puo aversi anche
in termini di utilizzazione e consumo di materiale: diminuzione dell’utiliz-
zo di cancelleria, riduzione delle spese per l’archiviazione e il trasporto di
documenti, possibilita di reimpiego del personale divenuto in esubero per
colmare le carenze di organico nei settori deficitarii.
A livello informatico le varie amministrazioni hanno lavorato secondo le pro-
prie esigenze e le proprie possibilita, senza una organizzazione a livello na-
zionale. Questo ha portato alla nascita di servizi applicativi con possibilita
comunicative limitate. Si pensi ad esempio a due comuni che si accordano
su un comune formato di scambio. Se un terzo comune che usa un proprio
formato di dati necessita di comunicare con questi comuni deve adattarsi allo
standard degli altri due. Il Ministero per l’Informatizzazione e le tecnologie
1
CAPITOLO 1. INTRODUZIONE 2
raggiunge, anche grazie all’insorgere di queste situazioni, la consapevolezza
di dover governare questo processo di informatizzazione. Quindi, nel 2002
il Centro Nazionale per l’Informatizzazione nella Pubblica Amministrazione
(CNIPA) ha avviato gli studi necessari per la definizione dello scenario futu-
ro delle infrastrutture informatiche delle pubbliche amministrazioni italiane.
Tramite il Decreto lgs. del 28 febbraio 2005, n. 42 dal titolo ’Istituzione del
Sistema Pubblico di connettivita e della Rete internazionale della pubblica
amministrazione’, il CNIPA istituisce e disciplina il Sistema Pubblico di
Connettivita (SPC). Questo e definito come
’l’insieme di strutture organizzative, infrastrutture tecnologiche e regole tec-
niche, per lo sviluppo, la condivisione, l’integrazione e la circolarita del patri-
monio informativo della pubblica amministrazione, necessarie per assicurare
l’interoperabilita e la cooperazione applicativa dei sistemi informatici e dei
flussi informativi, garantendo la sicurezza e la riservatezza delle informa-
zioni’.
Il progetto e articolato in due fasi principali secondo due obiettivi:
• La definizione del SPC nel suo complesso, delle strutture organizzative
per il suo governo, le infrastrutture tecnologiche e le regole tecniche
per la fornitura dei servizi di connettivita ed interoperabilita di base
nel rispetto dei necessari requisiti di sicurezza;
• La definizione del modello e dei servizi di interoperabilita evoluta e
cooperazione applicativa e lo sviluppo dell’architettura abilitante e
delle relative regole di governo.
I lavori per la definizione del sistema sono stati avviati sin dalla meta del
2002 in collaborazione con le pubbliche amministrazioni, esperti del mondo
accademico, rappresentanti delle aziende. Tra l’aprile 2004 e l’ottobre 2005
il CNIPA completa le specifiche per il Sistema Pubblico di Cooperazione
[SPCOOP] attraverso una serie di documenti. Nell’aprile 2004 viene rila-
CAPITOLO 1. INTRODUZIONE 3
sciata la versione 1.0 della specifica della busta e-Gov [CN3], che definisce il
formato standard in cui debbano avvenire le richieste di servizio e lo scambio
dei dati tra l’erogatore e il fruitore di un servizio nella Pubblica Amministra-
zione. Nel novembre 2004 il CNIPA rilascia la versione 1.0 dell’Architettura
SPCoop [CN1], che descrive i servizi infrastrutturali comuni e le modalita
d’interazione tra i vari componenti del Sistema Pubblico di Cooperazione.
Nell’ottobre 2005 il CNIPA completa la stesura di un insieme di documenti
che costituiscono il riferimento tecnico per lo sviluppo dei servizi infrastrut-
turali che delinea il quadro tecnico-implementativo del Sistema Pubblico di
Cooperazione. Tra i vari documenti e interessante citare:
• Porta di Dominio. E’ descritta l’entita che dovra gestire i servizi offerti
all’interno di un dominio pubblico [CN2].
• Registro dei Servizi e Accordo di Servizio. Il documento intitolato
’Accordo di Servizio’ [CN5] contiene la descrizione e la specifica delle
varie parti che compongono un Accordo di Servizio (erogato da una
PA). Si tratta di un documento standard in XML che formalizza e
regola l’erogazione/fruizione di un servizio applicativo in SPCoop. E’
inoltre fornita la specifica di quanto concerne la registrazione e la pub-
blicazione di Accordi dei Servizi all’interno di un apposito registro
[CN6], dove saranno registrati anche i Soggetti abilitati ad interagire
nell’architettura SPCoop.
• Busta di e-Gov. Descrive la nuova versione 1.1 [CN4] della specifica
della busta e-Gov.
Successivamente alla pubblicazione delle specifiche SPCoop da parte del
CNIPA ha avuto inizio il progetto OpenSPCoop [OPENSPCOOP] che ha
come obiettivo la realizzazione di un insieme di componenti Open Source
aderenti a tali specifiche. Questo progetto nasce da una collaborazione sul
tema della Cooperazione Applicativa avviata nel 2004 dal Dipartimento di
CAPITOLO 1. INTRODUZIONE 4
Informatica dell’Universita di Pisa e la societa Link.it di Pisa che decisero
di approfondire alcuni aspetti innovativi su questo tema, emersi in proget-
ti delle PA in cui erano rispettivamente coinvolti. Dopo un’ampia fase di
analisi, svolta attraverso lo studio di vari progetti pilota tra cui il progetto
CART della Regione Toscana [R12] e il Progetto SOLE dell’Emilia Romagna
[R13], e emersa la proposta di un’architettura innovativa per la realizzazio-
ne di una infrastruttura compatibile con le specifiche CNIPA, che riducesse
pero significativamente l’impatto sui sistemi preesistenti rispetto alle solu-
zioni disponibili.
Il paradigma per l’integrazione dei servizi scelto per la porta di dominio
OpenSPCoop e il paradigma Web Service Mediator. Questo paradigma par-
te dalla constatazione che l’ampia diffusione dell’XML e del paradigma dei
Web Services permette di considerare i sistemi interni al Dominio di Servi-
zio come gia capaci o facilmente adattabili al dialogo tramite Web Services.
Se si assume questa premessa, la componente di integrazione non dovra piu
supportare tecnologie diverse per ogni possibile sistema legacy da interfac-
ciare (CORBA, RMI,JMS, .NET, etc.), ma potra essere invece un generico
container che funga da mediatore dei messaggi SOAP in arrivo dai clienti
interni per i servizi esterni e viceversa.
I componenti architetturali della specifica SPCoop introdotti in precedenza
sono stati completamente implementati in OpenSPCoop rispettando le spe-
cifiche disponibili alla fine del 2005.
I componenti analizzati ed estesi durante questo lavoro di tesi riguardano il
Registro dei Servizi e l’Accordo di Servizio. Il ruolo del Registro dei Servizi
e quello di permettere la registrazione e la successiva interrogazione degli
Accordi di Servizio (AS) di SPCoop. A partire dagli AS si snodano i vari
riferimenti ai soggetti erogatori e fruitori, alle interfacce dei servizi erogati
e fruiti, alle politiche di sicurezza ed in generale a tutto quanto riferisce alle
politiche di cooperazione applicativa concordate tra i Soggetti interessati.
CAPITOLO 1. INTRODUZIONE 5
Successive versioni delle specifiche rilasciate hanno introdotto nuovi compo-
nenti dalle capacita piu avanzate e complesse. Tra questi, il componente
preso in considerazione in questa tesi e l’Accordo di Cooperazione[CN5].
Rispetto ad un Accordo di Servizio, un Accordo di Cooperazione definisce le
relazioni di servizio in qualita di intermediario: la relazione che questo tipo
di accordo e volta a creare coinvolge infatti piu organizzazioni. Tra queste
possiamo identificarne di tre tipi:
• Fruitrice, cioe l’organizzazione che intende ricevere la prestazione del
servizio.
• Erogatrici, cioe le organizzazioni che garantiscono le prestazioni di
servizio necessarie alla realizzazione dell’Accordo di Cooperazione.
• Referente, cioe l’organizzazione che si rende responsabile del corret-
to svolgimento dell’intera operazione concordata con l’organizzazione
fruitrice.
E’ chiaro quindi come l’organizzazione referente abbia un ruolo duale: es-
sa e infatti erogatrice nei confronti dell’organizzazione fruitrice e al tempo
stesso fruitrice dei servizi erogati dalle organizzazioni erogatrici. L’Accordo
di Cooperazione definisce quindi una composizione tra servizi che puo essere
di arbitraria complessita. Ad esempio, il risultato di uno o piu servizi puo
identificare il dato d’ingresso per un altro servizio. L’obiettivo di implemen-
tare gli Accordi di Cooperazione in OpenSPCoop ha richiesto lo studio e
l’utilizzo di meccanismi di organizzazione di processi produttivi (workflow)
per Web Service. Dopo l’analisi di vari linguaggi la scelta e ricaduta sul
linguaggio WS-BPEL (Business Process Execution Language for Web Ser-
vices [BPEL]) per la ricchezza dei costrutti e la semplicita d’uso. In seguito
e stata effettuata una ricerca di un engine per workflow scritti in BPEL;
tale ricerca ha portato alla scelta di JBPM-BPEL, un engine disponibile
per l’application server JBoss che costuituisce la base del funzionamento di
CAPITOLO 1. INTRODUZIONE 6
OpenSPCoop. Il componente Accordo di Cooperazione e stato infine inte-
grato nel Registro Servizi di OpenSPCoop e sono stati prodotti vari casi
d’uso che ne mostrassero le modalita d’utilizzo e il funzionamento.
1.1 Obiettivi della tesi
L’obiettivo di questa tesi e quindi la progettazione e l’implementazione di
un componente Accordo di Cooperazione che aderisca alle specifiche per
la Cooperazione Applicativa nella Pubblica Amministrazione rilasciata dal
CNlPA. Questo componente e diventato parte integrante del progetto Open-
SPCoop dalla versione 1.0.beta.3. Il raggiungimento di questo obiettivo ha
richiesto di affrontare i seguenti aspetti principali:
• Definizione dell’Accordo di Cooperazione a partire dalle specifiche del
CNIPA.
• Progettazione dell’Accordo di Cooperazione a partire dalla definizione
degli Accordi di Servizio e relativa integrazione nel Registro Servizi
OpenSPCoop.
• Ricerca ed identificazione di un engine per processi produttivi auto-
matizzabili (workflow).
• Realizzazione di strumenti per facilitare e velocizzare lo sviluppo di
servizi scritti secondo lo standard di orchestrazione per Web Service
WS-BPEL.
• Identificazione e realizzazione di casi d’uso per sperimentazione di WS-
BPEL.
• Identificazione e realizzazione di casi d’uso di Accordi di Cooperazione.
• Realizzazione di test suite per i casi d’uso identificati.
CAPITOLO 1. INTRODUZIONE 7
La prima fase del lavoro e consistita nell’analisi della versione del co-
dice esistente di OpenSPCoop con particolare riferimento agli Accordi di
Servizio e al Registro Servizi per verificare la fattibilita dell’obiettivo. In
una seconda fase si e passati ad analizzare le offerte tra engine BPEL per
la realizzazione di servizi di tipo workflow. Come anticipato in precedenza,
la scelta e ricaduta su JBPM-BPEL per la sua facile integrazione con gli
strumenti gia a disposizione nella piattaforma esistente. Successivamente si
e passati a implementare i primi esempi nel linguaggio BPEL per definire
scenari semplici del tipo
• verifica della disponibilita dell’engine sulla piattaforma (es. tipo Hello
World)
• implementazione di servizi di elaborazione ed inoltro di messaggi SOAP
semplici tra piu servizi
• utilizzo di tipi XML e di query Xpath
• indicizzazione dinamica di servizi.
In ultimo, si e passati all’identificazione dei casi d’uso e alla loro relativa
implementazione. Parte del codice scritto durante la tesi e stato reso frui-
bile, oltre che alla comunita OpenSPCoop, anche alla comunita dell’engine
JBPM-BPEL.
1.2 Contenuto della tesi
Nel secondo capitolo vengono descritte le architetture orientate ai servizi
(SOA) e i Web Service, nonche alcune tecnologie sulle quali si basa lo svi-
luppo di applicazioni secondo questo paradigma.
Nel terzo capitolo viene descritta la specifica SPCoop del CNIPA con una
descrizione sintetica dei componenti infrastrutturali e dell’architettura ge-
nerale di un progetto aderente a tale specifica.
CAPITOLO 1. INTRODUZIONE 8
Nel quarto capitolo si descrive OpenSPCoop, la realizzazione Open Source
della specifica SPCoop: sono mostrati sinteticamente i maggiori componenti
presenti, con particolare attenzione al Registro Servizi che e stato oggetto
di estensione e modifica durante questo lavoro di tesi.
Nel quinto capitolo si descrivono i linguaggi per workflow e il loro paradig-
ma di specifica chiamato linguaggio orientato ai grafi (GOP). Il capitolo
presenta il linguaggio WS-BPEL scelto per implementare la struttura di
orchestrazione dei servizi SPCoop e descrive brevemente altri linguaggi di
orchestrazione di Web Service, speigando le motivazioni che hanno portato
alla scelta di WS-BPEL.
Nel sesto capitolo si descrive come sia stato progettato e realizzato l’Accordo
di Cooperazione, la novita introdotta da questa tesi, a partire dall’Accordo
di Servizio gia presente in OpenSPCoop. In questo capitolo vengono ripresi
concetti della specifica del CNIPA per SPCoop relativi sia agli Accordi di
Servizio che agli Accordi di Cooperazione e viene spiegata la soluzione pro-
posta per l’Accordo di Cooperazione nel Regisro Servizi di OpenSPCoop.
Nel settimo capitolo dapprima si descrive l’engine JBPM per processi pro-
duttivi e l’estensione utilizzata durante questa tesi, l’engine JBPM-BPEL.
In seguito vengono mostrati casi d’uso scritti nel linguaggio WS-BPEL per
familiarizzare con il linguaggio e mostrarne le potenzialita. Il capitolo si
conclude con l’implementazione di casi d’uso decisi in fase di progettazione
e i relativi passaggi necessari per configurare porte di dominio che richiedano
Accordi di Cooperazione.
L’ultimo capitolo infine riassume gli obiettivi raggiunti e le conclusioni che
ne conseguono, illustrando alcuni possibili sviluppi futuri che possono essere
realizzati a partire dai risultati ottenuti in questa tesi.
Capitolo 2
Le Architetture basate su
Web Service
Le architetture orientate ai servizi (SOA) e i Web Service forniscono un
approccio standard per l’interoperabilita tra diverse applicazioni software in
esecuzione su una grande varieta di piattaforme e/o di framework. In questa
sezione verranno illustrati il modello concettuale e il contesto necessario
per comprendere i Web Service e le relazione tra le componenti di questo
modello.
2.1 Architetture Orientate ai Servizi (SOA)
Un sistema distribuito consiste di agenti software diversi che devono fun-
zionare insieme per realizzare certi compiti. Inoltre, gli agenti nel sistema
distribuito non operano nello stesso ambiente di esecuzione e quindi devono
comunicare usando protocolli hardware/software su una rete. Questo signifi-
ca che le comunicazioni in un sistema distribuito sono intrinsecamente meno
veloci e affidabili di quelle che usano invocazioni dirette di codice e memo-
ria condivisa. Questo ha importanti implicazioni perche i sistemi distribuiti
richiedono che gli sviluppatori (sia dell’infrastruttura che delle applicazioni)
9
CAPITOLO 2. LE ARCHITETTURE BASATE SU WEB SERVICE 10
tengano in considerazione la latenza della rete e gli accessi remoti, nonche
problemi di concorrenza e di fallimenti parziali.
I sistemi a oggetti distribuiti sono sistemi distribuiti nei quali l’inizializza-
zione degli oggetti e l’invocazione dei metodi sono esposti a sistemi remoti
attraverso meccanismi standard o proprietari per pubblicare le richieste at-
traverso i confini del sistema, marshall e unmarshall dei dati in argomento
dei metodi, ecc. . . .
I sistemi ad oggetti distribuiti tipicamente sono caratterizzati da oggetti
che mantengono uno stato interno complesso richiesto per supportare i loro
metodi e da una interazione tra un oggetto e un programma che lo usa ri-
spettando un sistema di tipi di oggetti condiviso.
Una architettura orientata ai servizi (SOA) e una forma di architettura
caratterizzata da:
• Visione logica: Il servizio e una visione astratta, logica dei program-
mi in esecuzione, database, processi di tipo business, ecc. . . definiti in
termine di cosa fanno, in genere adempiendo a operazioni a livello
business.
• Orientamento ai messaggi: il servizio e formalmente definito in termini
dei messaggi scambiati tra gli agenti fornitori e gli agenti richiedenti
e non in termini delle proprieta degli agenti stessi. La struttura in-
terna di un agente, incluse le caratteristiche come il suo linguaggio
di implementazione, la struttura del processo e anche la struttura del
database sono deliberatamente rese astratte in una architettura orien-
tata al servizio: usando la disciplina SOA non c’e bisogno di sapere
come un agente che implementa un servizio sia costruito.
• Orientamento alla descrizione: un servizio e descritto da metadati pro-
cessabili da una macchina. La descrizione esposta al pubblico contiene
solo dettagli importanti per l’uso del servizio. La semantica del servi-
CAPITOLO 2. LE ARCHITETTURE BASATE SU WEB SERVICE 11
zio dovrebbe essere documentata, indirettamente o direttamente, dalla
sua descrizione.
• Modularita: I servizi tendono ad usare un piccolo numero di operazioni
con messaggi relativamente larghi e complessi
• Orientazione alla rete: I servizi tendono ad essere progettati per essere
offerti attraverso la rete, sebbene questo non sia un requisito assoluto.
• Neutralita rispetto alla piattaforma: I messaggi sono inviati in manie-
ra neutrale rispetto alla piattaforma e recapitati in formati standard
attraverso le interfacce. XML e il piu ovvio formato che permette di
rendere questa caratteristica.
2.2 Web Service: una Tecnologia per SOA
Le architetture orientate ai servizi sono un modello di architettura informa-
tica distribuita che e diffusa grazie alla maturita e al consolidamento degli
standard e delle tecnologie Web Service[w3cArch]. E’ utile comunque pre-
cisare la differenza concettuale tra architetture orientate ai servizi e Web
Service:
L’architettura SOA definisce un modello concettuale di architettura informa-
tica distribuita costituita da un insieme di sistemi autonomi che comunicano
per mezzo di messaggi scambiati attraverso interfacce standardizzate.
Il termine Web Service ricopre invece un insieme di standard tecnologici che
permettono la realizzazione di architetture SOA su larga scala, garantendo
al tempo stesso l’interoperabilita e l’autonomia di implementazione dei si-
stemi componenti l’architettura.
In questa sezione verranno illustrati i concetti alla base dei Web Service e
come si possa usarli per erogare servizi. Inoltre verranno brevemente illu-
strate alcune delle tecnologie che sono critiche per il funzionamento dei Web
Service e il ruolo che ricoprono.
CAPITOLO 2. LE ARCHITETTURE BASATE SU WEB SERVICE 12
2.2.1 Cos’e un Web Service?
Un Web Service e un sistema software progettato per supportare intera-
zione machine-to-machine su una rete. Il Web Service e descritto in un
formato processabile dalle macchine (nella fattispecie WSDL). Altri sistemi
interagiscono con i Web Service secondo quanto definito nella loro descrizio-
ne usando messaggi SOAP, in genere trasportati attraverso HTTP con una
serializzazione XML in combinazione con altri standard legati al Web.
2.2.2 Agenti e Servizi
Un Web Service e una nozione astratta che deve essere implementata da un
agente concreto. Con agente si intende un pezzo di software o di hardware
capace di inviare e ricevere messaggi, mentre il servizio e la risorsa carat-
terizzata da un insieme astratto di funzionalita che vengono fornite. Per
illustrare questa distinzione e possibile implementare un particolare Web
Service usando un giorno un agente (scritto ad esempio in un linguaggio
di programmazione) e un altro agente il giorno successivo (magari usando
un linguaggio differente) mantenendo le stesse funzionalita. Sebbene questi
agenti possano differire, il Web Service rimane lo stesso.
2.2.3 Fornitori e Richiedenti
Lo scopo di un Web Service e di fornire la descrizione dell’invocazione di
un servizio tra due entita, quella fornitrice del servizio e quella richiedente.
L’entita fornitrice e la persona o l’organizzazione che fornisce un agente ap-
propriato per implementare un particolare servizio. Una entita richiedente
e una persona o una organizzazione che desidera usare l’entita fornitrice del
Web Service. Questa entita usera un agente richiedente per scambiare mes-
saggi con l’agente dell’entita fornitrice. In molti casi, l’agente richiedente e
colui che inizia lo scambio di messaggi. Per consistenza di trattazione, con-
tinueremo ad usare il termine agente richiedente per l’agente che interagisce
CAPITOLO 2. LE ARCHITETTURE BASATE SU WEB SERVICE 13
con l’agente fornitore anche nel caso in cui l’agente fornitore inizi lo scam-
bio di messaggi. Per realizzare uno scambio di messaggi corretto, l’entita
richiedente e l’entita fornitrice devono prima accordasi sia sulla semantica
sia sui meccanismi di scambio di messaggi.
2.2.4 Descrizione del Servizio
I meccanismi di scambio di messaggi sono documentati in una descrizione
di servizio (WSD). Tale descrizione e descritta in un linguaggio testuale
basato su XML di nome WSDL, Web Service Description Language. Questa
descrizione definisce i formati dei messaggi, i tipi dei dati, i protocolli di
trasporto e il trasporto per i formati di serializzazione per i dati tra l’agente
richiedente e l’agente fornitore. Nella descrizione inoltre troviamo una o piu
locazioni di rete alle quali un agente fornitore puo essere invocato e puo
fornire alcune informazioni sul pattern di scambio di messaggi che bisogna
aspettarsi. In sintesi, la descrizione del servizio rappresenta l’accordo che
regola i meccanismi per l’interazione con i Web Service.
2.2.5 La Semantica
La semantica di un Web Service e la definizione del comportamento del
servizio, condiviso tra gli agenti, che definisce nello specifico la risposta ai
messaggi che il servizio riceve. Questo e quello che si puo definire il con-
tratto tra l’entita richiedente e l’entita fornitrice che riguarda le finalita e
le conseguenze dell’interazione. Sebbene questo contratto rappresenti l’ac-
cordo globale tra l’entita richiedente e l’entita fornitrice su come e perche i
loro rispettivi agenti interagiranno, non deve essere necessariamente scritta
o esplicitamente negoziata. Puo essere implicita o esplicita, orale o scritta,
processabile da macchine o no e puo essere un accordo legale o informale.
Mentre la descrizione del servizio rappresenta un contratto che regola i mec-
canismi di interazione con un particolare servizio, la semantica rappresenta
CAPITOLO 2. LE ARCHITETTURE BASATE SU WEB SERVICE 14
un contratto che regola i significati e il motivo di quella interazione. La
linea di divisione tra questi due concetti non e necessariamente rigida. Cosı
quanto piu ricco e semanticamente un linguaggio usato per descrivere il mec-
canismo di interazione tanto piu le informazioni essenziali possono spostarsi
da una semantica informale alla descrizione di un servizio. Quando questo
spostamento si verifica, la maggior parte del lavoro richiesto per raggiungere
un’interazione corretta puo essere automatizzato.
2.2.6 Schema di Attivazione di un Web Service
Ci sono vari modi con cui una entita richiedente puo attivare e usare un
Web Service. In generale, i passi che seguono possono essere identificati in
quelli illustrati nella figura:
1. le entita fornitrice e richiedente diventano note l’una all’altra
2. le entita in qualche modo si accordano sulla descrizione del servizio e
sui meccanismi che regoleranno l’interazione tra i rispettivi agenti
3. la semantica del servizio viene realizzata da entrambi gli agenti (e.g.
il codice per processare l’input e calcolare la risposta)
4. gli agenti si scambiano i messaggi secondo il protocollo concordato
nella descrizione del servizio.
Alcuni dei passaggi precedenti possono essere eseguiti in maniera auto-
matica, altri in maniera manuale.
2.3 Tecnologie per Web Service
L’architettura Web Service coinvolge molte tecnologie stratificate e correlate.
Ci sono molti modi per visualizzare queste tecnologie proprio come ci sono
molti modi per costruire e usare i Web Service. La figura seguente fornisce
una illustrazione di alcune di queste tecnologie.
CAPITOLO 2. LE ARCHITETTURE BASATE SU WEB SERVICE 15
Figura 2.1: Schema di Attivazione di un Web Service.
Figura 2.2: Web Service: L’organizzazione dell’architettura.
2.3.1 XML
XML (eXtensible Markup Language, ovvero ’Linguaggio di marcatura esten-
sibile’) e un meta linguaggio utilizzato per creare nuovi linguaggi, atti a de-
scrivere documenti strutturati. XML, come HTML, utilizza dei marcatori,
CAPITOLO 2. LE ARCHITETTURE BASATE SU WEB SERVICE 16
detti tag, per assegnare una semantica al testo. L’estensibilita di XML si
riconosce nella capacita di poter esprimere tag personalizzati. Ad esempio,
se di un tipo persona vogliamo memorizzare solo il nome e il cognome, una
istanza di questo oggetto in XML e rappresentabuile come segue:
<persona>
<nome>Mario</nome>
<cognome>Rossi</cognome>
</persona>
XML risolve un requisito chiave di tecnologia che appare in molti con-
testi. Offrendo un formato per i dati standard e al tempo stesso flessibile,
XML riduce significativamente il peso di sviluppare le molte tecnologie ri-
chieste per assicurare il successo dei Web Service.
Gli aspetti rilevanti di XML, per le qualita dell’architettura, sono la sintassi
di base stessa, il concetto di XML Infoset, XML schema e XML namespace.
Gli XML Infoset [INFOSET] sono formati di dati astratti e il loro compito
e di fornire un insieme consistente di definizioni che altre specifiche possono
usare per riferire parti di informazioni in un documento XML ben formato.
Una di queste informazioni ad esempio e l’insieme dei vincoli per costruire
un element in un documento XML: unicita del nome nel documento, name-
space di riferimento, elemento padre ecc...
Gli XML Schema [SCHEMA] permettono di registrare tipi e regole dei tipi.
Per fare questo, forniscono costrutti per definire le strutture, i contenuti e
la semantica dei documenti XML. Ad esempio un documento che rispetti
un XML Schema dovra avere un certo numero di elementi e di ogni tipo di
elementi un numero che e regolato dal XML Schema.
Gli XML Namespace [NS] permettono di definire spazi di nomi con lo stesso
significato che questo termine assume nei comuni linguaggi di programmazio-
ne spesso sotto il concetto di package. Questo, ad esempio, permette di avere
due o piu elementi con il medesimo nome all’interno dello stesso documento
CAPITOLO 2. LE ARCHITETTURE BASATE SU WEB SERVICE 17
purche appartengano a namespace differenti. Essendo XML un linguaggio
completamente testuale permette la trasmissione attraverso la rete in manie-
ra abbastanza flessibile. La flessibilita di scelta dei formati di serializzazione
permette una interoperabilita piu vasta tra gli agenti del sistema. In futuro,
una codifica binaria di XML Infoset puo essere un ottimo candidato per
rimpiazzare la serializzazione testuale. Una codifica binaria potrebbe essere
piu efficiente e piu adatta per interazioni machine-to-machine.
2.3.2 SOAP
SOAP (Simple Object Access Protocol)[SOAP] e un protocollo per lo scam-
bio di messaggi tra componenti software, tipicamente per l’invocazione di
Web Service ed e basato su XML. Lo scambio di messaggi SOAP permet-
te l’esecuzione di procedure remote come accade per l’interazione con Web
Service. Un messaggio SOAP si divide tipicamente in due parti:
• Header (Intestazioni): in questa parte vengono racchiuse le informa-
zioni che non appartengono ai dati della applicazione ma che sono ne-
cessarie al corretto svolgimento del protocollo. Un esempio puo essere
la data di invio del messaggio. L’elemento Header non e obbligatorio.
• Body (Corpo): in questa parte vengono scambiati i dati relativi alle
applicazioni, tipicamente in formato XML. L’elemento body e obbli-
gatorio.
SOAP 1.1 fornisce un framework standard componibile ed estensibile per lo
scambio di messaggi XML. I messaggi SOAP possono essere trasportati su
una gran varieta di protocolli di rete come HTTP, SMTP, FTP, RMI/IIOP o
protocolli per messaggi proprietari. Un messaggio SOAP definisce, inoltre,
tre componenti opzionali: un insieme di regole di codifica per esprimere
le istanze dei tipi di dati definiti dall’applicazione, una convenzione per
rappresentare le chiamate a procedure remote (RPC) e ritorni e un insieme
CAPITOLO 2. LE ARCHITETTURE BASATE SU WEB SERVICE 18
di regole per utilizzare SOAP con HTTP 1.1. SOAP quindi rappresenta
un protocollo per architetture orientate al servizio. Un messaggio SOAP
rappresenta l’informazione necessaria per invocare un servizio o riflette i
risultati di una invocazione di servizio e contiene le informazioni specificate
nella definizione dell’interfaccia di un servizio.
2.3.3 WSDL
WSDL (Web Service Description Language) e un linguaggio per descrivere
Web Service. WSDL rappresenta un formato XML per descrivere servizi
di rete come un insieme di nodi basati su messaggi. WSDL descrive i Web
Service iniziando con la definizione dei messaggi che devono essere scambiati
tra l’agente richiedente e l’agente fornitore. I messaggi stessi sono descritti
in maniera astratta e sono legati ad un concreto formato di messaggi e a un
protocollo di rete ben definito. Un documento WSDL si divide tipicamente
in due parti:
• Astratta: Le operazioni sono definite tramite lo scambio di messaggi.
Operazioni e messaggi sono identificati da tipi XML.
• Concreta: Le operazioni astratte sono concretizzate aggiungendo lo-
ro le informazioni di rete relative al nodo su cui saranno disponibili
(indirizzo, tipo di chiamata (es. RPC) e protocollo di trasporto).
Le definizioni di Web Service possono essere mappate su un qualunque lin-
guaggio, piattaforma, modello a oggetti o sistema di messaggi. Semplici
estensioni all’infrastruttura Internet esistente possono implementare Web
Service per l’interazione via browser o direttamente dall’interno dell’appli-
cazione. L’applicazione puo essere implementata usando COM, JMS, COR-
BA, COBOL e un qualsiasi numero di soluzioni proprietarie di integrazione.
Fin quando mittente e destinatario sono d’accordo sulla descrizione del ser-
CAPITOLO 2. LE ARCHITETTURE BASATE SU WEB SERVICE 19
vizio (i.e. condividono lo stesso file WDSL), l’implementazione dietro al
Web Service puo essere qualunque cosa.
2.3.4 XPath
XPath e un linguaggio per espressioni che permette l’elaborazione di oggetti
XML. Tale elaborazione e resa possibile da un modello dei dati che rappre-
senta documenti XML tramite alberi navigabili. Il risultato di una espres-
sione XPath puo essere la selezione di nodi da documenti in input, o valori
atomici oppure in generale una qualunque sequenza ammessa nel modello
dei dati. Il nome XPath deriva dalla sua caratteristica piu distintiva, l’uso di
’cammini’ per individuare specifiche informazioni all’interno della struttura
ad albero di un determinato oggetto XML. Una tipica espressione XPath per
ottenere il nome della persona sul seguente tipo XML e ’/persona/nome’.
<persona>
<nome>Mario</nome>
<cognome>Rossi</cognome>
</persona>
2.3.5 Il Protocollo di Comunicazione per i Web Service
Concentriamo ora la nostra attenzione sui passi richiesti per utilizzare un
Web Service. Sebbene questi passi siano necessari potrebbero non essere
sufficienti: molti scenari richiederanno passi aggiuntivi o raffinamenti signi-
ficanti di questi passi fondamentali. Inoltre, l’ordine con cui questi passi
vengono eseguiti puo variare a seconda della situazione.
1. Le entita richiedente e fornitrice si conoscono nel senso che l’iniziatore
deve conoscere l’altra parte. Ci sono due casi:
(a) nel caso tipico, l’agente richiedente sara l’iniziatore. In questo
caso, diremo che l’entita richiedente deve conoscere l’entita for-
nitrice, cioe l’agente richiedente deve in qualche modo ottenere
CAPITOLO 2. LE ARCHITETTURE BASATE SU WEB SERVICE 20
l’indirizzo dell’agente fornitore. Questo avviene tipicamente in
due modi: l’agente richiedente puo ottenere l’indirizzo dell’agente
fornitore direttamente dall’entita fornitrice oppure l’entita richie-
dente puo usare un servizio di discovery per localizzare una de-
scrizione del servizio adatta (che contiene l’indirizzo per invocare
l’agente fornitore) attraverso una descrizione funzionale oppure
attraverso un discovery manuale o una selezione automatica.
(b) in altri casi, l’agente fornitore puo iniziare lo scambio di messag-
gi tra l’agente richiedente e fornitore. In questo caso, dire che le
due entita si conoscono in genere vuol dire che l’entita fornitrice
conosce l’entita richiedente; in altre parole l’agente fornitore in
qualche modo ottiene l’indirizzo dell’agente richiedente. Come
cio possa avvenire dipende dall’applicazione ed e irrilevante per
questa architettura. Sebbene questo caso sia meno diffuso, e im-
portante in scenari di tipo abbonamento (il client si abbona ad
un servizio e l’erogatore del servizio lo contatta per erogarlo).
2. Le due entita si mettono d’accordo sulla descrizione del servizio (un do-
cumento WDSL) e sulla semantica che regolera l’interazione tra i due
rispettivi agenti. Questo non significa necessariamente che le due en-
tita devono comunicare o negoziare l’un l’altra ma semplicemente che
devono condividere la stessa descrizione del servizio (o una compatibi-
le) e la relativa semantica e intendono sostenerla. Si puo raggiungere
questo scopo in vari modi:
• Le due entita possono comunicare direttamente l’una con l’altra
e mettersi esplicitamente d’accordo sulla descrizione del servizio
e sulla semantica.
• L’entita fornitrice puo pubblicare e offrire sia la semantica del
CAPITOLO 2. LE ARCHITETTURE BASATE SU WEB SERVICE 21
servizio che la sua descrizione che il fruitore accetta senza alcuna
obiezione.
• La descrizione del servizio e la sua semantica possono essere de-
finiti da una organizzazione industriale e usate da molte entita
fornitrici ed erogatrici. In questo caso, il consenso di entram-
be le parti e raggiunto indipendentemente grazie all’adesione allo
stesso standard.
• La descrizione del servizio e la sua semantica possono essere de-
finiti e pubblicati dall’entita richiedente e offerti dalle entita for-
nitrici su basi che non vengono discusse. Questo puo succedere,
ad esempio, se una grande compagnia richiede ai suoi fornito-
ri di fornire Web Service che siano conformi ad una particolare
descrizione del servizio e semantica. In questo caso l’accordo e
raggiunto tramite l’utilizzo da parte dell’entita fornitrice delle
informazioni pubblicate dal richiedente.
A seconda dello scenario il passo 2 puo essere eseguito prima del passo
1.
3. La descrizione del servizio e la sua semantica sono noti a entrambi gli
agenti. In altre parole, l’informazione di cui dispongono deve essere
input di entrambi o comunque fornita nell’implementazione. Ci sono
molti modi in cui si puo raggiungere questo obiettivo e l’architettura
non lo specifica e non ne ha bisogno. Per esempio
• Un agente potrebbe avere la descrizione del servizio e la relativa
semantica direttamente cablati nel codice.
• Un agente potrebbe essere implementato in una maniera piu ge-
nerica e la descrizione del servizio e la sua semantica possono
essere input dinamici.
CAPITOLO 2. LE ARCHITETTURE BASATE SU WEB SERVICE 22
• Un agente puo essere dapprima creato e la descrizione del servizio
e la sua semantica possono essere dedotti o generati dal codice
dell’agente. Per esempio un tool puo esaminare un insieme di
informazioni e generare da un insieme di classi esistenti la descri-
zione del servizio (come il tool Java2WSDL fornito da Apache
Axis).
Qualunque sia l’approccio usato la descrizione del servizio e la
sua semantica devono essere noti ad entrambi gli agenti prima
che i due agenti interagiscano.
4. I due agenti si scambiano messaggi SOAP per eseguire le comunica-
zioni.
Capitolo 3
La specifica SPCoop del
CNIPA
In questo capitolo viene presentata la specifica della Cooperazione Applica-
tiva del Centro Nazionale per l’informatica nella Pubblica Amministrazione
(CNIPA) per il Servizio Pubblico di Cooperazione (SPCoop). Per Coope-
razione Applicativa si intende un paradigma finalizzato alla gestione delle
informazioni e dei servizi tra Pubbliche Amministrazioni (PA). L’esigen-
za di una regolamentazione del paradigma di Cooperazione Applicativa e
maturata in questi ultimi anni come conseguenza del forte processo d’infor-
matizzazione che ha coinvolto le Pubbliche Amministrazioni, comunemente
riferito come e-Government, ed ha infine portato alla pubblicazione della
specifica SPCoop da parte del CNIPA. La trattazione si sviluppa in maniera
sintetica sui componenti SPCoop in quanto marginali per la comprensione
del lavoro di questa tesi. Argomenti centrali come gli Accordi di Servizio e
gli Accordi di Cooperazione sono invece trattati con un livello di dettaglio
maggiore per la loro centralita nel lavoro oggetto di questa tesi nel sesto
capitolo, Dagli Accordi di Servizio agli Accordi di Cooperazione.
23
CAPITOLO 3. LA SPECIFICA SPCOOP DEL CNIPA 24
3.1 La Specifica SPCoop di Cooperazione Appli-
cativa
Il Sistema Pubblico di Cooperazione (SPCoop) e un insieme di standard
tecnologici e di servizi infrastrutturali il cui obiettivo e di permettere l’in-
teroperabilita e la cooperazione di sistemi informatici per la realizzazione
di adempimenti amministrativi. Tali sistemi sono sotto la responsabilita di
soggetti pubblici, appartenenti ad amministrazioni centrali, enti pubblici, re-
gioni, provincie, comuni, comunita di enti locali, e soggetti privati (imprese
e associazioni accreditate). L’insieme dei soggetti pubblici e privati operanti
sul S.P. (Servizio Pubblico) di Cooperazione costituiscono la comunita dei
soggetti del S. P. di Cooperazione. Tale cooperazione e motivata da due
esigenze fondamentali:
• L’esigenza di coordinamento di processi realizzati con il concorso di
trattamenti distribuiti tra sistemi informatici di cui sono responsabili
soggetti pubblici e privati, al fine di assecondare l’esecuzione di proce-
dimenti amministrativi e la produzione di atti e provvedimenti ammi-
nistrativi. Il coordinamento e la collaborazione di detti sistemi devono
essere corredati dalla capacita di ispezionare in ogni momento lo sta-
to di avanzamento (gli adempimenti amministrativi effettuati e quelli
ancora da effettuare) dei processi applicativi e l’origine di ogni atto
amministrativo effettuato nell’ambito del processo applicativo, al fine
di realizzare concretamente la trasparenza dell’azione amministrativa
nel doveroso rispetto delle norme sulla confidenzialita e riservatezza
dei dati.
• Il coordinamento e la collaborazione dei trattamenti distribuiti tra piu
sistemi informatici appartenenti a piu soggetti pubblici e privati, al
fine di assicurare il funzionamento interno delle amministrazioni e di
fornire servizi di utilita alle altre amministrazioni, ai cittadini, alle
CAPITOLO 3. LA SPECIFICA SPCOOP DEL CNIPA 25
imprese e alle associazioni, in conformita con i compiti istituzionali
delle diverse amministrazioni.
Il modello generale di riferimento dell’architettura del Sistema pubblico
di cooperazione e il modello dell’architettura di servizi sulla base di tecnolo-
gie Web Service [w3cArch]. I vantaggi principali che derivano dall’adozione
di un tale modello per il Sistema Pubblico di Cooperazione sono:
• Il modello dell’architettura dei servizi e pienamente distribuito e per-
mette l’interoperabilita e la cooperazione dei sistemi informatici sul-
la base di accordi sullo scambio di funzionalita, sulle interfacce che
permettono tale scambio e sui suoi requisiti di sicurezza e qualita di
servizio, nella piena autonomia delle scelte implementative e gestio-
nali dei sistemi componenti l’architettura. L’indipendenza delle scelte
implementative delle funzionalita applicative e delle funzionalita di
infrastruttura (gestione dei messaggi, sicurezza, qualita di servizio)
dei sistemi cooperanti rende tale modello perfettamente adatto alle
esigenze di autonomia di gestione delle amministrazioni centrali e lo-
cali e all’interoperabilita con sistemi applicativi delle imprese e delle
associazioni qualificate.
• La realizzazione delle funzionalita infrastrutturali di interfaccia, si-
curezza e qualita di servizio necessarie alla cooperazione applicativa,
sulla base degli standard tecnologici Web Service [w3cArch], permette
di minimizzare l’impatto sull’implementazione delle funzionalita ap-
plicative gia realizzate nei sistemi informativi dei soggetti, pubblici e
privati. Il modello non solo garantisce la salvaguardia del patrimonio
applicativo dei soggetti pubblici e privati, ma ne stimola la valorizza-
zione attraverso il riuso in nuovi contesti di funzionalita applicative gia
implementate. La scelta del modello dell’architettura di servizi sulla
base delle tecnologie Web Service e quindi conforme alle esigenze di
CAPITOLO 3. LA SPECIFICA SPCOOP DEL CNIPA 26
economia e di controllo della spesa pubblica e della qualita del servizio
amministrativo.
Una caratteristica fondamentale del modello dell’architettura di servizi e
che l’interazione tra i sistemi partecipanti avviene esclusivamente per mezzo
dello scambio di messaggi in rete. Ne consegue che due sistemi interagenti
devono essere connessi per mezzo di uno o piu canali che trasportano i
messaggi scambiati. Il Sistema Pubblico di Cooperazione utilizza per il
trasporto dei messaggi esclusivamente i canali e i meccanismi di trasporto
forniti dal Sistema Pubblico di Connettivita [SPC]. Il S. P. di Connettivita
fornisce al S.P. di Cooperazione:
• l’infrastruttura di base per il trasporto dei messaggi,
• un insieme di funzionalita infrastrutturali di sicurezza e qualita di
servizio applicabili al trasporto dei messaggi.
Dal punto di vista dei sistemi interagenti nel S. P. di Cooperazione, il
S. P. di Connettivita e semplicemente e esclusivamente il fornitore della in-
frastruttura per il trasporto dei messaggi. L’architettura logica e fisica dei
sistemi partecipanti al S.P. di Cooperazione e indipendente dell’architettura
logica, fisica, di rete del S.P. di Connettivita: i soli punti di collegamento si
trovano nell’uso del protocollo di trasporto utilizzato dal S.P. di Connetti-
vita (IP), e, eventualmente nell’uso di funzionalita di sicurezza (IPSec) e di
qualita di servizio applicabili al trasporto fornite dal S.P. di Connettivita.
3.2 I Componenti Infrastrutturali previsti in SP-
Coop
Prima dell’avvento del paradigma di cooperazione applicativa, le comuni-
cazioni nella P.A. avvenivano tramite collegamenti punto-punto tra i ser-
ver applicativi interessati. Poiche tipicamente questi server erano dislocati
CAPITOLO 3. LA SPECIFICA SPCOOP DEL CNIPA 27
su reti private, raggiungibili quindi esclusivamente da altri server dislocati
sulla loro stessa rete privata, era necessario realizzare reti virtuali private
(VPN), ad esempio tra tutte le strutture afferenti a una certa amministrazio-
ne centrale, o anche appositamente realizzate tra due amministrazione per
permettere il collegamento punto-punto tra due server applicativi apparte-
nenti a quelle amministrazioni. Ovviamente questa soluzione si e dimostrata
inadatta nella gestione del processo di eGovernment, che prevede che due
qualunque enti debbano essere potenzialmente in grado di comunicare tra
loro. SPCoop risolve questo problema imponendo un’infrastruttura stan-
dard di comunicazione tra le amministrazioni pubbliche. In tal modo, una
volta che l’infrastruttura sia diventata completamente operativa, sara suffi-
ciente il collegamento di un’amministrazione all’infrastruttura SPCoop per
abilitarla alla comunicazione con qualunque altra amministrazione italiana
ed europea. La figura seguente mostra i principali componenti parte dell’in-
frastruttura SPCoop, in particolare: la busta eGov, la Porta di Dominio, le
porte delegate e applicative e il Registro dei Servizi.
Figura 3.1: I principali componenti dell’infrastruttura SPCoop.
CAPITOLO 3. LA SPECIFICA SPCOOP DEL CNIPA 28
3.2.1 La Porta di Dominio
Nella specifica SPCoop, un dominio e definito come il confine di responsabi-
lita di un ente o soggetto amministrativo e racchiude al suo interno tutte le
applicazioni da esso gestite. Le comunicazioni da e verso un dominio devono
attraversare la sua Porta di Dominio (PdD). Le Porte di Dominio si parlano
tra di loro scambiandosi richieste e risposte in un formato standard, deno-
minato busta eGov. Le porte delegate e le porte applicative costituiscono
gli elementi della Porta di Dominio che mediano gli accessi tra i sistemi in-
terni agli enti e l’infrastruttura SPCoop. In particolare una Porta Delegata
e utilizzata come proxy per l’accesso al servizio destinazione, mentre una
Porta Applicativa deve essere in grado di gestire la consegna dei contenuti
applicativi a un server interno al dominio destinazione. Poiche il formato
della busta eGov non e parlato nativamente (e non e previsto che lo sia)
dalle applicazioni, la Porta di Dominio deve anche occuparsi di converti-
re le richieste applicative in formato proprietario nel formato di SPCoop,
la busta eGov (vedi 3.2.2). Facendo riferimento a questa problematica, i
compiti della Porta di Dominio vengono solitamente divisi in due compo-
nenti: il componente di integrazione e quello di cooperazione. Mentre la
specifica SPCoop copre completamente gli aspetti relativi al componente di
cooperazione, si limita a presentare un esempio di massima di una possibile
realizzazione per quanto attiene al componente di integrazione.
3.2.2 La Busta eGov
Lo standard CNIPA sulla Busta di eGovernment e stato il primo ad esse-
re ratificato, il 21 Aprile 2004, tra quelli relativi a SPCoop. La Busta di
eGovernment specifica il formato dei messaggi scambiati tra le PdD nelle
interazioni di cooperazione applicativa e ne costituisce di fatto l’elemento
informativo di base. Una Busta di e-Government e sostanzialmente una
CAPITOLO 3. LA SPECIFICA SPCOOP DEL CNIPA 29
specializzazione di un messaggio SOAP, esteso con un apposito header per
definire le caratteristiche del protocollo SPCoop.
3.2.3 Il Registro Servizi
La specifica CNIPA prevede la presenza di un componente architetturale
per la memorizzazione della descrizione dei soggetti, dei servizi disponibi-
li e degli accordi di servizio. In particolare la specifica prevede di basare
quanto sopra su un registro in tecnologia UDDI e su un repository degli
accordi di servizio, tipicamente espressi in XML. La funzione di registrazio-
ne permettera agli enti di registrarsi e di registrare i servizi che intendono
erogare (porte applicative), mentre la funzione di consultazione consente ai
potenziali fruitori dei servizi di ottenere informazioni su di essi. Tramite il
registro UDDI e possibile:
• registrare enti o altre istituzioni eroganti servizi in standard SPCoop;
• registrare il servizio offerto da un punto di vista descrittivo;
• ottenere informazioni su un soggetto che ha pubblicato un servizio;
• ottenere dettagli relativi al tipo di servizio;
• ottenere dettagli tecnici necessari per invocare il servizio (ad es. l’in-
dirizzo del file WSDL).
La specifica SPCoop prevede l’esistenza di un registro di primo livello,
gestito dal CNIPA e che includa tutti i servizi ufficiali SPCoop, e di registri
di secondo livello che possano contenere un sottoinsieme dei servizi SPCoop.
3.2.4 Il Gestore Eventi
Il Gestore Eventi e un servizio a valore aggiunto, previsto dalla specifica
SPCoop per permettere lo scambio di buste eGov secondo l’architettura
CAPITOLO 3. LA SPECIFICA SPCOOP DEL CNIPA 30
EDA (Event Driven Architecture), permettendo quindi ai Sistemi Applica-
tivi iscritti di ricevere le buste inviate dai Sistemi Applicativi che le pubbli-
cano. Da questo punto di vista, il Gestore Eventi puo essere considerato un
normale servizio SPCoop, accessibile come mostrato nella figura seguente.
Figura 3.2: Il Gestore Eventi.
CAPITOLO 3. LA SPECIFICA SPCOOP DEL CNIPA 31
3.2.5 I Componenti di Integrazione
La necessita di utilizzare la busta eGovernment per la comunicazione tra
i due Server tramite SPCoop pone il problema di come costruire le buste
a partire dai dati forniti o attesi dall’applicativo. In sostanza, di come
realizzare il componente di integrazione. La soluzione tipicamente adottata
e quella mostrata nella figura seguente, che consiste nell’installare una coppia
di proxy, sviluppati ad-hoc per ogni servizio, sulle due porte di dominio.
Figura 3.3: Integrazione di SPCoop.
CAPITOLO 3. LA SPECIFICA SPCOOP DEL CNIPA 32
I proxy si occuperanno, rispettivamente, di incapsulare e deincapsula-
re i dati proprietari in un formato XML, poi utilizzato dai componenti di
cooperazione come body della busta eGov. Il proxy ha anche un altro com-
pito, che e quello di conoscere i metadati relativi alla comunicazione, come il
profilo di collaborazione (sincrono, oneway, asincrono simmetrico, asincrono
asimmetrico) attivo per quel servizio e l’indirizzo del destinatario reale del
servizio al quale la richiesta dovra essere diretta (Ente, Servizio e Azione da
utilizzare nell’header della busta). Tutti questi dati sono sostanzialmente
cablati nello stesso proxy. Questo problema e stato brillantemente risolto
nel progetto OpenSPCoop (vedi capitolo 4) potendo adottare la porta di
dominio come proxy SOAP. Non e quindi necessario installare un proxy per
ogni servizio offerto ma basta configurare opportunamente i servizi.
3.2.6 I Web Service come Soluzione per l’Integrazione
Di recente la grande diffusione dell’XML e dei Web Service, che usano l’XML
non solo per il trasporto dei dati (buste SOAP), ma anche per la definizione
del loro formato (schemi XML), sta semplificando la realizzazione della com-
ponente di Integrazione. Si puo infatti considerare un sistema interno gia
capace o facilmente adattabile al dialogo tramite Web Service o anche piu
semplici POST http che ne simulino il comportamento. In tal caso la com-
ponente di integrazione non dovra usare tecnologie diverse per ogni possibile
sistema legacy da interfacciare (CORBA, RMI, JMS, .NET, etc.), ma potra
essere invece un generico container (ad esempio J2EE) capace di ospitare
Web Service che fungano da proxy per le richieste di servizio formulate dai
server interni. Una soluzione di questo tipo ha il vantaggio di semplificare la
realizzazione dei proxy, ma richiede ancora che i proxy conoscano i metadati
relativi alla comunicazione. Anche basandosi sull’uso dei Web Service, sara
quindi ancora necessario realizzare ed installare sulle porte di dominio una
coppia di proxy per ogni servizio da raggiungere.
Capitolo 4
OpenSPCoop
OpenSPCoop [OPENSPCOOP] e un progetto finalizzato alla realizzazione
di un insieme di componenti Open Source aderenti alle specifiche SPCoop
descritte nel capitolo precedente. Il progetto OpenSPCoop nasce sostanzial-
mente con l’obiettivo di una implementazione di riferimento Open Source che
permetta di sperimentare in maniera condivisa l’implementazione dei con-
cetti proposti nella specifica, evidenziando e proponendo possibili soluzioni
per le potenziali ambiguita o debolezze della stessa. I vantaggi dell’approccio
Open Source adottati da OpenSPCoop si possono evidenziare nei seguenti
aspetti:
• Interoperabilita, OpenSPCoop intende rappresentare un riferimento
per disambiguare diverse possibili interpretazioni della specifica SP-
Coop;
• Sicurezza, l’apertura del codice assicura quelle caratteristiche di tra-
sparenza del codice ormai considerate un atto dovuto in molti settori
della sicurezza informatica;
• Comunita d’Utenza, OpenSPCoop tende a fungere da catalizzato-
re per le esperienze e le competenze degli utenti, permettendo di
ricapitalizzarle in risultati concreti e riusabili;
33
CAPITOLO 4. OPENSPCOOP 34
• Innovazione, un’implementazione Open Source e il veicolo ideale per
proporre delle implementazioni condivisibili di quanto non ancora trat-
tato nelle specifiche SPCoop.
Dopo un’ampia fase di analisi, svolta attraverso lo studio di vari progetti
pilota tra cui il progetto CART di Regione Toscana e il progetto SOLE di
Regione Emilia Romagna, e emersa la proposta di un’architettura innovativa
per la realizzazione di un’infrastruttura compatibile con le specifiche CNI-
PA, che riducesse pero significativamente l’impatto sui sistemi preesistenti
rispetto alle altre soluzioni disponibili. La prima release del software Open-
SPCoop, la 0.1, ha richiesto dapprima una approfondita fase di analisi e di
progettazione che ha costituito il lavoro oggetto della tesi di Ruggero Bar-
sacchi [RB]. In una fase successiva, la progettazione e stata estesa ed e stata
prodotta la prima versione del codice OpenSPCoop grazie al lavoro di tesi di
Andrea Poli [AP]. Questa prima release, rilasciata il 27 ottobre 2005, e stata
seguita da frequenti nuovi rilasci, anche grazie al feedback e al contributo
dei primi utenti del software. Attorno al sito http://www.openspcoop.org
ha cominciato subito a svilupparsi una comunita di utenti e sviluppatori
molto qualificati, provenienti da grandi aziende italiane, pubbliche ammini-
strazioni locali e centrali e centri di ricerca. L’interesse diffuso per il progetto
ha dimostrato tra l’altro la grande disponibilita di tutti i soggetti interes-
sati verso una soluzione open source in un settore cosı critico come quello
indirizzato dalla specifica SPCoop.
4.1 L’Architettura generale del Progetto
Il progetto OpenSPCoop e strutturato nei seguenti sottoprogetti:
• la libreria di base org.openspcoop.egov, che implementa le funzionalita
di trattamento del formato busta e-Gov;
CAPITOLO 4. OPENSPCOOP 35
• la Porta di Dominio di OpenSPCoop, che si basa sulla libreria di ba-
se org.openspcoop.egov per implementare le funzionalita di Porta di
Dominio dei Servizi Applicativi dell’architettura SPCoop, fungendo
quindi da intermediario tra i sistemi informativi dell’Ente e i servizi
esterni con cui tali sistemi interagiscono;
• il Registro dei Servizi OpenSPCoop, un’implementazione del Registro
dei Servizi SPCoop, atto a mantenere l’elenco dei soggetti erogatori di
servizi e, per ognuno di questi, l’elenco dei servizi erogati e i dettagli
necessari al loro utilizzo da parte di terzi;
• il Servizio di Gestione Eventi, previsto nella specifica SPCoop per il
supporto del modello di cooperazione per eventi (modello EDA), che
prevede lo scambio di messaggi applicativi uno a uno o uno a molti,
al fine di comunicare in maniera efficiente il verificarsi di uno specifico
evento.
La figura successiva mostra l’architettura software del progetto.
CAPITOLO 4. OPENSPCOOP 36
Figura 4.1: Architettura OpenSPCoop
La descrizione dell’architettura di OpenSPCoop viene ora presentata ap-
profondendo i vari componenti fondamentali. La seguente descrizione si pre-
sentera piu dettagliata su aspetti rilevanti per questa tesi come l’interazione
tra le porte di dominio per l’erogazione/fruizione di un servizio e il Registro
Servizi.
4.2 La Porta di Dominio OpenSPCoop
Uno degli aspetti innovativi del progetto OpenSPCoop e la soluzione adotta-
ta per la componente di integrazione della Porta di Dominio. L’abilitazione
di un nuovo servizio in OpenSPCoop, non richiede infatti la programmazione
di componenti applicativi ad-hoc, ma vengono invece messi a disposizione dei
servizi generici, utilizzabili da qualunque applicazione. Questi servizi intera-
giscono con dei repository XML che descrivono le specifiche porte delegate
e applicative residenti sulla Porta di Dominio per decidere come gestire le
CAPITOLO 4. OPENSPCOOP 37
Figura 4.2: La porta di dominio OpenSPCoop
richieste in arrivo. In funzione di queste descrizioni e dello stato delle transa-
zioni eGov in corso, le richieste ricevute dalla Porta di Dominio attraversano
quindi una pipeline di moduli specifici, arricchendosi di informazioni utili al
loro trattamento mantenute negli header dei messaggi. Infine vengono re-
capitate al destinatario o girate alla porta di Dominio competente. Questa
soluzione, illustrata nella figura 4.2, ha il grande vantaggio di non richiedere
l’installazione di un proxy per ogni servizio da utilizzare (porta delegata)
o da fornire (porta applicativa), lasciando comunque immutata l’interfaccia
d’uso del Servizio, in maniera quindi del tutto trasparente rispetto ai Server
Applicativi preesistenti.
OpenSPCoop interviene insomma come un proxy SOAP trasparente, in
grado di assicurare tutti gli stessi livelli di servizio di un proxy applicativo,
senza pero bisogno di realizzarlo come un’applicazione ad hoc. Altro vantag-
gio dell’approccio seguito in OpenSPCoop deriva dall’evitare che il codice
applicativo del proxy venga eseguito direttamente sul server applicativo che
funge da porta di dominio, prevenendo cosı significative controindicazioni
dal punto di vista dell’affidabilita e della sicurezza di un componente cosı
critico dell’infrastruttura SPCoop.
CAPITOLO 4. OPENSPCOOP 38
Figura 4.3: OpenSPCoop: esempio d’uso
4.3 Un Esempio d’Uso di Servizi in OpenSPCoop
La figura 4.3 fornisce un esempio completo di una interazione SOA, utiliz-
zando il profilo OneWay della specifica SPCoop.
L’esempio mostra l’invocazione di una porta delegata da parte di un Si-
stema Informativo Locale (SIL) residente nel dominio mittente, l’interazione
delle porte di dominio mittente e destinataria con il registro dei servizi, lo
scambio delle buste eGov tra le porte di dominio e infine la consegna del
contenuto applicativo al SIL che eroga effettivamente il servizio nel dominio
destinatario. In dettaglio, le operazioni eseguite sono le seguenti:
1. il Sistema Informativo interno al dominio di cooperazione mittente
(Dominio A in figura), invoca la porta delegata http://pddMittente/
portadelegata/test.
2. La porta di dominio mittente utilizza la parte variabile del servizio
portadelegata (test nell’esempio), per identificare la porta delegata ef-
fettivamente invocata nella configurazione locale della porta (file con-
fig.xml); dalla descrizione XML della porta delegata, sara possibile
identificata la tripla (fornitore del servizio, servizio, azione);
CAPITOLO 4. OPENSPCOOP 39
3. la tripla (fornitore del servizio, servizio, azione) viene quindi utilizzata
come chiave d’accesso al Registro dei Servizi, per ottenere l’Accordo di
Servizio relativo al servizio destinazione (endpoint, profilo eGov, etc.);
4. sulla base delle informazioni ottenute, la porta di dominio mittente
costruisce la busta e la spedisce all’endpoint della porta applicativa
indicato nel registro, http://pddDestinatario/portaApplicativa;
5. La porta di dominio destinataria, una volta ricevuta la busta, ne effet-
tua la validazione e, in caso di successo, ne identifica i valori destinata-
rio, servizio e azione; questi valori sono quindi usati per identificare la
porta applicativa effettivamente indirizzata nella configurazione locale
della porta (file config.xml);
6. a questo punto, utilizzando le informazioni appena reperite relative alle
modalita di consegna, la Porta di Dominio destinatario si occupera
di effettuare la consegna dei contenuti applicativi al servizio locale
abbinato alla porta applicativa riferita nella busta eGov.
4.4 Il Registro Servizi di OpenSPCoop
OpenSPCoop supporta due tipi di registri, uno realizzato completamente
tramite una rappresentazione XML e un altro che prevede l’uso di un regi-
stro UDDI che indicizza un insieme di oggetti descritti in XML e accessibili
via http. Prima di analizzare la struttura dei due tipi di registro, vediamo
quali sono i due oggetti principali indirizzati nel registro: i Soggetti SPCoop
e i Servizi. Il Soggetto SPCoop, come illustrano le specifiche SPCoop, viene
utilizzato per identificare un’organizzazione/dominio che eroga o fruisce di
servizi applicativi. Un soggetto e il proprio dominio vengono identificati da
un nome simbolico il piu possibile autoesplicativo della missione istituzio-
nale del soggetto stesso. Il dominio di cooperazione dovra quindi assumere
CAPITOLO 4. OPENSPCOOP 40
Figura 4.4: OpenSPCoop: Registro Servizi XML
il nome del soggetto con suffisso SPCoopIT. Nel registro XML e possibile
indicare, oltre al nome del soggetto (inteso come coppia tipo/identificatore,
ad esempio SPC/MinisteroInterni), anche l’identificativo del dominio e il
punto di accesso della porta di dominio utilizzata dal soggetto stesso. La
registrazione di un Servizio, oltre alla definizione di un nome (inteso come
coppia tipo/identificatore, ad esempio SPC/ComunicazioneVariazione) e la
descrizione dell’Accordo di Servizio, permette la definizione opzionale di un
ulteriore punto di accesso per l’erogazione del servizio, se diverso dal punto
di accesso della sua porta di dominio.
4.4.1 Il Registro XML
Nella versione XML tutti i soggetti SPCoop, sia erogatori che fruitori di
servizio, e le descrizioni dei servizi (gli accordi di servizio, in terminologia
SPCoop) sono registrati in un unico file XML che deve essere accessibi-
le alla porta di dominio. La struttura del registro XML di OpenSPCoop
e mostrata nella figura 4.4, insieme ad un esempio di file XML che de-
scrive la cooperazione tra il soggetto SPC/MinisteroFruitore e il soggetto
SPC/MinisteroErogatore che eroga il servizio one-way SPC/ComunicazioneVariazione
e il servizio sincrono SPC/RichiestaStatoAvanzamento.
CAPITOLO 4. OPENSPCOOP 41
Figura 4.5: OpenSPCoop: Registro Servizi UDDI
4.4.2 Il Registro UDDI
Nella versione UDDI del registro OpenSPCoop esistono invece un insieme
di file XML diversi, tanti quanti sono i soggetti in gioco e i servizi erogati,
ognuno dei quali descrive uno specifico soggetto o servizio. I file XML,
memorizzati in un server Web e reperibili quindi via http, sono riferiti a
partire da oggetti registrati in un registro UDDI. Nella figura che segue
viene mostrata la struttura del registro UDDI, istanziata su un esempio di
definizione del servizio SPC/ComunicazioneVariazione erogato dal soggetto
SPC/MinisteroErogatore.
Registrazione Soggetti SPCoop
Per la registrazione di un soggetto nel registro UDDI viene utilizzata una
chiave di tassonomia appositamente definita. La registrazione del soggetto
comporta la creazione di una Business Entity che possiede un Identifier
Bag che memorizza una KeyedReference a cui e associata l’identificativo
del dominio nel campo KeyName e l’identificatore del soggetto nel campo
KeyValue;una Category Bag che memorizza una KeyedReference a cui e
CAPITOLO 4. OPENSPCOOP 42
associata nel campo KeyValue la url che indirizza il file XML che descrive
il soggetto.
Registrazione Servizi
La registrazione di un servizio richiede la precedente registrazione del
Soggetto che lo eroga. Viene creato un Business Service con il campo nome
contenente l’identificatore del servizio. Associato al Business Service viene
creato un Binding Template contenente nel campo Access Point il riferi-
mento al file XML che descrive le funzionalita SPCoop del servizio. Inoltre,
associata al Binding Template esiste una TModel specifica per il servizio
nella quale, nel campo OverviewURL, e presente il riferimento al file WSDL
che descrive il servizio.
4.4.3 Il Gestore Eventi di OpenSPCoop
OpenSPCoop supporta due tipi di Gestori Eventi, il primo realizzato come
servizio SPCoop, mediato quindi da una specifica porta applicativa sulla
porta di dominio del dominio che eroga il servizio di Gestore Eventi, il
secondo implementato come un broker di messagistica su cui le porte di
dominio mittente e destinatario scrivono e leggono usando direttamente jms.
Per ulteriori informazioni sul Gestore Eventi si rimanda alla documentazione
di OpenSPCoop.
4.4.4 Gli Aspetti di Sicurezza in OpenSPCoop
OpenSPCoop, come richiesto dalla specifiche SPCoop, supporta la gestione
della sicurezza sia a livello trasporto (SSL) che a livello messaggio (WS-
Security). SSL a livello trasporto puo essere configurato sia per gestire i
collegamenti dei sistemi informativi locali alla porta di dominio che quelli
tra le porte di dominio, usando il supporto SSL degli Application Server che
ospitano la porta di dominio. WSSecurity e invece implementato in OpenSP-
Coop utilizzando la libreria Apache WSS4J (http://wss.apache.org/wss4j/)
CAPITOLO 4. OPENSPCOOP 43
Figura 4.6: OpenSPCoop: WS Security
e sfruttandone i moduli forniti per l’interazione con Axis (WSSDoAllSen-
der e WSSDoAllReceiver). In particolare, per ogni porta delegata e per
ogni porta applicativa potranno essere specificate le proprieta di WSSecu-
rity che si vogliono applicare durante la spedizione (WSSDoAllSender) di
buste SPCoop, rispettivamente nell’elemento request flow di una porta de-
legata e nell’elemento response flow di una porta applicativa, e durante la
ricezione (WSSDoAllReceiver) di buste SPCoop, rispettivamente nell’ele-
mento response flow di una porta delegata e nell’elemento request flow di
una porta applicativa. La figura 4.6 mostra un’esempio d’uso di WSSecurity
in OpenSPCoop.
Capitolo 5
Linguaggi per Workflow
In questo capitolo verranno illustrati i concetti di processo produttivo au-
tomatizzazato o workflow e le tecnologie esistenti che ne forniscono l’imple-
mentazione. La trattazione presenta dapprima le problematiche collegate ai
processi produttivi in merito alla loro descrizione e realizzazione. In seguito
sara presentato il linguaggio WS-BPEL per la sua centrale rilevanza con il
lavoro di questa tesi e le argomentazioni che ne hanno motivato la scelta
rispetto ai principali concorrenti disponibili.
5.1 Cos’e un Workflow
Con il termine workflow si intende un pattern ripetibile di attivita in cui e
possibile evidenziare una organizzazione sistematica delle risorse, una defini-
zione di ruoli e un flusso di energie e informazioni in un processo produttivo
che puo essere documentato e compreso. I workflow sono sempre progettati
per eseguire vari tipi di manipolazione da quella fisica a quella informati-
ca. I workflow sono strettamente collegati a concetti usati per descrivere
la struttura organizzativa come funzioni, team, progetti, gerarchie ecc.. I
workflow possono essere visti come uno dei blocchi primitivi di costruzione
delle organizzazioni. La connotazione piu generica che questo termine ha
44
CAPITOLO 5. LINGUAGGI PER WORKFLOW 45
assunto e l’identificazione di un tipo di interazione tra l’uomo e le macchine.
I workflow sono generalmente caratterizzati da:
• comportamenti dipendenti dai dati. Per esempio un processo di tipo
supply-chain dipende da dati tra cui il numero degli oggetti in un dato
ordine, il valore totale di un ordine e una data di scadenza per la
spedizione. Definire l’intento del processo in questi casi richiede l’uso
di costrutti condizionali e di time-out.
• condizioni eccezionali e le loro conseguenze. Il recupero e impor-
tante per i processi produttivi almeno quanto l’abilita di definire il
comportamento del processo in casi senza fallimenti.
• interazioni a lungo termine che includono lavori multipli e spesso in-
nestati, ognuno dei quali con i propri requisiti sui dati. I processi
produttivi frequentemente richiedono coordinazione fra piu piattafor-
me dei prodotti delle unita di lavoro (sia in casi di successo che di
fallimento) a vari livelli di granularita.
5.2 I Workflow per Applicazioni di Rete
L’integrazione di sistemi richiede piu dell’abilita di interazioni semplici usan-
do protocolli standard. Il pieno potenziale dei Web Service come una piatta-
forma di integrazione sara raggiunto solo quando le applicazioni e i processi
produttivi sapranno integrare le loro complesse interazioni usando modelli
di integrazione di processi standard. Il modello di interazione che e diret-
tamente supportato da WSDL e essenzialmente un modello senza stato di
interazione richiesta-risposta e interazioni one-way non correlate.
I modelli per processi produttivi tipicamente assumono sequenze di scambi
di messaggi peer-to-peer sia di tipo richiesta-risposta che di tipo one-way,
con interazioni con stato e di lunga durata tra due o piu partner di co-
municazione. Per definire tali processi di interazione bisogna definire una
CAPITOLO 5. LINGUAGGI PER WORKFLOW 46
descrizione formale dei protocolli usati per lo scambio di messaggi usato dal
processo produttivo nelle loro interazioni.
Un processo astratto puo essere usato per descrivere il comportamento di
ognuna delle parti durante lo scambio di messaggi, senza rivelare implemen-
tazioni interne.
Ci sono due buone ragioni per separare gli aspetti pubblici del comporta-
mento del processo produttivo dagli aspetti formali o privati. Una ragione
e che i processi ovviamente non vogliono rivelare tutte le loro decisioni e
la gestione dei propri dati ai partner del processo. L’altra ragione e che
separare il processo privato da quello pubblico garantisce la liberta di cam-
biare aspetti privati dell’implementazione del processo senza modficare il
comportamento esterno osservabile e quindi non variando le interfacce. Tale
comportamento deve essere chiaramente descritto in una maniera che sia
indipendente dalla piattaforma.
5.3 Programmazione Orientata ai Grafi (GOP)
A differenza della programmazione orientata agli oggetti nella quale si pen-
sa in termini di oggetti, campi di oggetti e metodi, nella programmazione
orientata ai grafi si ragiona in termini di attivita ed eventi che avviano,
interrompono, sincronizzano o terminano le attivita. Questo non significa
che la programmazione di questi meccanismi non sia realizzabile in un lin-
guaggio object oriented, ma solo che tale realizzazione sia un’operazione piu
macchinosa. In questi linguaggi, infatti, la strutturazione di piu attivita
che si sincronizzano non e fatta in maniera naturale ma tramite meccanismi
realizzati ad hoc: in Java, ad esempio, si ricorre all’utilizzo di monitor, cioe
oggetti realizzati con meccanismi hardware/software per realizzare la mutua
esclusione.
Nella GOP lo sviluppo di applicazioni concorrenti e facile grazie al supporto
nativo per i grafi. Il concetto di esecuzione di un programma in GOP cor-
CAPITOLO 5. LINGUAGGI PER WORKFLOW 47
risponde alla navigazione di un grafo diretto.
Alcuni aspetti dello sviluppo del software possono beneficiare molto da un
approccio basato su grafi. La gestione dei processi produttivi (BPM, Busi-
ness Process Management) e uno dei domini di applicazione piu diffusi di
linguaggi basati su grafi.
Com’e facile intuire questo tipo di programmazione puo avvalersi di stru-
menti di editing che ne aumentano il potere espressivo. La rappresentazione
grafica e un concetto chiave della GOP. Tramite gli strumenti e infatti pos-
sibile realizzare grafi di complessita arbitraria delegando allo strumento di
editing stesso la generazione automatica del codice che realizza la logica del
grafo. La rappresentazione grafica puo essere usata per avvicinare analista
di processi produttivi e sviluppatore come fosse il linguaggio naturale.
Uno dei linguaggi esistenti che permette di rappresentare un grafo e il
linguaggio XML. Il linguaggio BPEL, ad esempio, e basato su XML.
Figura 5.1: Rappresentazione grafica e generazione automatica di codice.
Programmare in GOP puo essere molto veloce se opportunamente sup-
portata da strumenti.
Per la natura delle attivita che puo descrivere, la GOP deve necessariamen-
te fornire un supporto nativo per stati d’attesa per sincronizzare le attivita
parallele e la gestione di eventi asincroni. Anche questi meccanismi sono
realizzabili in un linguaggio object oriented con semafori e monitor, ma e
un meccanismo che e piu difficile da controllare attraverso il codice.
CAPITOLO 5. LINGUAGGI PER WORKFLOW 48
E’ chiaro quindi perche la programmazione orientata ai grafi costituisca allo
stato attuale la base per realizzare linguaggi basati su grafi, come quelli per
workflow.
5.3.1 Orchestrazione e Coreografia
Quando la realizzazione di un compito richiede un complesso grafo di attivita
che richiede la partecipazione di piu agenti, identificare un meccanismo di
coordinazione diventa fondamentale. In letteratura per esprimere questa
coordinazione vengono adottati due approcci:
• Orchestrazione: il corretto svolgimento dell’intero compito viene con-
trollato da un unico agente che coordina tutte le attivita. Tale agente
puo anche essere uno dei partecipanti. I partecipanti eseguono compiti
in maniera trasparente rispetto alla coordinazione.
• Coreografia: il corretto svolgimento del compito e delegato alla tra-
smissione dello stato globale dell’esecuzione da un agente ad un al-
tro. Nessuno coordina le attivita ma ogni agente controlla che lo sta-
to di avanzamento del compito sia al punto giusto quando l’attivita
dell’agente deve essere eseguita. I partecipanti, a differenza del caso
precedente, sono consapevoli della coordinazione.
Tramite la GOP e possibile eseguire solo linguaggi con coordinazione di tipo
orchestrazione.
5.3.2 GOP a confronto con Reti di Petri
Il mondo accademico, per un lungo periodo, si e concentrato sull’utilizzo
di reti di Petri per workflow e modellazione di processi produttivi princi-
palmente perche le rete di Petri erano l’unico strumento matematico che
supportava cammini concorrenti d’esecuzione. Grazie al fondamento mate-
matico e possibile definire algoritmi per la validazione e la completezza. La
CAPITOLO 5. LINGUAGGI PER WORKFLOW 49
maggior differenza tra le reti di petri e la GOP e la loro natura. Le reti di
Petri sono un modello matematico mentre la GOP puo essere vista come
una tecnica di implementazione o un design pattern. La programmazione
orientata ai grafi puo essere impiegata per implementare le reti di Petri. I
places delle reti di Petri e le transizioni possono essere implementati come
due differenti tipi di nodi. Il token game di una rete di Petri corrisponde
all’esecuzione GOP. Le estensioni al livello piu alto che sono state definite
sopra le reti di Petri possono anche essere definiti in termini di programma-
zione orientata ai grafi. La GOP non supporta algoritmi di analisi come sono
definiti sulle reti di Petri. Questo perche la GOP non ha una interpretazio-
ne concreta. Gli algoritmi di analisi possono essere definiti su modelli che
hanno una interpretazione deterministica a tempo di design. La program-
mazione orientata ai grafi inoltre prevede la definizione di nodi che hanno
un comportamento non deterministico a tempo di design. L’implementa-
zione dei nodi GOP puo potenzialmente fare un qualunque tipo di calcolo
a tempo d’esecuzione e decidere solo in quel momento come l’esecuzione
deve essere propagata. Algoritmi di analisi possono solo essere definiti su
linguaggi a processi concreti per i quali l’implementazione dei nodi da una
interpretazione deterministica a tempo di design ai tipi dei nodi.
5.4 BPEL e WS-BPEL
BPEL (Business Process Execution Language) e un linguaggio basato su
XML costruito per descrivere formalmente i processi commerciali ed indu-
striali in modo da permettere una suddivisione dei compiti tra attori diversi.
Un’applicazione BPEL viene invocata come Web Service ed interagisce con il
mondo esterno esclusivamente invocando altri Web Service. In questo senso,
essa stessa rappresenta una forma di coordinazione di servizi Web, permet-
tendo altresı di comporre questi ultimi in maniera ricorsiva. L’ambiente run-
time all’interno del quale viene eseguito il generico processo e detto motore
CAPITOLO 5. LINGUAGGI PER WORKFLOW 50
(o engine) BPEL. Lo standard che definisce l’uso di BPEL nelle interazioni
tra Web Service e chiamato BPEL4WS o WS-BPEL. BPEL e nato come
integrazione delle ricerche svolte da IBM e Microsoft su WSFL e XLANG,
entrambi superati da BPEL. Nell’aprile del 2003 BPEL e stato sottoposto ad
OASIS che lo ha standardizzato. Il linguaggio BPEL permette di descrivere
un processo business mediante un insieme di attivita, che possono essere
semplici o strutturate. Le attivita semplici esprimono una generica azione
(ad es. invoca servizio, ricevi risposta, assegna valore ad una variabile, termi-
na processo, etc...), mentre quelle strutturate sono normalmente utilizzate
per raggruppare attivita semplici allo scopo di esprimere loop, operazioni
condizionali, esecuzione sequenziale, esecuzione concorrente, etc... L’intero
processo e descritto mediante un’unica attivita strutturata (top-level acti-
vity), generalmente di tipo sequenziale. Un tag scope racchiude l’insieme
di attivita che compone una transazione atomica, ovvero un processo che
puo terminare con un commit o un abort, senza stati intermedi, nel quale
l’arresto del processo su un’attivita comporta l’interruzione del processo e
la cancellazione delle modifiche in scrittura al database durante le attivita
precedenti (undo delle attivita). Questo e necessario ad esempio in una tran-
sazione bancaria/finanziaria nella quale ad ogni addebito deve corrispondere
un accredito di somme.
Un diagramma di workflow contiene tipicamente operazioni, messaggi, attori
(umani o applicativi), applicazioni che definiscono il Web-Service, condizioni
logiche (IF), parallelismi, loop e task di sincronizzazione fra operazioni.
BPEL e in particolare adatto a modellare workflow completamente auto-
matizzati, per la composizione di Web Service e l’integrazione di servizi
eterogenei per hardware che li esegue, architetture di rete e linguaggio del
relativo codice.
BPEL mette altresı a disposizione dei costrutti per esprimere le cosiddette
transazioni di lungo periodo (long running transactions, LRT), che rappre-
CAPITOLO 5. LINGUAGGI PER WORKFLOW 51
sentano un’estensione delle transazioni ACID al caso di processi di lunga
durata mediante la nozione di compensazione delle attivita eseguite. An-
cora, il meccanismo della correlazione e utilizzato per tener traccia di una
certa conversazione a livello business, identificando cosı una sorta di sessione
tra piu partecipanti ad una stessa istanza di processo.
BPEL consente di descrivere un workflow esistente oppure un processo astrat-
to non eseguibile. Con processo astratto si intende un processo specifica-
to solo in parte: non si prevede la sua esecuzione e deve essere dichiarato
astratto. Un processo concreto e un processo astratto che contiene i requisiti
necessari a renderlo eseguibile. Quindi un processo astratto e uno concreto
condividono lo stesso potere espressivo.
I processi astratti forniscono un ruolo descrittivo con piu di un solo caso
d’uso. Un caso d’uso potrebbe essere la descrizione del comportamento os-
servabile di alcuni o tutti i servizi offerti da un processo eseguibile. Un altro
caso d’uso potrebbe essere definire il template del processo che incorpora
le migliori pratiche specifiche del dominio. Tale template catturerebbe la
logica essenziale del processo in una maniera compatibile con la rappresen-
tazione a tempo di design, mentre escluderebbe i dettagli di esecuzione da
includere quando lo si mappa su un processo eseguibile.
Il linguaggio definisce un formato di esecuzione portabile per i processi pro-
duttivi che si basano esclusivamente su risorse di tipo Web Service (WSDL)
e dati XML. Tali processi, inoltre, vengono eseguiti e interagiscono con i loro
partner in maniera consistente senza tener conto delle piattaforme suppor-
tanti o dei modelli di programmazione usati dall’implementazione dell’am-
biente ospitante.
La continuita tra processi astratti e eseguibili in WS-BPEL rende possibi-
le esportare e importare aspetti pubblici incorporati nel processo astratto
come processo o come template di ruolo mentre si mantiene l’intento e la
struttura del comportamento osservabile.
CAPITOLO 5. LINGUAGGI PER WORKFLOW 52
Questo si applica anche quando gli aspetti di implementazione privata usano
funzionalita dipendenti dalla piattaforma.
Questa e una caratteristica chiave per l’uso di WS-BPEL dal punto di vista
dello sblocco delle potenzialita dei Web Service perche permette lo svilup-
po di tool e di altre tecnologie che aumentano enormemente il livello di
automazione e inoltre abbassano il costo di stabilire processi produttivi au-
tomatizzati cross enterprise.
WS-BPEL definisce un modello e una grammatica per descrivere il compor-
tamento di processi produttivi basati su interazioni tra il processo e i suoi
partner. L’interazione con ogni partner avviene attraverso interfacce Web
Service e la struttura delle relazioni al livello di interfacce e incapsulata in
quello che e chiamato partnerLink (vedi Breve presentazione del linguaggio
BPEL). Il processo WS-BPEL definisce come piu interazioni tra servizi con
questi partner sono coordinate per raggiungere l’obiettivo del processo cosı
come lo stato e la logica necessaria per la coordinazione.
WS-BPEL introduce anche un meccanismo sistematico per gestire le ecce-
zioni dei processi e processare gli errori. Inoltre, WS-BPEL introduce un
meccanismo per definire come attivita individuali o composte all’interno di
una unita di lavoro debbano essere compensate quando occorre una eccezio-
ne o un partner richiede un riscontro.
WS-BPEL utilizza diverse specifiche XML gia viste nel capitolo 2: WSDL
1.1, XML Schema 1.0, XPath 1.0 e XSLT 1.0. I messaggi WSDL e le defi-
nizioni di tipo XML forniscono il modello dei dati usato dal processo WS-
BPEL. XPath e XSLT forniscono il supporto per la manipolazione dei dati.
Tutte le risorse esterne e i partner sono rappresentati come servizi WSDL.
WS-BPEL fornisce estensibilita per rendere possibile future versioni di questi
standard, specialmente per Xpath e gli standard collegati alle computazioni
XML.
Un processo WS-BPEL, quindi, puo essere visto come una definizione riusa-
CAPITOLO 5. LINGUAGGI PER WORKFLOW 53
bile che puo essere sviluppata in molti modi e in molti scenari mantenendo
sempre un comportamento uniforme a livello applicativo attraverso tutti
questi scenari.
5.4.1 Breve Presentazione del Linguaggio BPEL
BPEL e un linguaggio basato su XML per orchestrazione di Web Service.
L’intera esecuzione del processo e regolata da azioni di tipo <activity> che
vengono intraprese a seconda dell’occorrenza di determinati eventi come la
ricezione dei messaggi, la conclusione di operazione sincrona o asincrona e
il raggiungimento di rami decisionali. A livello sintattico un processo BPEL
nella sua versione per Web Service e identificato come segue:
< process name=’ncname’
targetNamespace=’uri’
queryLanguage=’anyURI’
expressionLanguage=’anyURI’
abstractProcess=’yes|no’
xmlns=’http://schemas.xmlsoap.org/ws/2003/03/business-process/’>
<partnerLinks>
<partnerLink name=’ncname’ partnerLinkType=’qname’
myRole=’ncname’ partnerRole=’ncname’>+
</partnerLink>
</partnerLinks>
<variables>
<variable name=’ncname’ messageType=’qname’
type=’qname’ element=’qname’/>+
</variables>
activity
</process>
Tra gli attributi di <process> il linguaggio per esprimere le query (de-
fault e XPath 1.0) se il processo e astratto, cioe non istanziabile, o concreto
e altre informazioni come il namespace che identifica il processo. L’attribu-
CAPITOLO 5. LINGUAGGI PER WORKFLOW 54
to abstractProcess denota un processo astratto, come e stato descritto nel
paragrafo introduttivo. Tra gli elementi contenuti all’interno di <process>
troviamo una lista di partnerlink: con questo termine si indica una relazio-
ne tra il processo e uno dei servizi nella quale vengono definite le operazioni
che il processo ha a disposizione su quel servizio. In termini concreti, la rela-
zione vincola il processo a contattare il servizio coinvolto solo per un gruppo
ristretto di operazioni (portType). Nell’implementazione di JBPM-BPEL,
questo tipo di variabile mantiene a run-time le informazioni necessarie a con-
tattare il servizio per quell’operazione, quindi l’indirizzo del servizio (SOAP
Address) e l’implementazione dell’interfaccia del servizio (Service e Port).
Oltre a partnerlink troviamo una lista di variables : le variabili costi-
tuiscono di fatto lo stato del processo e hanno gli usi delle variabili di una
classe di un comune linguaggio di programmazione, come mantenere risul-
tati intermedi per operazioni o parti di messaggi ricevuti. I tipi che possono
assumere queste variabili vanno da quelli default XML a quelli definiti dai
WSDL dei servizi supportati in termini di tipo di messaggi o tipi XML.
L’intera esecuzione di un processo BPEL e regolata dalle <activity> . Le
<activity> ammesse in BPEL sono:
• <receive> , per eseguire una attesa di messaggio bloccante
• <reply> , per rispondere ad una precedente operazione di <receive>
e completare una interazione request-response (in genere col client).
• <invoke> , per invocare l’operazione di un determinato servizio.
• <if> , per rami decisionali di tipo if-then-else. Contiene una <activity>
per ramo.
• <switch> , per rami decisionali con salti multipli. Contiene una
<activity> per salto.
• <assign> , per assegnamenti tra variabili.
CAPITOLO 5. LINGUAGGI PER WORKFLOW 55
• <pick> ,per eseguire una attesa di messaggio bloccante con timeout.
• <sequence>, per eseguire una sequenza di attivita. Una sua istanza
e obbligatoria nella definizione di un processo (simile al concetto di
main).
• <throw> , per generare una eccezione all’interno del processo.
• <terminate> , per una terminazione non normale del processo.
• <while> , per iterare su una condizione. Contiente una scope <actvity>.
• <wait> , per effettuare una attesa con timeout o con un criterio
impostato.
• <flow>, per arbitrare l’accesso ai dati da una attivita ad un’altra in
esecuzione concorrente
• <scope> , per definire una attivita con variabili, partnerlink e <activity>
locali.
• <compensate> , per gestire eccezioni all’interno del processo.
Come e facile intuire, le <activity> sono componibili e innestabili e per-
mettono di coprire un’ampia gamma di situazioni tipiche di un processo pro-
duttivo. La scelta fatta per realizzare i casi d’uso e ricaduta su BPEL perche
ne esiste una implementazione completa su un engine facilmente integrabile
con JBoss, l’application server usato da OpenSPCoop (vedi JBPM).
5.5 Altri Linguaggi per Orchestrazione
In questa sezione mostriamo le due maggiori alternative a WS-BPEL. Win-
dows Workflow Foundation non e stato scelto perche non e open-source
mentre YAWL non e stato scelto per mancanza di implementazioni integra-
bili.
CAPITOLO 5. LINGUAGGI PER WORKFLOW 56
5.5.1 Windows Workflow Foundation
Windows Workflow Foundation e una tecnologia Microsoft per definire, ese-
guire e gestire processi produttivi. Questa tecnologia fa parte del .NET
Framework 3.0 che e disponibile in maniera nativa in Windows Vista e puo
essere installato su macchine con sistemi operativi Windows XP Service Pack
2 o Windows Server 2003 [WF].
Figura 5.2: .NET 3 Stack
CAPITOLO 5. LINGUAGGI PER WORKFLOW 57
Un nuovo linguaggio basato su XML, XAML, e usato per descrivere la
struttura del processo produttivo in Windows Workflow Foundation.
I processi produttivi comprendono le attivita. Gli sviluppatori possono scri-
vere le attivita nel loro dominio specifico e utilizzarle nei processi produttivi.
Lo stesso Workflow Foundation viene distribuito con un insieme di attivita
general-purpose che coprono diversi costrutti di controllo di flusso.
Windows Workflow Foundation e supportato grazie ad un insieme di esten-
sioni correlate in Visual Studio 2005. Queste estensioni contengono un de-
sign visivo di processi che permette di progettare processi produttivi, un
debugger visuale che rende possibile agli utenti il debugging del processo
progettato e un sistema a progetto che permette all’utente di sviluppare e
compilare il processo all’interno di Visual Studio 2005.
Le attivita in genere producono o ricevono dati. In Windows Workflow
Foundation queste informazioni vengono esposte usando le proprieta e per-
mettono all’autore di processi di collegarle al processo dichiarando delle
dipendenze.
Il workflow run-time di .NET 3.0 Framework fornisce i meccanismi necessari
per eseguire e gestire workflow e puo essere ospitato da un comune dominio
per applicazioni CLR, sia esso un Windows Service, una applicazione con-
sole, una GUI o una applicazione Web.
L’applicazione ospitante puo fornire meccanismi come serializzazione se ne-
cessari all’esecuzione del workflow e puo inoltre agganciarsi a eventi del
workflow di tipo attesa o terminazione.
I workflow in Windows Workflow Foundation definiscono interfacce con me-
todi ed eventi per comunicare con il mondo esterno. Una applicazione ospi-
tante in genere inizializza un ambiente prima di eseguire un workflow, for-
nendo oggetti che implementano queste interfacce.
Quando un oggetto che implementa tali interfacce solleva un evento si ot-
tiene il corrispondente workflow per passargli i dati.
CAPITOLO 5. LINGUAGGI PER WORKFLOW 58
I metodi sulle interfacce possono essere usati dal workflow per comunicare
con il suo agente ospitante.
5.5.2 YAWL
YAWL (Yet Another Workflow Language) [YAWL] e un linguaggio per work-
flow basato su pattern workflow. Il linguaggio e supportato da un sistema
software che include un engine di esecuzione, un editor grafico e una hand-
ler di worklist. Il sistema e disponibile come software open source sotto
licenza LGPL. Gli usi a livello di produzione del sistema YAWL includo-
no uno sviluppo nel Regno Unito di processi per automatizzare servizi di
front-end e l’utilizzo nella televisione australiana per coordinare i processi
di riproduzione delle pellicole. il sistema YAWL e stato anche impiegato per
l’insegnamento in oltre 20 universita.
YAWL comprende le seguenti caratteristiche:
• Supporto per workflow pattern.
• Supporto per politiche di allocazione di risorse avanzato.
• Supporto per adattamento dinamico di modelli workflow tramite la
nozione di worklets.
• Supporto per validazione del modello di workflow (ad esempio ricono-
scimento deadlock a design-time).
• Modello basato su XML per definizione di dati e manipolazione basata
su schemi XML, XPath e XQuery.
• Interfacce basate su XML per monitorare e controllare istanze di work-
flow e accedere ai registri di esecuzione.
• Interfacce basate su XML per connettere Web Service di terze parti al
sistema.
CAPITOLO 5. LINGUAGGI PER WORKFLOW 59
• Generazione automatica di form da schemi XML.
Inizialmente nato ispirandosi alle reti di Petri, YAWL si e evoluto in un
sistema con una semantica a transizioni con etichette. Questa scelta imple-
mentativa ha reso di fatto possibile l’implementazione di diverse tecniche
per analizzare i processi YAWL. In particolare, il sistema YAWL include un
tool per analisi statica chiamato WofYAWL.
YAWL e spesso visto come una alternativa a BPEL. Quest’ultimo ha il van-
taggio di essere diretto da una commissione di standardizzazione supportata
da diverse industrie dell’information technology. Come risultato, BPEL e
supportato da un insieme significativo di tool (proprietari e open-source)
mentre YAWL ha una singola implementazione per ora. Inoltre, molti ri-
cercatori hanno catturato la semantica formale di un sottoinsieme di BPEL
in termini di vari formalismi tra cui le reti di Petri, l’algebra per processi
e le macchine a stati finiti. Questo ha preparato la strada per lo sviluppo
di tool statici per BPEL che possono competere con le capacita di analisi
statica del sistema YAWL. E’ stato dimostrato, pero, che BPEL non riesce
completamente a supportare task umani, cioe svolti da umani e che possono
riguardare anche attivita fisiche. Una varieta di engine BPEL forniscono
estensioni di BPEL per task umani ma queste estensioni non sono anco-
ra standard. YAWL, invece, fornisce una interfaccia unificata per i servizi
worklist basati su standard Web Service. Queste interfacce permettono agli
sviluppatori di creare i loro servizi worklist per supportare task umani in
accordo alle loro necessita. Inoltre, il sistema YAWL viene fornito con un
servizio di base worklist che supporta vari tipi di allocazione e gestione di
task umani.
Un altro vantaggio di YAWL e il suo supporto per i workflow pattern, seb-
bene il divario tra YAWL e BPEL possa essere ridotto da nuovi costrutti
che sono inclusi in BPEL 2.0.
Capitolo 6
Dagli Accordi di Servizio agli
Accordi di Cooperazione
In questo capitolo viene presentato l’Accordo di Cooperazione. La trat-
tazione inizia con la descrizione dell’Accordo di Servizio per poi arrivare
all’Accordo di Cooperazione per OpenSPCoop come lavoro di comprensio-
ne delle specifiche CNIPA e relativa realizzazione sulla porta di dominio
OpenSPCoop.
6.1 L’Accordo di Servizio (AS)
Nell’architettura SPCoop, per instaurare una relazione di servizio tra sistemi
e obbligatorio definire un accordo esplicito sulla erogazione/fruizione delle
prestazioni del servizio: l’Accordo di Servizio. L’Accordo di Servizio (AS) si
basa sulle prestazioni del servizio e sulle modalita di erogazione/fruizione,
ovvero piu specificamente su:
• le funzionalita (classi di prestazioni) del servizio,
• le interfacce di scambio dei messaggi tra erogatore e fruitore,
• i requisiti di sicurezza dell’erogazione/fruizione,
60
CAPITOLO 6. DAGLI ACCORDI DI SERVIZIO AGLI ACCORDI DI COOPERAZIONE61
• i requisiti di qualita di servizio dell’erogazione/fruizione.
I termini dell’Accordo di Servizio sono raccolti in un insieme di documenti,
di cui una parte redatta in linguaggi formali e interpretabili da programma.
Detto insieme di documenti costituisce una specifica per l’implementazione
dei sistemi erogatore e fruitore ed e utilizzato dai progettisti e dagli ambienti
di sviluppo nelle fasi di implementazione dei sistemi erogatore e fruitore.
Alcune modalita operative dell’erogazione/fruizione del servizio possono
essere lasciate non specificate al momento della progettazione e perfezionate
automaticamente all’esecuzione; cio richiede l’implementazione di capacita
specifiche di contrattazione e di riconfigurazione dinamica da parte dei si-
stemi erogatore e fruitore. Un caso semplice di riconfigurazione dinamica
si verifica quando l’URI del punto di accesso del sistema destinatario e sco-
nosciuto al sistema mittente in esecuzione. In questo caso il mittente deve
implementare una strategia dinamica di recupero dell’indirizzo (URI) del
punto di accesso del destinatario, come per esempio l’interrogazione di un
servizio di rubrica. Una modalita alternativa di recupero dell’URI e la tra-
smissione dello stesso nel contenuto del messaggio. Nella figura 6.1 viene
rappresentato lo scenario di utilizzo di un Accordo di Servizio.
La rappresentazione dei termini dell’Accordo di Servizio in un insieme di
documenti permette la dissociazione delle responsabilita di definizione del
servizio da quelle dell’erogazione del servizio. Un servizio standardizzato:
• e definito da una autorita di definizione, che gestisce l’accordo e la
pubblicazione dei documenti che ne rappresentano i termini,
• e erogato da uno o piu sistemi erogatori, gestiti da differenti respon-
sabili, che si impegnano a fornire prestazioni conformi con i termini
dell’Accordo di Servizio.
L’accordo generale di un servizio standardizzato puo essere incompleto:
puo limitarsi a definire le funzionalita, le interfacce, i requisiti di sicurez-
CAPITOLO 6. DAGLI ACCORDI DI SERVIZIO AGLI ACCORDI DI COOPERAZIONE62
Figura 6.1: L’Accordo di Servizio in SPCoop.
za e lasciare la definizione dei requisiti di qualita di servizio all’autonomia
dell’offerta dei singoli erogatori o ad accordi specifici tra singoli fruitori e
erogatori.
6.1.1 L’Identificazione delle Parti
L’Accordo di Servizio SPCoop impone l’identificazione delle parti coinvolte
nella erogazione/fruizione del servizio.
Le parti in questione ricoprono i seguenti ruoli:
• Erogatori del servizio
• Fruitori del servizio
• Terzi (servizi di intermediazione e di supporto, ad esempio servizi
remoti per tracciamento delle operazioni)
I titolari dei sistemi erogatori del servizio e dei servizi terzi devono essere
identificati nell’Accordo di Servizio. I titolari dei sistemi fruitori posso-
no essere identificati nell’Accordo di Servizio, e in ogni caso devono essere
identificati (e registrati come fruitori) dagli erogatori e terzi.
CAPITOLO 6. DAGLI ACCORDI DI SERVIZIO AGLI ACCORDI DI COOPERAZIONE63
I codici identificatori dei soggetti titolari sono conformi allo standard
SPCoop, sono rilasciati esclusivamente dal Comitato di gestione del S.P. di
Cooperazione e sono registrati sul registro SICA nazionale generale, cioe il
registro nazionale per la memorizzazione degli accordi di servizio.
6.1.2 La Descrizione delle Funzionalita
L’Accordo di Servizio si basa in primo luogo sulle funzionalita ovvero le
classi di prestazioni fornite dall’erogatore del servizio. L’Accordo di Servizio
si limita alla descrizione puramente funzionale di tali classi di prestazioni:
l’architettura, le tecniche e le risorse d’implementazione adottate dal sistema
erogatore per fornire le prestazioni, cosı come quelle adottate dal sistema
fruitore per utilizzare i risultati delle prestazioni, sono totalmente escluse
dall’accordo (principio di occultamento dell’implementazione). Lo standard
di Accordo di Servizio SPCoop non impone ne un linguaggio formale ne un
formato per la descrizione delle funzionalita del servizio. La descrizione delle
interfacce di scambio dei messaggi contiene:
• la descrizione degli eventuali protocolli di conversazione,
• la descrizione del formato del corpo e delle testate dei messaggi,
• la descrizione del collegamento con il protocollo di connessione,
• gli indirizzi (URI) dei punti di accesso,
e, infine, la descrizione delle relazioni funzionali tra i protocolli di conver-
sazione, il contenuto dei messaggi e le modalita di erogazione/fruizione del
servizio, cioe la descrizione della semantica (cio che il mittente vuole signifi-
care con l’emissione del messaggio) e della pragmatica (cio che il destinatario
deve fare alla ricezione del messaggio). L’Accordo di Servizio SPCoop V.1.0
non specifica un linguaggio standard per la descrizione dei protocolli di con-
versazione. Il piano di evoluzione dell’architettura e dell’Accordo di Servizio
CAPITOLO 6. DAGLI ACCORDI DI SERVIZIO AGLI ACCORDI DI COOPERAZIONE64
SPCoop prevede l’introduzione in versioni successive di SPCoop del forma-
lismo di orchestrazione OASIS WSBPEL [BPEL]. L’Accordo di Servizio
SPCoop specifica il formalismo XML Schema [SCHEMA] per la descrizione
del formato del contenuto (corpo e testate) dei messaggi. Inoltre preve-
de delle restrizioni, prescrizioni e raccomandazioni nell’uso dello standard
XML Schema e specifica come linguaggio di descrizione dei messaggi, delle
connessioni e dei punti di accesso WSDL 1.1 [w3cArch] con le restrizioni
d’uso prescritte dalle raccomandazioni WS-I Basic Profile 1.1. La specifica
dell’Accordo di Servizio SPCoop fornisce gli elementi standard XML Sche-
ma e WSDL necessari alla generazione delle estensioni SOAP proprie alla
Busta SPCoop. Per la descrizione della semantica e della pragmatica dei
messaggi, e raccomandato l’uso dell’approccio Design by Contract. Tale ap-
proccio e particolarmente adatto per specificare le richiesta di prestazioni
che producono transizioni di stato delle risorse gestite dall’erogatore. L’ap-
proccio Design by Contract prescrive, per ogni scenario di richiesta/risposta
che causa una transizione di stato, la definizione esplicita delle:
• precondizioni: condizioni che devono essere verificate prima della tran-
sizione e quindi prima della richiesta,
• postcondizioni: condizioni che devono essere verificate dopo la transi-
zione, e quindi dopo la risposta contenente il resoconto della transizio-
ne,
• invarianti: condizioni sempre vere, prima e dopo la transizione.
La specifica dell’Accordo di Servizio SPCoop raccomanda la definizione,
per ogni richiesta/risposta che causa una transizione di stato, di richieste
informative sulle precondizioni, postcondizioni e invarianti della transizione
di stato. Tali richieste possono essere utilizzate in vario modo (per ispezione
in esecuzione, per implementare degli scenari di test, ecc.).
CAPITOLO 6. DAGLI ACCORDI DI SERVIZIO AGLI ACCORDI DI COOPERAZIONE65
6.1.3 Struttura dell’Accordo di Servizio
Un Accordo di Servizio e costituito da una parte comune e da una parte spe-
cifica, dove una diversa parte specifica puo essere definita per ogni coppia
fornitore/erogatore. E’ quindi possibile definire servizi singolo/multi frui-
tore e singolo/multi erogatore. La descrizione di un Accordo comprende i
seguenti elementi principali:
• accordo-servizio: corrisponde al contenuto del file manifest della parte
comune di un AS;
• servizio: rappresenta la parte specifica di un accordo mono-fruitore.
Inoltre contiene, se richieste dal tipo di accordo (multi-fruitore), anche
le parti specifiche per ogni singola istanza fruitore-erogatore, rappre-
sentata ognuna attraverso l’elemento XML fruitore.
• soggetto-spcoop: rappresenta la registrazione di un soggetto nel re-
gistro, che definisce il tipo, nome, dominio di amministrazione e un
eventuale connettore, che rappresenta un port di accesso generico per
i vari servizi erogati dal soggetto (poi ridefinibile nei port della parte
specifica di ogni servizio).
6.1.4 Descrizione della Parte Comune
Il manifesto della parte comune di un Accordo di Servizio, mostrato nella
figura 6.2, e definito dall’elemento XML ’accordo-servizio’ che racchiude il
nome dell’accordo, una sua descrizione non formale, il nome del soggetto
referente per l’accordo e riferimenti ai documenti che compongono la parte
comune quali:
• specifica delle Interfacce, contenente i documenti WSDL concettuale
(descrive le interfacce del servizio a livello di scenario di coordinamen-
to), WSDL logico fruitore (descrive le interfacce e i tipi di dato neces-
CAPITOLO 6. DAGLI ACCORDI DI SERVIZIO AGLI ACCORDI DI COOPERAZIONE66
sari per il fruitore) e WSDL logico erogatore (descrive le interfacce e i
tipi di dato necessari per l’erogatore);
• specifica delle Conversazioni che contiene un documento in forma-
to WSBL concettuale, un WSBL logico fruitore ed un WSBL logico
erogatore, con la stessa accezione del punto precedente;
• il riferimento a schemi ed ontologie;
• documento semiformale che segue uno schema XSD, per la definizio-
ne di informazioni eGov che compongono il servizio (es. Profilo di
Collaborazione).
Figura 6.2: Accordo di Servizio: Parte Comune
Un esempio di manifesto XML per la parte comune di un Accordo di
Servizio e mostrato in figura 6.3.
6.1.5 Descrizione degli Aspetti relativi al Protocollo SPCoop
La Parte Comune di un Accordo di Servizio deve contenere anche una de-
scrizione (formale o informale) degli aspetti relativi al protocollo SPCoop.
In particolare dovra contenere una descrizione di:
• Servizio
CAPITOLO 6. DAGLI ACCORDI DI SERVIZIO AGLI ACCORDI DI COOPERAZIONE67
Figura 6.3: Esempio di Manifesto della parte comune di un AS
• Azioni presenti
• Profilo di Collaborazione del servizio (o di una specifica azione del
servizio)
• Requisiti di funzionalita eGov come consegnaAffidabile e filtroDupli-
cati (elemento ProfiloTrasmissione della busta eGov), consegna in or-
dine e conversazione (elemento Collaborazione e Sequenza della busta
eGov)
• Scadenza temporale di una busta
Le funzionalita eGov richieste per un servizio possono essere definite una
volta per tutte per qualsiasi azione del servizio. Dopodiche possono esse-
re specializzate per particolari azioni che richiedono funzionalita diverse.
Un esempio di descrizione XML delle informazioni eGov di un servizio e il
seguente:
Figura 6.4: Documento semiformale con informazioni e-gov
CAPITOLO 6. DAGLI ACCORDI DI SERVIZIO AGLI ACCORDI DI COOPERAZIONE68
6.1.6 Descrizione della Parte Specifica
Il manifesto della parte specifica di un’Accordo di Servizio e definito dall’ele-
mento XML ’servizio’. Il Manifesto racchiude i riferimenti a documenti che
definiscono la parte specifica di una precisa erogazione del servizio. All’inter-
no del manifesto possono essere presenti la definizione di una singola parte
specifica (per servizio mono-fruitore) o la definizione di diverse parti speci-
fiche, una per ogni fruitore del servizio (servizio multi-fruitore). La parte
specifica puo essere composta da: un unico file zip che racchiude il manifesto
e i vari documenti per un Accordo di Servizio [monofruitore-monoerogatore]
o [multifruitore-monoerogatore]; diversi file zip che racchiudono ognuno il
manifesto e i vari documenti di una parte specifica di ogni servizio eroga-
to, nel cao di un contesto [monofruitore-multierogatore] o [multifruitore-
multierogatore]. Un manifesto di una parte specifica comprende il tipo e il
nome del servizio erogato, il riferimento alla parte comune che viene estesa
e la definizione della parte specifica. La parte specifica puo essere forni-
ta in diverse copie nel caso di istanziazione di servizio multi-fruitore, dove
ogni singola istanza [fruitore,erogatore] avra la propria parte specifica. La
definizione di una parte specifica comprende riferimenti ai documenti quali:
• Porti di Accesso del servizio.
• Specifica delle Interfacce, composta da documenti in formato WSDL
implementativo fruitore e WSDL implementativo erogatore.
• Definizione di livelli di servizio (SLA).
• Politiche di Sicurezza del Servizio.
• Documento semiformale per la ri-definizione di informazioni relative
al protocollo SPCoop richieste dall’Accordo per la specifica istanza del
servizio.
CAPITOLO 6. DAGLI ACCORDI DI SERVIZIO AGLI ACCORDI DI COOPERAZIONE69
Il manifesto di un servizio sara associato logicamente ad un soggetto spcoop,
erogatore di tale servizio. Lo schema logico e il seguente:
Figura 6.5: Accordo di Servizio:Parte Specifica
Un esempio di manifesto XML e il seguente:
Figura 6.6: Esempio di Manifesto della parte specifica di un AS
6.2 L’Accordo di Cooperazione
Da un punto di vista astratto, un Accordo di Servizio descrive una comunica-
zione/collaborazione tra due soggetti, in cui uno offre un servizio applicativo
SPCoop ed l’altro fruisce di tale servizio. Pertanto, tutti i servizi applicativi
offerti da un Dominio rientrano nella responsabilita del singolo soggetto. In
CAPITOLO 6. DAGLI ACCORDI DI SERVIZIO AGLI ACCORDI DI COOPERAZIONE70
realta molti procedimenti e compiti istituzionali non riguardano l’operato
di una singola amministrazione, ma vedono altresı il concorso dell’azione di
piu soggetti. Tale situazione, che in base ai processi organizzativi di decen-
tramento e di delega dallo Stato centrale verso le Regioni e gli Enti locali e
sempre piu frequente, si esemplifica in due principali tipologie di interazione:
• procedimenti inter-amministrativi, nei quali piu amministrazioni con-
corrono, con compiti diversi, al conseguimento di un risultato comples-
sivo, riconducibile ad uno o piu servizi integrati erogati sia a fruitori
esterni alla PA (ad esempio Sportello unico alle imprese, Sportello
unico per l’immigrazione, ecc.) che a fruitori interni alla PA. Questo
tipo di procedimenti sono incentrati sulla amministrazione che eroga
il servizio integrato finale;
• procedimenti di razionalizzazione, coordinamento e controllo, in cui e
individuato normativamente un soggetto vigilante e/o di regolazione,
a livello centrale o territoriale (ad es., Regioni, Provincie, ecc.), mentre
le funzioni amministrative sono attribuite a soggetti periferici, tipica-
mente enti locali (ad esempio Anagrafi, Demanio ecc.) che erogano sul
territorio una stessa gamma di servizi.
Il Dominio di Cooperazione rappresenta la formalizzazione della volonta
di associazione tra diversi soggetti per cooperare nella informatizzazione
di un insieme di procedimenti amministrativi pertinenti. Nel Dominio di
Cooperazione deve essere individuato un soggetto coordinatore responsabi-
le, che assicura l’efficacia organizzativa e tecnica della cooperazione ed il
coordinamento degli adempimenti di ciascuno dei soggetti partecipanti, e
l’insieme dei servizi applicativi composti che il Dominio di Cooperazione
eroga verso l’esterno. Infatti esternamente il Dominio di Cooperazione e un
erogatore di servizi al pari dei Domini di responsabilita delle singole am-
ministrazioni; la differenza e nella realizzazione di tali servizi, che nel caso
CAPITOLO 6. DAGLI ACCORDI DI SERVIZIO AGLI ACCORDI DI COOPERAZIONE71
del Dominio di Cooperazione nascono dall’integrazione e composizione dei
servizi offerti dai singoli domini regolata sulla base di accordi specifici tra
le parti in causa, mentre nel caso del singolo dominio la realizzazione si ap-
poggia ad applicazioni completamente sotto la responsabilita della singola
amministrazione.
Figura 6.7: Dominio di Cooperazione in SPCoop
Il Dominio di Cooperazione deriva spesso dalla trasposizione di una nor-
ma di legge, dove sono individuati i soggetti coinvolti e quello che ha respon-
sabilita del coordinamento o della vigilanza. Ove i ruoli non siano esplicita-
mente previsti dalla normativa, vale il principio generale di pariteticita delle
amministrazioni che, in tal caso, concordano quale tra di loro e responsabile
del Dominio di Cooperazione. Il principio di titolarieta (e quindi di respon-
sabilita) dell’azione amministrativa sul singolo adempimento/procedimento
e comunque valido. Ne consegue che nel Dominio di Cooperazione ciascun
adempimento o parte di procedimento e associato al soggetto pubblico che
istituzionalmente ne ha la responsabilita. Lo stesso rimane responsabile dei
dati e dei servizi scambiati di cui e normativamente titolare. Un Accordo di
Cooperazione (ACoop) e in sintesi la specifica dei servizi applicativi offerti
da un Dominio di Cooperazione. Tre elementi fondamentali caratterizzano
l’erogazione di servizi applicativi da parte di un Dominio di Cooperazione e
CAPITOLO 6. DAGLI ACCORDI DI SERVIZIO AGLI ACCORDI DI COOPERAZIONE72
sono:
• i servizi applicativi che il Dominio di Cooperazione offre all’esterno.
Dal punto di vista del fruitore, questi sono indistinguibili da qualsiasi
altro servizio applicativo offerto direttamente da un Dominio, e ven-
gono descritti attraverso un Accordo di Servizio; nel seguito verranno
indicati come servizi composti;
• i servizi applicativi che il Dominio di Cooperazione utilizza interna-
mente, componendoli, per offrire i servizi composti; anche questi sono
descritti attraverso il proprio Accordo di Servizio; nel seguito verranno
indicati come servizi componenti;
• per ognuno dei servizi applicativi composti, la specifica della modalita
secondo cui i servizi componenti sono coordinati al fine di offrire il ser-
vizio composto. Tale specifica puo essere definita secondo due diverse
ottiche:
– dal punto di vista interno al servizio composto, ovvero descri-
vendo il processo secondo cui i servizi componenti devono essere
coordinati per offrire il servizio composto. In tal caso si parla di
orchestrazione;
– dal punto di vista esterno, ovvero descrivendo i vincoli sugli scam-
bi di messaggi tra i vari servizi componenti; in tal caso si ha
cioe la specifica di una collaborazione N-party. Si parla allora di
coreografia.
Attualmente esiste uno standard maturo per la descrizione di un’orche-
strazione, WS-BPEL (Web Service Business Process Execution Langua-
ge [BPEL], che abbiamo visto nel capitolo 5 ), e sono in corso delle ini-
ziative di standardizzazione della coreografia come ad esempio WS-CDL
(Web Service Choreography Description Language). Pertanto un Accordo
di Cooperazione si compone di:
CAPITOLO 6. DAGLI ACCORDI DI SERVIZIO AGLI ACCORDI DI COOPERAZIONE73
• un documento istitutivo in linguaggio naturale che descrive le finalita
ed il fondamento normativo o istituzionale del Dominio di Coopera-
zione;
• un insieme di riferimenti ordinati agli Accordi di Servizio che descri-
vono i servizi composti offerti dal Dominio di Cooperazione;
• un insieme di documenti WS-BPEL che descrivono il processo di coor-
dinamento tra i servizi composti; tali documenti possono anche servi-
re per l’esecuzione diretta, attraverso opportune tecnologie di orche-
strazione che interpretano dinamicamente i documenti WS-BPEL, del
servizio composto da parte dell’organizzazione responsabile;
• un insieme di liste di riferimenti agli Accordi di Servizio che descrivono
i servizi componenti.
In termini formali si ha:
ACoop= <
Documento,
{ AS 1 , . . . , AS i , . . . , AS n },
{ O 1 , . . . , O i , . . . , O n },
{ AS 1 1 , . . . , AS j 1 , . . . AS m 1 ,}
{ . . . }
{ AS 1 i , . . . , AS j i , . . . AS m i ,}
{ . . . }
{ AS 1 n , . . . , AS j n , . . . AS m n }
>
da cui emerge che il servizio composto descritto dall’Accordo di Servizio
ASi , si compone a partire dall’insieme dei servizi descritti da altrettanti
Accordi di Servizio {AS 1 i , . . . , AS m i }, secondo il processo descritto
dall’orchestrazione Oi .
CAPITOLO 6. DAGLI ACCORDI DI SERVIZIO AGLI ACCORDI DI COOPERAZIONE74
6.3 L’Accordo di Cooperazione nel Registro Ser-
vizi OpenSPCoop
Rispetto ad un Accordo di Servizio, un Accordo di Cooperazione definisce le
relazioni di servizio in qualita di intermediario: la relazione che questo tipo
di accordo e volta a creare coinvolge infatti piu organizzazioni. Tra queste
possiamo identificarne di tre tipi:
• Fruitrice, cioe l’organizzazione che intende ricevere la prestazione del
servizio.
• Erogatrici, cioe le organizzazioni che garantiscono le prestazioni di
servizio necessarie alla realizzazione dell’Accordo di Cooperazione.
• Referente, cioe l’organizzazione che si rende responsabile del corret-
to svolgimento dell’intera operazione concordata con l’organizzazione
fruitrice.
E’ chiaro quindi come l’organizzazione referente abbia una definizione duale:
essa e infatti erogatrice nei confronti dell’organizzazione fruitrice e al tempo
stesso fruitrice dei servizi erogati dalle organizzazioni erogatrici.
L’Accordo di Cooperazione definisce quindi una composizione tra servizi.
Possiamo ora identificare due tipi di servizi:
• servizi componenti
• servizi composti.
I servizi componenti includono un riferimento all’Accordo di Servizio a cui
appartengono. La loro implementazione e la stessa della versione precedente
di OpenSPCoop. I servizi composti sono composizione di servizi componenti
e sono i diretti responsabili della cooperazione tra i servizi componenti di
cui si compongono.
CAPITOLO 6. DAGLI ACCORDI DI SERVIZIO AGLI ACCORDI DI COOPERAZIONE75
Figura 6.8: Dominio di Cooperazione
Figura 6.9: Visione Logica dell’Accordo di Cooperazione
Il Registro Servizi di OpenSPCoop e stato quindi arricchito di un nuovo
tipo che rappresenti il concetto di servizio composto (servizio-composto) e
CAPITOLO 6. DAGLI ACCORDI DI SERVIZIO AGLI ACCORDI DI COOPERAZIONE76
il suo relativo utilizzo come servizio base per la cooperazione in un Accordo
di Cooperazione (accordo-cooperazione).
6.3.1 Accordo di Cooperazione nel Registro Servizi
L’Accordo di Cooperazione permette la definizione di un nome, la descrizione
dell’Accordo di Servizio e la definizione delle URL ai WSDL che descrivono
l’interfaccia del servizio.
<xsd:element name=’accordo-cooperazione’>
<xsd:complexType>
<xsd :sequence>
<xsd:element name=’soggetto-referente’ maxOccurs=’1’ minOccurs=’1’>
<xsd:complexType>
<xsd:attribute name=’tipo’ type=’xsd:string’ use=’required’/>
<xsd:attribute name=’nome’ type=’xsd:string’ use=’required’/>
</xsd:complexType>
</xsd:element>
<xsd:element name=’servizio-composto’
maxOccurs=’unbounded’ minOccurs=’1’>
<xsd:complexType>
<xsd:attribute name=’nome-accordo-servizio’
type=’xsd:string’ use=’required’/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name=’nome’ type=’xsd:string’ use=’required’/>
<xsd:attribute name=’descrizione’ type=’xsd:string’/>
<xsd:attribute name=’documenti-istitutivo’ type=’xsd:string’/>
</xsd:complexType>
</xsd:element>
• Attributi:
CAPITOLO 6. DAGLI ACCORDI DI SERVIZIO AGLI ACCORDI DI COOPERAZIONE77
– nome rappresenta il nome associato all’Accordo di Cooperazione
– descrizione informazione puramente descrittiva contenente una
descrizione funzionale associata all’Accordo di Cooperazione
– documenti-istitutivo riferimento ad eventuali documenti relativi
a questo Accordo di Cooperazione
• Nested Element
– soggetto-referente. Questo nuovo tipo, specifico per l’Accordo
di Cooperazione, e’ ricavato rielaborando il soggetto-spcoop gia’
presente nel Registro Servizi di OpenSPCoop e in quanto tale
necessita delle informazioni per poter essere univocamente iden-
tificato (attributi tipo e nome). Il soggetto referente identifica
sul Registro Servizi l’organizzazione referente, cioe’ quella che
garantisce il corretto svolgimento delle operazioni.
– servizio-composto identifica un servizio composto (specificato in
dettaglio piu avanti). L’attributo nome-accordo-servizio identifi-
ca l’Accordo di Servizio per l’erogazione/fruizione di questo Ac-
cordo di Cooperazione. E’ necessario almeno un servizio compo-
sto per qualunque Accordo di Cooperazione.
L’Accordo di Cooperazione, come appena visto, prevede una sequenza
di servizi-composti. Questo e un nuovo elemento del Registro Servizi che e
riproposto di seguito.
<!- Servizio Composto ->
<xsd:element name=’servizio-composto’ maxOccurs=’1’ minOccurs=’0’>
<xsd:complexType>
<xsd:sequence>
<xsd:element name=’servizio-componente’ maxOccurs=’unbounded’ minOccurs=’2’>
<xsd:complexType>
<xsd:attribute name=’tipo-soggetto’ type=’xsd:string’ use=’required’/>
CAPITOLO 6. DAGLI ACCORDI DI SERVIZIO AGLI ACCORDI DI COOPERAZIONE78
<xsd:attribute name=’nome-soggetto’ type=’xsd:string’ use=’required’/>
<xsd:attribute name=’tipo’ type=’xsd:string’ use=’required’/>
<xsd:attribute name=’nome’ type=’xsd:string’ use=’required’/>
<xsd:attribute name=’azione’ type=’xsd:string’/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
Per il tipo servizio-composto sottolineiamo la definizione di servizio-
componente. Questo nuovo tipo rappresenta l’adattamento del servizio-
spcoop gia presente nel Registro Servizi di OpenSPCoop, cioe il soggetto
responsabile del servizio e il servizio stesso (attributi tipo e nome). Si noti
anche il vincolo sul numero minimo dei servizi componenti: per parlare di
servizio composto ce ne vogliono almeno due.
6.3.2 Esempio di Configurazione del Registro Servizi con un
Accordo di Cooperazione
Vediamo ora un caso di configurazione pratica reale del Registro dei Servizi
in OpenSPCoop per un Accordo di Cooperazione. Questo accordo prevede
il coinvolgimento di quattro soggetti:
• MinisteroFruitore, cioe il soggetto dell’organizzazione che usufruisce
del servizio composto
• MinisteroErogatore, cioe il soggetto dell’organizzazione che eroga il
servizio composto
• Ministero1 e Ministero2, cioe i soggetti delle organizzazioni che parte-
cipano all’Accordo di Cooperazione per erogare i servizi componenti
Questa divisione rispecchia la nozione astratta di Accordo di Cooperazio-
ne come e stata definita nei paragrafi precedenti. La presenza di un Accordo
CAPITOLO 6. DAGLI ACCORDI DI SERVIZIO AGLI ACCORDI DI COOPERAZIONE79
di Servizio e fondamentale anche se si tratta di un Accordo di Cooperazione:
l’Accordo di Servizio infatti regola la prestazione tra l’ente fruitore e l’ente
erogatore.
Il codice per il Registro in versione XML e presentato di seguito.
<!- Accordi di Cooperazione ->
<accordo-cooperazione
nome=’ServiziUtenti’ descrizione=’Esempio di un Accordo di Cooperazione’ >
<soggetto-referente tipo=’SPC’ nome=’MinisteroErogatore’ />
<servizio-composto nome-accordo-servizio=’ASVerificaUtente’ />
</accordo-cooperazione>
Per configurare un Accordo di Cooperazione e necessario fornire il nome
del soggetto referente e il servizio composto: in sintesi cosa fa l’organizza-
zione responsabile.
<!- Accordo di Servizio del servizio composto ->
<accordo-servizio nome=’ASVerificaUtente’
profilo-collaborazione=’sincrono’ utilizzo-senza-azione=’true’ >
<servizio-composto ws-bpel=’http://...PathDelWSPBEL’>
<servizio-componente accordo-servizio=’ASAutenticazioneUtente’ />
<servizio-componente accordo-servizio=’ASAutorizzazioneUtente’ />
</servizio-composto>
</accordo-servizio>
La configurazione continua con un Accordo di Servizio che serve a in-
dentificare la relazione uno a uno tra erogatore del servizio composto e
fruitore dello stesso. Nel servizio composto identifichiamo il riferimento al
documento WS-BPEL che contiene la logica di orchestrazione dei servizi
composti.
<!- Accordo di Servizio del servizio componente 1 ->
<accordo-servizio nome=’ASAutenticazioneUtente’
CAPITOLO 6. DAGLI ACCORDI DI SERVIZIO AGLI ACCORDI DI COOPERAZIONE80
profilo-collaborazione=’sincrono’ utilizzo-senza-azione=’true’ />
<!- Accordo di Servizio del servizio componente 2 ->
<accordo-servizio nome=’ASAutorizzazioneUtente’
profilo-collaborazione=’sincrono’ utilizzo-senza-azione=’true’ />
Gli Accordi di Servizio rimangono fondamentali per la cooperazione: essi
infatti stabiliscono la singole relazioni necessarie per la realizzazione delle
operazioni di invocazione previste dal servizio composto.
<!-
MinisteroFruitore: fruitore del servizio composto
->
<soggetto-spcoop tipo=’SPC’ nome=’MinisteroFruitore’>
<connettore tipo=’http’ nome=’PdDMinisteroFruitore’>
<property nome=’location’
valore=’http://localhost:8080/openspcoop/PA’ />
</connettore>
</soggetto-spcoop>
Per configurare il soggetto che fruisce del servizio composto e necessario
configurare l’indirizzo della porta applicativa utilizzata dal fruitore per le
comunicazioni con le altre porte di dominio (connettore).
<!-
MinisteroErogatore:
- erogatore del servizio composto
- fruitore dei servizi componenti
->
<soggetto-spcoop tipo=’SPC’ nome=’MinisteroErogatore’>
<connettore tipo=’http’ nome=’PdDMinisteroErogatore’>
<property nome=’location’ valore=’http://localhost:8080/openspcoop/PA’ />
</connettore>
<!- Servizio composto ->
CAPITOLO 6. DAGLI ACCORDI DI SERVIZIO AGLI ACCORDI DI COOPERAZIONE81
<servizio tipo=’SPC’ nome=’VerificaUtente’ accordo-servizio=’ASVerificaUtente’>
<servizio-composto>
<servizio-componente
tipo-soggetto=’SPC’ nome-soggetto=’Ministero1’
tipo=’SPC’ nome=’AutenticazioneUtente’ />
<servizio-componente
tipo-soggetto=’SPC’ nome-soggetto=’Ministero2’
tipo=’SPC’ nome=’AutorizzazioneUtente’ />
</servizio-composto>
<fruitore tipo=’SPC’ nome=’MinisteroFruitore’ />
</servizio>
</soggetto-spcoop>
Per configurare il soggetto che eroga il servizio composto e necessario con-
figurare l’indirizzo della porta applicativa del soggetto che eroga il servizio
(connettore). Oltre a questa operazione bisogna fornire i dettagli relativi ad
identificare ogni servizio componente che verra utilizzato da questo servizio
composto nel Registro Servizi. Si identifica l’organizzazione (tipo-soggetto e
( nome-soggetto)) e il servizio richiesto (tipo e ( nome)). Essendo il soggetto
erogatore un intermediario esso e al tempo stesso erogatore del servizio com-
posto e fruitore dei singoli servizi componenti. La dualita di questo soggetto
si riflette nella configurazione del soggetto fruitore.
<!-
Ministero1: erogatore del servizio componente 1
->
<soggetto-spcoop tipo=’SPC’ nome=’Ministero1’>
<connettore tipo=’http’ nome=’PdDMinistero1’>
<property nome=’location’ valore=’http://localhost:8080/openspcoop/PA’ />
</connettore>
<!- Servizio componente 1 ->
<servizio tipo=’SPC’
nome=’AutenticazioneUtente’ accordo-servizio=’ASAutenticazioneUtente’>
CAPITOLO 6. DAGLI ACCORDI DI SERVIZIO AGLI ACCORDI DI COOPERAZIONE82
<fruitore tipo=’SPC’ nome=’MinisteroErogatore’ />
</servizio>
</soggetto-spcoop>
<!-
Ministero2: erogatore del servizio componente 2
->
<soggetto-spcoop tipo=’SPC’ nome=’Ministero2’>
<connettore tipo=’http’ nome=’PdDMinistero2’>
<property nome=’location’ valore=’http://localhost:8080/openspcoop/PA’ />
</connettore>
<!- Servizio componente 2 ->
<servizio tipo=’SPC’
nome=’AutorizzazioneUtente’ accordo-servizio=’ASAutorizzazioneUtente’>
<fruitore tipo=’SPC’ nome=’MinisteroErogatore’ />
</servizio>
</soggetto-spcoop>
La forma dei singoli soggetti che erogano i servizi componenti coincide
con la forma dei soggetti per realizzare gli Accordi di Servizio.
Capitolo 7
Implementazione dei casi
d’uso
In questo capitolo introduciamo il framework scelto per l’orchestrazione dei
servizi complessi JBPM (Java Business Process Management). La trattazio-
ne include anche una descrizione sommaria di JBossAS, l’application server
necessario al funzionamento di JBPM. Saranno inoltre chiariti concetti im-
plementativi pratici riguardo l’uso del linguaggio BPEL e della sua relativa
implementazione nell’engine JBPM-BPEL. In questo capitolo viene espres-
samente mostrato il codice necessario allo sviluppo di un processo in BPEL
a partire da zero. Sara in ultimo approfondita l’implementazione dei casi
d’uso realizzati durante questo lavoro di tesi.
7.1 JBoss Application Server
JBossAS [JBoss] e un application server J2EE sviluppato da JBoss (http://www.JBoss.org).
E’ un application server ad alte prestazioni per piattaforme di classe enter-
prise per la creazione e lo sviluppo di applicazioni e-business. Combinando
una architettura robusta e al tempo stesso flessibile con una licenza no-cost
per software open source, JBossAS e rapidamente diventato il piu popolare
83
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 84
sistema middleware per sviluppatori, piccole e grandi imprese. Questo appli-
cation server e largamente conosciuto per la sua potenza e la sua semplicita
grazie al suo supporto per il modello di programmazione Enterprise Java
Bean 3.0 [EJB]. EJB3 riduce considerevolmente il modello di programma-
zione Java Enterprise espandendo la potenza dei servizi per la piattaforma
Java Enterprise Edition per semplificare gli oggetti Java tramite le annota-
zioni standard Java. Grazie a queste caratteristiche, JBossAS permette alle
organizzazioni dell’Information Technology di raggiungere grossi risultati in
minor tempo. JBoss e quindi un application server per architetture orientate
al servizio (vedi secondo capitolo) che ha i suoi punti di forza grazie anche
alle seguenti caratteristiche:
• supporto per Java Management Extensions (JMX) per la configura-
zione dei servizi via console.
• supporto per Java Server Faces, un framework standard per applica-
zioni Web.
• funzialita di caching e clustering per applicazioni complesse.
• supporto totale per web Service, dallo sviluppo alla sicurezza avanzata.
7.2 JBPM (java Business Process Management)
In questa sezione descriviamo JBPM, un framework per linguaggi a processi.
Il prodotto e disponibile presso il sito di JBoss (http://www.JBoss.com).
7.2.1 JBPM
JBoss JBPM (java Business Process Management) e un framework esten-
sibile e flessibile per linguaggi a processi. jPDL (java Process Description
Language) e un linguaggio a processi che e costruito sopra il comune fra-
mework JBPM. jPDL e intuitivo e permette di esprimere processi produttivi
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 85
in maniera grafica in termini di operazioni, stati d’attesa per comunicazioni
asincrone, timers, azioni automatizzate ecc... Per collegare queste operazio-
ni insieme, jPDL ha un meccanismo potente ed estensibile per il controllo
del flusso. jPDL ha dipendenze minime e puo essere usato tanto facilmente
quanto una libreria Java (vedi figura 7.2) ma puo essere anche usata in am-
bienti dove sono previste computazioni ad alto throughput impiegandolo in
cluster di application server J2EE (vedi figura 7.1). Il framework JBPM si
dimostra flessibile perche definisce una tecnologia di base per tutti i tipi di
linguaggi a processi.
Figura 7.1: Il linguaggio a processi e la sua collocazione
Figura 7.2: Panoramica sui componenti jPDL
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 86
7.2.2 JBPM per la gestione dei processi produttivi
L’obiettivo di BPM e di rendere un’organizzazione piu efficiente nell’esecu-
zione dei suoi compiti. Il primo passo e descrivere come il lavoro deve essere
fatto in una organizzazione. Definiamo un processo produttivo come una
descrizione di come le persone e il sistema lavorano insieme per compiere un
determinato compito. Una volta che il processo produttivo e stato defini-
to, si effettuano eventuali ottimizzazioni (Business Process Reengineering,
BPR), con meccanismi di controllo e statistiche.
Un altro modo di migliorare l’efficienza puo essere automatizzare una parte
o l’intero processo produttivo utilizzando l’information technology.
Quindi automatizzare e ottimizzare i processi produttivi sono le due princi-
pali tecniche per migliorare l’efficenza di una organizzazione.
L’adozione di processi produttivi ottimizzati e fondamentale per le aziende:
l’esecuzione di un processo produttivo efficiente permette loro di risparmiare
tempo e denaro, sia in termini di macchinari che in termini di forza lavo-
ro impiegati. Lo sforzo e il costo addizionale richiesti ad una azienda per
analizzare, automatizzare e ottimizzare i processi produttivi porta necessa-
riamente ad un guadagno a breve e a lungo termine.
Un altro obiettivo principale dei sistemi BPM e di facilitare l’automazione
dei processi produttivi. Nella costruzione del software per processi produtti-
vi si possono distinguere due ruoli: lo sviluppatore e l’analista del processo.
In piccoli team, questi lavori possono essere realizzati dalla stessa persona.
L’analista di processo studia e descrive il processo produttivo e specifica i
requisiti software, mentre lo sviluppatore crea software eseguibile.
Le suite tradizionali di BPM cercano di partire dal modello dell’analista
dei processi e si muovono verso il software eseguibile. In seguito cercano
di minimizzare le necessita di abilita tecniche in maniera tale che l’anali-
sta di processi possa produrre facilmente il software eseguibile a partire dal
modello. Questo scenario e descritto in figura 7.3.
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 87
Figura 7.3: La separazione dei ruoli nei processi produttivi
Invece, nella visione di JBPM, l’idea centrale e che l’analista di processi
e lo sviluppatore comunicano in un linguaggio condiviso con l’aiuto della vi-
sione grafica del processo. Le abilita tecniche saranno sempre necessarie per
lo sviluppo del software. L’analista software e responsabile per la rappre-
sentazione grafica e non dovrebbe essere forzato a tener conto degli aspetti
tecnici che saranno necessari per rendere il processo eseguibile. Gli aspetti
tecnici, comunque, non dovrebbero richiedere cambi alla rappresentazione
grafica del processo.
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 88
Figura 7.4: I ruoli nell’implementazione e gestione dei workflow
7.3 Realizzare workflow in JBPM-BPEL
7.3.1 Struttura dei File per un Servizio Workflow
In questa sezione presentiamo i passi necessari per realizzare un servizio di
tipo worfklow completo a partire da zero. E’ importante specificare che un
workflow scritto in WS-BPEL viene visto dall’esterno come un comune Web
Service che e possibile invocare con un comune client. La trattazione seguen-
te mostrera la struttura delle directory e dei file da utilizzare insieme ai task
Ant scritti per ottenere un processo WS-BPEL correttamente funzionante
sotto JBoss.
La descrizione di un workflow sara costituita dalle directory e dai file se-
guenti:
• src: in questa cartella si mantiene il codice java associato al Web
Service del workflow.
• deploy : in questa cartella si mantengono in maniera ben separata il
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 89
codice relativo al servizio di tipo workflow e altre informazioni collegate
al deploy
• file build.xml e local env.xml : essi contengono codice Ant riusabile per
qualunque servizio scritto rispettando questa struttura.
La directory deploy contiene:
• Directory bpel : in questa directory sono contenuti il file WS-BPEL
che implementa la logica di orchestrazione, il documento WSDL che
presenta il processo di tipo workflow come un comune Web-Service
e i documenti WSDL che il workflow deve orchestrare. Questi ulti-
mi WSDL possono essere non completamente specificati, cioe possono
mancare delle informazioni relative al deploy dei servizi orchestrati (ad
esempio, indirizzo).
• Directory resources: questa directory contiene i file necessari a:
– Creare le interfacce java e i tipi degli oggetti associati a questo
servizio a partire dal documento WSDL associato al workflow (file
wscompile.xml).
– Fornire all’engine JBPM-BPEL il mapping tra il workflow e le
classi java che lo implementano(cioe un file che mostra come un
oggetto XML viene convertito in un oggetto java e viceversa) e
gli indirizzi dei servizi che il workflow contattera a run-time (file
bpelapplication.xml in Web/classes ).
– Fornire ad JBoss le informazioni per mappare il Web Service
associato al workflow su una servlet come per qualunque altro
Web Service di cui si vuole effettuare il deploy (file Web.xml e
WebService.xml in Web)
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 90
7.3.2 Deploy del Servizio Workflow
Quando le directory e i file sono stati organizzati come specificato nel para-
grafo precedente, bisogna assicurarsi che sotto JBoss sia gia attivo l’engine
JBPM-BPEL. In caso affermativo e possibile utilizzare gli script Ant scritti
durante questo lavoro di tesi per velocizzare il piu possibile l’operazione di
deploy del servizio che implementa questo workflow. In questo paragrafo
verra descritto ogni singolo task Ant a livello funzionale mentre il loro uti-
lizzo verra mostrato in un esempio pratico che e possibile comprendere nel
paragrafo successivo.
• ant deploy-definition: Questo task crea un file compresso a partire dal
processo scritto in BPEL, dal relativo WSDL descrittivo e dai WSDL
dei servizi coinvolti e verifica la sintassi e la semantica del processo
inviando tale archivio all’engine BPEL. L’engine BPEL che e in ese-
cuzione sotto JBoss come un qualunque altro servizio Web risponde a
tale operazione con un codice HTTP, 200 se e accettato, 505 se sono
occorse delle eccezioni durante l’analisi dell’archivio. L’archivio viene
accettato se il compilatore WS-BPEL e il parser WSDL hanno accet-
tato i rispettivi file. Questa operazione di fatto registra la definizione
di questo progetto sull’engine JBPM-BPEL, cui manca solo il Web
Service associato (file WAR). I seguenti passi spiegano come ottenere
questo altro archivio.
• ant generate-Service: Questo task analizza il WSDL descrittivo as-
sociato al processo e provvede alla creazione del relativo servizio in
maniera concreta, iniziando cioe a mostrare quali siano le modalita
per contattare il Web Service che rappresenta il processo. Il risultato
di questo task e una serie di documenti WSDL che includono i ser-
vizi usati dal processo e i WSDL che definiscono il processo stesso.
L’informazione relativa all’indirizzo e fornita in maniera parametrica
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 91
tramite una particolare URL (REPLACE WITH ACTUAL URI ) che
indica che l’indirizzo del servizio sara definito a seconda del punto in
cui verra effettuato il deploy.
• ant generate-artifacts: Questo task utilizza i documenti WSDL pro-
dotti dal task generate-Service e ne analizza gli eventuali tipi XML
coinvolti. Questo task richiede l’utilizzo di Java Web Service Develo-
per Pack, una raccolta di tool per chi crea e sviluppa Web Service. Tra
i tool a disposizione viene usato WsCompile che effettua l’analisi di
un documento WSDL e produce le classi associate al servizio. Il tool
provvede a creare una interfaccia Java da implementare per la logica
del servizio oltre alla conversione in tipi Java dei tipi XML utilizzati
dai vari documenti WSDL. Il tool infine crea un file per collegare i tipi
XML ai tipi Java per le operazioni RPC, in una parola le informazioni
di binding e mapping. Tra le classi generate e bene ricordare quella
fondamentale, che ha lo stesso nome dell’operazione del servizio e che
va implementata per la completezza del servizio stesso.
• ant deploy: Questo task utilizza tutti i documenti prodotti dai task
generate-Service e generate-artifacts per creare una struttura di direc-
tory e di file ammessa dall’Application Server JBoss e che corrisponda
al formato del servizio per cui l’engine BPEL aveva accettato le de-
finizioni con il task deploy-definition. Il risultato di questo task e
la generazione di un archivio Web (WAR) e il suo relativo deploy in
JBoss. Al contrario di quanto accade per il task deploy-definition non
viene fornita alcuna risposta e il riscontro sul corretto deploy deve es-
sere ricercato analizzando il file di log di JBoss. Un corretto deploy
in genere e identificato dal sottoservizio ServiceEndPointManager di
JBoss che comunica la URL dove e possibile invocare il servizio.
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 92
7.4 I Casi di Prova in BPEL
Prima di passare all’implementazione dei casi d’uso per l’Accordo di Coope-
razione sono stati realizzati vari casi di prova in BPEL. Lo scopo funzionale
di questi casi d’uso e stato familiarizzare con il linguaggio e la sua imple-
mentazione scelta oltre a mostrare capacita avanzate di elaborazione del
linguaggio stesso. Per il caso d’uso ElevaQuadrato e solo per questo ca-
so viene mostrato il contenuto dei file coinvolti nella realizzazione e come
utilizzare gli script Ant.
7.4.1 Il Caso d’Uso ElevaQuadrato
Questo caso d’uso e un caso minimale ma permette di familiarizzare con
il linguaggio e con i relativi concetti base. Presentiamo questo caso d’uso
in maniera totale, specificando anche il ruolo di ogni file contenuto nella
directory del progetto e il significato semantico degli elementi all’interno
di ogni singolo file. L’organizzazione dei file rispetta quella descritta nei
Figura 7.5: ElevaQuadrato in BPEL
paragrafi precedenti ed e la seguente:
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 93
build.xml
local_env.xml
src/
Quadrato_Impl.java
deploy/
bpel/
quadrato.bpel
quadrato.wsdl
META-INF/
bpel-definition.xml
resources/
wscompile.xml
web/
web.xml
webservice.xml
classes/
bpel-application.xml
Iniziamo la descrizione del workflow ElevaQuadrato mostrando prima la
logica di orchestrazione che in questo caso non coinvolge altri servizi (il file
quadrato.bpel) e quindi il documento WSDL per la definizione astratta di
questo workflow come Web Service (il file quadrato.wsdl).
Il seguente codice WS-BPEL per il processo ElevaQuadrato e contenuto
in quadrato.bpel.
<process name=’ElevaQuadrato’
targetNamespace=’http://jbpm.org/examples/quadrato’
xmlns=’http://schemas.xmlsoap.org/ws/2003/03/business-process/’
xmlns:tns=’http://jbpm.org/examples/quadrato’
xmlns:bpel=’http://schemas.xmlsoap.org/ws/2003/03/business-process/’>
<partnerLinks>
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 94
<!- establishes the relationship with the caller agent ->
<partnerLink name=’caller’ partnerLinkType=’tns:Quadrato-Caller’
myRole=’Quadrato’ />
</partnerLinks>
<variables>
<!- holds the incoming message ->
<variable name=’request’ messageType=’tns:rootMessage’ />
<!- holds the outgoing message ->
<variable name=’response’ messageType=’tns:squareMessage’ />
</variables>
<sequence>
<!- receive the root ->
<receive operation=’quadrato’ partnerLink=’caller’ portType=’tns:Quadrato’
variable=’request’ createInstance=’yes’ />
<!- multiplies the root integer ->
<assign>
<copy>
<from expression=’
bpel:getVariableData(’request’, ’root’) *
bpel:getVariableData(’request’, ’root’)’ />
<to variable=’response’ part=’square’ />
</copy>
</assign>
<!- reply with the square ->
<reply operation=’quadrato’ partnerLink=’caller’ portType=’tns:Quadrato’
variable=’response’ />
</sequence>
</process>
Il processo (elemento <process>) e definito attraverso un nome (attribu-
to name) e identifica uno spazio di nomi (attributi targetNamespace e tns)
con connotazione identica a quella dei documenti di tipo WSDL. All’interno
del processo e definito un solo elemento partnerLink di nome caller, il cui ti-
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 95
po (tns:Quadrato-Caller) e stato gia definito nel documento quadrato.wsdl.
Il partnerlink come gia visto nel capitolo su BPEL identifica il collegamento
tra il processo e uno dei punti di entrata per l’invocazione dei servizi. In
questo caso il partnerLink definisce per mezzo di quale operazione del servi-
zio associato a questo processo viene effettuata la creazione dell’istanza del
processo. La definizione delle variabili globali segue quella dei partnerLink:
queste variabili sono usate per memorizzare i messaggi scambiati tra client,
processo e servizi e realizzano di fatto lo stato del processo. Le operazioni
contenute nella sequenza principali prevedono:
• (receive). La ricezione di un messaggio sul partnerLink identifica anche
la creazione del processo stesso (attributo createInstance)
• (assign). Il messaggio ricevuto viene processato: se ne estrapola il
campo ’root’ e lo si moltiplica per se stesso. Tale risultato viene copiato
nel messaggio finale.
• (reply). La risposta appena costruita viene rimandata indietro al
client.
Il file quadrato.wsdl contiene il seguente codice: si tratta di una descrizio-
ne di un Web Service come tutti gli altri, con la sola eccezione che definisce
il tipo del partnerLink che il processo usa.
<definitions targetNamespace=’http://jbpm.org/examples/quadrato’
xmlns=’http://schemas.xmlsoap.org/wsdl/’
xmlns:tns=’http://jbpm.org/examples/quadrato’
xmlns:xsd=’http://www.w3.org/2001/XMLSchema’
xmlns:plt=’http://schemas.xmlsoap.org/ws/2003/05/partner-link/’>
<!- characterizes the relationship between the Quadrato and its caller ->
<plt:partnerLinkType name=’Quadrato-Caller’>
<plt:role name=’Quadrato’>
<plt:portType name=’tns:Quadrato’ />
</plt:role>
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 96
<!- the Caller does not provide Services to the Quadrato,
this is why we omit the ’Caller’ role ->
</plt:partnerLinkType>
<!- carries the integer value ->
<message name=’rootMessage’>
<part name=’root’ type=’xsd:int’ />
</message>
<!- carries the result ->
<message name=’squareMessage’>
<part name=’square’ type=’xsd:int’ />
</message>
<!- describes the interface presented to callers ->
<portType name=’Quadrato’>
<operation name=’quadrato’>
<input message=’tns:rootMessage’ />
<output message=’tns:squareMessage’ />
</operation>
</portType>
</definitions>
Il file bpel-definition.xml e richiesto dall’engine BPEL e serve a fornire
le istruzioni per comprendere la struttura dell’archivio compresso che verra
generato col prossimo comando Ant.
<bpelDefinition location=’quadrato.bpel’ xmlns=’http://jbpm.org/bpel’>
<!- makes WSDL interface elements available to the process ->
<imports>
<wsdl location=’quadrato.wsdl’ />
</imports>
</bpelDefinition>
Dati questi tre file e possibile eseguire il comando
ant deploy-definition
per effettuare la registrazione di questo processo nell’engine. La corretta
esecuzione viene presentata come
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 97
INFO [/jbpm-bpel] processDeployServlet: deploying process definition:
file=file:/.../quadrato-process.zip
INFO [BpelReader] read wsdl definitions: quadrato.wsdl
INFO [BpelReader] read bpel process: quadrato.bpel
INFO [/jbpm-bpel] processDeployServlet: deployed process definition:
ElevaQuadrato
L’esecuzione del comando
ant generate-Service
effuttua la generazione in una directory locale dei documenti WSDL che
rendono il documento quadrato.wsdl la definizione completa di un Web Ser-
vice. I passi che seguono servono a costruire un Web Service in un formato
comprensibile per JBoss.
Il file wscompile.xml e associato all’utilizzo di WSCompile, una libreria
richiesta per la costruzione di WAR per workflow in JBPM-BPEL. Una delle
operazioni di questa libreria e di creare classi java a partire da documen-
ti WSDL per ogni oggetto trovato nel documento WSDL e interfacce java
per qualunque gruppo di operazioni trovate (i.e. portType). La configu-
razione dell’operazione e semplice: basta specificare per quale file bisogna
generarne le interfacce java (valore dell’attributo location) e a quale package
appartengono queste interfacce (valore dell’attributo packageName).
<configuration xmlns=’http://java.sun.com/xml/ns/jax-rpc/ri/config’>
<wsdl location=’target/resources/Web/wsdl/quadrato-Service.wsdl’
packageName=’org.jbpm.bpel.ElevaQuadrato’ />
</configuration>
Configurato appropriatamente questo file, e possibile eseguire il coman-
do
ant generate-artifacts
per creare le interfacce java. La classe che implementa il servizio (qua-
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 98
drato Impl.java) deve implementare l’interfaccia associata al portType di
questo servizio. La logica di questa classe non viene mai utilizzata ma la
sua definizione e necessaria allo sviluppo di un Web Service sotto JBoss.
il file Web.xml definisce il collegamento tra la definizione WSDL del
processo e la classe che ne implementa la logica. Si crea quindi un servlet,
cioe una applicazione che esegue codice java per Web Service. Si identifica
quindi il nome della servlet e per questo nome si specifica:
• Quale classe ne realizza la logica (servlet-class).
• Quale sia l’indirizzo per contattarlo (url-pattern).
<Web-app version=’2.4’ xmlns=’http://java.sun.com/xml/ns/j2ee’
xmlns:xsi=’http://www.w3.org/2001/XMLSchema-instance’
xsi:schemaLocation=’http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/Web-app_2_4.xsd’>
<servlet>
<servlet-name>quadratoServlet</servlet-name>
<servlet-class>org.jbpm.bpel.ElevaQuadrato.Quadrato_Impl</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>quadratoServlet</servlet-name>
<url-pattern>/quadrato</url-pattern>
</servlet-mapping>
</Web-app>
Il file WebServices.xml fornisce le informazioni per collegare i tipi defini-
ti nel documento WSDL quadrato.wsdl e le classi generate da WSCompile.
Ulteriori informazioni specificano come la parte concreta di quadrato.wsdl
(i port) sia collegata alle interfacce create e quale sia il servlet che gesti-
sce questo Web Service. In questo file si trovano informazioni per l’engine
JBPM-BPEL (elemento init-param) che specificano quale sia il partnerLink
che provoca la generazione del processo nell’engine.
<WebServices version=’1.1’ xmlns=’http://java.sun.com/xml/ns/j2ee’
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 99
xmlns:xsi=’http://www.w3.org/2001/XMLSchema-instance’
xsi:schemaLocation=’http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/j2ee_Web_Services_1_1.xsd’>
<WebService-description>
<!- descriptive name for the Service ->
<WebService-description-name>Eleva al Quadrato</WebService-description-name>
<!- WSDL Service file ->
<wsdl-file>WEB-INF/wsdl/quadrato-Service.wsdl</wsdl-file>
<!- Java to XML mapping file ->
<jaxrpc-mapping-file>WEB-INF/jaxrpc-mapping.xml</jaxrpc-mapping-file>
<port-component>
<!- logical name for the port (unique within the module) ->
<port-component-name>QuadratoPort</port-component-name>
<!- WSDL port element (in Service.wsdl) ->
<wsdl-port xmlns:portNS=’http://jbpm.org/examples/quadrato’>
portNS:QuadratoPort
</wsdl-port>
<!- Service endpoint interface class ->
<Service-endpoint-interface>
org.jbpm.bpel.ElevaQuadrato.Quadrato
</Service-endpoint-interface>
<!- associated servlet (in Web-app.xml) ->
<Service-impl-bean>
<servlet-link>quadratoServlet</servlet-link>
</Service-impl-bean>
<handler>
<init-param>
<description>
name of the partner link served by this port
</description>
<param-name>partnerLinkHandle</param-name>
<param-value>caller</param-value>
</init-param>
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 100
</handler>
</port-component>
</WebService-description> </WebServices>
Nel file bpelApplication.xml si specificano le URL usate dall’engine a run-
time per contattare i servizi. Questo esempio, non coinvolgendo altri servizi,
non richide una configurazione di questo file.
<bpelApplication name=’ElevaQuadrato’ xmlns=’http://jbpm.org/bpel’
xmlns:xsi=’http://www.w3.org/2001/XMLSchema-instance’
xsi:schemaLocation=’http://jbpm.org/bpel
http://jbpm.org/bpel/bpel_application_1_0.xsd’ />
L’esecuzione del comando
ant deploy
realizza un archivio Web (WAR) per un Web Service sotto JBoss. Il corretto
deploy viene evidenziato da tracce nel log del server
[TomcatDeployer] deploy, ctxPath=/quadrato, warUrl=...
[IntegrationConfigurator] Message reception enabled for process:
ElevaQuadrato
[WSDLFilePublisher] WSDL published to: file:/.../quadrato-Service.wsdl
[ServiceEndpointManager] WebService started: http://.../quadrato/quadrato
Il servizio e ora pronto per poter essere utilizzato da un qualsiasi client
Web Service correttamente configurato.
7.4.2 Routing Semplice e Routing Elaborato
A livello di logica di orchestrazione, questo caso d’uso e leggermente piu ela-
borato del precedente. In questo caso d’uso, il processo deve contattare due
servizi, inoltrando loro il messaggio ricevuto dal client e fornire come risposta
al client entrambe le risposte ricevute. Questo caso d’uso mette in eviden-
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 101
za le caratteristiche di BPEL in merito agli assegnamenti automatizzati di
messaggi SOAP.
Figura 7.6: Routing in BPEL
I passi che si analizzano in figura 7.6 sono i seguenti:
1. Il client contatta il processo Route per inviare il suo messaggio (es.
nome)
2. Il processo viene attivato e inoltra il messaggio ricevuto dal client ai
due servizi.
3. Ricevute le risposte dai servizi, provvede a ricavarne il contenuto (es.
’Servizio 1 nome OK’) e a ricomporle per creare la risposta per il client.
4. Il processo invia la risposta al client, chiudendo la comunicazione.
Nel caso d’uso di routing elaborato, il messaggio di risposta del primo
servizio viene usato come input del secondo servizio. L’esecuzione prosegue
come gia visto per il routing semplice. A differenza del caso d’uso ElevaQua-
drato, in questo caso d’uso il processo contatta Web Service esterni, prepara
ed elabora messaggi SOAP sia per il rispondere al client sia per formula-
re le richieste ai Web Service. L’elaborazione dei messaggi e estremamente
facilitata dalla gestione automatica dei namespace nell’engine JBPM-BPEL.
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 102
7.4.3 Uso di Tipi XML e Query XPath 1.0
BPEL e un linguaggio basato su XML e i tool messi a disposizione con
l’engine permettono di effettuare un controllo sintattico e semantico del
codice BPEL che viene scritto. Il validatore XML fornito realizza controlli
a livello di messaggi SOAP ma non relativamente all’intero contenuto del
messaggio. In altre parole, l’utilizzo di un tipo XML non default in un
documento WSDL usato da BPEL viene riconosciuto solo a livello di nome
e non a livello di contenuto.
Per utilizzare quindi i campi contenuti all’interno di un tipo XML bisogna
ricorrere a query Xpath. Supponiamo di avere un tipo XML di nome ’Utente’
definito come segue:
<complexType name=’Utente’>
<sequence>
<element name=’nome’ type=’xsd:string’/>
<element name=’cognome’ type=’xsd:string’ />
</sequence>
</complexType>
Una tipica espressione XPath per leggere il nome e ’/Utente/nome’. Que-
sto caso d’uso pone quindi l’accento sui tipi XML e sulle query XPath nel
linguaggio BPEL. L’utilizzo di questo caso d’uso e stato utilizzato nel caso
d’uso Login, a cui si rimanda per una descrizione piu completa.
7.4.4 Indirizzamento Dinamico dei Servizi
L’implementazione di BPEL nell’engine JBPM-BPEL risolve l’indirizzo dei
servizi da contattare tramite un registro XML di nome bpel-application che
contiene delle URL esplicite di servizi espressi sotto forma di documenti
WSDL. L’engine quindi ottiene dinamicamente tutte le informazioni neces-
sarie a contattare i servizi con una data interfaccia prelevando i WSDL asso-
ciati grazie alle URL nel registro e controllando che il servizio implementi le
operazioni richieste in maniera concreta. L’implementazione attuale dell’en-
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 103
gine, pero, impone la conoscenza statica, cioe a tempo di design, di questi
indirizzi. In caso di compatibilita di piu WSDL tra quelli con URL nota, vie-
ne scelto sempre il primo tra quelli registrati nella registro bpel-application.
Un esempio di file bpelapplication.xml che definisce la struttura del registro
per le URL e fatto in questo modo:
<bpelApplication name=’AtmFrontEnd’ xmlns=’http://jbpm.org/bpel’
xmlns:xsi=’http://www.w3.org/2001/XMLSchema-instance’
xsi:schemaLocation=’http://jbpm.org/bpel
http://jbpm.org/bpel/bpel_application_1_0.xsd’>
<ServiceCatalogs>
<urlCatalog contextUrl=’http://localhost:8080/’>
<wsdl location=’ticket/ticketIssuer?wsdl’ />
<wsdl location=’account/accountSystem?wsdl’ />
</urlCatalog>
</ServiceCatalogs>
</bpelApplication>
Questo tipo di implementazione e:
• poco flessibile, perche impone che l’indirizzo dei servizi da contattare
sia sempre gia noto a tempo di design
• in alcune situazioni, il comportamento del codice non e quello descritto
a causa della scelta basata su URL nel catalogo.
Per superare questa difficolta, in BPEL esiste il tipo EndpointReference che
permette di definire l’indirizzo di un servizio e il relativo Service. Quando
questo oggetto viene assegnato ad un partnerlink, la ricerca nel URLCata-
log viene annullata e viene direttamente contattato il servizio all’indirizzo
indicato. In questo caso d’uso il processo deve contattare il servizio previa
ricezione dell’indirizzo da un altro servizio di tipo ’Registro’ che ha la logica
semplice di ritornare l’indirizzo del servizio richiesto in parametro. I passi
rilevanti sono i seguenti:
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 104
1. Il client contatta il servizio Dinamico con un tipo XML contenente due
stringhe, un ’nomeutente’ e un ’nomeservizio’.
2. Il processo si attiva e, rilevato il ’nomeservizio’, contatta il Registro
per ottenere la URL.
3. Se la URL e ’NO URL’, una risposta con esito negativo viene ritornata
al client.
4. Se la URL non e ’NO URL’ si contatta il servizio all’indirizzo richiesto
e la relativa risposta viene raccolta.
5. Il processo risponde al client e pone fine alla comunicazione.
7.5 Implementazione dei Casi d’Uso per il Forma-
to degli Accordi di Cooperazione
L’implementazione dei casi d’uso di prova utilizzati nelle prime fasi della
tesi erano volti a prendere confidenza con la programmazione orientata ai
grafi, il funzionamento del linguaggio BPEL e la relativa implementazio-
ne nell’engine JBPM-BPEL. La realizzazione di queste prime applicazioni
e stata effettuata usando codice simile agli esempi di riferimento contenuti
all’interno della distribuzione utilizzata dell’engine. I Web Service scritti
durante questa fase sono stati realizzati utilizzando una libreria dell’engine,
WsCompile, che genera delle classi in stile stub/skeleton per tutte le proce-
dure di tipo RPC. Inoltre, i client realizzati erano anch’essi dei Web Service
JBoss che implementano l’interfaccia TestCase presente nel framework JU-
nit di Sun per la realizzazione di test.
Per realizzare, invece, i casi d’uso per OpenSPCoop e i relativi client di
prova sono stati utilizzati appositi strumenti appartenenti al SOAP Engine
Axis, nella fattispecie Java2WSDL e WSDL2Java. Questo per mantenere la
linea scelta con le precedenti distribuzioni di OpenSPCoop. Questo cambio
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 105
di strumenti ha creato la necessita di analizzare i messaggi SOAP scambiati
tra processo e servizi per analizzare condizioni di errore inattese. E’ stato
utilizzato un analizzatore di pacchetti TCP disponibile in ambiente Linux di
nome WireShark che ha permesso di rilevare il corretto formato dei messaggi
scambiati tra i processi e i servizi. Parte della composizione automatizzata
di messaggi in BPEL si e persa e questo ha allungato i tempi di sviluppo
dei casi d’uso stessi. Come gia descritto nel capitolo precedente, i casi d’uso
individuati sono tre e riguardano in ordine:
• la verifica del funzionamento dell’Accordo di Cooperazione e dei mezzi
necessari a realizzare una orchestrazione tra servizi.
• l’utilizzo di tipi XML, la composizione e l’inoltro di messaggi.
• l’invocazione di una famiglia di servizi con interfaccia comune con
indirizzo non noto.
7.5.1 La porta di dominio OpenSPCoop come proxy SOAP
La porta di dominio OpenSPCoop puo essere anche utilizzata come proxy
SOAP. Ne viene qui riproposto il funzionamento in quanto basilare per il
meccanismo di invocazione di Web Service da parte dei workflow. Per utiliz-
zare la porta di dominio in questo modo occorre integrare i servizi applicativi
del proprio dominio attraverso la modalita d’integrazione trasparente. Que-
sta modalita prevede che il servizio applicativo utilizzi (in caso di porta
delegata) o esponga (in caso di porta applicativa) le interfacce applicative
native dei servizi, cosı come registrate negli accordi di servizio; in tal caso la
Porta di Dominio agisce come un proxy SOAP trasparente con funzionalita
di imbustamento e sbustamento eGov dei messaggi applicativi; utilizzando
questa modalita, gli applicativi potranno continuare ad operare esattamente
come se stessero interagendo direttamente con il servizio applicativo dell’al-
tro Ente. L’invocazione della porta delegata in modalita trasparente puo
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 106
essere realizzata tramite gli strumenti del linguaggio di programmazione na-
tivo del servizio applicativo, utilizzando ad esempio stub creati tramite il
proprio ambiente di sviluppo Web Services (ad esempio WSDL2JAVA in
Axis), facendo riferimento direttamente al WSDL del servizio destinazione.
In questo caso la principale modifica rispetto all’invocazione dell’effettivo
servizio destinazione sara la URL utilizzata per l’invocazione http, che do-
vra essere quella corrispondente alla porta delegata del servizio esposta dalla
PdD.
7.5.2 Caso d’Uso Hello
Il caso d’uso Hello permette di verificare la corretta configurazione dell’en-
gine JBPM-BPEL e l’utilizzo di Accordi di Cooperazione in OpenSPCoop.
Questo caso d’uso coinvolge quattro soggetti, uno che richiede il servizio
(MinisteroFruitore ), uno che regola l’intero processo (MinisteroErogatore )
e i due soggetti che erogano i servizi da coordinare ( Ministero1 e Ministero2
). Il funzionamento del processo associato a questo Accordo di Cooperazione
puo essere riassunto nei seguenti passi:
• Il MinisteroFruitore contatta il MinisteroErogatore inviando il proprio
nome.
• Il MinisteroErogatore contatta il Ministero1 per ottenere la stringa
Hello seguita dal nome ricevuto in precedenza.
• Il MinisteroErogatore contatta il Ministero2 per confermare che la
precedente operazione e andata a buon fine e chiederne il tracciamento.
• Il MinisteroErogatore conclude le comunicazione inviando la stringa
Hello seguita dal nome ricevuto dal MinisteroErogatore.
I passi da effettuare coinvolgono:
• configurazione:
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 107
– configurazione del Registro Servizi di OpenSPCoop per la regi-
strazione dell’Accordo di Cooperazione definito tra i due sogget-
ti, registrazione dei soggetti SPCoop e del servizio che istanzia
l’Accordo di Cooperazione.
– configurazione del dominio MinisteroErogatoreSPCoopIT nella
porta di dominio OpenSPCoop: registrazione di una porta ap-
plicativa per il servizio SPC/Hello
– configurazione del dominio MinisteroFruitoreSPCoopIT nella por-
ta di dominio OpenSPCoop: registrazione della porta delega-
ta utilizzata dal soggetto SPC/MinisteroFruitore per invocare il
servizio SPC/Hello.
– configurazione del dominio Ministero1SPCoopIT e Ministero1SPCoopIT
nella porta di dominio OpenSPCoop: registrazione degli accordi
di servizio.
Solo per questo caso d’uso proponiamo qui di seguito una configurazione
reale del Registro Servizi. Per gli altri casi d’uso la configurazione varia nei
nomi e nelle URL ma rimane sostanzialmente la stessa.
<!- Accordi di Cooperazione ->
<accordo-cooperazione nome=’Hello’
descrizione=’Esempio di un Accordo di Cooperazione’ >
<soggetto-referente tipo=’SPC’ nome=’MinisteroErogatore’ />
<servizio-composto nome-accordo-servizio=’ASHello’ />
</accordo-cooperazione>
<!- Accordo di Servizio del servizio composto ->
<accordo-servizio nome=’ASHello’
profilo-collaborazione=’sincrono’ utilizzo-senza-azione=’true’ >
<servizio-composto ws-bpel=’http://...PathDelWSPBEL’>
<servizio-componente accordo-servizio=’ASHelloUtente’ />
<servizio-componente accordo-servizio=’ASTracciaUtente’ />
</servizio-composto>
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 108
</accordo-servizio>
<!- Accordo di Servizio del servizio componente 1 ->
<accordo-servizio nome=’ASHelloUtente’
profilo-collaborazione=’sincrono’ utilizzo-senza-azione=’true’ />
<!- Accordo di Servizio del servizio componente 2 ->
<accordo-servizio nome=’ASTracciaUtente’
profilo-collaborazione=’sincrono’ utilizzo-senza-azione=’true’ />
<!-
MinisteroFruitore: fruitore del servizio composto
->
<soggetto-spcoop tipo=’SPC’ nome=’MinisteroFruitore’>
<connettore tipo=’http’ nome=’PdDMinisteroFruitore’>
<property nome=’location’ valore=’http://localhost:8080/openspcoop/PA’ />
</connettore>
</soggetto-spcoop>
<!-
MinisteroErogatore:
- erogatore del servizio composto
- fruitore dei servizi componenti
->
<soggetto-spcoop tipo=’SPC’ nome=’MinisteroErogatore’>
<connettore tipo=’http’ nome=’PdDMinisteroErogatore’>
<property nome=’location’ valore=’http://localhost:8080/openspcoop/PA’ />
</connettore>
<!- Servizio composto ->
<servizio tipo=’SPC’ nome=’Hello’ accordo-servizio=’ASHello’>
<servizio-composto>
<servizio-componente tipo-soggetto=’SPC’ nome-soggetto=’Ministero1’
tipo=’SPC’ nome=’HelloUtente’ />
<servizio-componente tipo-soggetto=’SPC’ nome-soggetto=’Ministero2’
tipo=’SPC’ nome=’TracciaUtente’ />
</servizio-composto>
<fruitore tipo=’SPC’ nome=’MinisteroFruitore’ />
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 109
</servizio>
</soggetto-spcoop>
<!-
Ministero1: erogatore del servizio componente 1
->
<soggetto-spcoop tipo=’SPC’ nome=’Ministero1’>
<connettore tipo=’http’ nome=’PdDMinistero1’>
<property nome=’location’ valore=’http://localhost:9080/openspcoop/PA’ />
</connettore>
<!- Servizio componente 1 ->
<servizio tipo=’SPC’ nome=’HelloUtente’
accordo-servizio=’ASHelloUtente’>
<fruitore tipo=’SPC’ nome=’MinisteroErogatore’ />
</servizio>
</soggetto-spcoop>
<!-
Ministero2: erogatore del servizio componente 2
->
<soggetto-spcoop tipo=’SPC’ nome=’Ministero2’>
<connettore tipo=’http’ nome=’PdDMinistero2’>
<property nome=’location’ valore=’http://localhost:7080/openspcoop/PA’ />
</connettore>
<!- Servizio componente 2 ->
<servizio tipo=’SPC’ nome=’TracciaUtente’
accordo-servizio=’ASTracciaUtente’>
<fruitore tipo=’SPC’ nome=’MinisteroErogatore’ />
</servizio>
</soggetto-spcoop>
In sequenza evidenziamo:
• La configurazione dell’Accordo di Cooperazione. Questa prevede la
specifica di un nome e di una descrizione. L’elemento soggetto-referente
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 110
identifica quale soggetto-spcoop e responsabile per l’orchestrazione
mentre il servizio composto specifica solo un Accordo di Servizio: que-
sto permette l’identificazione dell’erogatore e del fruitore del servizio
composto.
• La configurazione dell’Accordo di Servizio. L’Accordo di Servizio con-
figura il servizio composto identificando il documento WS-BPEL per
l’orchestazione dei servizi e i servizi componenti che partecipano a que-
sta orchestrazione. Ogni servizio componente riferisce un Accordo di
Servizio.
• La configurazione degli Accordi di Servizio associati ad ogni servizio
componente.
• La configurazione dei soggetti coinvolti nell’intera orchestrazione. Ser-
vono quattro soggetti per l’intera operazione:
– Fruitore (MinisteroFruitore), cioe quello che usufruisce dell’intera
operazione.
– Erogatore (MinisteroErogatore), cioe quello che eroga il servizio
composto.
– Due componenti (Ministero1 e Ministero2 ), cioe i soggetti che
erogano i singoli servizi componenti.
La configurazione piu interessante e quella del soggetto erogatore, dal
momento che le altre sono identiche a quelle della versione del Registro
Servizi di OpenSPCoop senza Accordi di Cooperazione. Rispetto ad
un comune soggetto bisogna specificare l’Accordo di Servizio associato,
oltre ai singoli servizi componenti.
• Erogazione/fruizione del servizio
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 111
1. l’organizzazione fruitore MinisteroFruitoreSPCoopIT effettua l’in-
vocazione del servizio interessato semplicemente interagendo at-
traverso la sua porta di dominio
2. il messaggio SOAP viene ricevuto, controllato e viene identificato
il servizio relativo a questa richiesta; conclusa questa operazione
viene preparata una busta eGov e si procede all’invio tramite la
URL letta nel Registro Servizi. La porta di dominio rimane in
attesa della risposta
3. ricevuta la busta eGov, si procede al controllo della busta stessa e
in caso di controlli andati a buon fine si procede con la consegna
del messaggio SOAP all’interno della busta eGov.
4. riconosciuta la modalita di consegna WSDL si procede all’invo-
cazione del Web Service.
(a) L’invocazione del servizio provoca la creazione di un processo
workflow associato al Web Service Hello nell’engine JBPM-
BPEL.
(b) La logica del processo e definita come segue:
– ricevuto il messaggio SOAP si preleva il campo ’nome’.
– si invoca il Web Service HelloUtente che provvede ad ag-
giungere ’Hello’ al ’nome’ ricevuto nella richiesta inoltra-
ta dal processo
– si invoca il Web Service TracciaUtente, con il quale si
traccia la richiesta di questo servizio
– si prepara una risposta SOAP con il contenuto del mes-
saggio del Web Service HelloUtente e lo si invia
– tale risposta viene inviata al client di questo processo,
cioe la porta di dominio stessa e l’istanza di processo
associata a questo Web Service viene distrutta.
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 112
– Si prepara la busta eGov e la si invia alla porta di dominio
che sbloccata conclude la comunicazione.
Figura 7.7: Il caso d’uso Hello in BPEL
Illustriamo per questo caso d’uso il comportamento delle porte di domi-
nio che partecipano all’Accordo di Cooperazione Hello, senza riproporlo per
i casi d’uso che verranno presentati in seguito.
I profili di collaborazione tra tutti i soggetti in gioco sono del tipo request-
response, cioe il mittente contatta il destinatario e rimane in attesa della
risposta. La comunicazione tra tutte le porte di dominio avviene tramite
buste eGov. Mostriamo in sequenza quali azioni scatena lo scambio di buste
eGov, che sono numerate in figura 7.7.
La busta eGov 1 avvia l’Accordo di Servizio relativo a questo Accordo di
Cooperazione. Quando la porta di dominio del soggetto erogatore riceve la
busta eGov ne preleva la busta SOAP e la inoltra al Web Service che fa
da interfaccia al workflow. Questa azione causa la creazione dell’istanza di
processo secondo le modalita gia descritte all’inizio del capitolo. Il processo
deve quindi contattare il servizio HelloUtente attraverso la URL nota nel
suo ServiceCatalog. In questo caso, la porta di dominio viene usata come
proxy SOAP, cioe serve a inviare messaggi SOAP in buste eGov. La busta
eGov 2 arriva alla porta di dominio dov’e disponibile il servizio HelloUtente
che una volta contattato produce la risposta (inviata con la busta eGov 3)
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 113
usando anche questa porta di dominio come proxy SOAP. La busta eGov
3 continua l’avanzamento del workflow che genera un nuovo messaggio in
uscita per il secondo servizio TracciaUtente, imbustato nella eGov 4. La
busta eGov 4, a pari della 2, causa la generazione della risposta del servizio
TracciaUtente che viaggia nella busta eGov 5. La busta eGov 5 conclude le
comunicazioni del workflow con i soggetti per la cooperazione. Il messaggio
finale viene inviato con la busta eGov 6. La busta eGov 6 contiene la rispo-
sta per il soggetto fruitore e comporta la distruzione dell’istanza di processo
all’interno della porta di dominio.
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 114
Figura 7.8: Hello World in OpenSPCoop: Lo scambio delle buste eGov.
7.5.3 Caso d’Uso Transazione
Il caso d’uso Transazione e il primo caso d’uso ad utilizzare due servizi
fondamentali per la realizzazione di una operazione completa. Infatti nell’e-
sempio precedente si poteva notare che il servizio TracciaUtente non svolge
una azione fondamentale al completamento dell’operazione e la sua aggiunta
si deve alla costruzione sintattica dell’Accordo di Cooperazione che prevede
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 115
la presenza di almeno due servizi. Nel caso d’uso Transazione sono necessari
due servizi: il ControlloAutenticazione e il ControlloAutorizzazione. Questo
caso d’uso permette di verificare l’utilizzo di oggetti XML nelle richieste e
nelle risposte durante le comunicazioni con i Web Service. La logica del
ControlloAutenticazione e semplice e intuibile: viene verificata l’esatta cor-
rispondenza di nome utente e password in un apposito file di proprieta. Un
file di proprieta e un file costituito da righe ASCII che rispettano la sintas-
si nomeProprieta = valoreProprieta. Un file fatto in questo modo viene
letto grazie ad una classe di java.util, la classe Properties, che tramite il
metodo load(), provvede a costruire una Map, cioe una tabella hash con
chiavi nomeProprieta e valori valoreProprieta. In caso di verifica corretta
il nome dell’utente viene usato come chiave in un altro file di proprieta per
recuperare l’identificativo associato a questo nome utente. Questo identi-
ficativo costituisce la risposta del servizio chiamato con questa operazione.
Oltre a questa operazione, il servizio dispone anche di metodi per aggiunge-
re, modificare e rimuovere utenti e valori all’interno di questi file.
La logica del Controllo di Autorizzazione e simile a quella del Controllo di
Autenticazione: si verifica la presenza dell’identificativo ricevuto e in caso
di presenza viene ritornata una lista di operazioni che l’utente autenticato
puo invocare. In caso di mancata presenza, la lista ritorna un codice di
identificativoNonTrovato. Cosı come il servizio precedente, anche questo
servizio ha ulteriori operazioni per aggiungere modificare e rimuovere iden-
tificativi e rispettive liste di operazioni autorizzate. Le definizioni dei tipi
degli oggetti XML sono definiti in un file XSD (types.xsd) che viene condi-
viso sia dai WSDL dei Web Service utilizzati dal processo sia dal processo
stesso. Il tipo Credenziali e usato dal ControlloAutenticazione mentre il tipo
EsitoAutorizzazione dal ControlloAutorizzazione.
<xsd:complexType name=’Credenziali’>
<xsd:sequence>
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 116
<xsd:element name=’nome’
type=’xsd:string’></xsd:element>
<xsd:element name=’password’
type=’xsd:string’></xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name=’EsitoAutenticazione’>
<xsd:sequence>
<xsd:element name=’IDUtenteAutenticato’
type=’xsd:string’></xsd:element>
<xsd:element name=’eventualeMotivoErrore’
type=’xsd:string’></xsd:element>
</xsd:sequence>
</xsd:complexType>
I passi da effettuare coinvolgono:
• configurazione: la configurazione e del tutto simile a quella del caso
d’uso Hello, tranne naturalmente per i nomi e le descrizioni dei servizi
utilizzati.
• Erogazione/fruizione del servizio
1. come nel caso d’uso Hello.
2. come nel caso d’uso Hello.
3. come nel caso d’uso Hello.
4. riconosciuta la modalita di consegna WSDL si procede all’invo-
cazione del Web Service.
(a) L’invocazione del servizio provoca la creazione di un processo
workflow associato al Web Service Transazione nell’engine
JBPM-BPEL.
(b) La logica del processo e definita come segue:
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 117
– ricevuto il messaggio SOAP si preleva l’oggetto XML di
tipo Credenziali che diventa parte del messaggio SOAP
in uscita per il servizio ControlloAutenticazione.
– si invoca il Web Service ControlloAutenticazione che prov-
vede a ritornare l’identificativo di questo nome utente in
caso di corretta autenticazione, mentre un messaggio di
errore (’NOK’) e il relativo motivo di errore (es ’Utente
non trovato’ o ’Utente/Password errate’) accompagnano
la risposta per autenticazione incorretta.
– in base alla risposta del punto precedente, il processo
∗ in caso di esito negativo conclude la comunicazione,
preparando la risposta per il client e include la prece-
dente risposta nel messaggio per il client.
∗ in caso positivo si preleva l’identificativo che diventa
parametro del messaggio SOAP in uscita per il servizio
ControlloAutorizzazione.
· si preleva la risposta del servizio, un oggetto XML
EsitoAutorizzazione che diventa parte della risposta
per il client.
· la risposta precedentemente preparata viene inviata
al client di questo processo, cioe la porta di dominio
stessa e l’istanza di processo associata a questo Web
Service viene distrutta.
5. come nel caso d’uso Hello.
In questo caso d’uso non sono stati considerati gli aspetti della sicurezza
relativi a informazioni confidenziali (ad esempio il tipo Credenziali) per-
che non rientra tra gli obiettivi di questo caso d’uso che e invece quello di
mostrare l’utilizzo complesso di tipi XML in un Accordo di Cooperazione.
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 118
7.5.4 Caso d’Uso Sportello
Il caso d’uso Sportello permette di rappresentare in OpenSPCoop e con gli
Accordi di Cooperazione uno tra gli scenari piu comuni nelle organizzazio-
ni con Architetture Orientate ai Servizi. Lo scenario che viene realizzato e
l’aggiornamento di una informazione su una famiglia di servizi con la me-
desima interfaccia. Per mostrare come sia comune un servizio del genere in
una organizzazione, specie se appartenente alla Pubblica Amministrazione,
mostriamo un esempio.
Un utente ha cambiato residenza e quindi decide di informare l’Ufficio del-
l’Anagrafe al fine di aggiornare questa informazione. L’utente quindi si pre-
sentera allo Sportello con un documento di identificazione (carta d’identita)
e i documenti che attestano il cambio di residenza (es. contratto d’acquisto
dell’immobile). In assenza di un mezzo di coordinazione tra gli uffici del-
lo stesso comune, l’utente dovrebbe recarsi in tutti gli uffici per i quali e
necessario il suo indirizzo di residenza, ad esempio l’Ufficio delle Imposte e
altri uffici che regolano erogazioni di servizi della vita di tutti i giorni per
quell’utente, come ad esempio la corrente elettrica, l’acqua corrente ecc...
In presenza di uno strumento unificato di aggiornamento per il cambio di
residenza, l’utente deve solo recarsi all’Ufficio dell’Anagrafe per cambiare in
un solo passo la residenza presso tutti gli uffici convenzionati. Risulta ovvio
come un tale esempio sia estendibile ad una vasta gamma di scenari molto
vicini alla vita di tutti i giorni.
Il comportamento di base dell’engine JBPM-BPEL permette l’invocazione
dei servizi offerti secondo l’utilizzo di un Service Catalog: con questo si in-
tende un file XML con le URL dei servizi da invocare. Come gia descritto
nella sezione 7.4.4 (indirizzamento dinamico dei servizi), all’atto di una invo-
ke in BPEL, il processo utilizza tale file per cercare tra gli URL noti il primo
che implementa il servizio che sta per invocare. E’ chiaro come una imple-
mentazione fatta in questo modo sia scomoda per invocare diversi servizi
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 119
con una stessa interfaccia. I problemi che si incontrano sono i seguenti:
• imposizione della conoscenza statica degli indirizzi di tutti i servizi.
Sebbene questo non sia un vincolo progettuale difficoltoso, questo ap-
proccio di fatto richiede manipolazioni del file Service Catalog diretta
per gestire l’iterazione e non permette in maniera semplice di realizzare
un aggiornamento parallelo delle interfacce interessate.
• imposizione della conoscenza di tutte le casistiche. Potrebbe accadere
che un dato utente non debba aggiornare le sue informazioni per tut-
te le interfacce note ma solo per quelle per cui e registrato. Questo
impone di fatto di conoscere fra tutte le URL dei servizi possibili quel-
le da utilizzare realmente per l’utente che chiede tale aggiornamento.
Generalizzare una logica per tutti gli utenti sarebbe proponibile ma
risulterebbe complicata da realizzare direttamente in codice BPEL.
L’implementazione proposta e piu flessibile perche aperta alla conoscenza
dinamica delle URL e degli utenti, e utilizza una variabile di tipo Endpoin-
tReference con la quale e possibile memorizzare le informazioni circa la parte
concreta di un Web Service, cioe i suoi elementi Service e l’indirizzo SOAP.
<wsa:EndpointReference>
<wsa:Address>wsa:AttributedURI</Address>
<wsa:ReferenceProperties>
wsa:ReferencePropertiesType</ReferenceProperties>
<wsa:ServiceName PortName=’xs:NCName’>
wsa:ServiceNameType</ServiceName>
<wsa:PortType>wsa:AttributedQName</PortType>
</wsa:EndpointReference>
E’ possibile assegnare una variabile EndpointReference a un variabile
partnerLink: un partnerLink memorizza la parte astratta (portType) di un
servizio a tempo di design e le informazioni per contattare quel servizio a
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 120
tempo d’esecuzione. Mentre la parte astratta non e logicamente modificabi-
le, la parte relativa all’indirizzo lo e. Nell’implementazione del partnerLink
nell’engine infatti le informazioni relative al servizio vengono lette solo al
momento della invoke in quanto necessarie a creare il client SOAP per il
processo.
I servizi coinvolti in questo caso d’uso sono lo SportelloServizi e una lista
di servizi di tipo GenericoServizio non nota a tempo di design. Lo Spor-
telloServizi riceve in input il nome di una operazione e controlla un file di
proprieta (vedi caso d’uso Transazione) alla ricerca di una entry per il nome
dell’operazione. Se tale operazione e presente allora viene ritornata la lista
degli indirizzi da contattare per quella operazione. Gli indirizzi apparten-
gono a servizi di tipo GenericoServizio. Il GenericoServizio aggiorna il suo
file di proprieta per il nome utente con l’informazione ricevuta. Il risultato
dell’invocazione del servizio con l’operazione di aggiornamento produce un
esito (es. ’Utente Mario Rossi ha aggiornato le sue informazioni con via
Spade 3’).
I passi da effettuare coinvolgono:
• configurazione:
– come nel caso d’uso Hello
– configurazione del dominio MinisteroErogatoreSPCoopIT nella
porta di dominio OpenSPCoop: registrazione di una porta ap-
plicativa per il servizio SPC/Sportello
– configurazione del dominio MinisteroFruitoreSPCoopIT nella por-
ta di dominio OpenSPCoop: registrazione della porta delega-
ta utilizzata dal soggetto SPC/MinisteroFruitore per invocare il
servizio SPC/Sportello.
I servizi di tipo GenericoServizio che verranno invocati non vengono
configurati nel Registro Servizi. In questo caso la porta di dominio viene
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 121
usato come SOAP Proxy usando la modalita trasparente di integrazione.
• erogazione/fruizione del servizio
1. come nel caso d’uso Hello.
2. come nel caso d’uso Hello.
3. come nel caso d’uso Hello.
4. riconosciuta la modalita di consegna WSDL si procede all’invo-
cazione del Web Service.
(a) L’invocazione del servizio provoca la creazione di un proces-
so workflow associato al Web Service Sportello nell’engine
JBPM-BPEL.
(b) La logica del processo e definita come segue:
– ricevuto il messaggio SOAP si preleva il campo operazio-
ne e si prepara il messaggio SOAP in uscita per il servizio
SportelloServizi.
– si invoca il Web Service SportelloServizi che provvede a
ritornare la lista delle URL dei servizi, mentre un mes-
saggio di errore (′NO URL′) identifica la situazione ec-
cezionale di ’nessuna URL per quella operazione’.
– in base alla risposta del punto precedente, il processo
∗ in caso di esito negativo conclude la comunicazione,
preparando la risposta per il client e include la prece-
dente risposta nel messaggio per il client.
∗ in caso positivo si prelevano le URL. Per ogni URL
· si preleva la stringa i-esima e si inizializza una va-
riabile EndpointReference.
· si assegna la variabile al partnerlink per il Generico-
Servizio
CAPITOLO 7. IMPLEMENTAZIONE DEI CASI D’USO 122
· si memorizza la risposta del servizio
∗ al termine del while si prepara una risposta per il client
di questo processo, cioe la porta di dominio stessa e
l’istanza di processo associata a questo Web Service
viene distrutta.
5. come nel caso d’uso Hello.
Capitolo 8
Conclusioni e sviluppi futuri
In questa tesi e stato presentato il processo tramite il quale e stato perseguito
l’obiettivo di progettare l’Accordo di Cooperazione secondo le specifiche del
CNIPA per OpenSPCoop e la relativa implementazione nel registro Servizi
di OpenSPCoop oltre ai casi d’uso che potessero dimostrare le reali poten-
zialita di questo nuovo elemento.
Passare dalle specifiche del CNIPA alla realizzazione dell’Accordo di Coope-
razione in OpenSPCoop ha richiesto uno studio approfondito del Registro
Servizi e un principale studio di fattibilita dell’obiettivo prefisso. Conclusa
questa prima fase l’attenzione si e concentrata sulla ricerca di un engine per
processi produttivi. Sia la nuova tecnologia che la programmazione orien-
tata agli oggetti hanno richiesto uno studio abbastanza approfondito e non
sempre facile a causa di una documentazione spesso poco chiara, frammen-
taria e soprattutto incompleta. La stessa realizzazione dei casi d’uso iniziali
e stata per questi motivi parecchio difficoltosa.
Durante questo lavoro di tesi e stata realizzata una documentazione piu det-
tagliata e un tutorial di base messi a disposizione della stessa comunita di
sviluppatori in JBPM-BPEL. L’indirizzo di tale documentazione e disponi-
bile in bibliografia [NB]. Lo sviluppo dei casi d’uso e stato reso anche piu
difficoltoso per la mancanza di strumenti per realizzare le logiche di orche-
123
CAPITOLO 8. CONCLUSIONI E SVILUPPI FUTURI 124
strazione in maniera grafica. Le interfacce grafiche che si trovano in rete cosı
come quelle indicate dagli sviluppatori dell’engine stesso presentano lacune
che hanno imposto una stesura manuale di tutto il codice di orchestrazione
realizzato, prolungandone i tempi necessari. Per rendere quindi utilizzabile
in maniera piu facile l’Accordo di Cooperazione si suggerisce l’implementa-
zione di una interfaccia grafica che renda possibile realizzare workflow con
pochi click. Una feature interessante di questa applicazione e senza dubbio
un analizzatore di tipi XML per velocizzare le operazioni che coinvolgono
query XPath.
Bibliografia
[AP] Andrea Poli, OpenSPCoop: un’implementazione della Specifi-
ca di Cooperazione Applicativa per la Pubblica Amministra-
zione Italiana,
Tesi di Laurea Specialistica in Tecnologie Informatiche,
Universita di Pisa, Febbraio 2006.
[BPEL] Business Process Execution Language for Web Services version
1.1
http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-
OS.html
[CN1] SPC, ’Sistema pubblico di cooperazione: Architettura, Ver-
sione 1.0’, CNIPA, 25 Novembre 2004.
http://www.cnipa.gov.it/site/ files/SPCoop-
Architettura v1.0 20041125 .pdf
[CN2] SPC, ’Sistema pubblico di cooperazione: Porta di Dominio,
Versione 1.0’,CNIPA, 14 Ottobre 2005
http://www.cnipa.gov.it/site/ files/SPCoop-
PortaDominio v1.0 20051014.pdf
[CN3] SPC, ’Specifiche della Busta di e-Government, Edizione 1.0’,
CNIPA, 21 Aprile 2004
125
BIBLIOGRAFIA 126
http://www.cnipa.gov.it/site/ files/SPC Bustae-Gov v.1 0-
21-04-2004.pdf
[CN4] SPC, ’Sistema pubblico di cooperazione: Busta di e-Gov,
Versione 1.1’,CNIPA, 14 Ottobre 2005
http://www.cnipa.gov.it/site/ files/SPCoop-Busta e-
Gov v1.1 20051014.pdf
[CN5] SPC, ’Sistema pubblico di cooperazione: Accordo di Servizio,
Versione 1.0’ CNIPA, 14 Ottobre 2005
http://www.cnipa.gov.it/site/ files/SPCoop-
AccordoServizio v1.0 20051014.pdf
[CN6] SPC, ’Sistema pubblico di cooperazione: Servizi di Registro,
Versione 1.0’, CNIPA, 14 Ottobre 2005
http://www.cnipa.gov.it/site/ files/SPCoop-
ServiziRegistro v1.0 20051014.pdf
[CNIPA] Sistema Pubblico di Connettivita (SPC)
http://www.cnipa.gov.it/site/it-
it/In primo piano/Sistema Pubblico di Connettivita (SPC)
[EJB] Enterprise JavaBeans Technology
http://java.sun.com/products/ejb/
[INFOSET] XML Information Set (Second Edition)
http://www.w3.org/TR/xml-infoset/
[JBoss] JBoss Application Server
http://www.JBoss.org/elqNow/elqRedir.htm?ref=/pdf/JBossASBrochure-
Mar2006.pdf
[JBPM] JBoss.com - JBoss JBPM
http://labs.JBoss.com/JBossjbpm/docs/index.html
BIBLIOGRAFIA 127
[JBPM-BPEL] JBoss: JBPM BPEL extension 1.1 beta 3
http://docs.JBoss.com/jbpm/bpel/introduction.html
[NB] Developing Netbeans BPEL process with jbpm-bpel
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4084745
[NS] Namespaces in XML 1.0 (Second Edition)
http://www.w3.org/TR/REC-xml-names/
[OPENSPCOOP] OpenSPCoop - Implementazione Open Source della Spe-
cifica SPCoop
http://www.openspcoop.org
[R12] Il progetto CART, Regione Toscana
http://www.rete.toscana.it/etoscana/eprog cart.php
[R13] Il progetto SOLE, Regione Emilia Romagna
http://www.progetto-sole.it
[RB] Ruggero Barsacchi, Progettazione di un framework Open Sour-
ce per la
cooperazione applicativa per la Pubblica Amministrazione Ita-
liana, Tesi di Laurea Specialistica in Tecnologie
Informatiche, Universita di Pisa, 2005.
[SCHEMA] XML Schema
http://www.w3.org/XML/Schema
[SOAP] SOAP Specifications
http://www.w3.org/TR/soap
[SPC] Sistema Pubblico di Connettivita
http://www.cnipa.gov.it/site/ files/5.SPC,Architettura%20SPC,Q,3.0.pdf
BIBLIOGRAFIA 128
[SPCOOP] CNIPA: Servizi di interoperabilita evoluta e cooperazione
applicativa
http://www.openspcoop.org/openspcoop/jsp/index.jsp?sel=spcoop
[w3cArch] Web Service Architecture
http://www.w3.org/TR/ws-arch/
[WF] Windows Workflow Foundation
http://msdn2.microsoft.com/en-
us/netframework/aa663328.aspx
[XML] Extensible Markup Language (XML)
http://www.w3.org/XML/
[YAWL] YAWL: Yet Another Workflow Language
http://www.yawl-system.com