Implementazione di un linguaggio di base per servizi web

Università degli Studi di Firenze
FACOLTÀ DI SCIENZE MATEMATICHE, FISICHE E NATURALI
Relatore:
Prof. Rosario Pugliese
Correlatore:
Dott. Francesco Tiezzi
Tesi di Laurea in Informatica
Implementazione di un
linguaggio di base
per servizi web
Anno Accademico 2008/2009
Candidato:
Leonardo Nuti

Ai miei genitori,
ai miei amici
e a Eleonora.

Indice
1 Introduzione 11
2 Supporti per la realizzazione di servizi web 15
2.1 Piattaforma per l’esecuzione dei servizi . . . . . . . . . . . . . . . . . . 15
2.1.1 Definizione di servizio web . . . . . . . . . . . . . . . . . . . . . 16
2.1.2 Modello dei sevizi web . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.3 Architettura dei servizi web . . . . . . . . . . . . . . . . . . . . 19
2.2 SOAP, WSDL e WS-BPEL . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.1 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.2 WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.3 WS-BPEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3 JAX-WS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3 Il linguaggio COWSlite 35
3.1 Il calcolo di processi COWS . . . . . . . . . . . . . . . . . . . . . . . . 36
3.1.1 µCOWS m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.1.2 Esempi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2 Descrizione di COWSlite . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2.1 Sintassi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2.2 Tipi di dato e vettori di variabili write-once . . . . . . . . . . . 48
3.2.3 Regole di matching . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.2.4 Semantica e differenze con µCOWS m . . . . . . . . . . . . . . 50
5

INDICE
3.3 Esempi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4 Implementazione di COWSlite 59
4.1 Obiettivi e scelte implementative . . . . . . . . . . . . . . . . . . . . . 59
4.2 Un servizio COWSlite in Java . . . . . . . . . . . . . . . . . . . . . . 61
4.3 Il package cowslite.engine . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.3.1 L’unità di comunicazione . . . . . . . . . . . . . . . . . . . . . 66
4.3.2 Descrittori di servizio web e variabili
(WsDescriptor e PartnerLink) . . . . . . . . . . . . . . . . . . . 71
4.3.3 Descrizione del servizio COWSlite . . . . . . . . . . . . . . . 76
4.3.4 Spazio dei servizi . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.4 Generazione del compilatore . . . . . . . . . . . . . . . . . . . . . . . . 85
4.4.1 Componenti di SableCC . . . . . . . . . . . . . . . . . . . . . . 88
4.4.2 Generazione del codice . . . . . . . . . . . . . . . . . . . . . . . 90
5 Uso di COWSlite 99
5.1 Compilatore COWSlite . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.1.1 Script per automatizzare la compilazione e la build . . . . . . . 102
5.1.2 Utility di supporto . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.2 Note sul compilatore . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.2.1 Linguaggio accettato dal compilatore . . . . . . . . . . . . . . . 105
5.2.2 Linee guida per la scrittura e la compilazione dei file COWSlite106
5.3 Caso di studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6 Conclusioni 117
A Grammatica 121
A.1 Grammatica COWSlite per SableCC . . . . . . . . . . . . . . . . . . 121
B Deploy su application server 127
Bibliografia 131
6

Elenco delle tabelle
2.1 Struttura di un processo WS-BPEL . . . . . . . . . . . . . . . . . . . 29
3.1 Sintassi di COWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2 Sintassi di µCOWS m . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3 Congruenza strutturale di µCOWS m . . . . . . . . . . . . . . . . . . . 39
3.4 Regole di matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.5 Semantica operazionale di µCOWS m . . . . . . . . . . . . . . . . . . . 40
3.6 Sintassi di COWSlite . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.1 Codice di un servizio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.2 Web Service Proxy con JAX-WS . . . . . . . . . . . . . . . . . . . . . 70
4.3 Web Service - Messaggio SOAP . . . . . . . . . . . . . . . . . . . . . . 71
4.4 Costruttori della classe WOVar . . . . . . . . . . . . . . . . . . . 74
4.5 Classe CowsProcess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.6 Receive - ?(partner,operation,).continuazione . . . . . . . . . . 82
4.7 Invoke - !(partner,operation,) . . . . . . . . . . . . . . . . . . . 82
4.8 Delimitation - [x1,...,xn]p . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.9 Replication - *[n](p) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.10 Parallel - |(p1,p2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.11 Choice - +(p1,p2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.12 Assign - x:=exp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.13 Esempio di codice generato per la logica del servizio . . . . . . . . . . 95
7

8
ELENCO DELLE TABELLE
4.14 Esempio di codice generato per la scelta condizionata . . . . . . . . . . 97
5.1 Messaggio di errore del compilatore . . . . . . . . . . . . . . . . . . . . 101
5.2 Messaggio di errore exec . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.3 Messaggio di errore makeXmlStub . . . . . . . . . . . . . . . . . . . . 105
5.4 File COWSlite da compilare . . . . . . . . . . . . . . . . . . . . . . . 108

Elenco delle figure
2.1 Ruoli, Attività e Artefatti nelle architetture orientate ai servizi . . . . 17
2.2 Pila dei servizi web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3 Messaggi XML in SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4 Descrizione di un servizio . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.5 Processo WS-BPEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1 Struttura del progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2 Compilazione di un servizio COWSlite . . . . . . . . . . . . . . . . . 62
4.3 Architettura dell’engine . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.4 Classi del sottosistema di comunicazione . . . . . . . . . . . . . . . . . 68
4.5 Diagramma delle classi delle variabili WO . . . . . . . . . . . . . . . . 72
4.6 Diagramma delle classi dei processi COWSlite . . . . . . . . . . . . . 78
4.7 AST generato per l’espressione (45 + 36/2) ∗ 3 + 5 ∗ 2 . . . . . . . . . . 86
4.8 Albero AST per il costrutto Parallel . . . . . . . . . . . . . . . . . . . 94
4.9 Albero AST per il costrutto Choice . . . . . . . . . . . . . . . . . . . . 96
5.1 Test dell’operazione con Sun Applicatioin Server . . . . . . . . . . . . 116
B.1 Pagina di amministrazione dell’application server . . . . . . . . . . . . 128
B.2 Pagina di amministrazione dei servizi in esecuzione . . . . . . . . . . . 129
9

10
ELENCO DELLE FIGURE

Capitolo 1
Introduzione
In questi ultimi anni il ruolo dell’Information Technology (IT) all’interno delle azien-
de si è spesso orientato verso problematiche di integrazione e fornitura di servizi.
Acronimi come SOA e SOC sono ormai divenuti parole di uso comune. SOA (Servi-
ce Oriented Architecture) sta ad indicare un paradigma architetturale per i sistemi
aziendali, mentre SOC (Service Oriented Computing) individua un paradigma utiliz-
zato per la progettazione di sistemi enterprise. Anche se ultimamente l’espressione
SOA sta lasciando il posto a SOC, essi indicano uno stesso scopo, costruire siste-
mi che siano debolmente accoppiati, interoperabili, ad elevata scalabilità, sfruttando
il più possibile tecnologie già esistenti all’interno degli standard aziendali. L’uso di
questi paradigmi permette di mantenere in funzione tutti quei sistemi che, sebbene
siano costruiti con tecnologie un po’ datate, hanno ormai passato tutti i test ‘sul
campo’ e possono essere considerati ‘maturi’, integrandoli ed estendendoli con nuove
funzionalità sfruttando tecnologie più recenti.
All’interno di tutto ciò i servizi web sono fra le applicazioni che meglio interpretano
questa filosofia. La loro diffusione e il supporto da parte della stragrande maggioranza
dei linguaggi esistenti, permette di creare applicazioni complete. Uno dei punti di forza
dei servizi web è la composizionalità, cioè la capacità di comporre servizi semplici per
crearne di più complessi. Questa capacità ha fatto si che si sviluppassero dei linguaggi
che hanno fra le loro caratteristiche principali diversi costrutti per l’orchestrazione di
11

CAPITOLO 1 Introduzione
servizi web, cioè di poter aggregare servizi web descrivendo il flusso di esecuzione e le
interazioni fra i servizi stessi; fra questi linguaggi uno dei più noti è WS-BPEL.
Tutti i linguaggi di programmazione, a partire da C, C++, Java, fino a WS-BPEL
non permettono di verificare o specificare proprietà sul codice prodotto, non è ad
esempio possibile fare verifiche su proprietà relative ai servizi concorrenti (liveness,
deadlock, ecc.), sulla corretta gestione delle risorse o sui servizi stessi (affidabilità,
disponibilità, responsività, ecc.). Per poter provare ad analizzare tali proprietà diversi
sistemi formali sono stati proposti quali i calcoli di processo (ad es. CCS [29] e
π-calcolo [30]).
Vari calcoli di processo sono stati recentemente progettati con l’intento di studiare
e valutare diverse combinazioni di primitive per il SOC. Tra questi solo per citarne
alcuni troviamo COWS[25], SOCK [18], SCC [9] e CaSPiS [7].
COWS è un linguaggio che, ispirandosi a WS-BPEL da un punto di vista fun-
zionale, presenta tutte le caratteristiche di base per modellare servizi web racchiuse
in un calcolo di processi che, con la sua definizione formale, permette anche la verifica
di proprietà.
Vari strumenti sono stati sviluppati per investigare le specifiche di COWS, come
le estensioni stocastiche definite in [37] che permettono ragionamenti quantitativi sul
comportamento dei servizi, il sistema di tipi introdotto in [26] per controllare proprietà
di confidenzialità e la logica e il model checker presentati in [14] per esprimere e testare
proprietà funzionali dei servizi.
Lo scopo di questa tesi sarà quello di introdurre un linguaggio di programmazione
per servizi web e di realizzarne il compilatore. Il linguaggio sarà progettato partendo
da COWS e cercando di scrivere la grammatica in modo da accettare istruzioni che
siano il più possibile somiglianti ai termini COWS. Il compilatore dovrà generare un
codice intermedio che sia compilabile ed eseguibile su una piattaforma esistente per
servizi web senza dover installare altro software.
Per fare ciò partiremo col descrivere quelle che sono le tecnologie di base che
costituiscono l’architettura dei servizi web [19], su cui dovremo appoggiarci per poter
12

ealizzare il compilatore del linguaggio, introducendo un po’ di concetti sui servizi web
e analizzando i protocolli necessari per il trasporto dei messaggi, per la descrizione
e pubblicazione dei servizi e i pacchetti necessari per sviluppare il software; daremo
anche uno sguardo a WS-BPEL che è tra i linguaggi di specifica attualmente più
utilizzati e che ha ispirato il linguaggio formale dal quale abbiamo preso spunto.
In seguito descriveremo COWS ponendo l’attenzione su µCOWS m , il frammento
che si avvicina di più a COWSlite, il linguaggio proposto nel presente lavoro, e li
metteremo a confronto.
Descriveremo infine il processo di progettazione e realizzazione del compilatore e
del supporto per l’esecuzione del linguaggio in questione concludendo con degli esempi
di uso del software realizzato.
Il CD allegato a questa tesi contiene il software sviluppato, i file sorgenti e i file
di installazione dell’ambiente di sviluppo e di alcuni application server usati nei test.
13

14
CAPITOLO 1 Introduzione

Capitolo 2
Supporti per la realizzazione di
servizi web
In questo capitolo descriveremo cosa si intende con il termine servizio web e analizze-
remo alcune delle tecnologie che stanno alla base della costruzione e del funzionamento
di un servizio web. Introdurremo anche un linguaggio per lo sviluppo di servizi in
ambiente SOA dal quale COWS ha preso spunto. Concluderemo il capitolo con un
breve panoramica di JAX-WS, l’API di SUN per la costruzione e l’interrogazione di
servizi web.
2.1 Piattaforma per l’esecuzione dei servizi
I servizi web permettono di costruire un architettura tale da consentire l’integrazione
di software e l’accesso a sistemi proprietari in maniera semplice. Questo fa si che
possano essere mantenuti in funzione i vecchi sistemi informativi aziendali facendoli
colloquiare con moduli di nuova concezione. Di conseguenza i costi per la produzione
e la messa in opera di nuove funzionalità e servizi sono ridotti.
15

CAPITOLO 2 Supporti per la realizzazione di servizi web
2.1.1 Definizione di servizio web
Un servizio web (web service) è una collezione di funzionalità, dette operazioni, ac-
cessibili via rete che possono essere utilizzate e richieste attraverso messaggi XML
standard. L’interfaccia di un servizio web è descritta usando WSDL [12], una no-
tazione basata su XML alla quale ci si riferisce generalmente come descrizione del
servizio. Questa descrizione copre tutti i dettagli necessari a interagire con il servizio,
incluso il formato dei messaggi, il protocollo di comunicazione e la locazione. Una ca-
ratteristica dell’interfaccia è quella di nascondere i dettagli dell’implementazione del
servizio, rendendone possibile l’uso indipendentemente dalla piattaforma hardware o
software utilizzata. Questo fa si che le applicazioni basate su servizi web siano debol-
mente accoppiate (losely-coupled), orientate ai componenti e implementate sfruttando
tecnologie differenti (cross-technology). I servizi web possono eseguire un compito spe-
cifico oppure un insieme di compiti; possono altresí essere usati in congiunzione ad
altri servizi web per svolgere compiti complessi o operazioni transazionali (ad esempio
economico-finanziarie).
2.1.2 Modello dei sevizi web
Il modello dei servizi web individua tre ruoli differenti che interagiscono fra loro: for-
nitore del servizio (service provider), registro dei servizi (server registry) e richiedente
dei servizi (service requestor). L’interazione si concretizza in tre attività: pubblica-
zione, ricerca e utilizzo. I ruoli e le attività agiscono insieme sugli artefatti del servizio
web, cioè il modulo software del servizio web e la sua descrizione, come descritto in
Figura 2.1.
In un tipico scenario, un fornitore di servizi ospita un modulo software accessibile
attraverso la rete (l’implementazione del servizio web). Il fornitore del servizio pro-
duce la descrizione del servizio e la pubblica ad un richiedente o ad un registro. Il
richiedente utilizza una operazione di ricerca per recuperare la descrizione del servizio
localmente oppure dal registro dei servizi, usa questa descrizione per collegarsi col
fornitore del servizio, infine invoca o interagisce con l’implementazione del servizio
16

2.1 Piattaforma per l’esecuzione dei servizi
Figura 2.1: Ruoli, Attività e Artefatti nelle architetture orientate ai servizi
web. I ruoli di fornitore e richiedente sono costrutti logici e un servizio può esibire
caratteristiche di entrambi i ruoli.
Ruoli
I ruoli definiti in un modello orientato ai servizi possono essere visti da due prospet-
tive diverse in funzione della logica del servizio (business logic) oppure in relazione
all’architettura.
Fornitore del servizio Da una prospettiva di business è il proprietario del servizio,
mentre da una prospettiva architetturale è la piattaforma che ospita l’accesso
al servizio.
Richiedente del servizio Dalla prospettiva di business sono le attività che richie-
dono che siano soddisfatte determinate funzioni. Da una prospettiva architet-
turale è l’applicazione che si prepara a invocare o iniziare un’interazione con un
17

CAPITOLO 2 Supporti per la realizzazione di servizi web
servizio. Questo ruolo può essere interpretato da un browser utilizzato da una
persona oppure da un programma senza interfaccia utente.
Registro dei servizi Da una prospettiva di business è un elenco di servizi disponi-
bili all’interno della rete. È un registro di descrizioni di servizi ricercabili in cui
i fornitori del servizio pubblicano le descrizioni dei loro servizi. I richiedenti del
servizio cercano dei servizi e ottengono le informazioni per il collegamento; tale
collegamento può essere definito in modo statico durante lo sviluppo oppure di-
namicamente durante l’esecuzione. Nel caso di servizi collegati staticamente, il
ruolo di registro dei servizi è opzionale, in quanto il fornitore può inviare diret-
tamente i dati al richiedente. Un richiedente potrebbe ricevere tali informazioni
anche in altro modo, ad esempio da un file locale, da un sito FTP, da un sito
Web, o tramite altri servizi di discovery tipo Advertisement and Discovery of
Service (ADS) [33] o Discovery of Web Service (DISCO) [38] di Microsoft.
Artefatti di un servizio web
Dalla Figura 2.1 si nota che gli artefatti sono:
Servizio Un servizio è un modulo software in esecuzione su una piattaforma accessi-
bile tramite la rete e fornito da un fornitore di servizi. Esiste per essere invocato
o interagire con un richiedente di servizi. Può funzionare anche da richiedente
usando altri servizi web nella sua implementazione.
Descrizione del servizio La descrizione del servizio contiene i dettagli dell’inter-
18
faccia e dell’implementazione del servizio. Questa include i tipi di dati, le
operazioni, le informazioni di collegamento e la localizzazione sulla rete. Può
anche contenere altri metadati per facilitare la ricerca e l’utilizzo da parte del
richiedente. Può essere pubblicata dal fornitore o dal registro.

2.1 Piattaforma per l’esecuzione dei servizi
2.1.3 Architettura dei servizi web
Possiamo pensare concettualmente l’architettura con cui costruire i servizi web come
se fosse organizzata per strati; ogni strato fornisce determinate funzionalità ed è
implementato mediante specifiche tecnologie. Questo viene denominato pila dei servizi
web (Web Service Stack).
Pila dei servizi web
Per eseguire le tre operazioni di pubblicazione, ricerca e utilizzo in modo interoperabile
ci deve essere una pila di servizi web che utilizza tecnologie standard ad ogni livello.
La Figura 2.2 mostra concettualmente le tecnologie legate ai servizi web organiz-
zate come una pila. Gli strati superiori sono sviluppati sfruttando le capacità fornite
dagli strati inferiori. I livelli più bassi della pila che descrive i servizi web sono re-
lativamente più maturi e standardizzati rispetto agli altri strati. Le barre verticali
rappresentano i requisiti che devono essere affrontati a tutti i livelli della pila. Il testo
a sinistra indica le tecnologie standard applicabili ad ogni livello della pila.
Le fondamenta su cui poggiano i componenti della pila dei servizi web è la rete.
I servizi web devono essere accessibili in rete per poter essere invocati da un richie-
dente. Perché ciò sia possibile è necessario sfruttare i protocolli di rete comunemente
impiegati. A causa della sua ubiquità, HTTP è lo standard di fatto fra i protocolli di
rete per i servizi web disponibili su Internet. Altri protocolli Internet sono comunque
supportati, ad es. SMTP e FTP. Oppure nei domini intranet è possibile utilizzare
infrastrutture per la messaggistica affidabile e le chiamate come MQSeries, CORBA
e altre.
Lo strato successivo (XML-Based Messaging) evidenzia l’uso del linguaggio XML
come base per il protocollo di messaggistica. La scelta di SOAP per questo scopo è
principalmente dovuta ai seguenti motivi:
• È il meccanismo di incapsulamento standardizzato per la comunicazione
document-centric di messaggi e chiamate di procedura remota eseguita tramite
il linguaggio XML.
19

CAPITOLO 2 Supporti per la realizzazione di servizi web
Figura 2.2: Pila dei servizi web
• È semplice, perché si appoggia alla funzionalità HTTP POST con un contenitore
di dati XML nel payload.
• È preferibile usare un meccanismo semplice per inviare messaggi XML come
l’HTTP POST in quanto definisce un meccanismo standard ortogonale per
includere le estensioni nel messaggio usando un header SOAP e una codifica
standard per l’operazione o la funzione.
• Supporta le attività definite per l’architettura dei servizi web (pubblicazione,
ricerca ed utilizzo).
Il livello di servizio è costituito da un insieme di documenti di descrizione. Tra
questi documenti uno dei più importanti è il WSDL, lo standard attuale per la descri-
zione dei servizi basati su XML che permette l’interoperabilità sul web. Il documento
WSDL definisce l’interfaccia ed i meccanismi di interazione di un servizio. Può es-
20

2.1 Piattaforma per l’esecuzione dei servizi
sere integrato da altri documenti per descrivere aspetti di livello più elevato come il
contesto di business, la qualità del servizio e le relazioni fra i servizi. Ad esempio il
contesto di business può essere descritto utilizzando i dati forniti da UDDI (Universal
Description Discovery and Integration) [34] in aggiunta ai documenti WSDL, la com-
posizione e il flusso del servizio possono essere descritti per mezzo di un documento
WSFL (Web Services Flow Language) [28] oppure WS-BPEL.
I primi tre strati di questa pila sono necessari per fornire o utilizzare qualsiasi
servizio web. Questo implica che la configurazione di base della pila per l’interopera-
bilità, sia per servizi web pubblici che privati, sia formata dai protocolli HTTP per il
livello di rete, SOAP per il livello di messaggistica XML e da WSDL per il livello di
descrizione del servizio.
Questo però non impedisce che altri servizi intranet o privati supportino altri
protocolli di rete o tecnologie di calcolo distribuito.
La pila raffigurata in Figura 2.2 fornisce l’interoperabilità e permette ai servizi
web di sfruttare l’infrastruttura Internet già esistente. Le richieste di interoperabilità
non compromettono comunque la flessibilità del sistema, perché è comunque possibile
supportare tecnologie alternative e a valore aggiunto. Ad esempio, oltre a SOAP
over HTTP, è possibile supportare anche SOAP over MQ senza particolari sforzi
implementativi.
Qualsiasi azione che mette a disposizione un documento WSDL ad un servizio
richiedente in qualunque fase del ciclo di vita del servizio richiedente è chiamato ser-
vizio di pubblicazione. A questo livello, l’esempio più semplice per la fornitura statica
di servizi è l’invio di un documento WSDL direttamente ad un servizio richiedente;
tale operazione viene chiamata pubblicazione diretta. Questa è spesso utilizzata per
applicazioni a collegamento statico. In alternativa, il fornitore di servizi è in grado
di pubblicare il documento WSDL che descrive il servizio in un registro di documenti
WSDL sull’host locale, in un registro privato UDDI o in un nodo operatore UDDI.
Dal momento che l’implementazione di un servizio web è un modulo software, è
naturale produrre servizi web mediante la loro composizione. Tale composizione fa
21

CAPITOLO 2 Supporti per la realizzazione di servizi web
si che un servizio web svolga contemporaneamente più ruoli. I servizi web di una
intranet possono collaborare fra loro e presentare come interfaccia pubblica quella di
un unico servizio web, oppure servizi di differenti imprese possono collaborare per
eseguire operazioni macchina-macchina o business-business. Potrebbe anche esistere
un gestore di workflow che si prende carico di chiamare altri servizi web partecipando
al processo aziendale. Il livello più alto dello stack descrive come devono avvenire
le comunicazioni fra servizi, come essi devono collaborare e come vengono eseguiti i
flussi. Per descrivere queste interazioni possono essere usati linguaggi come WSFL o
WS-BPEL.
2.2 SOAP, WSDL e WS-BPEL
Fra tutte le tecnologie che possono essere utilizzate per implementare i vari strati
all’interno della pila dei servizi web è interessante soffermarsi su quelli che occupano i
livelli inferiori, che sono quelli che considereremo per gli scopi di questa tesi. Questa
scelta è stata fatta in quanto ormai sono implementati con standard consolidati ed al
tempo stesso supportati dalla maggior parte dei produttori di software. Tralasceremo
la descrizione dello strato di rete, ed in particolare di HTTP, perché basato su standard
affermati ormai da tantissimo tempo. Inseriremo in questa carrellata anche WS-
BPEL, che si posiziona invece nello strato più alto della pila, in quanto tecnologia
che implementa la gestione del flusso operativo di un servizio e perché da esso trae
ispirazione COWS.
2.2.1 SOAP
La parte fondamentale su cui poggia l’architettura dei servizi web è la messaggistica
XML. Lo standard attuale di settore per la messaggistica XML è SOAP [31].
SOAP è un protocollo semplice e leggero per lo scambio di dati strutturati tra
applicazioni in rete. Un messaggio SOAP si compone di tre parti: un involucro che
definisce una sezione nella quale inserire la descrizione di ciò che c’è in un messaggio,
22

2.2 SOAP, WSDL e WS-BPEL
una serie di regole di codifica per esprimere istanze di tipi di dati definiti dall’appli-
cazione e una convenzione per rappresentare le chiamate di procedura remota (RPC)
e le risposte. SOAP può essere utilizzato in combinazione, o ‘reincapsulato’, con una
varietà di protocolli di rete come ad esempio HTTP, SMTP, FTP, RMI over IIOP o
MQ.
La Figura 2.3 mostra come la messaggistica XML basata su SOAP e i protocolli
di rete costituiscono la base dell’architettura dei servizi web.
Figura 2.3: Messaggi XML in SOAP
I requisiti di base che un nodo di rete deve avere per svolgere il ruolo di fornitore
o di richiedente in un ambiente di calcolo distribuito basato su messaggistica XML
sono la capacità di costruire e/o analizzare un messaggio SOAP e la capacità di
comunicare su una rete (ricevere e/o inviare messaggi). Tipicamente, un server SOAP
in esecuzione in un Web application server svolge tutte queste funzioni. In alternativa
può essere utilizzata una libreria specifica per un linguaggio di programmazione che
incapsula queste funzioni all’interno di un API. L’integrazione delle applicazioni con
SOAP può essere ottenuta con l’uso di quattro passi fondamentali:
23

CAPITOLO 2 Supporti per la realizzazione di servizi web
1. Un’applicazione che richiede servizi crea un messaggio SOAP. Questo messaggio
rappresenta la richiesta necessaria per invocare l’operazione resa disponibile dal
fornitore di servizi. Il documento XML contenuto nel corpo del messaggio può
essere una richiesta SOAP RPC oppure un messaggio data-centric, come spe-
cificato nella descrizione del servizio. Il richiedente presenta questo messaggio
insieme all’indirizzo di rete del fornitore del servizio all’infrastruttura SOAP.
L’infrastruttura interagisce con i protocolli di rete dello strato sottostante per
inviare il messaggio SOAP sulla rete.
2. L’infrastruttura di rete consegna il messaggio al runtime SOAP del fornitore
del servizio. Il runtime server SOAP inoltra il messaggio di richiesta al fornito-
re del servizio. Il runtime è responsabile di convertire il messaggio XML nelle
strutture dati specifiche del linguaggio di programmazione usato per l’applica-
zione. La conversione è guidata dagli schemi di decodifica contenuti all’interno
del messaggio.
3. Il servizio web è responsabile di elaborare il messaggio di richiesta ed eventual-
mente formulare una risposta; la risposta è a sua volta un messaggio SOAP. Il
messaggio di risposta SOAP è presentato al runtime SOAP come richiedente
del servizio verso la destinazione. In caso di protocolli richiesta/risposta sin-
crona su HTTP, il protocollo di messaggistica sfrutta la caratteristica naturale
del protocollo di rete di essere appunto richiesta/risposta. Il runtime invia il
messaggio SOAP attraverso la rete al richiedente.
4. Il messaggio di risposta che è giunto al richiedente del servizio attraverso l’in-
frastruttura di rete, viene indirizzato attraverso l’infrastruttura SOAP, conver-
tito secondo gli standard del linguaggio di programmazione di destinazione, se
necessario, e infine presentato all’applicazione che lo ha richiesto.
Questo esempio sfrutta le primitive di trasmissione richiesta/risposta presenti in
molti ambienti di programmazione distribuita. Lo scambio dei messaggi può avve-
24

2.2 SOAP, WSDL e WS-BPEL
nire in modo sincrono o asincrono con l’applicazione richiedente. Altre primitive di
comunicazione utilizzabili con SOAP sono one-way e notification.
2.2.2 WSDL
Attraverso la descrizione del servizio il fornitore del servizio comunica tutte le specifi-
che necessarie per l’invocazione del servizio da parte del richiedente. La descrizione del
servizio è la chiave per rendere l’architettura dei servizi web debolmente accoppiata e
per ridurre la quantità di informazioni da condividere fra il fornitore e il richiedente
del servizio per la comprensione, la programmazione e l’integrazione del servizio. Ad
esempio, né il fornitore né il richiedente devono essere a conoscenza della piattaforma,
del linguaggio di programmazione e degli oggetti distribuiti utilizzati dall’altra parte.
La descrizione del servizio insieme all’infrastruttura SOAP devono essere sufficienti
ad incapsulare tutti i dettagli necessari a far colloquiare l’applicazione del richiedente
con il servizio web del fornitore.
Il descrittore di servizio
All’interno dell’architettura dei servizi web, il linguaggio WSDL (versione 1.1) [12]
è utilizzato per fornire una descrizione di base di un servizio. WSDL è ormai uno
standard, formalizzato dal consorzio W3C 1 . Un documento WSDL descrive il servizio
web come un insieme di endpoint (terminali di comunicazione) che operano attraverso
messaggi il cui contenuto può essere a sua volta un documento oppure una chiamata
di procedura (tipo RPC). WSDL è un formalismo estensibile che consente di definire
gli endpoint e i messaggi in relazione al formato dei messaggi e ai protocolli di rete
usati nella comunicazione. Tuttavia al momento sono supportati solo SOAP, HTTP
POST e MIME.
WSDL divide convenzionalmente la descrizione di base dei servizi in due parti:
descrizione concreta e descrizione astratta. Questo permette di definire ogni parte
1 World Wide Web Consortium
25

CAPITOLO 2 Supporti per la realizzazione di servizi web
Figura 2.4: Descrizione di un servizio
separatamente, in maniera indipendente e riusabile dalle altre parti. Le operazioni e
i messaggi sono definiti in modo astratto e collegati con un protocollo di rete reale.
La definizione della descrizione astratta del servizio è riusabile e può essere istan-
ziata e referenziata da più descrizioni concrete del servizio. Basti pensare alla descri-
zione astratta come ad un linguaggio IDL (Interface Definition Langauge), alle inter-
facce in Java oppure a dei tipi nei servizi web. Questo permette di definire e implemen-
tare tipi che siano standard industriali comuni in modo da avere più implementazioni
per lo stesso servizio.
La descrizione astratta del servizio contiene degli elementi WSDL che compongono
la parte riutilizzabile della descrizione del servizio (illustrati in Figura 2.4):
26
• binding;
• portType;
• message;
• type.

2.2 SOAP, WSDL e WS-BPEL
L’elemento portType definisce le operazioni esposte dal servizio web, cioè quali tipi di
messaggi XML possono apparire nel flusso dei dati in input e output, in modo analogo
a come si definisce la segnatura di un metodo in un linguaggio di programmazione.
L’elemento message specifica i tipi di dati XML che costituiscono le varie parti di
un messaggio, è usato per definire i parametri di input ed output di un’operazione.
Dati complessi possono essere usati all’interno delle definizione se sono stati definiti
tramite l’elemento type.
L’elemento binding descrive il protocollo, il formato dei dati, la sicurezza e altri
attributi relativi ad una specifica descrizione astratta del servizio.
Un servizio web è modellato con un elemento service che contiene una collezione (in
genere uno solo) di elementi port. Il compito dell’elemento port è quello di associare
un endpoint (ad esempio un indirizzo di rete o un URL) con un elemento binding
contenuto nella descrizione astratta del servizio.
L’unione della descrizione astratta e di quella concreta costituiscono una defini-
zione completa del servizio secondo lo standard WSDL. Questa coppia di definizioni
contiene informazioni sufficienti per descrivere ai richiedenti del servizio come invocare
e interagire con il servizio web.
2.2.3 WS-BPEL
WS-BPEL (Web Services Business Process Execution Language) [2, 4] è un linguag-
gio per la definizione di processi di business e interazione di protocolli di business in
ambiente SOA. Estende il modello di interazione dei servizi web e li abilita a sup-
portare le transazioni tipiche dei processi di business aziendali. Definisce, inoltre,
un modello di integrazione interoperabile tale da facilitare l’espansione di processi
automatizzati interni alle aziende e le operazioni in ambienti business-to-business.
Nato dallo sforzo congiunto di alcuni dei maggiori produttori di software del mondo
(Microsoft, IBM, Bea Weblogic, SAP e Sibel) come evoluzione e fusione di alcuni
famosi linguaggi (XLANG [42] e WSFL [28]) è stato standardizzato da OASIS 2 nel
2 Organization for the Advancement of Structured Information Standards
27

CAPITOLO 2 Supporti per la realizzazione di servizi web
2002 ed è giunto alla sua seconda versione nel 2007.
WS-BPEL consente, tramite un linguaggio di descrizione basato su XML, di
specificare la logica di business di un processo permettendo di eseguire attività in pa-
rallelo, di manipolare dati, gestire eccezioni e interagire con servizi web. Data la sua
spiccata propensione all’interazione con i servizi web, possiamo fare rientrare WS-
BPEL nella categoria degli orchestratori di servizi web. Uno di motivi per cui è stato
scelto l’XML come linguaggio per la specifica dei processi WS-BPEL è la sua diffe-
renza dai normali linguaggi di programmazione. Questo potrebbe far pensare che sia
più semplice definire un processo anche da parte di utenti che non sono propriamente
dei programmatori, sicuramente questo ha agevolato la realizzazione di tool grafici
per la programmazione.
Per poter eseguire un processo specificato tramite WS-BPEL è necessario met-
terlo in esecuzione su un apposito server di applicazioni detto appunto BPEL
engine.
Un processo è un contenitore in cui vengono dichiarate le relazioni con i partner
esterni, i dati, collegamenti necessari per altri scopi e soprattutto le attività da ese-
guire, offrendo la possibilità di aggregare servizi web e definire una logica per ognuna
delle possibili interazioni, come si può vedere dalla Figura 2.5. Un esempio della
struttura di un generico processo WS-BPEL è riportata in Tabella 2.1.
Per riferirsi ed interagire con altri servizi web WS-BPEL fa uso di un apposita
dichiarazione che si chiamano partnerLink. Ognuno di questi partnerLink associa ad
ogni servizio un nome, un ruolo e il tipo di porta (secondo lo standard WSDL) che
saranno utilizzati all’interno del contesto del processo e nelle relazioni che intercorrono
fra tutti i servizi utilizzati. Un partnerLink può essere visto come un particolare
canale di comunicazione e più partnerLink possono essere associati allo stesso partner.
Questa interazione è bidirezionale; il partner invoca il processo e il processo invoca il
partner. Ogni link è caratterizzato da un tipo e un ruolo.
Un dato per WS-BPEL è una variabile il cui tipo può essere dichiarato all’interno
di un processo oppure all’interno di uno scope del processo. Le variabili mantengono
28

2.2 SOAP, WSDL e WS-BPEL
. . .
. . .
. . .
. . .
. . .
Tabella 2.1: Struttura di un processo WS-BPEL
i dati che costituiscono lo stato di un processo WS-BPEL durante l’esecuzione.
Per specificare il comportamento di un processo WS-BPEL si usano le attività.
Queste possono essere di due tipi: di base o strutturate.
Le attività di base rappresentano le azioni primitive del linguaggio e sono:
receive attende un messaggio,
replay invia un messaggio come risposta ad uno ricevuto,
invoke invia un messaggio ad un partner,
assign modifica i valori delle variabili,
validate verifica il valore delle variabili confrontandolo con il tipo dichiarato nel
WSDL associato,
wait mette il processo in attesa per un tempo definito,
empty non esegue alcuna operazione,
29

CAPITOLO 2 Supporti per la realizzazione di servizi web
Figura 2.5: Processo WS-BPEL
throw genera un fallimento nel processo (cioè una sorta di eccezione),
compensate esegue la compensazione di default a seguito di un fallimento,
compensateScope esegue la compensazione di uno scope a seguito di un fallimento,
exit termina il processo,
rethrow rilancia un fallimento precedentemente catturato verso lo scope di livello
superiore,
extensionActivity estende WS-BPEL introducendo nuovi tipi di attività,
Le attività strutturate sono quelle che permettono la creazione di un flusso logico
delle attività:
sequence esegue sequenzialmente alcune attività
flow esegue concorrentemente alcune attività
scope definisce un ambiente di esecuzione isolato per le attività contenute
30

2.3 JAX-WS
if seleziona un’attività rispetto ad un insieme di scelte
while, forEach, repeatUntil ripetono un’attività fino al soddisfacimento di una
specifica condizione
pick tiene in sospeso un insieme di attività fino al verificarsi di un determinato evento
che comporta la scelta di una delle attività in attesa.
Per far sì che durante l’esecuzione di un processo sia possibile mantenere la con-
nessione con i partner coinvolti nell’esecuzione, WS-BPEL fa uso dei Correlation Set.
Sono istanziati insieme allo scope del processo ed hanno il compito di identificare le
istanze del processo in modo che siano distinguibili fra loro. Le attività di invoke,
receive, pick e replay possono riferirsi ad un correlation set per mantenere la comu-
nicazione, al fine di implementare un meccanismo per il mantenimento della sessione
di comunicazione.
WS-BPEL prevede infine un meccanismo di gestione delle eccezioni per soppe-
rire ad eventuali errori che si possono generare durante l’esecuzione di un processo
di business con dei meccanismi di correzione e compensazione che vengono definiti
nell’apposita sezione del documento XML e vengono richiamati dalle attività di base
throw, compensate, rethrow e compensateScope.
2.3 JAX-WS
JAX-WS [24], acronimo di Java API for XML Web Services, è una tecnologia per
realizzare servizi web e client che comunicano tramite messaggi XML sfruttando la
tecnologia Java. Come abbiamo visto, uno dei protocolli usati per scambiare messaggi
di tipo XML sulla rete è SOAP. Questi messaggi hanno però la caratteristica di
avere una struttura molto complessa. Lo scopo dell’API JAX-WS è proprio quello di
nascondere la complessità della comunicazione allo sviluppatore. Dal lato server lo
sviluppatore deve specificare le procedure remote definendo i metodi in un’interfaccia
scritta mediante il linguaggio di programmazione Java. Il compito dello sviluppatore è
quello di codificare una o più classi che implementano i metodi desiderati. Lo sviluppo
31

CAPITOLO 2 Supporti per la realizzazione di servizi web
della parte client è altrettanto semplice. L’applicazione client crea dei proxy (oggetti
che rappresentano localmente i servizi) e invoca semplicemente i metodi dei proxy.
JAX-WS è molto flessibile perché utilizza tecnologie definite dal W3C come HTTP,
SOAP e WSDL; in più si appoggia ad altre API di comunicazione standard per il
mondo Java in modo tale da permettere una migliore integrazione con altre tecnologie
Java-oriented e favorire l’adeguamento verso standard nuovi e in via di definizione.
Una delle API alle quali si appoggia è l’API JAX-RPC che fornisce alla piattaforma
Java il supporto RPC per lo scambio di messaggi XML fra servizi web. Nelle versioni
successive alla prima è stato aggiunto il supporto al WS-I Basic Profile al fine di
migliorare l’interoperabilità fra JAX-RPC e implementazioni analoghe che usano altre
tecnologie.
La versione di JAX-WS 2.0 supporta le specifiche JAX-RPC 1.1 che fornisce il
supporto ad altri standard già citati come SOAP 1.2, WSDL 2.0, WS-I Basic Profile
e ad altre tecnologie e specifiche quali:
Java Architecture for XML Binding (JAXB) Framework per la definizione e
la trasformazione di documenti XML in oggetti Java e viceversa, porta notevoli
benefici se comparato con i metodi precedentemente usati come ad esempio
l’utilizzo del Document Object Model (DOM). Questa tecnologia consente una
gestione flessibile del WSDL, perché permette di accedere a tutti gli elementi
del documento XML allo stesso modo del DOM, ma con costrutti che le rendono
più comprensibili e veloci al programmatore.
Web service Security (JSR 183) supporto all’integrazione della sicurezza secon-
do le specifiche del Java Community Process.
L’API inoltre introduce il supporto per le operazioni asincrone lato client, semplifi-
ca l’utilizzo di JAX-WS con protocolli di trasporto diversi da HTTP diminuendo la
correlazione fra messaggi XML e lo strato di trasporto in modo da facilitare l’imple-
mentazione di nuovi standard, semplifica l’accesso ai messaggi scambiati dai mecca-
32

2.3 JAX-WS
nismi sottostanti e aggiunge il supporto per la gestione delle sessioni nello scambio di
messaggi.
Uno degli aspetti importanti di quest’API è che il suo supporto è parte integrante
della piattaforma Java in quanto è stato incluso nella J2SE (per la precisione a partire
dalla versione 6 di JAVA, mentre per le precedenti versioni, in particolare Java 1.4 e
Java 5, esistono appositi pacchetti per l’integrazione).
L’API è composta da una serie di package ognuno con uno specifico scopo: uno
permettere il mapping fra gli oggetti Java e il WSDL, uno esegue il mapping inverso fra
WSDL e oggetti Java, uno permette di implementare client per i servizi JAX-WS, un
altro si occupa della parte server ed, infine, uno contiene il nucleo di classi necessarie
a far funzionare l’intera API. Vedremo nei capitoli successivi qualche dettaglio.
Un concetto molto importante quando si parla di servizi web è relativo all’inter-
locutore a cui vengono richiesti i servizi. Ci si riferisce all’interlocutore in termini di
Endpoint (o porte di comunicazione) per identificare tutti i servizi che esso fornisce
ad un richiedente esterno, per cui è estremamente importante poter uniformare ed
astrarre il concetto in modo da rendere fruibile tali servizi a tutti i possibili richieden-
ti. Si parla quindi di interfaccia esposta da un servizio o, utilizzando la terminologia
inglese, Service Endpoint Interface (SEI).
Più formalmente potremmo dire che è un interfaccia Java che esporta i meto-
di del servizio che un client può invocare. Non è necessario descriverla o definirla
quando si costruisce un servizio con JAX-WS, in quanto è la stessa classe a definirlo
implicitamente.
33

34
CAPITOLO 2 Supporti per la realizzazione di servizi web

Capitolo 3
Il linguaggio COWSlite
COWSlite è un frammento di COWS [25] esteso in modo da essere usato come
linguaggio di programmazione per servizi web, cercando al contempo di mantenere
le caratteristiche espressive del linguaggio originale e di introdurre gli elementi ne-
cessari per renderlo utilizzabile per scrivere servizi eseguibili. Il risultato ottenuto
è un linguaggio concorrente basato sulle comunicazioni fra servizi web in cui sono
presenti primitive di invocazione e ricezione di richieste, un costrutto per l’esecuzio-
ne concorrente dei processi, un costrutto di scelta non deterministica, un operatore
per la delimitazione dello scopo delle variabili e uno per la replicazione di processi.
Nel linguaggio sono anche presenti le definizioni dei tipi di dato, per cui le variabili
utilizzate devono essere obbligatoriamente definite.
Lo scopo del linguaggio è quello di permettere di sviluppare servizi web utilizzando
la sintassi COWS e di poterli eseguire all’interno di un web server che supporti le
specifiche JAX-WS definite da Sun e dal Java Community Process.
In questo capitolo descriveremo brevemente COWS, del quale esporremo solo la
sintassi, soffermandoci su un suo frammento chiamato µCOWS m , che descriveremo
più a fondo, presentando sia la sintassi che la semantica. Successivamente intro-
durremo la sintassi di COWSlite e discuteremo la sua semantica confrontandola
con quella di µCOWS m . Per meglio descrivere il comportamento dei due linguaggi
presenteremo anche alcuni esempi.
35

3.1 Il calcolo di processi COWS
CAPITOLO 3 Il linguaggio COWSlite
COWS (Calculus for Orchestration of Web Services) è un linguaggio per la specifica
formale di processi orientati all’orchestrazione di servizi web. Fa parte della famiglia
dei calcoli di processo dalla quale eredita la possibilità di esprimere formalmente
proprietà dimostrabili sul processo descritto. Possibilità che in generale non si applica
ai linguaggi di programmazione tradizionali.
In Tabella 3.1 è riportata la sintassi di COWS. Lo scopo è quello di evidenziare le
differenze con il frammento µCOWS m che verrà esposto successivamente, in modo da
poter discutere future estensioni di COWSlite. La notazione utilizzata è la stessa
di µCOWS m e verrà enunciata successivamente.
COWS si basa su due concetti cardine: comunication endpoint (p • o) e ser-
vizio (s). Questo fornisce un meccanismo molto flessibile per l’identificazione dei
servizi (come succede con i ruoli dei partner in WS-BPEL).
Un comunication endpoint è la codifica della locazione del servizio da orchestrare
mediante una rappresentazione composta da due entità, partner e operazione, che
identificano rispettivamente la località che ospita il servizio che si sta richiedendo e
l’operazione specifica che si intende richiedere. Questa particolare notazione permette
di fruire dello stesso servizio da parte di siti diversi il che potrebbe anche prevedere
che i servizi richiesti eseguano la funzione esposta mediante implementazioni diverse,
rendendo questa rappresentazione molto flessibile.
Il servizio invece è l’entità computazionale di base di COWS. In genere, ogni
servizio crea un’istanza specifica per gestire ogni richiesta che gli perviene, a sua volta
ogni istanza è composta da thread concorrenti in grado di offrire la scelta fra diverse
attività di ricezione. Un servizio deve essere capace di ricevere messaggi multipli in
un ordine non predicibile in modo tale che il primo messaggio provochi la creazione
di un’istanza del servizio alla quale verranno indirizzati tutti i messaggi successivi.
Il meccanismo utilizzato per correlare i messaggi che appartengono logicamente alla
stessa sessione è il pattern-matching.
36

3.1 Il calcolo di processi COWS
s::= (service) g::= (input-guarded choice)
kill(k) (kill) 0 (nil)
| u • u ′ !¯ɛ (invoke) | p • o? ¯w.s (receive)
| g (choice) | g + g (choice)
| s | s (parallel)
| {|s|} (protection)
| [d] s (delimitation)
| ∗ s (replication)
3.1.1 µCOWS m
Tabella 3.1: Sintassi di COWS
µCOWS m è un frammento di COWS nel quale sono state eliminate le attività di
kill e la protezione di un insieme di attività dalla terminazione forzata. La sintassi
fra i due calcoli è stata mantenuta compatibile. Inoltre, in µCOWS m non esiste una
priorità sulla selezione fra più attività di ricezione attive compatibili con l’attività di
invocazione ricevuta, la selezione dell’attività avviene in maniera non deterministica.
Sintassi
La sintassi di µCOWS m è indicata in Tabella 3.2. La sintassi è basata su due insiemi
disgiunti: l’insieme dei valori (tipo v, v ′ ,. . . ) e l’insieme delle variabili ’write-once’
(tipo x, y,. . . ). L’insieme dei valori è volutamente non formalizzato, anche se si
suppone che contenga almeno dei nomi (tipo n, m, p, o,. . . ) che sono utilizzati
per descrivere i partner e le operazioni. C’è anche un altro insieme, quello delle
espressioni (ɛ), del quale omettiamo la sintassi esatta, anche se supponiamo contenga
almeno valori e variabili.
In seguito utilizzeremo w per indicare valori e variabili ed u per indicare no-
mi e variabili. La notazione ¯· sta ad indicare una tupla; ad esempio ¯x rappresenta
〈x1, . . . , xn〉 (con n ≥ 0), dove ogni variabile all’interno della tupla è diversa da tutte
le altre. Scriveremo a, ¯ b per indicare le tuple ottenute concatenando l’elemento a con
la tupla ¯ b. Il termine n rappresenta un endpoint di comunicazione che non contiene
variabili (ad es. p • o), mentre u rappresenta un endpoint di comunicazione che può
37

CAPITOLO 3 Il linguaggio COWSlite
s ::= (services) g ::= (receive-guarded choice)
u • u ′ !¯ɛ (invoke) 0 (nil)
| g (choice) | p • o? ¯w.s (request processing)
| s | s (parallel) | g + g (choice)
| [u] s (delimitation)
| ∗ s (replication)
Tabella 3.2: Sintassi di µCOWS m
contenere variabili (ad es. u • u ′ ). Utilizzeremo la notazione I s per assegnare un
nome I al termine s.
Assumeremo la convenzione che gli operatori monadici abbiano la precedenza sul-
la composizione parallela e che l’operatore prefisso abbia la precedenza sulla scelta.
L’unico costrutto legante è la delimitazione: [u] s lega u nell’ambito s.
Le comunicazioni fra servizi danno luogo alla sostituzione delle variabili con i valo-
ri. Il campo di applicazione delle sostituzioni generate dalle comunicazioni è regolato
dall’operatore di delimitazione; tale operatore, inoltre, permette di generare nomi
nuovi (fresh). Quindi le occorrenze di un nome o di una variabile sono libere (free)
se non sono sotto l’influenza di una delimitazione. Indicheremo con fu(t) l’insieme di
nomi o variabili libere che occorrono in t. Due termini si dicono α-equivalenti se uno
può essere ottenuto dall’altro per mezzo di una ridenominazione consistente che leghi
i nomi e le variabili.
Semantica Operazionale
La semantica operazionale di µCOWS m è definita solo per servizi chiusi, cioè servizi
senza variabili libere. La semantica è data formalmente mediante una relazione di
congruenza strutturale e una relazione di transizione etichettata.
La congruenza strutturale (≡) identifica sintatticamente servizi differenti che in-
tuitivamente rappresentano lo stesso servizio. È definita come la più piccola relazione
indotta dalle leggi mostrate in Tabella 3.3. Le leggi che esprimono la congruenza strut-
turale sono semplici da interpretare. In particolare, la proprietà commutativa sulle
delimitazioni consecutive implica che l’ordine in cui sono scritte le ui in [〈u1, . . . , un〉] s
38

3.1 Il calcolo di processi COWS
∗ 0 ≡ 0 ∗ s ≡ s |∗ s
s | 0 ≡ s s1 | s2 ≡ s2 | s1 (s1 | s2) | s3 ≡ s1 | (s2 | s3)
g + 0 ≡ g g1 + g2 ≡ g2 + g1 (g1 + g2) + g3 ≡ g1 + (g2 + g3)
[u] 0 ≡ 0 [u1] [u2] s ≡ [u2] [u1] s s1 | [u] s2 ≡ [u] (s1 | s2) if u /∈fu(s1)
Tabella 3.3: Congruenza strutturale di µCOWS m
M(x, v) = {x ↦→ v} M(v, v) = ∅ M(〈〉, 〈〉) = ∅ M(w1, v1) = σ1 M( ¯w2, ¯v2) = σ2
M((w1, ¯w2), (v1, ¯v2)) = σ1 ⊎ σ2
Tabella 3.4: Regole di matching
è irrilevante, permettendo così di usare una notazione più semplice come [u1, . . . , un] s.
L’ultima legge permette di estendere l’ambito di nomi e variabili, rendendo possibile
la comunicazione fra servizi.
Per definire la relazione di transizione etichettata sono necessarie delle funzioni
ausiliarie. In primo luogo la funzione [_] per valutare le espressioni chiuse: data in
ingresso un’espressione chiusa restituisce un valore. Non verrà definita esplicitamente
in quanto la sintassi delle espressioni non è stata deliberatamente specificata. La
seconda è una funzione parziale M(_ , _) che permette di eseguire il pattern-matching
su dati semi-strutturati, in modo da determinare se una receive ed una invoke possono
sincronizzarsi sullo stesso endpoint. Le regole per il pattern-matching sono mostrate
nella Tabella 3.4. Da queste si evince che due tuple corrispondono se hanno lo stesso
numero di campi e i rispettivi valori o variabili di ogni campo corrispondono. Una
variabile corrisponde a qualsiasi valore e due valori corrispondono solo se sono identici.
Quando si ha una corrispondenza fra due tuple ¯w e ¯v , allora M( ¯w, ¯v) restituisce una
sostituzione per le variabili in ¯w; altrimenti è indefinita. Una sostituzione σ è una
funzione che mappa variabili in valori e si scrive come un insieme di coppie del tipo
x ↦→ v. L’effetto di applicare una sostituzione σ a s (s · σ) è quello di sostituire
tutte le occorrenze libere di x in s con v, per ogni x ↦→ v ∈ σ, possibilmente usando
α-conversione in modo da evitare che v sia catturata da una delimitazione all’interno
di s.
39

n!¯ɛ
[¯ɛ] = ¯v
s
[x] s
n ✁ ¯v
−−−−→ 0
(inv)
σ⊎{x↦→v}
−−−−−−−−→ s ′
σ
−−→ s ′ ·{x ↦→ v}
g α
−−→ s
′ α
g + g −−→ s
s1
n ✄ ¯w
−−−−−→ s ′ 1
(choice)
s2
s1 | s2
s ≡ s1 s1
CAPITOLO 3 Il linguaggio COWSlite
(delcom)
n ✁ ¯v
−−−−→ s ′ 2
n? ¯w.s
n ✄ ¯w
−−−−−→ s (rec)
s α
−−→ s ′ u /∈ u(α)
(del)
[u] s α
−−→ [u] s ′
s1
s1 | s2
σ
−−→ s ′ 1 | s ′ 2
α
−−→ s2 s2 ≡ s ′
s α
−−→ s ′
α
−−→ s ′ 1
α
−−→ s ′ 1 | s2
(par)
M( ¯w, ¯v)=σ (com)
(str)
Tabella 3.5: Semantica operazionale di µCOWS m
La relazione di transizione etichettata
α
−−→ è la più piccola relazione sui servizi
indotta dalle regole della Tabella 3.5, in cui l’etichetta α è generata dalla seguente
grammatica:
α ::= n ✁ ¯v | n ✄ ¯w | σ
Il significato delle etichette è il seguente: n ✁ ¯v e n ✄ ¯w indicano rispettivamente
l’esecuzione delle attività di invocazione e ricezione sull’endpoint n con argomenti ¯v e
¯w, mentre σ indica l’esecuzione di una comunicazione fra servizi che genera la sostitu-
zione σ. I passi computazionali corrispondo a transizioni etichettate dalla sostituzione
vuota ∅, cioè corrispondono alle comunicazioni interne al servizio considerato.
Analizziamo ora i punti salienti delle regole operazionali. L’invocazione di un
servizio può avvenire solo se l’espressione nell’argomento può essere valutata (regola
(inv)). Ciò significa, per esempio, che se essa contiene una variabile x, l’invocazione è
bloccata fino a quando x non viene sostituito da un valore per mezzo di una ricezione
che assegna un valore a x.
40

3.1 Il calcolo di processi COWS
Un’attività di ricezione rappresenta un operazione invocabile rispetto ad un deter-
minato nome del partner (regola (rec)), allo stesso modo l’esecuzione di una ricezione
permette di prendere una decisione riguardo a dei comportamenti alternativi (regola
(choice)). Una comunicazione può avvenire quando due servizi in parallelo eseguo-
no delle attività di invocazione e ricezione per cui si ha una corrispondenza (regola
(com)). La comunicazione genera una sostituzione che è riportata nella transizione
etichettata per le attività successive. Quando una variabile delimitata x è argomento
di una ricezione facente parte di un processo di comunicazione allora la delimitazione
imposta dalla variabile viene rimossa appena si verifica la sostituzione della variabile
ad opera dell’azione di comunicazione (delcom)). La variabile x sparisce dal termine
e non è più possibile riassegnargli un valore (questo è il motivo per cui in COWS
si dice che le variabili sono ’write-once’). [u] s si comporta come s (regola (del)) ad
eccezione del caso in cui in α sia contenuto u. L’esecuzione di servizi in parallelo è
interleaved (regola (par)). La regola (str) è una regola di inferenza usuale per cui dei
servizi congruenti hanno le stesse transizioni. Vale la pena di notare che quando vie-
ne applicata la regola (openrec) ad un servizio µCOWS m chiuso, il termine risultante
potrebbe essere aperto.
3.1.2 Esempi
Vediamo alcuni esempi per chiarire ed evidenziare alcuni aspetti di µCOWS m .
Comunicazione
La comunicazione fra servizi deve sfruttare l’estensione dello scope per far si che
possano interagire attività di ricezione e di invocazione. Infatti queste attività pos-
sono sincronizzarsi solo se entrambe sono all’interno dello stesso ambito rispetto alle
delimitazioni che legano le variabili delle attività di ricezione.
odds • throw!〈first, cbA, 2〉 | [xp, xnum] (odds • throw?〈first, xp, xnum〉).s | s ′ ) ≡
[xp, xnum] (odds • throw!〈first, cbA, 2〉 | odds • throw?〈first, xp, xnum〉).s | s ′ )
(s | s ′ ) · {xp ↦→ cbA, xnum ↦→ 2}
∅
−−→
41

CAPITOLO 3 Il linguaggio COWSlite
Da notare che la sostituzione {xp ↦→ cbA, xnum ↦→ 2} è applicata a tutti i termini
delimitati da [xp, xnum] , non soltanto alla continuazione s del servizio che esegue la
ricezione.
Istanze di servizio e correlazione di messaggi
Data la natura debolmente accoppiata dei servizi µCOWS m (come tutti i linguaggi
usati in SOA) questo implica che la connessione tra istanze di servizi comunicanti non
sono da considerarsi persistenti per tutta la durata dell’attività di business. Quindi è
necessario che sia fornito ad ogni singolo messaggio una forma di contesto che permetta
ad un servizio di associare fra loro i messaggi. Questo si può ottenere inserendo dei
valori, chiamati dati di correlazione, all’interno del contesto del messaggio stesso.
Il meccanismo per individuare i dati necessari per selezionare le istanze di servizio
interessate dallo scambio di messaggi è il pattern-matching. Consideriamo il seguente
termine:
(srv • throw!〈first, cbA, 2〉 | srv • throw!〈second, cbA, 3〉 | sA)
| (srv • op!〈first, cbB, 1〉 | sB)
| ∗ [xid, xp, xnum, yp, ynum] srv • throw?〈xid, xp, xnum〉.srv • op?〈xid, yp, ynum〉.s
Supponiamo che le prime due sincronizzazioni siano relative alle due invocazioni lo
stato del servizio diventa:
∗ [xid, xp, xnum, yp, ynum] (srv • throw?〈xid, xp, xnum〉.srv • op?〈xid, yp, ynum〉.s)
| [yp, ynum] (srv • op?〈first, yp, ynum〉.s) · {xid ↦→ first, xp ↦→ cbA, xnum ↦→ 2}
| [yp, ynum] (srv • op?〈second, yp, ynum〉.s) · {xid ↦→ second, xp ↦→ cbA, xnum ↦→ 3}
| sA | (srv • op!〈first, cbB, 1〉 | sB)
dopo la terza sincronizzazione si ottiene:
∗ [xid, xp, xnum, yp, ynum] (srv • throw?〈xid, xp, xnum〉.srv • op?〈xid, yp, ynum〉.s)
| s · {xid ↦→ first, xp ↦→ cbA, xnum ↦→ 2, yp ↦→ cbB, ynum ↦→ 1}
| [yp, ynum] (srv • op?〈second, yp, ynum〉.s) · {xid ↦→ second, xp ↦→ cbA, xnum ↦→ 3}
| sA | sB
42
Le due invocazioni srv • throw!〈〉 generano due istanze diverse del blocco repli-

3.1 Il calcolo di processi COWS
cabile, il blocco srv • op!〈〉 si sincronizzerà con l’istanza in cui c’è corrispondenza, in
questo caso quella con parametro ‘first’, dando luogo alla sostituzione. Sfruttando
il pattern-matching sui parametri all’interno della richiesta è possibile correlare le
richieste sulla stessa istanza in esecuzione.
Descrizione ed esecuzione di un servizio
In µCOWS m un servizio può essere modellato con un termine della forma ∗ [ū] s,
dove la tupla ū contiene tutte le variabili libere presenti in s. L’uso dell’operatore
di replicazione fornisce tutte le istanze concorrenti necessarie, mentre la delimitazio-
ne definisce lo stato del servizio (restringendo la visibilità delle variabili). Questo
significa che il termine appena descritto corrisponde ad un servizio in cui le istanze
sono eseguite concorrentemente senza condividere uno stato. Ad esempio prendiamo
il seguente servizio:
∗ [x1, . . . , xn] p • o?〈x1〉.s
Se lo poniamo in parallelo ad una invocazione del tipo p • o!〈v1〉 il risultato è un
sistema che evolve nel seguente modo:
∗ [x1, . . . , xn] p • o?〈x1〉.s | p • o!〈v1〉
∅
−−→
∗ [x1, . . . , xn] p • o?〈x1〉.s | [x2, . . . , xn] s · {x1 ↦→ v1}
Allo stesso modo se prendiamo due clienti che tentano di utilizzare il medesimo
servizio:
∗ [x1, . . . , xn] p • o?〈x1〉.s | p • o!〈v1〉 | p • o!〈v2〉
∅
−−→ ∅
−−→
∗ [x1, . . . , xn] p • o?〈x1〉.s | [x2, . . . , xn] s · {x1 ↦→ v1} | [x2, . . . , xn] s · {x1 ↦→ v2}
La replication fornisce copie del servizio ogni volta che c’è una richiesta.
Bank Account
Questo esempio è una semplificazione di quello che potrebbe essere un reale servizio
di un sistema bancario. Il servizio offerto permette di eseguire accrediti e addebiti sul
conto indicato.
43

CAPITOLO 3 Il linguaggio COWSlite
Il servizio Bank è composto da due sottoservizi persistenti, uno è invocabile
pubblicamente degli ipotetici Client, l’altro è un servizio interno che può interagire
esclusivamente con Bank. Il servizio Client simula il richiedente dell’operazione.
Bank [check, checkOK, checkF ail]
(∗ [CUST, CC, AMOUNT, ID]
bank • charge?〈CUST, CC, AMOUNT, ID〉.
(bank • check!〈ID, CC, AMOUNT 〉 |
bank • checkOK?〈ID〉.CUST • chargeOK!〈ID〉+
bank • checkF ail?〈ID〉.CUST • chargeF ail!〈ID〉)
| ∗ [CUST ID, CC, AMOUNT ]
bank • check?〈CUST ID, CC, AMOUNT 〉.
[p, o] (p • o!〈〉 |
p • o?〈〉.bank • checkOK!〈CUST ID〉+
p • o?〈〉.bank • checkF ail!〈CUST ID〉))
Client bank • charge!〈client, 1234, 100, id1〉 |
(client • chargeOK?〈id1〉.0 + client • chargeF ail?〈id1〉.0) |
bank • charge!〈client, 1234, 200, id2〉 |
(client • chargeOK?〈id2〉.0 + client • chargeF ail?〈id2〉.0)
Il servizio Bank quindi gestisce le richieste del Client pervenute sull’endpoint con-
trollando che la tupla di valori ricevuti combaci con i parametri passati. Inoltre,
attraverso i canali di comunicazione checkOK e checkF ail, il servizio bank gestisce
le risposte, rispettivamente positive e negative, alle richieste ricevute. Ad ogni richie-
sta, Bank crea un istanza specifica per soddisfare quella richiesta ed è immediatamente
pronto a soddisfare contemporaneamente altre richieste.
Il servizio Client, invece, invoca il servizio Bank inviando una tupla comprensiva
di tipo utente, numero di conto, somma da versare e codice cliente.
44

3.2 Descrizione di COWSlite
3.2 Descrizione di COWSlite
Adesso introdurremo il linguaggio COWSlite e ne descriveremo la sintassi e alcuni
aspetti particolari legati alle variabili e al loro confronto; infine ne definiremo la
semantica mediante differenza con i calcoli precedentemente esposti ed in particolare
con µCOWS m .
3.2.1 Sintassi
Dato che COWSlite è un linguaggio per l’orchestrazione di servizi web, uno degli
aspetti principali da tenere in considerazione nello sviluppo è la necessità di definire
in maniera semplice gli endpoint di comunicazione. A tal fine si mantiene la stessa
modalità proposta per COWS e µCOWS m .
La sintassi di COWSlite, definita in Tabella 3.6, è composta da una serie di
produzioni suddivisibili in quattro gruppi: Programma, Dichiarazioni, Processi ed
Espressioni.
Il primo blocco è relativo alla struttura del programma ed è composto da un’unica
produzione, che definisce che un programma COWSlite è costituito da due sezioni:
la prima, opzionale, riguarda le dichiarazioni globali, la seconda contiene una serie
di blocchi di descrizione di servizi, di cui almeno uno obbligatorio. Ogni blocco
rappresenta un servizio completo. Il fatto di poter definire più blocchi è solo per
agevolare il programmatore.
Il secondo gruppo contiene le produzioni per il blocco delle dichiarazioni. Questo
serve per dichiarare tutti gli identificatori che saranno globali a tutte le istanze del
servizio. Cioè ogni servizio definito avrà come identificatori globali, condivisi fra
tutte le istanze, quelli definiti all’interno della sezione dec{...}. Se ad esempio in
un programma sono definiti due servizi S1 e S2 e D è l’insieme degli identificatori
definiti in dec{...}, allora ogni istanza di S1 avrà una copia di D condivisa fra tutte
le istanze e ogni istanza di S2 avrà un’altra copia di D condivisa fra le istanze. Per
definire identificatori privati ad una istanza è necessario sfruttare la delimitazione.
Dalle produzioni si ottiene che un identificatore può essere un partner, un nome,
45

Programma:
program = declaration ? cows_service +
CAPITOLO 3 Il linguaggio COWSlite
Dichiarazioni:
declaration=dec {element ∗ }
element=ide : lab_type;
lab_type=var(var_type)
| name
| partner partner_name operation_name wsdl_link
var_type = String
| int
| vect (number)
Processi:
cows_service = once ? service {proc}
proc = (process)
| process;
process = |(proc,proc)
| ∗[number] ? proc
| [element*]proc
| !(partner_name,operation_name,)
| choice
| ide := assignable.proc
assignable = expr | const
choice = +(choice, choice)
| nil
| ?(partner_value,operation_name,).proc
Espressioni:
expr = term | -term | +term | expr+term | expr-term
term = fact | term*fact | term/fact
fact = number | ide | (expr)
Tabella 3.6: Sintassi di COWSlite
oppure una vera e propria variabile write-once che può contenere al momento tre tipi
di dato: stringa, intero o vettore di variabili. Tra i tipi di identificatore esiste anche
l’etichetta killer che non è stata inserita per appesantire la notazione, ma è presente
nell’implementazione per estensioni future.
46
Il terzo e il quarto gruppo sono relativi al blocco di definizione dei servizi. Il terzo

3.2 Descrizione di COWSlite
gruppo di produzioni descrive i processi che concorrono alla specifica della logica del
servizio COWSlite. Un servizio comincia con la parola chiave service e contiene
all’interno delle parentesi graffe la descrizione dei processi. La keyword service po-
trebbe essere preceduta dalla parola chiave once che sta ad indicare che il servizio
potrà essere istanziato al massimo una sola volta.La produzione proc non è impor-
tante a livello semantico, serve solo per poter racchiudere una sequenza di processi
all’interno di una coppia di parentesi tonde al fine di migliorare la leggibilità del li-
stato. Le produzioni process, assignable e choice sono quelle che descrivono le azioni
del servizio COWSlite. Process definisce i processi principali costituenti un servizio
COWSlite. Il motivo per cui le operazioni definite nelle produzioni vengono chia-
mate processi saranno chiare successivamente quando verrà descritta l’architettura
del motore di esecuzione. La produzione process definisce tutti i processi eseguibili
del linguaggio: la composizione parallela, la replicazione, l’invocazione di un servizio,
la scelta guardata e l’assegnazione di un valore o di un espressione ad una variabile.
Fra queste assignable definisce il costrutto di assegnazione nel quale avviene anche la
valutazione delle espressioni.
La produzione choice descrive la singola operazione di ricezione o il costrutto di
scelta guardata. Questo prevede che in caso di scelta questa venga eseguita in maniera
non deterministica fra tutte le possibilità definite dalle operazioni di ricezione, cioè
solo la prima richiesta pervenuta in ordine temporale che corrisponde ad una delle
richieste collegate tramite l’operatore di scelta provocherà la modifica dello stato del
sistema e permetterà l’esecuzione dei processi ad esso successivi. La corrispondenza è
definita dalle regole di matching fra invocazione e ricezione del servizio. Se ci sono più
ricezioni che soddisfano l’invocazione allora la ricezione sarà selezionata in maniera
non deterministica.
Sarebbe stato forse più opportuno o più comodo definire degli operatori n-ari
anziché binari per il parallelo e la scelta guardata, ma è stato scelto di definirli binari
per semplificare lo sviluppo del compilatore e per restare più fedeli possibile alla
sintassi di COWS.
47

CAPITOLO 3 Il linguaggio COWSlite
Inoltre per essi valgono le proprietà associativa e commutativa.
L’ultimo gruppo di produzioni definisce la struttura delle espressioni algebriche.
Per realizzare il compilatore è necessario definire un sottoinsieme minimo di operatori
aritmetici. Al momento le espressioni supportate operano su variabili di tipo intero e
implementano solo le quattro operazioni algebriche (somma, sottrazione, moltiplica-
zione e divisione) e l’uso delle parentesi per indicare la precedenza delle operazioni. Il
blocco di definizione è composto da tre definizioni expr, term e fact che rappresentano
le operazioni in ordine di precedenza; in fact ci sono gli elementi di base (numeri e
identificatori di variabili) e la possibilità di definire espressioni che abbiano precedenza
sull’espressione corrente per mezzo delle parentesi; in term sono indicate le operazioni
di prodotto e di divisione ed infine in expr sono indicate le operazioni di somma e
differenza che hanno precedenza minima.
3.2.2 Tipi di dato e vettori di variabili write-once
Nella sintassi non sono state incorporate formalmente, per non appesantire la nota-
zione, le definizioni dei valori numerici e letterali presenti nel corpo delle produzioni; i
tipi di valori si dividono in tre categorie: identificatori (ide), costanti letterali (const)
e numeri (number). Il termine values è utilizzato per indicare uno qualsiasi dei tre
tipi di base. Con il termine identificatori si intende una qualsiasi sequenza di caratteri
(lettere e numeri) che inizia obbligatoriamente con una lettera. Una costante lettera-
le, invece, è una qualsiasi sequenza di simboli (lettere, numeri, segni di interpunzione,
ecc.) racchiusi fra doppie virgolette. Anche gli elementi presenti all’interno delle
operazioni di invoke e receive, indicate rispettivamente con i simboli ! e ?, sono dei
valori, ma si è preferito dar loro un nome più significativo, per cui partner_name è un
identificatore, partner_value è un valore, operation_name e wsdl_link sono costanti,
mentre con list_of_values si intende un sequenza, anche vuota, di valori separati da
virgola.
Il termine list_of_values rappresenta la lista dei parametri che vengono associati
alle operazioni di invocazione e ricezione, questa lista può essere formata quindi da
48

3.2 Descrizione di COWSlite
valori costanti, tipo stringhe racchiuse fra i doppi apici o valori numerici, e nomi di
variabili che devono essere stati precedentemente definiti all’interno della dichiarazione
globale oppure all’interno di una delimitazione.
Dal momento che deve essere eseguita una traduzione in Java del servizio CO-
WSlite, le variabili in gioco devono essere tipate al fine di essere compatibili con
Java.
Attualmente COWSlite supporta solo variabili di tipo string, intero e vettori di
variabili ad una dimensione, in cui però ogni elemento può essere uno qualunque dei
tre tipi appena nominati.
Come per COWS anche in COWSlite le variabili utilizzate sono tutte di tipo
write-once. Questo implica che una volta assegnato un valore alla variabile, questo non
può essere modificato; ovvero una qualunque azione successiva di modifica fatta con
una receive o con un’assegnazione non produrranno alcun effetto, non modificheranno
il valore della variabile e non genereranno alcun errore. Anche i vettori sono variabili
di tipo write-once.
3.2.3 Regole di matching
Affinché sia possibile sincronizzare due servizi o accettare una richiesta in ingresso
è necessario definire l’operatore di match fra una invocazione e una ricezione. Tale
definizione è ricorsiva sulla struttura degli operatori.
Siano !(p, o, < lv >) e ?(p ′ , o ′ , < lv ′ >) rispettivamente una invocazione ed una
ricezione, con p e p ′ partner, o e o ′ operation e lv e lv ′ parametri delle operazioni. Il
match è positivo fra le due operazioni se: p = p ′ , o = o ′ e si ha match fra lv e lv ′ ,
quindi se partner e operazione coincidono e le liste di valori sono compatibili.
Le liste di valori sono compatibili se hanno lo stesso numero di elementi e ogni
singolo valore della lista è compatibile. Cioè siano lv = x1, .., xn e lv ′ = x ′ 1 , .., x′ m si
ha match(lv, lv ′ ) = true se m = n e ∀i : match(xi, x ′ i ) = true.
Due valori v e v ′ sono compatibili se sono dello stesso tipo e se v = v ′ , se invece
v ′ non ha un valore assegnato,si parla allora di variabile x ′ , il match è ancora vero,
49

ma genera una sostituzione x ′ ↦→ v.
3.2.4 Semantica e differenze con µCOWS m
CAPITOLO 3 Il linguaggio COWSlite
Analizzeremo la semantica di COWSlite facendo un parallelo con i costrutti di
µCOWS m in modo da evidenziarne le similitudini e discuterne le differenze.
La prima differenza che salta agli occhi rispetto al calcolo originale è la presenza
di una sezione di dichiarazione delle variabili utilizzate. Si presenta infatti la necessità
di tipare le variabili che verranno usate all’interno del listato COWSlite in modo
da semplificare la costruzione del compilatore, visto soprattutto che il linguaggio
di destinazione è un linguaggio fortemente tipato e con molti controlli in fase di
compilazione sulla congruenza degli oggetti utilizzati.
Le variabili definite nella sezione dichiarativa sono globali a tutte le istanze del
servizio.
Sempre per semplificare la stesura del compilatore tutte le azioni del linguaggio
sono state riscritte usando una notazione prefissa o di tipo funzionale, cioè sono tutte
delle forma Azione(lista parametri); essendo tutte della stessa forma si semplifica il
trattamento durante la compilazione.
I costrutti di composizione parallela e di scelta hanno la stessa semantica.
Il costrutto di replicazione si comporta come in µCOWS m anche per esso vale
la regola di congruenza strutturale ∗ s ≡ s | ∗ s; in più in COWSlite ammette un
parametro numerico che permette di definire il numero massimo di processi replicati
contemporaneamente attivi; questo serve per non allocare infiniti processi in fase di
inizializzazione e limitare allo stesso tempo il carico sullo scheduler del Web Server,
non incide sulla semantica del linguaggio.
La delimitazione [d] s permette di definire nomi che sono solo locali al processo
s, allo stesso modo in COWSlite le variabili definite all’interno della delimitazione
sono visibili ai soli costrutti contenuti in proc.
Il costrutto di invocazione non supporta la valutazione di espressioni di nessun
tipo, ma accetta solo variabili write-once. Per eseguire la valutazione di espressioni
50

3.2 Descrizione di COWSlite
è stato introdotto il costrutto di assegnazione per cui per eseguire la valutazione di
una espressione di un parametro da utilizzare nell’invocazione di un servizio si devono
usare entrambi i costrutti. Ad esempio il codice COWS relativo alla invoke:
p1 • o1!〈a + b ∗ c, a − c/b〉
deve essere tradotto nell’equivalente COWSlite:
tmp1 := a + b ∗ x.tmp2 := a − c/b.!(p1, o1, < tmp1, tmp2 >)
p • o? ¯w.s si comporta come ?(p, o, ¯w).s perché entrambi accettano un insieme di
parametri in input e modificano lo stato del processo successivo assegnando i valori
dei parametri alle relative variabili.
Una comunicazione fra due azioni, una di invocazione ed una di ricezione, da luogo
ad una sostituzione delle variabili interessate dall’operazione di ricezione e comporta
la terminazione dell’azione di invocazione, quello che rimane è solo la continuazione
della ricezione alla quale è applicata la sostituzione.
Anche per gli altri operatori il comportamento è analogo nei due linguaggi.
La keyword name può essere utilizzata per indicare un nome all’interno del co-
strutto che non ha un tipo associato, ma che corrisponda semplicemente ad un nome
non visibile dall’esterno.
L’assegnazione, a differenza della definizione, non è un costrutto bloccante. Cioè,
esso viene eseguito senza controlli sullo stato delle variabili, se le variabili non so-
no tutte assegnate si genererà un’eccezione in fase di esecuzione che comporterà la
terminazione del ramo in questione.
L’attuale mancanza dei costrutti di kill e protection fa si che il linguaggio sia meno
espressivo rispetto a COWS, ma il comportamento in tutti gli altri casi è coerente
con quello di µCOWS m in cui non viene fatto uso di tali operatori.
COWS
Una delle semplificazioni fatte a livello sintattico è stata la scelta di usare operatori
prefissi al posto degli operatori infissi.
51

CAPITOLO 3 Il linguaggio COWSlite
Non sono state implementate le azioni di kill e protection, che vengono lasciate ad
una futura estensione. Invece le parole chiave KillerLabel e name sono presenti nella
definizione del linguaggio, ma non hanno effetto sul codice generato, proprio perché
riguardano gli aspetti di COWS non ancora implementati.
La progettazione e la definizione del linguaggio sono stati fatti per permettere e
agevolare l’implementazione delle operazioni e dei costrutti mancanti in un momento
successivo.
3.3 Esempi
Riprendiamo adesso alcuni degli esempi visti con µCOWS m in modo da chiarire il
funzionamento di COWSlite ed evidenziare che le differenze fra i due linguaggi sono
sostanzialmente di natura sintattica.
Dato che COWSlite non è un formalismo di specifica in senso stretto, ma si
avvicina di più ai linguaggi di programmazione, non è stata definita per esso una
semantica operazionale tramite regole di transizione, per cui negli esempi successivi
abuseremo un po’ della notazione definita per µCOWS m per spiegare l’evoluzione
di stato del sistema. Utilizzeremo
∅
−−→ per indicare una comunicazione con sincro-
nizzazione e utilizzeremo la sostituzione ·{...} per indicare l’assegnazione di valori a
variabili a seguito di comunicazioni.
Comunicazione
Questo esempio, che nel calcolo viene eseguito tramite estensione dello scopo, mette
in evidenza che tutti i processi all’interno di una delimitazione subiscono l’effetto di
una sostituzione (assegnazione delle variabili) a seguito di una comunicazione.
service{|(!(odds,throw,),
[xp,xnum]|(?(odds,throw,).s,s’)} ∅
−−→
service{|(s,s’)·{xp ↦→ cbA, xnum ↦→ 2}}
52

3.3 Esempi
I due processi rimanenti s e s’ sono eseguiti all’interno dello stesso ambiente
nel quale le due variabili ristrette (xp e xnum) hanno assegnati dei valori derivanti
dall’avvenuta comunicazione.
In COWSlite possiamo prendere ad esempio un altro tipo di comunicazione,
quello fra due servizi.
service{|(!(odds,throw,),s}
service{[xp,xnum]|(?(odds,throw,).s,s’)} ∅
−−→
Il seguente sistema evolve dopo la comunicazione in:
service{s}
service{[xp,xnum]|(s,s’)·{xp ↦→ cbA, xnum ↦→ 2}}
Cioè il servizio che ha per nome odds riceve due valori e al suo posto rimane in
esecuzione la sua continuazione che viene eseguita all’interno dell’ambiente delimitato
dalle variabili [xp,xnum] alle quali è stato assegnato un valore dalla sostituzione
generata dall’avvenuta comunicazione.
Istanze di servizio e correlazione di messaggi
Riprendiamo l’esempio visto precedentemente sulla correlazione fra le istanze di un
servizio.
Dividiamo il servizio visto in due servizi separati per evidenziare maggiormente
il concetto di correlazione. Il primo dei due è il servizio fornito, mentre il secondo
simula due clienti che effettuano la richiesta. La parte di dichiarazione iniziale serve
solo al servizio client per individuare la locazione in cui verranno posti i servizi.
dec{
}
srv : partner srv "o1"
srv2: partner srv "o2"
service {
"http://localhost:8080/test/srvService?WSDL";
"http://localhost:8080/test/srvService?WSDL";
53

}
[Xid:var(String);Xp:var(String);Xnum:var(int);
Yp:var(String);Ynum:var(int);]
CAPITOLO 3 Il linguaggio COWSlite
?("srv","o1",).?("srv","o2",).nil
once service {
}
|(
)
|(!(srv,"o1",),!(srv,"o1",)),
!(srv2,"o2",)
Le richieste dei client all’operazione o1 genereranno nel servizio srv due istanze
differenti del servizio stesso. La richiesta del servizio o2 invece rimane in attesa fino
a che non verrà avviata l’istanza di servizio srv che ha come primo parametro ‘first’.
In questo esempio la correlazione fra le istanze avviene utilizzando una variabile, che
chiameremo appunto variabile di correlazione.
Dopo l’esecuzione delle due richieste dell’operazione o1 da parte del cliente lo
stato del servizio è il seguente:
service {
}
[Xid:var(String);Xp:var(String);Xnum:var(int);
Yp:var(String);Ynum:var(int);]
?("srv","o1",).?("srv","o2",).nil
|[Yp:var(String);Ynum:var(int);]
?("srv","o2",).nil·{Xp ↦→ ′′ cbA ′′ , Xnum ↦→ 2}
|[Yp:var(String);Ynum:var(int);]
?("srv","o2",).nil·{Xp ↦→ ′′ cbA ′′ , Xnum ↦→ 3}
once service {
}
54
!(srv2,"o2",)

3.3 Esempi
Ed infine, dopo l’ultima comunicazione:
service {
}
[Xid:var(String);Xp:var(String);Xnum:var(int);
Yp:var(String);Ynum:var(int);]
?("srv","o1",).?("srv","o2",).nil
|nil·{Xid ↦→ first, Xp ↦→ cbA, Xnum ↦→ 2, Y p ↦→ cbB, Y num ↦→ 2}
|[Yp:var(String);Ynum:var(int);]
?("srv","o2",).nil·{Xp ↦→ cbA, Xnum ↦→ 3}
once service {}
Descrizione ed esecuzione di un servizio
La principale differenza fra µCOWS m e COWSlite è proprio nella definizione ini-
ziale, in COWSlite ogni processo definito è un vero e proprio servizio web.
service{} indica un servizio web vuoto in cui non ci sono servizi dichiarati.
service {[x1:var(...);...;xn:var(...)]?(p,o,).s}
è il più semplice servizio web che può essere dichiarato, la presenza della keyword
service fa la vece del costrutto di replicazione iniziale usata in µCOWS m . Quindi
l’esempio visto precedentemente si può scrivere come
service {[x1:var(int)]?(p,"o",)}
once service {!(p,"o",)}
oppure nel caso di due richieste contemporanee
once service {|(!(p,"o",),!(p,"o",))}
che produce dopo due comunicazioni, con un po’ di abuso di notazione:
service {[x1:var(int)]?(p,"o",)} | s·{x1 ↦→ v1} | s·{x1 ↦→ v2}
55

Bank Account
CAPITOLO 3 Il linguaggio COWSlite
Riprendiamo la simulazione di un servizio bancario, soffermandoci sul servizio
bancario vero e proprio individuato dal processo bank.
dec{
}
clientEndPoint : partner client "charge"
"http://localhost:8080/bankAccount/clientService?WSDL";
bankEndPoint : partner bank "charge"
"http://localhost:8080/bankAccount/bankService?WSDL";
service{ |(
[CUST:var(String); CC:var(int); AMOUNT:var(int); ID:var(String);]
?("bank", "charge", ).
|(!("bank", "check", ),
+( ?("bank", "checkOk", ).!(CUST, "chargeOK", ),
?("bank", "checkFail", ).!(CUST, "chargeFail", ) )
),
[CUSTID:var(String); CC:var(int); AMOUNT:var(int);]
}
?("bank", "check", ).
)
|(
)
!("bank","o",),
+( ?("bank", "o", ).!("bank", "checkOk", ),
?("bank", "o", ).!("bank", "checkFail", ))
once service { | (
| ( !(bankEndPoint,"charge",),
56

3.3 Esempi
+(?("client", "chargeOk", ).nil ,
?("client", "chargeFail", ).nil)),
| ( !(bankEndPoint,"charge",),
)
}
+(?("client", "chargeOk", ).nil ,
?("client", "chargeFail", ).nil))
Il processo bank è costituito da due endpoint di comunicazione uno esterno corri-
spondente all’operazione charge e uno interno l’operazione check. Il secondo endpoint
ha semplicemente la funzione di simulare se la transazione richiesta è andata a buon
fine ed avvisare dell’eventuale fallimento. Il servizio principale esegue la richiesta e
comunica al client il risultato della transazione utilizzando per la risposta due diver-
si canali di comunicazione corrispondenti a due operazioni che il client deve esporre
(checkOk e checkFail).
Nella parte di dichiarazione sono definiti gli endpoint di comunicazione sui quali
si prevede di mettere in esecuzione i servizi. Questa definizione serve per il processo
client.
57

58
CAPITOLO 3 Il linguaggio COWSlite

Capitolo 4
Implementazione di COWSlite
In questo capitolo descriveremo come è stato realizzato il compilatore COWSlite e
il motore di esecuzione, introducendo le scelte tecnologiche e di progetto effettuate
e gli obiettivi prefissati. Partiremo dalla descrizione di un servizio web definito con
il nostro linguaggio e descriveremo le strutture e i moduli realizzati per l’esecuzione
del suddetto servizio. Infine, ci soffermeremo sulla realizzazione del compilatore che
produce il codice Java [40, 13] che rappresenta il servizio.
4.1 Obiettivi e scelte implementative
Dal momento che sono necessarie più fasi per poter compilare il codice COWSlite,
distribuire il codice Java ottenuto ed eseguire il codice compilato all’interno di un Web
Application Server, anche il nostro progetto dovrà essere suddiviso in più componenti
per poter affrontare tutti i passi definiti nelle varie fasi.
I componenti evidenziati in Figura 4.1 sono:
1. Il motore di esecuzione dei servizi COWSlite che viene ospitato all’interno del
server web e che esegue il codice Java compilato.
2. Il compilatore COWSlite che traduce il codice in Java e fa uso dei servizi messi
a disposizione dal motore.
59

CAPITOLO 4 Implementazione di COWSlite
Figura 4.1: Struttura del progetto
3. Alcuni programmi o script di utilità per agevolare la compilazione e il deploy
del servizio sviluppato.
La realizzazione ha quindi comportato diverse fasi di analisi, progettazione e rea-
lizzazione dei vari componenti del progetto. All’inizio della fase di analisi sono state
fatte delle scelte, la prima, ormai chiara, è il linguaggio di programmazione utilizzato
come target della compilazione. Questa scelta è stata fatta in base a molti parametri
oggettivi: la facilità a reperire compilatori, ambienti di sviluppo e documentazione a
costo zero; la natura open source del linguaggio e quindi la libertà di ridistribuzione
del codice prodotto; la presenza di molte librerie di supporto anch’esse open source.
Un altro aspetto importante è la spiccata propensione di Java verso il networking e
tutti gli aspetti ad esso legati. Java infatti ha da sempre puntato sull’utilizzo del
web come uno dei principali sbocchi per le applicazioni prodotte, introducendo da
subito librerie di sistema dedicate e tecnologie specifiche (basti pensate ad esempio
alle applet). È stato anche uno dei primi linguaggi per cui sono comparsi strumenti
e librerie specifiche per i servizi web. Questo è uno dei motivi principali che hanno
pesato a favore di tale scelta.
Un altro degli obiettivi perseguiti era quello di utilizzare meno materiale di terze
parti possibile: librerie, API, ecc., in modo tale da non dover ridistribuire troppi file
aggiuntivi a corredo del codice prodotto, oppure obbligare il web master ad installare
60

4.2 Un servizio COWSlite in Java
nel server pacchetti aggiuntivi per il supporto del prodotto. Tutto ciò che serve per
costruire ed eseguire l’engine è contenuto nel JDK 1.6, dal momento che le librerie
di supporto ai servizi web sono state inglobate da SUN nella distribuzione ufficiale
proprio in questa release. Le librerie necessarie sono comunque presenti anche nel
pacchetto Metro che è contenuto in molti application server di ultima produzione
come ad esempio Sun Application Server [39] e Glassfish [21].
Per sviluppare il progetto è stato utilizzato l’ambiente di sviluppo open source
NetBeans versione 5.5.1 e i test sono stati effettuati utilizzando gli application server
SUN Application Server Platform Edition 9.0 e Glassfish 2.1.
4.2 Un servizio COWSlite in Java
Quello che vogliamo ottenere è un listato di codice Java, che realizzi il comportamento
specificato da un programma COWSlite. Tale codice una volta compilato deve poter
essere eseguito all’interno di un server web come un comune servizio web prodotto
secondo gli standard e deve poter interagire con altri servizi web presenti nella rete.
Per far ciò è stato necessario realizzare un package di supporto al fine di permettere
l’interfacciamento fra il codice prodotto e il server web su cui verrà eseguito, in modo
da poter scrivere più semplicemente il codice Java che descrive il processo COWSlite.
Il compilatore COWSlite, quindi, produce del codice che utilizza i componenti
definiti nel package per descrivere la logica del servizio, le sue interfacce e tutte le
interazioni e operazioni specificate. Uno dei compiti del package, che d’ora in poi
chiameremo engine o runtime, è quello di separare gli aspetti legati alla comunica-
zione da e verso altri servizi in modo da non doversi preoccupare di considerare tutti
gli elementi necessari all’interazione fra servizi web. Allo stesso tempo deve fornire
un’astrazione per la descrizione e l’esecuzione della logica dei processi e per la gestione
delle variabili, delle etichette e dei dati da scambiare fra i servizi.
La Figura 4.2 mostra tutti i passi necessari per ottenere un servizio che può essere
pubblicato su un server web partendo dal file sorgente contente la descrizione scritta
in COWSlite. Per prima cosa è necessario usare il compilatore COWSlite per
61

CAPITOLO 4 Implementazione di COWSlite
ottenere uno o più file Java che descrivono il servizio. Dopo di che, questi file devono
essere compilati con il compilatore Java, fornendo insieme il package mcows.engine,
in modo da ottenere i file Java eseguibili (.class). Successivamente è necessario re-
cuperare i file compilati, il file .jar contenente la libreria del motore ed alcuni file
XML di descrizione del servizio, organizzarli secondo le specifiche per realizzare una
web application e assemblarli utilizzando l’apposita utilità del JDK per produrre i file
archivio. Con questo file archivio assemblato, avente estensione .war, sarà possibile
eseguire il deploy del servizio su un application server.
Figura 4.2: Compilazione di un servizio COWSlite
Le specifiche dell’API JAX-WS [41] permettono di definire un servizio web tramite
una classe Java seguendo alcuni semplici accorgimenti. L’API in questione fa uso
delle annotazioni, introdotte con la versione 1.5 di Java, per dichiarare che la classe in
questione rappresenta un servizio web e per definire le operazioni esposte e le modalità
di lavoro.
Questo semplifica il lavoro allo sviluppatore in quanto non è più necessario definire
a priori l’interfaccia del servizio da esporre mediante il formato WSDL. Infatti è
62

4.2 Un servizio COWSlite in Java
l’application server stesso che genera la descrizione del servizio esposto in maniera
conforme con le specifiche e lo espone in modo che esso sia disponibile a chiunque
voglia usufruire di tale servizio. Questa caratteristica dell’API si rivela utile anche
agli scopi di questo progetto perché ci permette di non doverci preoccupare di fornire
un WSDL del servizio, dal momento che ci penserà l’application server a farlo per
noi appena il servizio sarà stato distribuito sul server. Quindi non è stato necessario
realizzare funzioni nel package per generare i file WSDL.
Come si vede dal codice in Tabella 4.1, definire un servizio web secondo le specifi-
che è molto semplice con le API fornite da Sun. Un servizio altro non è che una classe
package _nomedelpackage_ ;
import javax . jws . ∗ ;
. . .
@WebService
public class S e r v i z i o {
. . .
public S e r v i z i o ( ) { // C o s t r u t t o r e d e l WS
. . .
/∗ Crea i p r o c e s s i d e l s e r v i z i o . ∗/
CowsProcess f i r s t P r o c e s s = S e r v i c e C r e a t o r ( ) ;
/∗ Esegue i l primo Processo ∗/
f i r s t P r o c e s s . s t a r t ( ) ;
}
}
@WebMethod
@Oneway
public void operazione1 ( S t r i n g x ) {
/∗ esegue l a r i c h i e s t a d i operazione1 ∗/
. . .
}
private CowsProcess S e r v i c e C r e a t o r ( ) {
. . .
/∗ d e s c r i z i o n e d e l s e r v i z i o ∗/
. . .
return ( r i f e r i m e n t o a l l a prima i s t r u z i o n e d e l s e r v i z i o )
}
Tabella 4.1: Codice di un servizio
63

CAPITOLO 4 Implementazione di COWSlite
Java che segue alcune regole e fa uso di annotazioni per marcare i punti principali
della classe. È sufficiente assegnare un nome al package e importare le classi dell’API
JAX-WS; dopo di che con l’annotazione @WebService, posta prima della dichiara-
zione della classe, si dichiara che quella classe dovrà essere convertita in un servizio
web e poi si dichiarano le operazioni esposte anteponendo l’annotazione @WebMethod
alla dichiarazione di ogni metodo, in questo modo durante la compilazione del file la
dichiarazione del metodo con la sua segnatura verrà utilizzata per ricavare tutti gli
aspetti necessari per la realizzazione della Service Endopoint Interface (SEI). L’anno-
tazione @OneWay, presente prima della definizione di un metodo, serve per impostare
l’operazione in modalità ‘sola richiesta’, come vuole appunto la definizione di CO-
WSlite. Infine la parte introdotta da COWSlite è il metodo ServiceCreator()
che conterrà la descrizione del servizio sfruttando le istruzioni fornite nell’API del
runtime.
Il compito del compilatore COWSlite è quello di produrre il codice per il me-
todo ServiceCreator() e riempire il corpo dei metodi che corrispondono alle ope-
razioni esposte dal servizio in modo che inoltrino le richieste all’engine. Vedremo
successivamente con cosa riempire il corpo di questi metodi.
4.3 Il package cowslite.engine
Per poter completare il codice all’interno dello scheletro del servizio visto preceden-
temente si fa uso del package cowslite.engine che è stato realizzato per fornire con-
temporaneamente l’ambiente per l’esecuzione del servizio e una serie di oggetti che
permettono di descriverne la logica di funzionamento.
Il motore di esecuzione dei servizi COWSlite è composto da quattro componenti
principali come illustrato nella Figura 4.3: tre spazi di memorizzazione e un’unità di
comunicazione.
Gli spazi di memorizzazione hanno lo scopo di mantenere le informazioni necessarie
affinché un servizio possa essere eseguito. Questi sono tre perché contengono le unità
fondamentali di un servizio: la descrizione logica del servizio, così come descritta per
64

4.3 Il package cowslite.engine
Figura 4.3: Architettura dell’engine
mezzo della sintassi, che sarà contenuta nello spazio denominato ProcessSpace; i dati
gestiti dal servizio e da ognuna delle istanze in esecuzione che saranno organizzati
in ambienti fra loro correlati e mantenuti in un apposito spazio di memorizzazione
dati denominato DataSpace; le informazioni necessarie per gestire ogni comunicazione
attiva interna ed esterna che saranno mantenute in un apposito spazio denominato
appunto ServiceSpace.
L’unità di comunicazione, che si occupa di mantenere alcune informazioni, invece
fornisce le funzioni per colloquiare con l’esterno interfacciandosi con il server web che
ospita il motore di esecuzione COWSlite.
I tre spazi di memorizzazione sono fra loro collegati perché il contenuto del Da-
taSpace è influenzato dalla logica del processo che genera nuove variabili e nuovi
ambienti in funzione dello stato di esecuzione e contemporaneamente le variabili con-
tenute negli ambienti possono subire modifiche da parte di azioni avvenute nel Ser-
viceSpace o a causa della logica del servizio; il ServiceSpace influenza la logica del
servizio modificando lo stato di esecuzione delle istanze a seguito di modifiche avve-
nute nel DataSpace; infine la logica del servizio non modifica direttamente lo stato
del ServiceSpace, ma lo fa attraverso l’interazione con l’unità di comunicazione.
Ogni richiesta proveniente dall’esterno e ogni attività di ricezione del servizio pas-
sano attraverso il ServiceSpace, dove vengono elaborate oppure archiviate in attesa
65

CAPITOLO 4 Implementazione di COWSlite
di una possibile esecuzione. Il metodo per scegliere e/o selezionare un elemento con-
tenuto all’interno del ServiceSpace è il matching fra una richiesta ed una ricezione.
Se al momento della ricezione di una richiesta esterna è presente una attività di ri-
cezione nel ServiceSpace per cui si ha un matching, le eventuali variabili correlate
con l’operazione vengono aggiornate e si procede con l’attività corrispondente alla
continuazione dell’operazione di ricezione così come definito nello spazio dei processi.
Se non c’è corrispondenza invece la richiesta viene memorizzata all’interno del Ser-
viceSpace. Analogamente, quando dall’esecuzione del servizio COWSlite si ottiene
un’attività di ricezione, questa viene inviata al ServiceSpace che controlla la presen-
za di una corrispondenza con una delle richieste memorizzate e in caso affermativo
la richiesta trovata viene eliminata dal ServiceSpace, quindi vengono aggiornate le
variabili coinvolte nella ricezione e il servizio continua la sua esecuzione. In caso ne-
gativo l’attività viene memorizzata nel ServiceSpace e questo provoca la sospensione
del servizio o del ramo del servizio interessato dall’attivita.
Il ciclo di funzionamento su cui si basa l’engine e in particolare il ServiceSpace si
ispira allo ‘spazio delle tuple’ di Klaim [8, 5, 6], ma mentre Klaim gestisce solo tuple
di dati, COWSlite gestisce i servizi con i relativi dati.
4.3.1 L’unità di comunicazione
Per fornire tutti i servizi di comunicazione l’engine sfrutta le caratteristiche degli
application server all’interno dei quali vengono inseriti i servizi compilati. In questo
modo tutte le invocazioni provenienti dall’esterno sono gestite dal server web e passate
all’engine che non deve preoccuparsi di trattare i dati provenienti dalla connessione,
acquisirli e convertirli. Allo stesso modo le invocazioni di servizi esterni sono gestite
dall’unità di comunicazione per mezzo dell’API JAX-WS [24] associata all’application
server, che fornisce tutto il supporto necessario per inviare sulla connessione i dati
necessari per effettuare la richiesta.
L’unità di comunicazione, come già detto, si occupa di gestire tutte le comuni-
cazioni da e verso il servizio COWSlite. In particolare, il suo compito è quello di
66

4.3 Il package cowslite.engine
trattare le operazioni di invoke e receive del linguaggio, discriminare quali richie-
ste sono dirette internamente al servizio e quali invece sono da richiedere all’esterno.
Parte principale del lavoro dell’unità è quella di occuparsi dell’interfacciamento con i
servizi esterni.
L’aspetto legato alle comunicazioni relative alle invocazioni delle operazioni espo-
ste dal servizio web sono lasciate a totale carico del web application server. Infatti il
server si comporta da fornitore di servizi occupandosi della ricezione della richiesta,
della pubblicazione del servizio e di gestire tutti gli strati dei protocolli di comuni-
cazione in maniera trasparente per lo sviluppatore del servizio, tanto che, come si è
visto nello scheletro di codice del servizio, il programmatore che realizza un servi-
zio dovrà semplicemente preoccuparsi di definire quali, quanti e di che tipo sono le
operazioni e i relativi parametri. Non sarà quindi necessario preoccuparsi di definire
qual è il WSDL che specifica l’interfaccia del servizio, perché questo verrà generato
automaticamente nel momento in cui il servizio verrà distribuito sull’host.
La Figura 4.4 mostra alcune delle classi che compongono l’unità di comunica-
zione. Queste classi rappresentano due aspetti presi in considerazione dall’unità
assolvendo ciascuna un compito ben preciso. Sono suddivisibili in base alla clas-
se di base della gerarchia di ereditarietà: una parte ha come origine l’interfaccia
ComunicationServices, mentre l’altro gruppo deriva dalla classe astratta WsdlModel.
Il blocco che implementa l’interfaccia CommunicationServices, fornisce al siste-
ma tutte le primitive di comunicazione e si interfaccia con il ServiceSpace. Le classi
Comunication e ComunicationSystem sono due implementazioni dell’interfaccia che
si comportano in mainera differente rispetto all’invocazione dei servizi sulla rete, la
classe ComunicationServiceFactory ha lo scopo di inizializzare una delle due im-
plementazioni a runtime. Nell’implementazione corrente l’engine sceglie sempre come
istanza la classe ComunicationService, per cui l’altra può essere considerata soltan-
to un puro esercizio stilistico dell’applicazione del pattern Factory [17] all’interno del
lavoro.
Il blocco che estende la classe astratta WsdlModel, come si può intuire dal nome,
67

CAPITOLO 4 Implementazione di COWSlite
Figura 4.4: Classi del sottosistema di comunicazione
ha lo scopo di rappresentare internamente all’engine il modello WSDL di un servizio.
Anche se è stato ripetuto più volte che la generazione di tali WSDL non è neces-
saria, perchè a carico del framework JAX-WS, per l’invocazione dei servizi richiesti
a server esterni al motore è necessario recuperare e sfruttare la descrizione offerta
dal WSDL per eseguire dei controlli semantici e di consistenza e per costruire cor-
68

4.3 Il package cowslite.engine
rettamente il blocco SOAP da innestare nel Payload della richiesta HTTP. La classe
ServiceProxyFactory ha il compito di generare la rappresentazione dell’interfaccia
descritta dal WSDL sufficiente ai fini del progetto. Gli approcci per la generazione
di tale modello possono essere diversi; quelli comunemente usati con Java sono due e
corrispondo a due modelli di parsing differente, uno sfrutta un parser SAX 1 mentre
l’altro costruisce il DOM 2 a partire dall’XML. Entrambi i metodi hanno pro e con-
tro. Dopo averne realizzata una prima implementazione mediante il modulo SAX, si
è preferito sfruttare il DOM perché, per via della persistenza del modello in memoria,
consente accessi multipli e successivi per la creazione della struttura di supporto a sca-
pito della maggiore occupazione di memoria necessaria. Entrambe le implementazioni
sono comunque presenti all’interno del Factory.
La parte più delicata da trattare delle comunicazioni del servizio COWSlite sono
le invocazioni di servizi diversi da quello locale per cui è necessario interfacciarsi con il
fornitore di servizi e recuperare le informazioni necessarie per realizzare la connessione
e la comunicazione. Per questo tipo di comunicazioni ci si avvale dell’API JAX-WS
ed in particolare della sezione dedicata ai servizi Client. Il package javax.xml.ws
contiene le classi Service, Dispatch e l’interfaccia EndpointReference che permettono
di costruire dinamicamente una chiamata ad un servizio web invocando un’operazione
esposta alla quale è possibile fornire i parametri necessari per mezzo di un messaggio
in formato SOAP inserito all’interno della chiamata.
La prima classe da utilizzare per invocare un servizio esterno è la classe Service.
Questa classe ha il compito di creare un proxy per interfacciarsi con il servizo web
e può essere usata in due modi: statico o dimanico. Con il metodo statico vengono
generate, a partire dal WSDL, una serie di classi che identificano il servizio che deve
essere invocato. Il metodo dinamico viene utilizzato a tempo di esecuzione e con esso
si ottiene un istanza dell’oggetto Service che agisce da proxy per le richieste.
1
SAX [1] (Simple API for XML) è un’API per accedere in maniera seriale ad un documento XML
al fine di leggerne i dati contenuti.
2
Il Document Object Model [20] (DOM) è una convenzione per rappresentare e interagire con
documenti HTML, XHTML e XML per mezzo di un linguaggio indipendente dal linguaggio e dalla
piattaforma.
69

CAPITOLO 4 Implementazione di COWSlite
L’altra classe direttamente utilizzata per invocare un servizio è la classe Dispatch.
Il suo scopo è quello di eseguire lo scambio di messaggi in formato XML fra il servizio
e il cliente. Ha due modi di funzionamento a seconda del controllo che si vuole avere
sui messaggi scambiati: Message e Message Payload. Con il primo il client lavora
direttamente con l’intera struttura del messaggio nello specifico protocollo scelto; con
il secondo tipo invece lavora solamente con la parte di messaggio relativa all’infor-
mazione (Payload); ad esempio se i messaggi scambiati sono di tipo SOAP questo
corrisponde al body del messaggio e non all’intero messaggio.
Come si vede dal codice di Tabella 4.2, per invocare dinamicamente un servizio è
sufficiente istanziare un proxy per mezzo del metodo statico create() fornendo come
parametri l’URL che contiene il file WSDL e un oggetto di tipo QName (Qualified
Name) composto dal nome del servizio e dal namespace nel quale collocare la classe
proxy. Infine tramite l’oggetto Dispatch, creato partendo dal servizio ottenuto, si
invierà la richiesta SOAP utilizzando il metodo invokeOneWay().
URL wsdlLocation = " http : / / . . . . " ;
QName serviceName = new QName( namespace , nomeServizio ) ;
S e r v i c e s = S e r v i c e . c r e a t e ( wsdlLocation , serviceName ) ;
QName p o r t S e r v i c e ;
Dispatch d i s p a t c h =
s . c r e a t e D i s p a t c h ( p o r t S e r v i c e , Source . class ,
S e r v i c e . Mode .PAYLOAD) ;
S t r i n g B u i l d e r contenuto =
. . . D e f i n i z i o n e d e l Payload usando SOAP . . . ;
ByteArrayInputStream b a i s =
new ByteArrayInputStream ( contenuto . t o S t r i n g ( ) . getBytes ( ) ) ;
Source input = new StreamSource ( b a i s ) ;
dispatch . invokeOneWay ( input ) ;
Tabella 4.2: Web Service Proxy con JAX-WS
La struttura del messaggio SOAP da inviare è del tipo riportato in Tabella 4.3.
La parte da inserire nel PAYLOAD del messaggio è quella contenuta all’interno
del tag , nella quale viene specificato il nome dell’operazione e poi,
delimitati da tag appositi, i valori dei parametri.
70

4.3 Il package cowslite.engine
ok
Tabella 4.3: Web Service - Messaggio SOAP
4.3.2 Descrittori di servizio web e variabili
(WsDescriptor e PartnerLink)
Andiamo a guardare più in profondità il blocco relativo al DataSpace.
Un’aspetto molto importante per tutto il package e per l’implementazione del
linguaggio è la memorizzazione e la gestione dei dati. È importante definire i tipi
di dato necessari per descrivere gli oggetti COWSlite e contemporaneamente per
gestire le entità logiche necessarie per l’esecuzione del servizio.
Si presenta quindi la necessità di trovare un modo per descrivere agevolmente e
in maniera omogenea tutti gli elementi del linguaggio a partire dagli elementi più
semplici come etichette, variabili write-once, per arrivare ai partner e ai servizi. Il
requisito importante da seguire nella progettazione è quello di disegnare la struttura
in modo omogeneo perché ciò permette di sfruttare le caratteristiche di ereditarietà
e polimorfismo tipiche del paradigma orientato agli oggetti (Object Oriented), sem-
plificando la realizzazione delle classi per il trattamento dei dati in modo che siano
‘intercambiabili’.
Tra i tipi di dato trattati è stato menzionato anche il servizio che, seppur non
facendo parte dei tipi definiti dal linguaggio, ricopre uno dei ruoli principali all’interno
del linguaggio. Basti pensare che ogni interazione svolta fra le istanze dei servizi o con
i servizi esterni è basata sulla comunicazione di dati attraverso un’operazione esposta
da un servizio.
71

CAPITOLO 4 Implementazione di COWSlite
La Figura 4.5 mostra il diagramma delle classi presenti nel package per trattare i
dati usati in COWSlite. In essa spiccano un’interfaccia e due classi astratte: l’in-
terfaccia DataModel ha lo scopo di definire i metodi per il confronto ed il matching di
tutte le classi che descrivono tipi di dati del linguaggio; la classe astratta LabelModel
è la classe radice di tutta la gerarchia e definisce le caratteristiche comuni a tutti gli
elementi, come ad esempio la possibilità di assegnare un nome ad ogni elemento. Il
nome impostato, tramite le proprietà esposte dalla classe, corrisponde alla stringa
identificativa di un etichetta oppure al nome nel caso di una variabile, di un vettore o
di un partner. I dati veri è propri trattati dal linguaggio sono quelli contenuti nelle va-
riabili write-once, il cui comportamento è espresso dalla classe astratta WOItem, da cui
derivano tutte le classi reali che conterranno le entità memorizzabili con COWSlite
(variabili, vettori e partner).
72
Figura 4.5: Diagramma delle classi delle variabili WO
Label e LabelKiller sono state definite solo in previsione di una estensione

4.3 Il package cowslite.engine
del package che implementi il costrutto di kill e quello di protezione non presenti
nell’attuale versione.
La classe WOVar è la classe che implementa le variabili semplici di tipo write-
once. È una classe parametrica (Generics come viene chiamata in Java) in modo da
poter coprire qualunque tipo di dato, anche se, al momento l’engine supporta solo
due possibilità WOVar(Integer) e WOVar(String). L’uso della classe parametrica
permetterà tuttavia di trattare anche gli altri tipi di dati con uno sforzo minimo. In
Tabella 4.4 è riportata una porzione della classe dove sono evidenziati i due costruttori
principali. L’attributo value è parametrico e contiene la variabile vera e propria. Il
costruttore che opera su questa variabile è quello con due parametri, in cui il primo
è il nome della variabile e il secondo è l’oggetto che rappresenta la variabile. Il
costruttore con un unico parametro ha il compito di inizializzare la classe assegnandole
solamente il nome. Quindi se, ad esempio, vogliamo creare la varibile pippo come
intero contenente il valore 3 utilizzeremo il seguente metodo:
new WOVar("pippo", new Integer(3))
Un altro aspetto in cui si rivela utile questa scelta è nel trattamento delle varia-
bili non valorizzate o, come si direbbe in ambito programmativo, nulle: sono quelle
variabili delle quali è stato definito il nome, il tipo e a cui non è stato ancora as-
segnato un valore. Per trattare questi casi occorrerebbe un elemento che faccia da
segnaposto, in modo da permettere la descrizione del servizio e l’interazione di questi
con il resto delle istruzioni. Altrimenti potrebbe essere più pratico utilizzare gli stessi
oggetti sfruttando la loro definizione tramite generics invece di sostituire a runtime al
momento dell’assegnazione i segnaposti definiti con le variabili istanziate.
Per istanziare questa classe con un tipo di dato preciso occorrerebbe inserirvi
all’interno un oggetto del tipo esatto che la variabile dovrebbe rappresentare, questo
però impedirebbe di poter istanziare variabili di un tipo predefinito senza valore,
dal momento che inizializzare una variabile write-once con un valore ne blocca il
contenuto. Per permettere ciò si ricorre al seguente espediente: si istanzia la variabile
con un oggetto Class del tipo voluto. Così facendo la variabile è istanziata, ha il suo
73

CAPITOLO 4 Implementazione di COWSlite
public class WOVar extends WOItem {
private T value ;
. . .
public WOVar( S t r i n g id ) {
super ( id ) ;
this . setType ( this . g e t C l a s s ( ) . getName ( ) ) ;
s e t = f a l s e ;
this . value = null ;
}
public WOVar( S t r i n g id , T value ) {
super ( id ) ;
i f ( value instanceof Class ) {
s e t = f a l s e ;
this . value = (T) value ;
} else {
s e t = true ;
this . value = value ;
}
}
. . .
}
Tabella 4.4: Costruttori della classe WOVar
nome e il tipo che dovrà contenere rigidamente fissato, ma non esiste un valore ad
essa assegnato.
Ad esempio per un intero si utilizzerà una dichiarazione del tipo
new WOVar("nomevar", new Integer(0).getClass())
mentre per una stringa
new WOVar("nomevar", new String().getClass())
In questo modo l’attributo value della classe WOVar appena creata contiene un
oggetto che non ha valore, ma rappresenta il tipo che gli vogliamo assegnare, non sarà
quindi possibile assegnare un intero ad una stringa e viceversa.
La classe WOVect permette di definire vettori unidimensionali di elementi write-
once, ha un duplice ruolo quello di tipo di dato e quello di contenitore dei parametri
scambiati fra i servizi come vedremo fra poco.
74

4.3 Il package cowslite.engine
La classe Partner è un tipo di variabile COWSlite complesso che serve per
rappresentare la locazione di un servizio inglobando anche i dati necessari per po-
ter contattare il fornitore dei servizi. Quindi oltre alle informazioni necessarie per
individuare l’endpoint di un servizio deve contenere anche quelle per recuperare la
descrizione del servizio (indirizzo del file WSDL) e altre informazioni necessarie per
il collegamento.
Descrittore di servizio (WsDescriptor)
La classe WSDescriptor discende dalla classe WOItem, ma non è un tipo di dato del
linguaggio. Questa classe, che indicheremo col nome di descrittore del servizio è
una delle più importanti di tutto il motore. Il suo compito è quello di presentare e
mantenere tutte le informazioni utili a descrivere ed utilizzare un’operazione esposta
da un servizio. Il suo ruolo è quindi quello di rappresentare le operazioni di invocazione
e ricezione all’interno dello spazio dei servizi, di descrivere le operazioni esposte dal
servizio locale e raccogliere le informazioni necessarie per invocare operazioni fornite
da servizi esterni.
I suoi componenti principali sono il partner, l’operazione e il vettore di dati da
gestire, in quanto elementi che contraddistinguono le operazioni di receive e invoke.
Di questi l’operazione è una stringa contenente il nome, il partner è l’omonimo oggetto
definito nel package e per semplificare le operazioni di matching i parametri sono
contenuti in un vettore write-once (WOVect). Questo permette di confrontare due
WsDescriptor con i metodi definiti nell’interfaccia senza dover implementare nessuna
classe apposita.
All’interno di questa classe sono mantenute anche altre informazioni necessarie
per l’esecuzione dell’intero servizio, come il riferimento ad altri descrittori di servizio
rappresentanti un’operazione di receive che hanno in comune una operazione di scelta
guardata e il riferimento al processo successivo dell’operazione di receive.
75

DataSpace e ambienti annidati
CAPITOLO 4 Implementazione di COWSlite
Il DataSpace non è soltanto un’unità concettuale all’interno dell’engine, ma è anche
un oggetto fisico che riveste un ruolo molto importante nella definizione e nell’esecu-
zione dei processi. Questo oggetto rappresenta un ambiente di esecuzione del servizio
e contiene tutte le variabili alle quali fa riferimento l’istanza in esecuzione. Poiché
l’oggetto implementa il concetto di ambiente ogni istanza del servizio può fare uso di
più istanze di un DataSpace contemporaneamente. Infatti un’altra delle peculiarità
del DataSpace è quella di poter essere annidati. Ogni DataSpace può avere un Data-
Space padre e possedere dei DataSpace figli; l’unico DataSpace senza padre è quello
globale, comune a tutti i servizi. In questo modo è possibile definire la stessa variabile
all’interno di più ambienti e se questi sono fra loro annidati l’unica visibile dal pro-
cesso è quella dell’ambiente più interno. Questo permette di gestire opportunamente
lo scope dei nomi da parte dell’operatore di delimitazione.
Il DataSpace, oltre a contenere e fornire le funzioni per la ricerca e l’accesso alle
variabili, fornisce accesso agli altri elementi dell’engine COWSlite in quanto man-
tiene un riferimento al ServiceSpace di lavoro e al ComunicationSystem. Questa scelta
è stata fatta al fine di ridurre il numero di parametri che dovrebbero essere scambiati
fra i processi per la loro esecuzione. Ogni DataSpace deve comunque conoscere a quale
ServiceSpace è associato il dato per via delle variabili in gioco; resta pertanto facile
sfruttare questo per semplificare le chiamate ai metodi e ai costruttori.
4.3.3 Descrizione del servizio COWSlite
Uno dei problemi affrontati nella realizzazione dell’engine di COWSlite è stato quel-
lo di definire delle modalità per descrivere ed eseguire i servizi. C’era la necessità di
trovare il modo per tradurre il codice scritto in azioni eseguibili e componibili in modo
tale che potessero descrivere la logica del servizio e ad essere contemporaneamente
delle unità eseguibili all’interno dell’engine. Se da una parte le richieste di operazioni
del servizio possono scatenare l’esecuzione dell’interazione, dall’altra è necessario de-
76

4.3 Il package cowslite.engine
scrivere quando e come queste richieste possono essere trattate e in che modo devono
essere eseguite.
L’idea di base è che dal momento in cui i linguaggi (quello che stiamo cercando di
descrivere e quello di programmazione scelto per l’implementazione) sono concorren-
ti, risulta naturale affidarsi al modello multithreading di Java in modo da sfruttare
tutte le caratteristiche e le funzionalità di esecuzione e gestione dei processi messe a
disposizione da quest’ultimo. Partendo da questi propositi il problema diventa come
suddividere le unità di calcolo in modo da permetterne una semplice descrizione in
Java.
Il costrutto di composizione parallela già ci obbliga a pensare che ognuno dei
blocchi concorrenti definiti dovrà essere delegato a un thread diverso. Ciò non è
sufficiente per descrivere all’interno dei thread tutto il resto della logica del servizio in
modo da renderla modulare, componibile e anche di facile traduzione, perché sarebbe
comunque complessa e faticosa la traduzione del codice.
La soluzione adottata è quindi quella di pensare ad ogni singola azione come ad
un thread. Alcune azioni terminano, altre invece hanno come conseguenza una’altra
azione gestita da un thread avviato dall’azione stessa.
Ogni azione verrà chiamata d’ora in poi CowsProcess o processo perché descritta
per merito di una classe derivata dalla classe padre CowsProcess che definisce l’azione
generica.
I processi
Come si vede dal diagramma UML [35] che rappresenta l’insieme dei processi (Fi-
gura 4.6) ogni azione è definita come una classe ed ognuna di queste classi ha come
padre comune la classe astratta CowsProcess. Ogni classe eredita dalla classe padre
la caratteristica di essere una classe di tipo Thread e tutte le operazioni necessarie
per eseguire lo start-up del thread all’interno dell’engine, insieme alla definizione di
altre operazioni di contorno.
77

CAPITOLO 4 Implementazione di COWSlite
Figura 4.6: Diagramma delle classi dei processi COWSlite
Il fatto di avere una classe padre permette di sfruttare il polimorfismo degli oggetti
ottenendo così che tutte le classi derivate hanno un tipo comune. Ciò consente di poter
comporre fra loro le azioni, perché permette di scrivere cose del tipo
|(CowsP rocess, CowsP rocess) oppure
?(p, o, < data >).CowsP rocess
dove CowsP rocess è uno qualunque dei possibili processi.
Un altro scopo della classe CowsProcess è quello di definire un’interfaccia co-
mune per tutte le operazioni definendo un’insieme di metodi che tutte le classi de-
rivate (in questo caso ogni singola azione) devono ridefinire per fornire il corretto
comportamento all’interno dell’engine.
Osservando il codice della classe CowsProces (Tabella 4.5) si può notare che
ogni sottoclasse dovrà obbligatoriamente implementare quattro metodi: execute(),
changeDS(...), isDestroing() e clone(). Di questi il principale è execute() che
78

4.3 Il package cowslite.engine
package cows . engine ;
public abstract class CowsProcess
extends Thread implements Cloneable {
boolean d e s t r o i n g , e x e c u t i n g ;
private DataSpace wds ;
public CowsProcess ( ) {
super ( ) ;
e x e c u t i n g = f a l s e ;
d e s t r o i n g = f a l s e ;
}
public CowsProcess ( DataSpace ds ){
this ( ) ;
setWds ( ds ) ;
}
f i n a l public void run ( ) {
// R e g i s t r a i l processo n e l ServiceSpace
wds . g e t S e r v i z i ( ) . addProcess ( this ) ;
e x e c u t i n g = true ;
try{
execute ( ) ;
} catch ( CowsException ce ){
ce . printStackTrace ( ) ;
} f i n a l l y {
e x e c u t i n g = f a l s e ;
//Rimuove i l processo n e l ServiceSpace
wds . g e t S e r v i z i ( ) . removeProcess ( this )
d e s t r o i n g = true ;
}
}
public DataSpace getWds ( ) {return wds ; }
public void setWds ( DataSpace l d s ) { this . wds = l d s ; }
// da d e f i n i r e n e l l e c l a s s i d e r i v a t e .
public abstract void execute ( ) throws CowsException ;
public abstract void changeDS ( DataSpace nds ) ;
public abstract boolean i s D e s t r o i n g ( ) ;
public abstract Object c l o n e ( ) ;
}
Tabella 4.5: Classe CowsProcess
viene eseguito al momento dell’esecuzione del thread (viene infatti richiamato nel me-
todo run()) e contiene le istruzioni che realizzano il comportamento dell’operazione
determinata. Gli altri metodi devono essere definiti per eseguire una corretta clona-
zione dell’oggetto, per definire il comportamento del processo quando viene eseguito
all’interno di un altro DataSpace e per eseguire la corretta terminazione del processo.
79

CAPITOLO 4 Implementazione di COWSlite
Oltre ai metodi da definire, la classe CowsProcess ha un costruttore con parametro
DataSpace; questo serve per inizializzare la porzione di dati comune a tutti i processi
con il riferimento al DataSpace a cui deve riferirsi il processo. Come si vedrà in se-
guito ogni sottoclasse insieme ai parametri del costruttore richiederà il DataSpace di
lavoro. Unica eccezione è la classe che identifica il processo nil; dal momento che nil
è un processo vuoto che serve ad indicare la terminazione di un ramo non è necessario
fornire nessun riferimento.
Per poter scrivere la logica del servizio COWSlite mediante un blocco di codice
Java che sfrutta le classi che descrivono i processi, sono necessarie altre entità ed altre
informazioni. WsDescriptor e WOVect sono utilizzate per gestire le comunicazioni ed
i dati scambiati, le azioni sono concatenate utilizzando la classe base CowsProcess,
oppure nel caso di più azioni delle semplici liste di CowsProcess. Per realizzare il com-
portamento desiderato le classi dell’unità ProcessSpace si interfacciano soltanto con
il DataSpace e indirettamente con l’unità di comunicazione e il ServiceSpace oppure
con altre classi di tipo CowsProcess.
Ogni classe che estende CowsProcess deve implementare la propria azione
ridefinendo il metodo execute() nel seguente modo:
ReceiveProcess Inserisce il descrittore del servizio e la sua continuazione
nel ServiceSpace, attraverso un metodo apposito fornito dall’unità di
comunicazione.
InvokeProcess Esegue il descrittore del servizio se esterno, altrimenti lo inse-
risce nel ServiceSpace, attraverso un metodo apposito fornito dall’unità di
comunicazione.
NilProcess Non fa niente.
DelimitationProcess Crea un DataSpace annidato a quello corrente contenente le
80
variabili definite nel corpo della definizione e modifica il DataSpace di lavoro dei
processi successivi con quello creato.

4.3 Il package cowslite.engine
ReplicationProcess Esegue un numero di copie specificato del processo in thread
separati, avviando nuove copie appena terminano le altre in modo che siano
sempre attive un numero di copie. È stata imposta questa limitazione per non
avviare un numero infinito di thread.
ParallelProcess Esegue i thread di tutti i processi che devono essere eseguiti in
parallelo.
ChoiceProcess Inserisce nel ServiceSpace tutti i descrittori dei servizi che fanno
parte della scelta guardata collegandoli fra loro. E’ una specie di receive iterata
che collega fra loro i descrittori.
La classe AssignProcess è differente dalle altre appena elencate. Il suo compito
è quello di permettere l’assegnazione di valori alle variabili e l’esecuzione della valu-
tazione delle espressioni. Dal momento in cui le espressioni sono definite all’interno
del codice non è possibile sapere a priori quale sarà la forma di tale processo, quindi
AssignProcess è una classe astratta che implementa i metodi di base necessari all’e-
secuzione del costrutto senza specificare però qual’è l’espressione in esso contenuta.
Sarà quindi necessario costruire una classe apposita che estende AssignProcess per
ogni assegnazione presente nel codice in modo che ognuna implementi l’assegnazione
dell’espressione descritta dal costrutto.
Per costruire la logica del servizio per ognuna delle azioni sopra descritte dovrà
essere inserito un blocco di codice all’interno del metodo ServiceCreator(), partendo
dall’ultima azione definita fino ad arrivare alla prima, percorrendo l’albero che descrive
il processo in senso inverso dalle foglie alla radice.
I codici presenti nelle Tabelle dal 4.6 a 4.12 rappresentano i modelli di codice che
deve essere scritto all’interno del metodo ServiceCreator() al fine di implementare
la logica definita.
Nei codici presentati nelle tabelle sono usati dei segnaposti che stanno ad indicare
particolari porzioni di codice di cui descriviamo adesso il significato.
81

CowsProcess cpxxx = null ;
WOVect vxxx = new WOVect( data . l enght ) ;
CAPITOLO 4 Implementazione di COWSlite
vxxx . insVar ( (WOVar) x−x ) ; // data . l e n g h t v o l t e
WsDescrioptor wdxxx = new WsDescriptor (xVx , "x" , vxxx ) ;
wdxxx . setContinuazione ( cpyyy ) ;
cpxxx = new ReceiveProcess ( wdxxx , ds ) ;
Tabella 4.6: Receive - ?(partner,operation,).continuazione
CowsProcess cpxxx = null ;
WOVect vxxx = new WOVect( data . l enght ) ;
WsDescriptor wdxxx = ( WsDescriptor ) ddd . c l o n e ( ) ;
cpxxx = new InvokeProcess ( wdxxx , vxxx , ds ) ;
Tabella 4.7: Invoke - !(partner,operation,)
cpxxx definisce il nome della variabile associata al processo come concatenazione
del prefisso cp e di un numero rappresentante un progressivo che individua l’azione.
vxxx definisce il nome di una variabile, anche per questa il suffisso xxx è un
contatore in modo che tutte le variabili siano definite univocamente. Lo stesso vale
anche per wdxxx relativa ai WSDescriptor, mentre ds è riferita ai DataSpace, ddd al
descrittore di servizio e xVx individua un Partner.
cpyyy individua il processo cows che deve essere inteso come successore di quello
di cui viene prodotto il codice dove yyy rappresenta una altro valore numerico iden-
tificativo. x-x indica una variabile recuperata dal DataSpace o un valore costante
generato.
DataSpace dsx = new DataSpace ( ds ) ;
dsx . addVariable (new WOVar( " x i " ,new I n t e g e r ( 0 ) . g e t C l a s s ( ) ) ) ; //OR
dsx . addVariable (new WOVar( " x i " ,new S t r i n g ( ) . g e t C l a s s ( ) ) ) ; //
CowsProcess cpxxx = null ;
cpxxx = new D e l i m i t a t i o n P r o c e s s ( cpyyy , dsx ) ;
82
Tabella 4.8: Delimitation - [x1,...,xn]p

4.3 Il package cowslite.engine
CowsProcess cpxxx = null ;
cpxxx = new R e p l i c a t i o n P r o c e s s ( nproc , ds , n ) ;
Tabella 4.9: Replication - *[n](p)
CowsProcess cpxxx = null ;
List cplxxx = new ArrayList();
cplxxx . add ( nproc ) ; //2 v o l t e
cpxxx = new P a r a l l e l P r o c e s s ( cplxxx , ds ) ;
Tabella 4.10: Parallel - |(p1,p2)
Per quanto riguarda il processo di tipo receive (4.6) la riga commentata deve
essere ripetuta per ogni variabile definita come parametro della receive cioè esat-
tamente data.length volte. Allo stesso modo per i processi tipo parallel (4.10) e
choiche (4.11) il codice relativo alla riga commentata con 2 volte sta a significare che
deve essere ripetuta per ognuno dei due processi coinvolti nell’operazione. Invece per
il processo di tipo delimitation (4.8) le righe commentate con OR stanno ad indicare
che deve essere usato uno dei costrutti per ogni variabile indicata nella delimitazione
tenendo conto del tipo della variabile (se intero o stringa).
Utilizzare i thread in Java è comunque una scelta che porta a fare diverse conside-
razioni. Tanto per cominciare i thread vengono allocati all’interno della Java Virtual
Machine al momento della creazione e la abbandonano solo dopo la loro terminazione;
in più con le ultime versioni della Virtual Machine sono stati deprecati i metodi rela-
tivi alla distruzione e alla terminazione forzata di un thread per motivi di sicurezza
e di stabilità. Questo implica che un elevato numero di thread, di cui molti bloccati
in attesa di essere eseguiti o di essere terminati, potrà provocare rallentamenti nell’e-
secuzione a causa dell’elevata occupazione di risorse. Questo è un prezzo da pagare
che può essere ridotto da una gestione oculata del numero di thread, facendo sì che
i thread che rappresentano processi non eseguiti (tipo le continuazioni delle scelte
guardate non selezionate) vengano terminati facendoli eseguire come processi vuoti.
Il disegno della architettura con una classe base derivata da un thread comporta
83

CAPITOLO 4 Implementazione di COWSlite
CowsProcess cpxxx = null ;
List cplxxx = new ArrayList();
cplxxx . add ( nproc ) ; //2 v o l t e
cpxxx = new ChoiceProcess ( cplxxx , ds ) ;
CowsProcess cpxxx = null ;
cpxxx = new Assxxx ( cpyyy , ds ) ;
Tabella 4.11: Choice - +(p1,p2)
Tabella 4.12: Assign - x:=exp
diversi aspetti favorevoli. Ogni azione è un thread e quindi la sua esecuzione è indi-
pendente da tutte le altre azioni, inoltre ogni azione è in uno stato di stand-by fino a
che non viene esplicitamente eseguita. Inoltre essendo tutta inglobata in un thread,
deve solo preoccuparsi di avviare l’azione successiva che per la macchina virtuale è a
sua volta in stand-by. Questo comporta che non deve esserci un gestore aggiuntivo
che si preoccupi di far partire e mettere in attesa i thread nel momento in cui l’azione
che vi è rappresentata deve essere disabilitata. Il codice che produce l’effetto della
singola azione è comunque composto da poche istruzioni, quindi ogni thread per essere
eseguito completamente non ha bisogno di un tempo di esecuzione molto lungo.
Questa elevata modularità facilita la scrittura della logica mediante la semplice
composizione delle azioni, facendo sì che il codice da scrivere sia molto semplice e
quindi si riduce la probabilità di produrre codice Java non funzionante.
Infine il codice di questa unità dell’engine risulta di più semplice manutenzione e
permette di estendere l’engine semplicemente aggiungendo nuove classi che eseguano
il comportamento di azioni finora non definite.
4.3.4 Spazio dei servizi
Lo spazio dei servizi è l’oggetto all’interno del quale viene gestito il servizio. In esso
vengono inserite e confrontate le richieste e le attività di ricezione, viene mantenuta
84

4.4 Generazione del compilatore
l’origine del DataSpace principale, quello in cui sono contenute le variabili globali
definite per il servizio. Esso sfrutta e maneggia tutte le classi del package principale,
i DataSpace, le variabili, i processi e i servizi di comunicazione. È costituito da due
insiemi disgiunti di descrittori di servizio: uno per raccogliere le richieste pendenti in
entrata e uno per le attività di ricezione in attesa. È critico perché da esso dipen-
dono le prestazioni dell’intero servizio e in esso possono verificarsi problemi di accesi
concorrenti poiché è soggetto ad accessi multipli da parte di tutti i thread.
Concorrenza
Alcuni aspetti della concorrenza non vengono trattati perché demandati nella loro
gestione allo scheduler del sistema operativo, della virtual machine e dell’application
server. Questo semplifica enormemente lo sviluppo dell’engine. L’oggetto più critico
nei confronti della concorrenza a questo punto è proprio il ServiceSpace ed in par-
ticolare l’accesso alle due liste contenti i servizi pendenti. Anche qui ci si affida al
modello di threading offerto da Java ed in particolare alle primitive di sincronizzazione
definendo i metodi e le proprietà interessate come syncronized.
4.4 Generazione del compilatore
Per realizzare il compilatore del codice COWSlite è stato utilizzato SableCC [16].
SableCC è un compilatore di compilatori, cioè un strumento sviluppato per costruire lo
scheletro di un compilatore, automatizzando la creazione di tutti quei componenti che
costituiscono l’infrastruttura di analisi del linguaggio, i metodi di verifica del codice
e la trasformazione in un altro linguaggio sia esso codice eseguibile, un linguaggio
intermedio (ad es. bytecode o MSIL) o un’altro linguaggio di programmazione.
Partendo dalla descrizione del linguaggio mediante una grammatica scritta con
le espressioni regolari e la EBNF, SableCC produce una rappresentazione del pro-
gramma che si vuole compilare generando l’albero sintattico astratto (AST) ottenuto
dal parsing del codice. L’albero così ottenuto è fortemente tipato e questo assicura
85

CAPITOLO 4 Implementazione di COWSlite
che l’albero non possa essere corrotto attraverso manipolazioni successive. Inoltre
fornisce gli strumenti per implementare le successive fasi che permettano l’analisi e
la compilazione del codice, producendo delle classi apposite con lo scopo di separare
fra loro tutti gli aspetti sia da un punto di vista di codifica delle operazioni che di
memorizzazione delle informazioni utilizzate da ogni passo di analisi.
La Figura 4.7 è un esempio di AST generato mediante SableCC rappresentante
un’espressione matematica data una grammatica per il riconoscimento. La gramma-
tica usata nell’esempio è presente in molti esempi in letteratura ed è analoga alla
sezione espressioni descritta per COWSlite (Tabella 3.6).
Figura 4.7: AST generato per l’espressione (45 + 36/2) ∗ 3 + 5 ∗ 2
Il codice generato da questo compilatore consiste in una serie di classi in linguag-
gio Java che rappresentano le entità sintattiche del linguaggio e da altre classi che
86

4.4 Generazione del compilatore
forniscono i metodi per analizzare il sorgente del linguaggio descritto. Il codice così
ottenuto è già funzionante e per lo sviluppatore che utilizza il framework è sufficien-
te specificare le azioni corrispondenti agli elementi lessicali definiti all’interno della
descrizione.
SableCC fa parte di una classe di programmi molto utilizzata dai programmatori
fra cui possiamo ricordare Lex/YACC [27, 23], PCCTS [36] ed altri specifici del mondo
Java come JavaCC [22].
L’approccio utilizzato da SableCC di costruire un framework object oriented per la
realizzazione del compilatore rende più semplice la manutenibilità del codice prodotto,
permettendo di correggere eventuali errori o effettuare modifiche sul codice scritto
dallo sviluppatore, ad esempio nuovi metodi di analisi e ottimizzazione, senza toccare
il framework a meno che non vengano effettuate modifiche sul linguaggio. Anche in
questo caso è sufficiente modificare il file di specifica che descrive la grammatica e
rigenerare il framework. Tale struttura permette di realizzare facilmente compilatori
multipassata come avviene nella gran parte dei compilatori moderni. Tutto il lavoro di
verifica e produzione del codice è reso più semplice dal fatto che il framework produce
un AST sul quale lavorano le classi prodotte dallo sviluppatore demandate all’analisi
e alla produzione del codice.
SableCC si occupa però solo della definizione lessicale e grammaticale del
linguaggio e non della parte semantica.
Il framework fa uso di pattern di progettazione Object Oriented per assicurare la
modularità del codice, ad esempio l’AST è prodotto sfruttando il pattern visitor [17].
I passi necessari per costruire un compilatore con SableCC sono:
1. Creare un file contenente la specifica SableCC in cui è definita la sintassi e la
grammatica.
2. Lanciare SableCC con il file contenete la specifica per generare il framework.
3. Creare una o più working classes, possibilmente estendendo quelle generate da
SableCC.
87

CAPITOLO 4 Implementazione di COWSlite
4. Creare una classe generale per il compilatore in cui vengono attivati il lexer, il
parser e le working classes.
5. Compilare il tutto con Java.
Con il termine working classes si intendono tutte le classi che contengono il nucleo delle
funzionalità del compilatore, queste classi possono essere analizzatori, trasformazioni
dell’AST o semplicemente dei generatori di codice.
Il file di specifica è un file di testo che contiene la definizione lessicale e le produzioni
che descrivono il linguaggio che deve essere riconosciuto.
4.4.1 Componenti di SableCC
I componenti principali del framework sono:
1. Lexer: è il componente che si occupa del riconoscimento dei token del linguag-
gio e della corretta costruzione sintattica del codice. La classe prodotta nel
framework che assolve questo compito porta lo stesso nome ed è sufficiente a
svolgere il compito.
2. Nodo: è la classe base dalla quale sono costruite tutte le produzioni e i token
del linguaggio e che verranno usati come elementi dell’albero sintattico astratto.
3. Parser: sfrutta il lexer, o più precisamente le informazioni in output dal lexer
per produrre in base alle produzioni, l’AST strutturato mediante le classi figlie
della classe Nodo.
4. Analisys (AST walkers): sono una serie di classi che forniscono metodi per at-
traversare l’albero sintattico prodotto dal parser. Estendendo opportunamente
una o più di queste classi si costruisce il compilatore.
Ognuno di questi elementi è identificato da una o più classi all’interno del
framework e corrispondo agli elementi definiti nel file di specifica della grammatica.
Per rendere possibile la produzione e l’analisi del codice è necessario che i nomi
assegnati agli oggetti rappresentanti gli elementi del linguaggio (i nodi dell’AST)
88

4.4 Generazione del compilatore
siano uniformi, per questo SableCC definisce delle precise regole per l’assegnazione
di tali nomi (Name Rules). Tali nomi rappresenteranno i nodi e determineranno la
nomenclatura dei metodi presenti negli AST walkers.
Name Rules
• Ad ogni classe produzione è assegnato il nome della produzione preceduto da
una P maiuscola, e trasformato rendendo maiuscola la prima lettera e tutte
quelle precedute da una sottolineatura e cancellando le sottolineature.
• Se una produzione ha una sola alternativa senza nome, la classe corrispondente
all’alternativa ha lo stesso nome della produzione con una A maiuscola al posto
della P.
• Se le alternative sono più di una, solo una può essere senza nome, tutte le altre
devono avere un nome e tale nome è inserito come prefisso dopo la A seguendo
le stesse regole usate per il nome della produzione.
• Gli elementi vengono indicati con il nome stesso a meno che non compaiano più
di una volta all’interno della produzione, in questo caso devono avere un nome
e questo nome è usato come prefisso in modo analogo a quanto fatto nei casi
precedenti.
SableCC non da accesso diretto agli elementi, ma fornisce dei metodi accessori con-
formi allo standard Java (setxxx e getxxx). La presenza di tali metodi ha lo scopo
di impedire che venga corrotta la struttura dell’AST che potrebbe avvenire fornendo
un accesso diretto alla struttura.
File di specifica della grammatica
Il file di specifica di SableCC è composto da 6 sezioni: package, helper, stati, token,
token ignorati e produzioni. I primi quattro influenzano il lexer, mentre gli ultimi tre e
il package interessano il parser. Alcune sezioni quindi hanno a che vedere con entrambi
89

CAPITOLO 4 Implementazione di COWSlite
i componenti di SableCC, ma la cosa non sorprende perché i token, essendo i tasselli
che compongono il linguaggio, devono essere tenuti in considerazione da entrambi,
mentre la sezione package non è direttamente collegata al linguaggio, ma si riferisce
al codice Java prodotto (infatti serve per dare un nome al package che conterrà le classi
generate). Ogni sezione ha un proprio insieme di regole per specificare gli aspetti del
linguaggio. Mentre le sezioni token, token ignorati e produzioni si riferiscono agli
elementi di una grammatica, è necessario chiarire il significato delle due sezioni non
ancora citate. La sezione helper permette di definire degli insiemi di caratteri o delle
espressioni regolari. L’uso che se ne fa è simile alle macro definite in molti compilatori
se non per la differenza che la sostituzione degli identificatori definiti è semantica e non
statica. La sezione stati invece permette di definire un’automa a stati finiti all’interno
dell’insieme dei token, assegnando ad ogni token un insieme di stati in modo tale che
durante il riconoscimento dei token il lexer possa eseguire altre operazioni sul codice
analizzato in funzione di tali stati.
Una volta scritta la grammatica nel file di specifica potrebbe essere sufficien-
te estendere uno degli attraversatori inserendo nella nuova classe le operazioni per
produrre il codice.
4.4.2 Generazione del codice
La grammatica completa che implementa COWSlite in formato SableCC è riportata
in appendice. Le porzioni di codice su cui soffermarsi sono quelle che descrivono le
dichiarazioni e i processi. Osservando questi due blocchi possiamo notare che non c’è
molta differenza con quanto descritto nella Tabella 3.6, infatti sia la notazione usata
nella descrizione che quella di cui fa uso SableCC sono tutte derivate dalla EBNF,
con le seguenti differenze:
90
• Le scelte all’interno di una regola devono avere un nome che le distingue dalle
altre, questo nome è indicato fra parentesi graffe all’inizio dell’alternativa della
produzione. Ad esempio :
prec_process =

4.4 Generazione del compilatore
{precedence} l_par process r_par |
{normal} process;
• Nel caso di termini duplicati all’interno di una delle alternative della produzione
anche questi devono essere distinti fra loro mediante un nome racchiuso fra
parentesi quadre. Ad esempio:
choice =
{choice} plus r_par [left]:choice comma [right]:choice l_par |
...
• I token del linguaggio non sono direttamente scritti nelle produzioni ma sono
indicati tramite alias rispetto a quelli specificati all’interno dell’apposito blocco
di definizione.
Da questo file di specifica vengono generate per mezzo del compilatore una serie
di classi che rappresenteranno gli elementi della grammatica e ci permetteranno di
costruire un albero raffigurante il codice che vogliamo interpretare.
Una volta ottenuto l’albero dal parsing del codice è possibile, con una o più passate
su di esso, produrre il codice voluto come risultato della compilazione. In questo caso
è stato sufficiente implementare un’unica classe attraversatrice che scandisce l’albero
con un logica depth first e costruisce il codice durante la scansione.
L’idea con cui si procede nella scansione è la seguente.
La prima receive incontrata all’interno del blocco service sarà quella che darà il
nome al servizio e che verrà considerata come l’endpoint principale con il quale espor-
re il servizio. Tutte le altre receive verranno considerate come operazioni fornite
dallo stesso servizio e saranno considerate esterne solo se si trovano a livello più alto
nell’AST, che è lo stesso livello della prima receive che è stata incontrata. Inoltre
solo le operazioni che vengono considerate esterne devono fare in modo che venga
avviata una nuova istanza del servizio definito. In particolare tutte le operazioni che
devono essere esposte dovranno avere lo stesso partnerName per portare a termine
91

CAPITOLO 4 Implementazione di COWSlite
la compilazione. Questa scelta deriva dal fatto che una volta che un servizio viene
compilato in Java, questi deve avere un unico nome che viene utilizzato dall’applica-
tion server per raggruppare le operazioni da esso fornito all’esterno. Quindi quando
il compilatore trova delle receive all’interno del codice dovrà comportarsi in modo
diverso rispetto a tutti gli altri processi trovati durante l’analisi.
Ogni processo viene numerato durante la fase discendente della scansione, in que-
sto modo ognuno di essi ha un riferimento numerico differente da tutti gli altri e
questo ci consente di identificarlo in maniera univoca. Durante questa fase vengono
allocate tutte le informazioni ricavate dalla scansione all’interno di appositi oggetti
di appoggio definiti nel package mcows.compiler ognuno di questi oggetti rappresen-
tante gli elementi verrà successivamente interrogato durante la fase ascendente della
scansione.
Il package mcows.compiler contiene la classe che implementa l’attraversatore, che
è il cuore del compilatore, più alcune classi di supporto alla compilazione. Tali classi
sono:
CowsTranslator Classe principale del compilatore che esegue la traduzione in Ja-
va mediante l’attraversamento dell’AST, estende la classe DepthFirstAdapter
creata con SableCC.
Dato Contiene le informazioni sui parametri scambiati con i descrittori.
Operazione Identifica un operazione trovata all’interno del codice, sia essa una
richiesta o un’invocazione.
Servizio Mantiene le informazioni di stato per il servizio che stiamo compilando.
Processo Mantiene le informazioni sui processi trovati durante la scansione.
Assegnazione Contiene il codice che dovrà essere generato per eseguire la
valutazione dell’espressione e la sua successiva assegnazione.
Tutte queste classi contengono dei metodi per produrre il codice Java da inserire nel
listato finale.
92

4.4 Generazione del compilatore
La particolarità della scansione depth first è che ogni ramo viene scandito sempre
fino alla foglia prima di cominciare a risalire e questo fa si che al termine della scan-
sione di ogni singolo ramo sia possibile scrivere una porzione di codice completo che
rappresenta la logica indirizzata partendo dall’azione terminale fino al principio.
Quindi durante la fase ascendente si hanno tutte le informazioni relative alla par-
te terminale del codice che possono quindi essere agganciate al processo che viene
prodotto per costruire una porzione di descrizione della logica completa fino al pun-
to in cui sta avvenendo l’analisi. Il codice viene costruito con un approccio di tipo
bottom-up. Per spiegare più chiaramente questo concetto prendiamo degli esempi:
Come primo esempio prendiamo due azioni di invocazione eseguite in parallelo
( | (!(p1, o1, ), !(p2, o2,)) )
con x1, x2 istanziate altrove con un valore assegnato e scriviamo il codice COWSlite
nel modo più semplice possibile, tralasciando ai fini dell’esempio la parte relativa alla
definizione delle variabili. Il codice da riconoscere diventa il seguente:
service{|( !(p1,o1,),!(p2,o2,))}
L’albero AST generato dal parser per mezzo delle classi generate con SableCC e
raffigurato in Figura 4.8.
Seguendo un ordine depth first per l’attraversamento dell’albero si nota che il
primo elemento di tipo process incontrato è quello relativo al costrutto parallelo che
quindi avrà come progressivo 1, poi l’invoke sul partner p1 che avrà progressivo 2 ed
infine quella sul partner p2 che avrà progressivo 3. Allo stesso modo il primo blocco
process completato sarà quello relativo alla invoke con partner p1, poi quello con
partner p2 e infine il blocco che descrive la composizione parallela dei due processi.
Il codice da inserire nel metodo ServiceCreator() è riportato in Tabella 4.13.
Osservandolo possiamo notare che partendo dal basso troviamo prima il blocchi di
codice generato relativo all’istruzione parallel e poi i due blocchi relativi alle due
istruzioni di invoke, in questo modo al momento della definizione alle due istruzioni
invoke viene assegnato un identificativo che è passato successivamente al blocco che
93

CAPITOLO 4 Implementazione di COWSlite
Figura 4.8: Albero AST per il costrutto Parallel
le mette in parallelo. Le due righe all’inizio del metodo sono sempre le stesse e servono
per inizializzare correttamente il DataSpace di lavoro; infatti mainDS è un riferimento
al DataSpace principale a cui fa riferimento il servizio.
L’altro costrutto che prendiamo in esame è quello relativo all’operatore di scelta
condizionata (Choice) del tipo
+(?(p1, o1, < x1 >).nil, ?(p1, o1, < x2 >).nil)
supponiamo che x1 e x2 siano variabili definite in qualche passo precedente e che le
loro istanze abbiano dei valori fissati, tralasciando la parte di definizione delle variabili
in COWSlite possiamo ipotizzare un codice di questo tipo.
service{ +(?(p1,o1,).nil,?(p1,o1,).nil)}
94

4.4 Generazione del compilatore
private CowsProcess S e r v i c e C r e a t o r ( ) {
DataSpace ds ; /∗ modello d e l ds per i l s e r v i z i o ∗/
ds = new DataSpace (mainDS ) ;
/∗ DataSpace D e l i m i t a t i o n ∗/
/∗ Invoke ∗/
CowsProcess cp3 = null ;
WOVect v3 = new WOVect ( 1 ) ;
v3 . insVar ( (WOVar) ds . f i n d V a r i a b i l e ( "x2" ) ) ;
WsDescriptor wd3 = ds . findWsDVar ( "p2" ) ;
cp3 = new InvokeProcess (wd3 , v3 , ds ) ;
/∗ Invoke ∗/
CowsProcess cp2 = null ;
WOVect v2 = new WOVect ( 1 ) ;
v2 . insVar ( (WOVar) ds . f i n d V a r i a b i l e ( "x1" ) ) ;
WsDescriptor wd2 = ds . findWsDVar ( "p1" ) ;
cp2 = new InvokeProcess (wd2 , v2 , ds ) ;
/∗ P a r a l l e l ∗/
CowsProcess cp1 = null ;
List cpl1 = new ArrayList();
cpl1 . add ( cp2 ) ;
cpl1 . add ( cp3 ) ;
cp1 = new P a r a l l e l P r o c e s s ( cpl1 , ds ) ;
return cp1 ;
}
Tabella 4.13: Esempio di codice generato per la logica del servizio
Come possiamo vedere dalla Figura 4.9, l’albero AST risultante dal parsing è ana-
logo a quello ottenuto per l’esempio precedente e quindi anche il codice da inserire
nel metodo ServiceCreator() sarà analogo. Questa volta, però, ci sono altri par-
ticolari da evidenziare che non sono direttamente connessi al codice della logica, ma
che coinvolgono la costruzione del servizio web vero e proprio.
In questo caso, oltre alla compilazione del codice per il metodo ServiceCreator(),
devono essere inseriti altri blocchi di codice all’interno della classe che stiamo generan-
do per rappresentare il nostro servizio. In particolare dovrà essere controllato che il
nome del partner definito nelle operazioni di receive coincida con quello assegnato al
servizio; se il nome dato al servizio corrisponde allora stiamo definendo un’operazione
del servizio e quindi deve essere verificato se tale operazione è già stata trovata oppure
no, per non scrivere più volte la sua definizione; se invece il nome del servizio non è
95

CAPITOLO 4 Implementazione di COWSlite
Figura 4.9: Albero AST per il costrutto Choice
stato definito allora il compilatore prenderà il nome trovato come nome da assegnare
al servizio e quindi definirà l’operazione trovata come metodo da esporre.
Il codice inserito nella classe che definisce un nuovo metodo da esporre è del
tipo indicato in Tabella 4.14. In questo caso il codice corrisponde proprio a quello
generato per l’operazione o1 dell’esempio. Se nel codice fossero state presenti più
azioni di receive con indicate operazioni diverse il compilatore avrebbe generato più
blocchi di questo genere; uno per ogni operazione trovata.
Le operazioni trovate vengono via via accumulate per mezzo della classe di ap-
poggio Operazione e solo alla fine della scansione di tutto l’albero viene generato il
96

4.4 Generazione del compilatore
@WebMethod
@Oneway
public void o1 ( S t r i n g x1 ) {
WOVect v = new WOVect ( 1 ) ;
v . insVar (new WOVar( null , x1 ) ) ;
i f ( ! CS . r e q u e s t (new WsDescriptor ( locPartner , "o1" , v ) ) ) {
S e r v i c e C r e a t o r ( ) . s t a r t ( ) ;
}
}
Tabella 4.14: Esempio di codice generato per la scelta condizionata
codice che crea i metodi rappresentanti le operazioni.
La parte di listato riguardante le dichiarazioni globali genererà un blocco di co-
dice nel quale viene definito il DataSpace primario, chiamato mainDS con allocate
all’interno tutte le variabili definite nel blocco dec {...}.
97

98
CAPITOLO 4 Implementazione di COWSlite

Capitolo 5
Uso di COWSlite
In questo capitolo descriveremo l’uso degli strumenti realizzati soffermandoci sull’uti-
lizzo e su alcuni accorgimenti di programmazione del linguaggio COWSlite (eviden-
ziando limiti e possibilità dell’implementazione). Infine utilizzeremo uno degli esempi
già discussi nei capitoli precedenti come caso di studio per mostrare l’utilizzo degli
strumenti software sviluppati ed il funzionamento del supporto a runtime.
5.1 Compilatore COWSlite
Il software prodotto contiene alcuni file che coadiuvano nella compilazione e nella
creazione dei servizi COWSlite ed altri programmi per la generazione dei pacchetti
per la distribuzione su un web application server.
I principali strumenti realizzati sono tutti programmi a linea di comando, da
utilizzare cioè dalla shell del sistema operativo. Il progetto è stato sviluppato e testato
in ambiente Windows. Non sono state verificate le sue funzionalità in ambiente Linux,
ma la compatibilità dovrebbe essere assicurata dall’ambiente Java stesso. Gli script
per aiutare l’utilizzatore nell’esecuzione dei comandi sono stati preparati solo per
Windows, ma non dovrebbe essere difficile realizzarli anche per i sistemi operativi
Linux.
99

CAPITOLO 5 Uso di COWSlite
Per i test sono stati utilizzati gli application server SUN Application Server [39]
e Glassfish [21]. Alcune prove sono state effettuate anche su Apache Geronimo [3]
ed hanno evidenziato che in alcuni casi il file XML preparato per la distribuzione del
pacchetto sul server non è perfettamente compatibile con quello generato per gli altri
due application server.
Il compilatore è costituito da due pacchetti Java: CowsCompiler e CowsRuntime,
che contengono rispettivamente il compilatore e l’engine di esecuzione di COWSlite.
Il programma principale è contenuto nel pacchetto CowsCompiler distribuito come
file JAR. Al suo interno è contenuta una classe main che esegue la compilazione di un
file di testo contenete il servizio COWSlite. La classe accetta dei parametri, alcuni
opzionali, altri obbligatori. La sintassi del comando è:
CowsCompiler [-a] [-v|-V level] [-o outdir] [-p packageName] nomefile
Dal momento che il file è contenuto in un archivio Java deve essere eseguito per mezzo
dell’interprete del linguaggio in modo da poter passare i parametri necessari:
prompt> java -jar CowsCompiler.java .
L’unico parametro obbligatorio è il nome del file da compilare completo di percorso, gli
altri sono tutti opzionali. Il parametro -o serve per indicare al compilatore in quale
percorso mettere i file generati dalla compilazione, se questo parametro è assente
vengono messi nella directory corrente. Il parametro -p serve per specificare un nome
di package che sarà assegnato a tutti i file prodotti, in caso di assenza di questo
parametro il compilatore assegna un nome di default. Il parametro -a serve per
visualizzare in una finestra separata l’albero AST ottenuto dal riconoscitore sotto
forma di ‘treeview’. I parametri -v e -V level servono per impostare il livello di
visualizzazione delle informazioni da parte del compilatore. In assenza del parametro
il compilatore non visualizzerà alcuna informazione ad esclusione degli errori. Se
viene selezionato -V level allora vengono abilitati gli errori e al posto di level
deve essere inserito un valore fra 6 e 0: con 6 verranno visualizzati solo errori e
warning, con 5 anche le informazioni intermedie via via fino ad arrivare a 0 in cui
si hanno informazioni quasi su ogni azione del compilatore. I livelli sotto il 5 hanno
100

5.1 Compilatore COWSlite
mCOWSCompiler ver 0 . 9 . 1 . 3
27−feb−2010 1 1 . 5 4 . 4 7 cows . compiler . Main main
GRAVE: Parametri e r r a t i
S i n t a s s i :
CowsCompiler [ −a ] [ −v |−V l e v e l ] [ −o outDir ] [−p packageName ] fileName
outDir − Percorso di output d e i f i l e g e n e r a t i .
packageName − Nome da a s s e g n a r e a l package compilato
fileName − I l nome del f i l e cw da compilare .
−a −> V i s u a l i z z a AST.
−v/−V −> Verboso − l e v e l 0−6 (0 max , 6 min ) .
Tabella 5.1: Messaggio di errore del compilatore
principalmente valore di debug sulla compilazione. Se viene selezionato -v, questo
equivale all’impostazione di un livello 5.
In caso di assenza dei parametri o di errore nei parametri il programma visualizzerà
una serie di messaggi a video simili a quelli di Tabella 5.1.
Dopo avere generato con il compilatore i file Java questi devono essere compilati
ed assemblati.
Per produrre il file archivio WAR per l’installazione del servizio sul server pos-
siamo utilizzare l’utility jar presente nel Development Kit di Java. Tramite questa
utility devono essere uniti i file compilati, il file web.xml ed un file xml apposita-
mente prodotto che contiene le informazioni necessarie per installare ed instanziare
il servizio. Questo file per gli application server della famiglia SUN (Glassfish e Sun
Application Server) deve chiamarsi sun-web.xml.
Il file generato deve avere la seguente struttura: una directory principale chia-
mata WEB-INF che contiene al suo interno una cartella classes con i file compilati
corrispondenti ai servizi da eseguire, una cartella lib in cui sono inseriti eventua-
li archivi jar contenenti i pacchetti necessari alle classi compilate e i due file XML
precedentemente indicati.
101

CAPITOLO 5 Uso di COWSlite
5.1.1 Script per automatizzare la compilazione e la build
Per realizzare lo schema di compilazione rappresentato in Figura 4.2 sarebbe sufficien-
te usare i programmi realizzati e seguire l’iter indicato. Per agevolare l’intero processo
sono presenti due script per la compilazione e la creazione dei pacchetti da distribuire
sull’application server. Lo script cwc.bat serve per la compilazione dei file COW-
Slite e lo script build.bat serve per compilare i file java ottenuti ed assemblarli
all’interno di un file archivio.
Questi due script per funzionare correttamente devono essere contenuti in una car-
tella del filesystem all’interno della quale deve essere presente una cartella chiamata
mCows contenente il package CowsCompiler e una cartella lib contenente il package
CowsRuntime. A sua volta i due script produrranno, sempre all’interno della stessa
cartella in cui sono inseriti, una cartella build contenente i file prodotti dal compi-
latore, una cartella classes contenente i file compilati e una cartella WEB-INF nella
quale viene replicata la struttura di file e cartelle per produrre l’archivio WAR.
102
Per compilare un file COWSlite (.cw) sono necessari 2 passi:
1. Compilazione dei file .cw per produrre i file .java. Per fare ciò si può usare
cwc.bat. Lo script prende in input alcuni dei parametri del compilatore: il
nome del file e il package nel quale inserire i file java. Per definire il package si
usa lo switch -p _nome_del_package_, dove il nome deve essere inserito con la
notazione puntata anziché con i backslash proprio come devono essere scritti in
Java. Ad esempio -p servizio.cows, questo creerà i file .java all’interno della
cartella build riproducendo anche il path indicato dal package.
I due script sono costruiti per lavorare insieme
2. Creazione del file WAR. Per questo è necessario utilizzare build.bat. Allo script
sono necessari 2 parametri: il primo è il nome che vogliamo dare al WAR che sarà
anche il nome in cui verrà messo il servizio all’interno del web server, il secondo
è il package con cui l’abbiamo compilato (con la notazione con backslash).

5.1 Compilatore COWSlite
Se ad esempio vogliamo che il servizio o i servizi siano richiamati con http:
//nome_server:porta_server/TestCows/Test1Service?wsdl (indirizzo del
wsdl del servizio Test1) allora il primo parametro è TestCows. Il carattere ?
serve per passare dei parametri alla pagina web, in questo caso un parametro
senza valore, ma sufficiente per richiedere il WSDL del servizio.
Se vogliamo inserire servizi definiti in più file COWSlite nello stesso WAR basta
ripetere il passo 1 per tutti i file con COWSlite da compilare e poi eseguire un’unica
volta il passo 2.
Ad esempio se dobbiamo compilare il file Test1.cw, assegnandolo al package ser-
vizio.cows e costruire il file per il deploy di nome TestCows, allora devono essere usati
i seguenti comandi:
prompt:> cwc -p servizio.cows Test1.cw
prompt:> build TestCows servizio\\cows
Si otterrà così un file TestCows.war da caricare sul web server con l’apposita
procedura di deploy.
È necessario ricordarsi si svuotare la cartella build ogni volta che si vuole fare un
nuovo file WAR.
5.1.2 Utility di supporto
All’interno del package CowsRuntime sono contenute alcune classi eseguibili che è
possibile richiamare dall’esterno e che forniscono alcune funzioni di utilità per la
produzione e il test dei servizi prodotti.
Per eseguire tali classi è necessario ricorrere ancora una volta all’interpre-
te Java, ma questa volta non è sufficiente indicare il file jar, ma è neces-
sario indicare con precisione la classe necessaria, con una istruzione del tipo:
java -classpath lib\CowsRuntime.jar [parametri]. In cui no-
me classe è il percorso completo in cui si trova la classe, cioè la concatenazione del
103

CAPITOLO 5 Uso di COWSlite
nome del package e del nome della classe. Ad esempio, cows.execution.exec per
eseguire la classe exec che vedremo successivamente.
Di seguito verranno descritte le funzioni di utilità presenti all’interno del package
CowsRuntime.
exec
Invia una richiesta ad un servizio web. Questo comando può essere utile per eseguire
un’operazione esposta da un servizio web che che vogliamo testare.
dove:
La sintassi del comando è: exec i|e [wsdl] [operazione] [(parametri)].
i|e i per informazioni oppure e per esecuzione
wsdl indirizzo http del WSDL che descrive il servizio che vogliamo invocare
operazione il nome dell’operazione da eseguire
parametri la lista dei parametri per l’operazione richiesta, tali parametri devo essere
racchiusi tra parentesi e separati mediante virgola (...,...)
In caso di errore nei parametri viene visualizzato un messaggio di errore come
quello in Figura 5.2.
COWS − WS executor ver . 0 . 9 . 0
I n s e r i r e Parametri !
SINTASSI: exec o p e r a z i o n e wsdl o p e r a t i o n ( parameter )
o p e r a z i o n e i = i n f o
e = execute
wsdl i n d i r i z z o del f i l e WSDL
o p e r a t i o n nome d e l l ’ o p e r a z i o n e da i n v o c a r e
parameter l i s t a d e i paramteri da p a s s a r e r a c c h i u s i t r a ( ) e
s u d d i v i s a da ,
104
Tabella 5.2: Messaggio di errore exec

5.2 Note sul compilatore
makeXmlStub
Crea i file web.xml e sun-web.xml necessari per la produzione e la distribuzione del
pacchetto di installazione dei servizi web sull’application server.
dove:
La sintassi del comando è: makeXmlStub tipofile outpath parametro.
tipofile indica quale dei due file produrre
outpath directory dove creare il file
parametro nel caso di file sun-web corrisponde al nome del package war da creare
In caso di errore nei parametri viene visualizzato un messaggio di errore come quello
in Figura 5.3.
S i n t a s s i :
makeXmlStub t i p o F i l e outPath Parameter
t i p o f i l e : SUN −> f i l e sun−web . xml 1 parametro: nome package war
WEB −> f i l e web . xml Nessun Parametro
Tabella 5.3: Messaggio di errore makeXmlStub
5.2 Note sul compilatore
Analizziamo alcune caratteristiche del compilatore che possono essere considerate
punti di forza o limitazioni imposte al linguaggio che abbiamo definito.
5.2.1 Linguaggio accettato dal compilatore
Oltre alla sintassi esposta in Tabella 3.6 in un file di specifica COWSlite è possibile
aggiungere dei commenti che vengono ignorati in fase di compilazione. Per fare ciò è
sufficiente racchiudere il commento fra i due delimitatori /* e */, come si fa con altri
linguaggi di programmazione ad esempio C++ e Java. Inoltre il compilatore ignora
105

CAPITOLO 5 Uso di COWSlite
eventuali spazi aggiuntivi, tabulazioni e ritorno a capo che possono essere inseriti per
migliorare la leggibilità del programma originale.
5.2.2 Linee guida per la scrittura e la compilazione dei file
COWSlite
Per scrivere dei programmi eseguibili in COWSlite è necessario seguire alcune linee
guida generali.
Dal momento che non sono definiti metodi di discovery di un servizio, per poter
ottenere il WSDL di un servizio che si vuole utilizzare è necessario specificare l’URL
esatto da cui è possibile reperire il WSDL.
Se è necessario scrivere due o più servizi che devono comunicare tra loro, come ad
esempio dei servizi interdipendenti, dei servizi correlati oppure dei servizi da eseguire
sullo stesso host con la stessa directory di esecuzione, e questi non sono già presenti,
è necessario tener conto di dove verrà generato il WSDL dei servizi utilizzati in modo
da poter specificare l’URL per individuarli.
Per far questo è necessario tener presente che:
• Deve essere conosciuto il nome, o l’indirizzo IP, dell’host che ospiterà il servizio,
nonché la porta di comunicazione usata se diversa dalla 80 (standard HTTP)
• Deve essere specificata la directory che conterrà i servizi esposti.
• Il nome del servizio che verrà generato sarà il nome che è stato assegnato al
servizio COWSlite da interrogare con l’aggiunta del suffisso Service.
• Il percorso esatto in cui risiede il WSDL. Se il server di esecuzione è SAS (Sun
Application Server) oppure Glassfish il WSDL si ottiene aggiungendo al nome
del servizio (il partner COWSlite) ‘?wsdl’.
In questo modo l’URL risultante per invocare un altro servizio COWSlite è del tipo:
http://host:porta/nomeprogetto/nomeServizioSerice?wsdl
106

5.3 Caso di studio
Il nome progetto è importante perché è quello che deve essere fornito al batch di
generazione del file .war e che verrà utilizzato anche come nome da dare al pacchetto
WAR da creare.
5.3 Caso di studio
Prima di addentrarci in un esempio vero e proprio dobbiamo fare alcune considerazioni
sulla natura dei servizi web. Un servizio web non ha un’interfaccia che possa essere
interrogata direttamente, non è user-friendly, quindi non è facile e nemmeno possibile
riuscire a far vedere esattamente come si comporta una volta messo in funzione,
ma possiamo limitarci solo a testarlo come se fosse una scatola nera, cioè dandogli
un input per poi andare a recuperare l’output prodotto, sempre che questo servizio
fornisca un qualche tipo di output.
Quindi analizzeremo in maniera più accurata la parte relativa alla compilazione e
al codice prodotto, perché questo è un output che possiamo verificare e ci limiteremo
a verificare il funzionamento dell’esempio in base alla risposta fornitaci.
Per facilitare il compito della verifica del servizio abbiamo realizzato una sempli-
cissima applicazione web che consiste in un servizio web che accetta un input e scrive
quello che riceve su un file di log. Chiameremo il servizio in questione dataLogService
e fra le operazioni esposte utilizzeremo logInfo per scrivere l’output voluto sul file
WS_COWS.log all’interno dell’application server. Il servizio web, per semplicità, è
stato realizzato con l’IDE 1 utilizzato per lo sviluppo del progetto.
Riprendiamo uno degli esempi che abbiamo già trattato nel Paragrafo 3.3, sce-
gliamo quello relativo alle istanze e alla correlazione dei messaggi. Prendiamo questo
esempio perché il codice prodotto non è troppo lungo e al tempo stesso è interes-
sante in quanto affronta vari aspetti del linguaggio. Infine modifichiamo l’esempio in
modo da poter mandare un messaggio contenente una certa informazione al servizio
di log che abbiamo messo in ascolto. Il file che andremo a compilare è riportato in
Tabella 5.4.
1 Integrated Development Environment
107

CAPITOLO 5 Uso di COWSlite
dec{
srv : partner srv "o1"
"http://localhost:8080/test/srvService?WSDL";
srv2: partner srv "o2"
"http://localhost:8080/test/srvService?WSDL";
log: partner log "logInfo"
"http://localhost:8080/cowsTest/dataLogService?WSDL";
}
service {
[Xid:var(String);Xp:var(String);Xnum:var(int);
Yp:var(String);Ynum:var(int);res:var(int);]
?("srv","o1",).?("srv","o2",).
res:=Xnum+Ynum.!(log,"logInfo",)
}
once service {
|(
|(!(srv,"o1",),!(srv,"o1",)),
!(srv2,"o2",)
)
}
Tabella 5.4: File COWSlite da compilare
Come si può notare rispetto al codice del servizio esposto nel Paragrafo 3.3 è stato
aggiunta la definizione di un partner che corrisponde al sito in cui si trova il servizio
di log ed è stata modificata la definizione del servizio principale srv aggiungendo al
termine della computazione una assegnazione e l’invocazione del servizio di log al
quale viene inviato il risultato della assegnazione.
Si esegue la compilazione del file che chiameremo caseStudy.cw per mezzo dello
script cwc con il seguente comando:
cwc -p tesi.cap5 caseStudy.cw
Questo comando generato all’interno delle cartella build, la struttura di cartelle in-
dicata dal parametro package nella quale sono contenuti i due file Java srv.java e
client1.java contenenti rispettivamente il servizio principale e quello di invocazione.
108
Analizziamo adesso il contenuto del file srv.java riportato di seguito.

5.3 Caso di studio
package t e s i . cap5 ;
import javax . jws . Oneway ;
import javax . jws . WebMethod ;
import javax . jws . WebParam ;
import javax . jws . WebService ;
import java . u t i l . ∗ ;
import cows . engine . ∗ ;
@WebService
public class srv {
ServiceSpace mainSS ;
DataSpace mainDS ;
ComunicationSystem CS ;
Partner l o c P a r t n e r ;
// C o s t r u t t o r e d e l WS
public srv ( ) {
/∗ Crea i l s e r v i z i o i s t a n z i a n d o i l DataSpace P r i n c i p a l e
e i l ServiceSpace ed esegue i l primo processo d e l s e r v i z i o ∗/
/∗ I n i z i a l i z z a g l i s p a z i ∗/
mainSS = new ServiceSpace ( ) ;
CS = new ComunicationSystem ( mainSS ) ;
mainDS = new DataSpace (CS ) ;
// I d e n t i f i c a i l Partner f i t t i z i o per l o c a l
l o c P a r t n e r = mainSS . getLocalPartner ( ) ;
mainDS . addVariabile (new WsDescriptor ( " srv " , new Partner ( null ,
" http : / / l o c a l h o s t :8080/ t e s t / s r v S e r v i c e ?WSDL" ) , "o1" , null ) ) ;
mainDS . addVariabile (new WsDescriptor ( " srv2 " , new Partner ( null ,
" http : / / l o c a l h o s t :8080/ t e s t / s r v S e r v i c e ?WSDL" ) , "o2" , null ) ) ;
mainDS . addVariabile (new WsDescriptor ( " l o g " , new Partner ( null ,
" http : / / l o c a l h o s t :8080/ cowsTest / dataLogService ?WSDL" ) ,
109

" l o g I n f o " , null ) ) ;
/∗ Crea i p r o c e s s i d e l s e r v i z i o . ∗/
CowsProcess f i r s t P r o c e s s = S e r v i c e C r e a t o r ( ) ;
/∗ Esegue i l primo Processo ∗/
}
f i r s t P r o c e s s . s t a r t ( ) ;
CS . p r i n t S t a t u s ( ) ;
@WebMethod
@Oneway
public void o2 ( S t r i n g Xid , S t r i n g Yp, int Ynum) {
}
try {
WOVect v = new WOVect ( 3 ) ;
v . insVar (new WOVar( null , Xid ) ) ;
v . insVar (new WOVar( null , Yp ) ) ;
v . insVar (new WOVar( null , Ynum ) ) ;
CAPITOLO 5 Uso di COWSlite
CS . r e q u e s t (new WsDescriptor ( locPartner , "o2" , v ) ) ;
} catch ( DataCoreException ex ) {
}
@WebMethod
@Oneway
ex . printStackTrace ( ) ;
public void o1 ( S t r i n g Xid , S t r i n g Xp, int Xnum) {
110
try {
WOVect v = new WOVect ( 3 ) ;
v . insVar (new WOVar( null , Xid ) ) ;
v . insVar (new WOVar( null , Xp ) ) ;
v . insVar (new WOVar( null , Xnum ) ) ;
i f ( ! CS . r e q u e s t (new WsDescriptor ( locPartner , "o1" , v ) ) ) {
}
S e r v i c e C r e a t o r ( ) . s t a r t ( ) ;

5.3 Caso di studio
}
} catch ( DataCoreException ex ) {
}
ex . printStackTrace ( ) ;
private CowsProcess S e r v i c e C r e a t o r ( ) {
DataSpace ds ; /∗ modello d e l ds per i l s e r v i z i o ∗/
ds = new DataSpace (mainDS ) ;
/∗ DataSpace D e l i m i t a t i o n ∗/
DataSpace ds1 = new DataSpace ( ds ) ;
ds1 . addVariabile (new WOVar( "Xid" , new S t r i n g ( ) . g e t C l a s s ( ) ) ) ;
ds1 . addVariabile (new WOVar( "Xp" , new S t r i n g ( ) . g e t C l a s s ( ) ) ) ;
ds1 . addVariabile (new WOVar( "Xnum" , new I n t e g e r ( 0 ) . g e t C l a s s ( ) ) ) ;
ds1 . addVariabile (new WOVar( "Yp" , new S t r i n g ( ) . g e t C l a s s ( ) ) ) ;
ds1 . addVariabile (new WOVar( "Ynum" , new I n t e g e r ( 0 ) . g e t C l a s s ( ) ) ) ;
ds1 . addVariabile (new WOVar( " r e s " , new I n t e g e r ( 0 ) . g e t C l a s s ( ) ) ) ;
/∗ Invoke ∗/
CowsProcess cp5 = null ;
try {
WOVect v5 = new WOVect ( 1 ) ;
v5 . insVar ( (WOVar) ds1 . f i n d V a r i a b i l e ( " r e s " ) ) ;
WsDescriptor wd5 = ds1 . findWsDVar ( " l o g " ) ;
cp5 = new InvokeProcess (wd5 , v5 , ds1 ) ;
} catch ( DataCoreException dce ) {
}
/∗ Assign ∗/
CowsProcess cp4 = null ;
cp4 = new Assign4 ( cp5 , ds1 ) ;
/∗ Receive ∗/
CowsProcess cp3 = null ;
try {
WOVect v3 = new WOVect ( 3 ) ;
v3 . insVar ( (WOVar) ds1 . f i n d V a r i a b i l e ( "Xid" ) ) ;
111

v3 . insVar ( (WOVar) ds1 . f i n d V a r i a b i l e ( "Yp" ) ) ;
CAPITOLO 5 Uso di COWSlite
v3 . insVar ( (WOVar) ds1 . f i n d V a r i a b i l e ( "Ynum" ) ) ;
WsDescriptor wd3 = new WsDescriptor ( locPartner , "o2" , v3 ) ;
wd3 . setContinuazione ( cp4 ) ;
cp3 = new ReceiveProcess (wd3 , ds1 ) ;
} catch ( DataCoreException dce ) {
}
/∗ Receive ∗/
CowsProcess cp2 = null ;
try {
WOVect v2 = new WOVect ( 3 ) ;
v2 . insVar ( (WOVar) ds1 . f i n d V a r i a b i l e ( "Xid" ) ) ;
v2 . insVar ( (WOVar) ds1 . f i n d V a r i a b i l e ( "Xp" ) ) ;
v2 . insVar ( (WOVar) ds1 . f i n d V a r i a b i l e ( "Xnum" ) ) ;
WsDescriptor wd2 = new WsDescriptor ( locPartner , "o1" , v2 ) ;
wd2 . setContinuazione ( cp3 ) ;
cp2 = new ReceiveProcess (wd2 , ds1 ) ;
} catch ( DataCoreException dce ) {
}
/∗ D e l i m i t a t i o n ∗/
}
CowsProcess cp1 = null ;
cp1 = new D e l i m i t a t i o n P r o c e s s ( cp2 , ds1 ) ;
return cp1 ;
}
class Assign4 extends AssignProcess {
public Assign4 ( CowsProcess succ , DataSpace cds ){
}
super ( succ , cds ) ;
public void execute ( ) throws CowsException {
112
WOVar r e s = (WOVar) this . getWds ( ) . f i n d V a r i a b i l e ( " r e s " ) ;
i f ( r e s==null ) {

5.3 Caso di studio
}
r e s = new WOVar( " r e s " ) ;
this . getWds ( ) . a ddVariabile ( r e s ) ;
WOVar Xnum = (WOVar) this . getWds ( ) . f i n d V a r i a b i l e ( "Xnum" ) ;
WOVar Ynum = (WOVar) this . getWds ( ) . f i n d V a r i a b i l e ( "Ynum" ) ;
r e s . setValue (Xnum. add (Ynum ) ) ;
//Come ultimo a v v i a l a c o n t i n u a z i o n e
}
cont . s t a r t ( ) ;
public Object c l o n e ( ) {
}
}
return new Assign4 ( ( CowsProcess ) cont . c l o n e ( ) , this . getWds ( ) ) ;
Innanzitutto il file contiene al suo interno due classi, una pubblica relativa al
servizio ed una privata corrispondente al’istruzione di assegnazione definita nel codice.
La classe principale è suddivisibile in tre blocchi, il primo corrisponde al costruttore
della classe, il secondo contiene i metodi corrispondenti alle operazioni esposte dal
servizio e l’ultimo è il metodo ServiceCreator() che contiene la descrizione della
logica del servizio.
Nel costruttore, oltre alle istruzioni necessarie per inizializzare i componenti del-
l’engine (DataSpace e ServiceSpace), vengono inserite all’interno del DataSpace appe-
na creato le variabili presenti all’interno del blocco dichiarazioni del file COWSlite
infatti troviamo tre variabili di tipo WsDescriptor che rappresentano le due opera-
zioni del servizio principale srv, che serviranno al servizio client, e l’endpoint del
servizio di log.
Le operazioni del servizio sono esposte da due metodi contrassegnati con lo stes-
so nome presente nel file e adornati con le keyword @WebMethod e @Oneway come
richiesto dalle specifiche JAX-WS. Il corpo di tali metodi è molto simile, entrambi
sono composti da una parte iniziale dove sono definiti e richiamati gli oggetti cor-
rispondenti alle variabili che corrispondono ai parametri dell’operazione esposta dal
113

CAPITOLO 5 Uso di COWSlite
servizio web e che verranno poi inserite come parte della richiesta nel ServiceSpace.
L’unica differenza fra i due metodi è che il metodo o1 ha la facoltà di avviare un
nuovo processo nel caso in cui non ci siano più processi attivi disponibili, mentre il
metodo o2 non può farlo. Questo è coerente con la logica del processo, poiché o1 è
il metodo iniziale e si può comunicare con o2 solo se c’è già un istanza avviata del
servizio.
Infine il metodo ServiceCreator() contiene all’inizio la definizione del Servi-
ceSpace generato dalla delimitazione e poi esattamente in senso inverso le 5 azioni
definite nel file: invocazione del log, assegnazione di res, ricezione dell’operazione o2,
ricezione dell’operazione o1 e delimitazione. Da notare che l’assegnazione non fa altro
che istanziare la classe Assign4 che troviamo all’interno del file e nella quale è definita
l’assegnazione e la valutazione dell’espressione.
A questo punto non resta che provare il codice generato dal compilatore CO-
WSlite. Per testare il servizio creiamo il pacchetto di distribuzione con lo script
build:
build test tesi\\cap5
Otteniamo così il file test.war contenente i servizi da distribuire sull’application
server.
Una volta distribuito il servizio sull’application server è sufficiente chiamare
un’operazione del servizio oppure il file WSDL per avviarne l’esecuzione.
Quello che ci aspettiamo di trovare nel file di log è il contenuto della variabile res
dopo l’assegnazione cioè Xnum+Ynum che nel caso dell’esempio deve essere uguale a
2 + 1 = 3. Guardando il file di log generato, che è in formato XML, troviamo infatti:
114
2010−03−20 T10:26:52
1269077212140

5.3 Caso di studio
298
cows . t e s t
INFO
cows . cowstest . dataLog
&l t ; i n i t&gt ;
11
Log Avviato !
2010−03−20 T10:27:27
1269077247140
350
cows . t e s t
INFO
cows . cowstest . dataLog
l o g I n f o
20
3
Dove notiamo che il primo record è l’avvio del logger e il secondo è stato inserito con
il metodo logInfo che ha scritto come messaggio 3 all’interno del log, proprio come
ci aspettavamo.
Possiamo quindi dedurre che il servizio COWSlite ha eseguito correttamente
il suo compito. Naturalmente ripetendo il test si ottiene sempre lo stesso risultato.
L’unica incognita è l’ordine con cui sono eseguite le tre richieste di servizio fatte dal-
l’istanza di client1, perché tale ordine dipende da come le richieste vengono eseguite
dal gestore dei thread.
Volendo potremmo simulare un ordine specifico sfruttando una caratteristica dei
servizi compilati sugli application server Java. Con SAS e Glassfish una volta installa-
to un servizio è possibile, solo sulla macchina che esegue l’application server, accedere
ad una particolare pagina web che permette il test del servizio web. Questo si può
115

CAPITOLO 5 Uso di COWSlite
Figura 5.1: Test dell’operazione con Sun Applicatioin Server
fare semplicemente con un browser, richiamando il servizio web tramite l’URL che
lo individua e aggiungendo il parametro tester. Nel nostro caso accedendo all’URL
http://localhost:8080/test/srvService?Tester si ottiene la pagina mostrata in
Figura 5.1.
Dalla pagina web ottenuta possiamo invocare una qualunque operazione esposta
dal servizio passando i parametri necessari. In questo modo richiamando più volte
la pagina e inserendo i parametri che vogliamo inviare possiamo scegliere noi l’ordine
con cui mandare le richieste al servizio. Questa funzione è molto utile per testare il
funzionamento e la corretta istallazione di un servizio.
116

Capitolo 6
Conclusioni
In questa tesi abbiamo introdotto COWSlite un linguaggio di programmazione per
servizi web derivato da un linguaggio formale, tale da scrivere servizi che soddisfi-
no certe proprietà desiderate che sono state precedentemente verificate sul model-
lo del servizio scritto nel formalismo originario, utilizzando metodi analitici tramite
strumenti automatici o manuali.
Dopo aver descritto i calcoli di processo da cui abbiamo preso spunto (COWS
e µCOWS m ) ed il linguaggio che abbiamo implementato, abbiamo osservato che la
sintassi adottata per COWSlite presenta numerosi punti in comune con quella dei
calcoli presi a modello; la notazione utilizzata è rimasta la stessa ed è stato mantenuto
l’approccio algebrico alle istruzioni presente nei calcoli. Questa scelta evidenzia la
somiglianza dei formalismi a scapito della semplicità di scrittura di un programma
usando COWSlite. Le differenze dal punto di vista semantico fra il linguaggio e i
calcoli non sono molte e sono soprattutto ristrette alla gestione della valutazione delle
espressioni e all’utilizzo dei partner link. Abbiamo anche motivato le scelte fatte per
la definizione del linguaggio e la sua successiva realizzazione.
Per poter procedere con l’implementazione abbiamo definito un insieme di tipi di
dato ed un linguaggio di base per le espressioni sui valori che né in COWS, né in
µCOWS m sono specificati.
Ma lo sforzo maggiore è stato la progettazione e lo sviluppo dell’infrastruttura
117

CAPITOLO 6 Conclusioni
per la gestione delle comunicazioni e la descrizione dei processi che ha portato alla
creazione di un motore per coadiuvare l’esecuzione delle istruzioni.
Poiché COWSlite deve esporre e colloquiare con servizi web reali, mentre i servizi
web descritti mediante COWS sono servizi astratti, in fase di progettazione abbiamo
dovuto tenere conto di numerosi vincoli che si ripercuotono nell’implementazione e
nell’utilizzo. Inoltre, per poter realizzare un linguaggio di programmazione che collo-
qui con servizi scritti nei linguaggi più vari è stato importante cercare di mantenere la
compatibilità con gli standard (XML,WSDL, XSD, ...), ricordando che per ottenere
tale compatibilità è spesso necessario utilizzare metodi che siano più semplici possi-
bili e ricondursi ad un insieme minimo di dati che siano comuni a tutti. Anche se le
caratteristiche e le numerose API che Java possiede sono state di notevole aiuto in
questo processo, ci sono volute molte ore di lavoro per implementare e testare le varie
parti.
Il compilatore che deve produrre la descrizione in Java del file di specifica CO-
WSlite è a sua volta scritto in Java ed è stato sfruttato il framework SableCC per
la produzione del riconoscitore grammaticale in modo da semplificare lo sviluppo del
software e ottenere del codice che garantisca il corretto riconoscimento del linguag-
gio. SableCC oltre a velocizzare la scrittura del compilatore, ne semplifica anche la
manutenzione; per ogni aggiunta o modifica della grammatica sarà quindi sufficiente
ricompilarne il progetto per ottenere una nuova serie di classi; il nome della classe che
rappresenta l’attraversatore dell’albero AST è sempre lo stesso; quindi, a meno che
non ci siano state modifiche sostanziali alla grammatica (eliminazione di produzioni
o parte di esse), la parte già scritta non dovrebbe generare errori.
Una prerogativa del nostro lavoro è stata di non usare alcuna libreria o API che
non sia distribuita con Java. Infatti per il funzionamento dei servizi creati non è
necessario installare alcun plug-in sull’application server, ma è sufficiente ridistribuire
insieme alle classi ottenute solo il motore di esecuzione, che occupa poche centinaia
di kb.
118
Come abbiamo già evidenziato precedentemente in questi ultimi anni è molto

sentita la necessità di formulare calcoli per i servizi web che abbiano delle implemen-
tazioni reali tali da permettere di eseguire prove e misure sul codice scritto. Ci sono
diversi esempi di altre università italiane che si muovono in questa direzione e tra
i tanti progetti realizzati possiamo citare Pi-Duce [11], Jolie [32], JSCL [15], jCa-
SPiS [7]. Ognuno di questi linguaggi implementa un calcolo per l’orchestrazione di
servizi. Pi-Duce e JSCL, che sono entrambi derivati da π-calculus, non sono nati con
il chiaro intento di dialogare con servizi web, ma questa caratteristica è stata inse-
rita nelle implementazioni, mentre Jolie e jCaSPiS sono stati progettati tenendo in
considerazione questo aspetto. Ad esclusione di Pi-Duce che è scritto in C#, gli altri
linguaggi sono tutti implementati in Java. Molti sono i concetti comuni fra questi
linguaggi, ad esempio tutti sono stati costruiti prendono in considerazione lo stesso
insieme di primitive di comunicazione, ma le diverse scelte fatte li portano ad essere
tutti differenti fra loro e orientati a modellare e studiare aspetti diversi dell’interazio-
ne fra servizi e della loro orchestrazione. È interessante notare che JSCL, jCaSPiS e
Jolie sono linguaggi interpretati, mentre Pi-Duce è più simile a COWSlite poiché
viene prodotto del codice compilabile.
Il compilatore presentato in questo lavoro è solo un prototipo che potrebbe evol-
vere in modo da ottenere un implementazione di COWS completa sotto tutti gli
aspetti. Il motore di esecuzione può essere esteso in modo da implementare i costrutti
mancanti rispetto a COWS, semplicemente aggiungendo due classi che implementino
il comportamento dei due operatori mancanti in µCOWS m (kill e protection). Allo
stesso tempo sarebbe opportuno aggiungere nuovi tipi di dato, ad esempio i booleani,
rendendo così più semplice simulare il costrutto if tipico dei linguaggi di program-
mazione. Poiché la classe di base delle variabili è costruita tramite generics, non sarà
difficile aggiungere nuovi tipi di dato; le parti principali su cui intervenire saranno la
generazione di una nuova grammatica, estendendo il blocco espressione con le nuove
produzioni, e la modifica delle funzioni che producono il codice delle classi Assign.
Un altro aspetto che potrebbe essere oggetto di modifica per ottenere un comporta-
mento più vicino a COWS riguarda la modalità di selezione delle attività di ricezione;
119

CAPITOLO 6 Conclusioni
cioè selezionare fra tutte le attività di ricezione coerenti con la richiesta quella più
compatibile e non una qualunque in modo non deterministico; per fare ciò sarà neces-
sario agire sulle funzioni di match in modo da definire una priorità fra le alternative
al fine di scegliere la migliore fra tutte quelle possibili. Infine il compilatore potrebbe
essere modificato in modo da non rendere obbligatoria la definizione dei partner per
quei servizi che sono definiti all’interno dello stesso file facendo in modo che sia il
compilatore stesso a risolvere il nome.
120

Appendice A
Grammatica
A.1 Grammatica COWSlite per SableCC
Di seguito è riportata le definizione secondo SableCC della grammatica che è stata
costruita per implemetare il linguaggio COWSlite.
// Grammatica per COWSlite. Ver. 1.0.0
// Grammatica ridotta per il linguaggio COWS
// usando la sintassi per SableCC.
Package mcows.grammar;
Helpers
all = [0 .. 127];
digit = [’0’ .. ’9’];
nonzerodigit = [digit -’0’];
nondigit = [’_’ + [[’a’ .. ’z’]+[’A’ .. ’Z’]]];
cr = 13; //Carriage return
lf = 10; //Line feed
tab = 9; //Tab char
not_star = [all - ’*’];
121

not_star_slash = [not_star - ’/’];
s_char = [all - [’"’ + [’\’ + [10 + 13]]]];
s_char_seq = s_char+;
// Definizione dei Token appartenenti al linguaggio.
Tokens
dot = ’.’;
comma = ’,’;
l_par = ’(’;
r_par = ’)’;
l_qpar = ’[’;
r_qpar = ’]’;
l_gpar = ’{’;
r_gpar = ’}’;
plus = ’+’;
minus = ’-’;
mult = ’*’;
div = ’/’;
semicolon = ’;’;
colon = ’:’;
equal = ’=’;
lesser = ’’;
mod = ’mod’;
elev =’^’;
non = ’not’;
and = ’and’;
or = ’or’;
122
CAPITOLO A Grammatica

A.1 Grammatica COWSlite per SableCC
// Keyword non appartenenti originariamente al linguaggio
dec = ’dec’;
service = ’service’;
once = ’once’;
var = ’var’;
killerlabel = ’killer’;
label = ’lab’;
partner = ’partner’;
// Keyword per i tipi di dato.
string= ’String’;
int=’int’;
vect=’vect’;
// Keyword delle azioni COWS
receive = ’?’;
parallel = ’|’;
invoke = ’!’;
kill = ’kill’;
assign = ’:=’;
nil = ’nil’;
// identificatori, stringhe, numeri, spazi e comenti.
ide = nondigit (digit | nondigit)*;
string_literal = ’"’ s_char_seq? ’"’;
number = nonzerodigit digit*;
blank = ( cr | lf | tab | ’ ’)+;
comment = ’/*’ not_star* ’*’+
(not_star_slash not_star* ’*’+)* ’/’;
123

Insieme dei token da ignorare durante il parsing.
Ignored Tokens
blank,
comment;
// Insieme delle produzioni che rappresentano
// il linguaggio COWS.
Productions
//Programma
cows = declaration? cows_service+;
//Dichiarazioni - Blocco dichiarativo iniziale del
declaration = dec l_gpar variable* r_gpar;
variable = variable_end semicolon;
variable_end = ide colon lab_type;
lab_type = {var} var l_par var_type r_par|
{kill} killerlabel |
{label} label |
CAPITOLO A Grammatica
{partner} partner partner_name operation_name wsdl_link;
var_type = {string} string |
{int} int |
{vect} vect l_par number r_par;
delimdec = variable; //Alias per le dichiarazioni
// di variabili all’interno della delimitazione
replication = mult; //Alias per il prodotto.
//Processi
cows_service = once? service l_gpar prec_process r_gpar;
prec_process = {precedence} l_par process r_par |
124

A.1 Grammatica COWSlite per SableCC
{normal} process;
process = {parallel} parallel l_par [left]:prec_process comma
[right]:prec_process r_par |
{replication} replication repetition_time? prec_process |
{delimitation} l_qpar delimdec* r_qpar prec_process |
{invoke} invoke l_par partner_name
[first]:comma operation_name
[second]:comma invoke_param r_par |
{choice} choice |
{assign} ide assign assignable dot prec_process;
assignable = {expression} expr | {const} const;
choice = {choice} plus r_par [left]:choice comma
[right]:choice l_par|
{nil} nil |
{receive} receive l_par partner_value
[first]:comma operation_name
[second]:comma receive_param r_par dot prec_process;
//Parametri
repetition_time = l_qpar number r_qpar;
partner_value = value;
partner_name = ide;
operation_name= string_literal;
receive_param = lesser list_value? greater;
invoke_param = lesser list_value? greater;
list_value = value list_cont*;
list_cont =comma value;
value = {ide} ide | {const} const | {number} number;
const = string_literal;
wsdl_link = string_literal;
125

Espressioni
expr =
{term} term |
{negterm} minus term | {posterm} plus term |
{sum} expr plus term |
{diff} expr minus term ;
term = {fact} fact |
{mult} term mult fact |
{div} term div fact ;
fact = {number} number |
126
{ide} ide |
{precexpr} l_par expr r_par;
CAPITOLO A Grammatica

Appendice B
Deploy su application server
Gli application server di ultima generazione forniscono delle interfacce di amministra-
zione molto evolute, non è quindi più necessario andare a studiarsi tediosi manuali
pieni di comandi, oppure scorrere riga per riga degli interminabili file di configurazione.
Per poter modificare la configurazione basta accedere alla console di amministrazione.
SUN Application Server e Glassfish hanno una console web per la configurazione.
Basta accede con un qualunque browser alla pagina http://localhost:4848, immet-
tere le credenziali di amministratore per accedere alla pagina principale di gestione
del server (Figura B.1).
Dalla console di amministrazione è possibile gestire tutte le componenti dell’appli-
cation server e controllare lo stato dei componenti: avviarli, arrestarli, riavviarli, ecc.
Da questa console è possibile installare nuovi servizi in modo semplice e soprattutto
veloce.
Sulla parte sinistra della finestra troviamo una rappresentazione ad albero di tutti
i componenti dell’application server. Delle 5 sezioni in cui sono organizzati tutti i
parametri, quelle che ci interessano per la gestione dei servizi e la loro distribuzione
sono solo due, le altre servono per la configurazione del server, per il monitoraggio dello
stato del server e per la gestione di altri componenti. La prima voce da selezionare è
la sottosezione Web Application nel nodo Applications, come si vede dalla Figura B.2,
dalla quale è possibile gestire il carico e lo scarico delle applicazioni e l’altra è sotto
127

CAPITOLO B Deploy su application server
Figura B.1: Pagina di amministrazione dell’application server
la sezione Web Services dalla quale è possibile controllare lo stato di funzionamento
di ogni servizio web installato all’interno dell’appication server.
Per installare una applicazione web (come i file WAR generati per il nostro pro-
getto) è necessario selezionare il pulsante Deploy... all’interno della pagina di ammi-
nistrazione delle applicazioni web (visibile in Figura B.2) e seguire il semplice wizard,
composto da due pagine, che ci viene proposto per l’installazione dell’applicazione.
Nella prima delle due pagine deve essere inserito il percorso dal quale caricare il file
archivio oppure la posizione in cui si trovano i file sorgenti, nella pagina successiva
devono essere inseriti i parametri che verranno utilizzati per avviare l’applicazione;
fra questi quelli essenziali sono il nome dell’applicazione e il contesto che corrispon-
dono al nome con cui verrà indicata l’applicazione nel pannello di amministrazione e
il percorso in cui dovranno essere cercati i servizi web una volta installati; è possibile
anche indicare un server diverso da quello di default nel caso in cui nell’application
server siano definiti più server virtuali. Il resto dei parametri riguardano l’attivazione,
128

Figura B.2: Pagina di amministrazione dei servizi in esecuzione
alcuni controlli da eseguire precedentemente alla fase di esecuzione e se precompilare
il codice oppure no. Terminati questi passi se l’installazione è andata a buon fine la
nuova applicazione sarà presente all’interno della lista delle applicazioni.
L’interfaccia e la modalità da utilizzare per il server Glassfish è del tutto analoga.
129

130
CAPITOLO B Deploy su application server

Bibliografia
[1] Simple API for XML (SAX) project site. 2003. http://www.saxproject.org/.
[2] A. Alves, A. Arkin, S. Askary, C. Barreto, B. Bloch, F. Curbera, M. Ford, Y. Go-
land, A. Guízar, N. Kartha, C. Kevin Liu, R. Khalaf, D. König, M. Marin, V. Me-
hta, S. Thatte, D. van der Rijn, P. Yendluri e A. Yiu. Web Services Business
Process Execution Language Version 2.0. Relazione tecnica, 2007. Disponibile
su http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.html.
[3] Apache Software Foundation. Apache Geronimo. Disponibile su http://
geronimo.apache.org/.
[4] C. Barreto, V. Bullard, T. Erl, J. Evdemon, D. Jordan, K. Kand, D. König,
S. Moser, R. Stout, R. Ten-Hove, I. Trickovic, D. van der Rijn e A. Yiu. Web
Services Business Process Execution Language Version 2.0 primer. Relazione tec-
nica, 2007. Disponibile su http://docs.oasis-open.org/wsbpel/2.0/Primer/
wsbpel-v2.0-Primer.html.
[5] L. Bettini. Progetto e Realizzazione di un Linguaggio di Programmazione per
Codice Mobile. Tesi di Laurea, Dipartimento di Sistemi e Informatica, Uni-
versità di Firenze, 1998. Disponibile su http://music.dsi.unifi.it/thesis/
xklaimthesis.ps.gz.
[6] L. Bettini, V. Bono, R. De Nicola, G. Ferrari, D. Gorla, M. Loreti, E. Moggi,
R. Pugliese, E. Tuosto e B. Venneri. The Klaim Project: Theory and Practice.
131

BIBLIOGRAFIA
In Global Computing: Programming Environments,Languages, Security and Ana-
lysis of Systems, volume 2874 di Lecture Notes in Computer Science. Springer,
2003.
[7] L. Bettini, R. De Nicola e M. Loreti. Implementing Session Centered Calculi.
In COORDINATION, volume 5052 di Lecture Notes in Computer Science, pp.
17–32. Springer, 2008.
[8] L. Bettini, R. De Nicola e R. Pugliese. KLAVA: a Java package for distributed
and mobile applications. Softw. Pract. Exper., 32(14):1365–1394, 2002.
[9] M. Boreale, R. Bruni, L. Caires, R. De Nicola, I. Lanese, M. Loreti, F. Mar-
tins, U. Montanari, A. Ravara, D. Sangiorgi, V. T. Vasconcelos e G. Zavattaro.
SCC: A Service Centered Calculus. In WS-FM, volume 4184 di Lecture Notes in
Computer Science, pp. 38–57. Springer, 2006.
[10] G. Bruno. Linguaggi formali e compilatori. UTET Libreria, 1992.
[11] S. Carpineti, C. Laneve e L. Padovani. PiDuce - A project for experimenting
Web services technologies. Sci. Comput. Program., 74(10):777–811, 2009.
[12] E. Christensen, F. Curbera, G. Meredith e S. Weerawarana. Web Services
Description Language (WSDL) 1.1. Relazione tecnica, 2001. Disponibile su
http://www.w3.org/TR/2001/NOTE-wsdl-20010315.
[13] B. Eckel. Thinking in Java (3rd Edition). Prentice Hall Professional Technical
Reference, 2002.
[14] A. Fantechi, S. Gnesi, A. Lapadula, F. Mazzanti, R. Pugliese e F. Tiezzi. A model
132
checking approach for verifying COWS specifications. In Proc. of Fundamental
Approaches to Software Engineering (FASE’08), volume 4961 di Lecture Notes
in Computer Science, pp. 230–245. Springer, 2008.

BIBLIOGRAFIA
[15] G. Ferrari, R. Guanciale e D. Strollo. JSCL: A Middleware for Service Coordina-
tion. In FORTE, volume 4229 di Lecture Notes in Computer Science, pp. 46–60.
Springer, 2006.
[16] E. Gagnon. SableCC, An Object-Oriented Compiler Framework. Master’s The-
sis, McGill University, Montreal, Quebec, 1998. Disponilile su http://www.dcs.
gla.ac.uk/~wpc/hi/sablecc-thesis.pdf.
[17] E. Gamma, R. Helm, R. Johnson e J. Vlissides. Design Patterns. Addison-Wesley
Professional, 1995.
[18] C. Guidi, R. Lucchi, R. Gorrieri, N. Busi e G. Zavattaro. SOCK: a calculus for
service oriented computing. In ISOC, volume 4294 di Lecture Notes in Computer
Science, pp. 327–338. Springer, 2006.
[19] K. Heather. Web Services Conceptual Architecture (WSCA 1.0). IBM, 2001.
Disponibile su http://www-306.ibm.com/software/solutions/webservices/
pdf/WSCA.pdf.
[20] A. Le Hors, P. Le Hégaret, L. Wood, G. Nicol, J. Robie, M. Champion
e S. Byrne. The Document Object Model(DOM) Level 2 Core Specifica-
tion. Relazione tecnica, 2000. Disponibile su http://www.w3.org/TR/2000/
REC-DOM-Level-2-Core-20001113/.
[21] java.net. Glassfish. Disponibile su https://glassfish.dev.java.net/.
[22] java.net. JavaCC Home Page. https://javacc.dev.java.net/.
[23] S. C. Johnson. Yacc: Yet Another Compiler-Compiler. Tech. Rep. Computing
Science 32, Bell Laboratories, 1975.
[24] D. Kohlert e A. Gupta. JSR-000224 Java API for XML-Based Web Services
(JAX-WS). Relazione tecnica, 2007. Disponibile su http://jcp.org/en/jsr/
detail?id=224.
133

BIBLIOGRAFIA
[25] A. Lapadula, R. Pugliese e F. Tiezzi. A Calculus for Orchestration of Web
Services. In Proc. of 16th European Symposium on Programming (ESOP’07),
volume 4421 di Lecture Notes in Computer Science, pp. 33–47. Springer, 2007.
[26] A. Lapadula, R. Pugliese e F. Tiezzi. Regulating data exchange in service oriented
applications. In Proc. of IPM International Symposium on Fundamentals of
Software Engineering (FSEN’07), volume 4767 di Lecture Notes in Computer
Science, pp. 223–239. Springer, 2007.
[27] M. E. Lesk. Lex - a lexical analyzer generator. Tech. Rep. Computing Science 39,
Bell Laboratories, 1975.
[28] F. Leymann. Web Services Flow Language (WSFL 1.0). Relazione tecnica. Dispo-
nibile su http://www.itee.uq.edu.au/~infs7201/Assessments/Assignment\
%201\%20Material/WSFL.pdf.
[29] R. Milner. Communication and Concurrency. Prentice Hall, 1989.
[30] R. Milner. Communicating and mobile systems: the π-calculus. Cambridge
University Press, New York, NY, USA, 1999.
[31] N. Mitra e Y. Lafon. SOAP Version 1.2 Part 0: Primer (Second
Edition). W3C, 2007. Disponibile su http://www.w3.org/TR/2007/
REC-soap12-part0-20070427/.
[32] F. Montesi, C. Guidi, R. Lucchi e G. Zavattaro. JOLIE: a Java Orchestration
Language Interpreter Engine. Electronic Notes in Theoretical Computer Science,
181:19 – 33, 2007.
[33] W. Nagy, F. Curbera e S. Weerawarana. The Advertisement and Discovery of
Services (ADS) protocol for Web services. Relazione tecnica. Disponibile su
http://www.ibm.com/developerworks/library/ws-ads.html.
[34] OASIS. UDDI Reference Site. http://uddi.xml.org/.
134

BIBLIOGRAFIA
[35] M. Page-Jones. Progettazione a oggetti UML. Apogeo, 2002.
[36] T. J. Parr, H. D. Dietz e W. E. Cohen. PCCTS Reference Manual - Version 1.00.
SIGPLAN Notices, 27:88–165, 1991.
[37] D. Prandi e P. Quaglia. Stochastic COWS. In Proc. 5th International Conference
on Service Oriented Computing (ICSOC’07), volume 4749 di Lecture Notes in
Computer Science. Springer, 2007.
[38] A. Skonnard. The XML File: Publishing and Discovering Web Services wi-
th DISCO and UDDI. Relazione tecnica, 2002. Disponibile su http://msdn.
microsoft.com/en-us/magazine/cc302073.aspx.
[39] SUN. Sun Application Server. http://developers.sun.com/appserver/.
[40] SUN. JDK 6 Documentation. 2006. Disponibille su http://java.sun.com/
javase/6/docs/.
[41] SUN. The Java Web Services Tutorial. Relazione tecnica, 2006. Disponibile su
http://java.sun.com/webservices/docs/2.0/tutorial/doc/.
[42] S. Thatte. XLANG: Web Services for Business Process Design. Relazione tecnica,
2001. Disponibile su http://www.gotdotnet.com/team/xml_wsspecs/xlang-c/
default.htm.
135