Implementazione di un. linguaggio di base. per servizi web

Transcript

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

2

3 Ai miei genitori, ai miei amici e a Eleonora.

4

5 Indice 1 Introduzione 11 2 Supporti per la realizzazione di servizi web Piattaforma per l esecuzione dei servizi Definizione di servizio web Modello dei sevizi web Architettura dei servizi web SOAP, WSDL e WS-BPEL SOAP WSDL WS-BPEL JAX-WS Il linguaggio COWSlite Il calcolo di processi COWS µcows m Esempi Descrizione di COWSlite Sintassi Tipi di dato e vettori di variabili write-once Regole di matching Semantica e differenze con µcows m

6 INDICE 3.3 Esempi Implementazione di COWSlite Obiettivi e scelte implementative Un servizio COWSlite in Java Il package cowslite.engine L unità di comunicazione Descrittori di servizio web e variabili (WsDescriptor e PartnerLink) Descrizione del servizio COWSlite Spazio dei servizi Generazione del compilatore Componenti di SableCC Generazione del codice Uso di COWSlite Compilatore COWSlite Script per automatizzare la compilazione e la build Utility di supporto Note sul compilatore Linguaggio accettato dal compilatore Linee guida per la scrittura e la compilazione dei file COWSlite Caso di studio Conclusioni 117 A Grammatica 121 A.1 Grammatica COWSlite per SableCC B Deploy su application server 127 Bibliografia 131 6

7 Elenco delle tabelle 2.1 Struttura di un processo WS-BPEL Sintassi di COWS Sintassi di µcows m Congruenza strutturale di µcows m Regole di matching Semantica operazionale di µcows m Sintassi di COWSlite Codice di un servizio Web Service Proxy con JAX-WS Web Service - Messaggio SOAP Costruttori della classe WOVar<T> Classe CowsProcess Receive -?(partner,operation,<data>).continuazione Invoke -!(partner,operation,<data>) Delimitation - [x1,...,xn]p Replication - *[n](p) Parallel - (p1,p2) Choice - +(p1,p2) Assign - x:=exp Esempio di codice generato per la logica del servizio

8 ELENCO DELLE TABELLE 4.14 Esempio di codice generato per la scelta condizionata Messaggio di errore del compilatore Messaggio di errore exec Messaggio di errore makexmlstub File COWSlite da compilare

9 Elenco delle figure 2.1 Ruoli, Attività e Artefatti nelle architetture orientate ai servizi Pila dei servizi web Messaggi XML in SOAP Descrizione di un servizio Processo WS-BPEL Struttura del progetto Compilazione di un servizio COWSlite Architettura dell engine Classi del sottosistema di comunicazione Diagramma delle classi delle variabili WO Diagramma delle classi dei processi COWSlite AST generato per l espressione ( /2) Albero AST per il costrutto Parallel Albero AST per il costrutto Choice Test dell operazione con Sun Applicatioin Server B.1 Pagina di amministrazione dell application server B.2 Pagina di amministrazione dei servizi in esecuzione

10 10 ELENCO DELLE FIGURE

11 Capitolo 1 Introduzione In questi ultimi anni il ruolo dell Information Technology (IT) all interno delle aziende si è spesso orientato verso problematiche di integrazione e fornitura di servizi. Acronimi come SOA e SOC sono ormai divenuti parole di uso comune. SOA (Service Oriented Architecture) sta ad indicare un paradigma architetturale per i sistemi aziendali, mentre SOC (Service Oriented Computing) individua un paradigma utilizzato per la progettazione di sistemi enterprise. Anche se ultimamente l espressione SOA sta lasciando il posto a SOC, essi indicano uno stesso scopo, costruire sistemi 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

12 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. π-calcolo [30]). CCS [29] e 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 funzionale, 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

13 realizzare 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 14

15 Capitolo 2 Supporti per la realizzazione di servizi web In questo capitolo descriveremo cosa si intende con il termine servizio web e analizzeremo 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

16 CAPITOLO 2 Supporti per la realizzazione di servizi web Definizione di servizio web Un servizio web (web service) è una collezione di funzionalità, dette operazioni, accessibili via rete che possono essere utilizzate e richieste attraverso messaggi XML standard. L interfaccia di un servizio web è descritta usando WSDL [12], una notazione 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 caratteristica 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 debolmente accoppiate (losely-coupled), orientate ai componenti e implementate sfruttando tecnologie differenti (cross-technology). I servizi web possono eseguire un compito specifico 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) Modello dei sevizi web Il modello dei servizi web individua tre ruoli differenti che interagiscono fra loro: fornitore del servizio (service provider), registro dei servizi (server registry) e richiedente dei servizi (service requestor). L interazione si concretizza in tre attività: pubblicazione, 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 produce 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

17 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 prospettive 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 richiedono che siano soddisfatte determinate funzioni. Da una prospettiva architetturale è l applicazione che si prepara a invocare o iniziare un interazione con un 17

18 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 disponibili 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 dinamicamente durante l esecuzione. Nel caso di servizi collegati staticamente, il ruolo di registro dei servizi è opzionale, in quanto il fornitore può inviare direttamente 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 accessibile 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 interfaccia 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. 18

19 2.1 Piattaforma per l esecuzione dei servizi 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 organizzate 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 relativamente 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 richiedente. 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

20 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 descrizione 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

21 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 composizione 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 interoperabilità, 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 servizio 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

22 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 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

23 2.2 SOAP, WSDL e WS-BPEL una serie di regole di codifica per esprimere istanze di tipi di dati definiti dall applicazione 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

24 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 specificato 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 fornitore del servizio. Il runtime è responsabile di convertire il messaggio XML nelle strutture dati specifiche del linguaggio di programmazione usato per l applicazione. La conversione è guidata dagli schemi di decodifica contenuti all interno del messaggio. 3. Il servizio web è responsabile di elaborare il messaggio di richiesta ed eventualmente 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 sincrona 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 infrastruttura di rete, viene indirizzato attraverso l infrastruttura SOAP, convertito 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

25 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 WSDL Attraverso la descrizione del servizio il fornitore del servizio comunica tutte le specifiche 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

26 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 istanziata e referenziata da più descrizioni concrete del servizio. Basti pensare alla descrizione astratta come ad un linguaggio IDL (Interface Definition Langauge), alle interfacce in Java oppure a dei tipi nei servizi web. Questo permette di definire e implementare 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): binding; porttype; message; type. 26

27 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 definizione 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 WS-BPEL WS-BPEL (Web Services Business Process Execution Language) [2, 4] è un linguaggio 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 supportare 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

28 CAPITOLO 2 Supporti per la realizzazione di servizi web 2002 ed è giunto alla sua seconda versione nel 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 parallelo, 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 differenza 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 metterlo 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 eseguire, 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

29 2.2 SOAP, WSDL e WS-BPEL <p r o c e s s name = "... " targetnamespace = "... " xmlns = " h t t p : // docs. o a s i s open. org / wsbpel /2.0/ p r o c e s s / e x e c u t a b l e "> <partnerlinks> <partnerlink name="... ">... </ partnerlink>... </ partnerlinks> <v a r i a b l e s>... </ v a r i a b l e s> <f a u l t H a n d l e r s>... </ f a u l t H a n d l e r s> <sequence>... </ sequence> </ p r o c e s s> 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

30 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

31 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 connessione 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 comunicazione, al fine di implementare un meccanismo per il mantenimento della sessione di comunicazione. WS-BPEL prevede infine un meccanismo di gestione delle eccezioni per sopperire 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

32 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 secondo le specifiche del Java Community Process. L API inoltre introduce il supporto per le operazioni asincrone lato client, semplifica 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 implementazione di nuovi standard, semplifica l accesso ai messaggi scambiati dai mecca- 32

33 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 interlocutore 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 richiedenti. 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 metodi 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 34

35 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 necessari 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 esecuzione 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 introdurremo 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

36 CAPITOLO 3 Il linguaggio COWSlite 3.1 Il calcolo di processi COWS 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 servizio (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

37 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) µ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 nomi e variabili. La notazione sta ad indicare una tupla; ad esempio x rappresenta x 1,..., x n (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

38 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 sulla 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 valori. 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 intuitivamente rappresentano lo stesso servizio. È definita come la più piccola relazione indotta dalle leggi mostrate in Tabella 3.3. Le leggi che esprimono la congruenza strutturale sono semplici da interpretare. In particolare, la proprietà commutativa sulle delimitazioni consecutive implica che l ordine in cui sono scritte le u i in [ u 1,..., u n ] s 38

39 3.1 Il calcolo di processi COWS 0 0 s s s s 0 s s 1 s 2 s 2 s 1 (s 1 s 2 ) s 3 s 1 (s 2 s 3 ) g + 0 g g 1 + g 2 g 2 + g 1 (g 1 + g 2 ) + g 3 g 1 + (g 2 + g 3 ) [u] 0 0 [u 1 ] [u 2 ] s [u 2 ] [u 1 ] s s 1 [u] s 2 [u] (s 1 s 2 ) if u / fu(s 1 ) Tabella 3.3: Congruenza strutturale di µcows m M(x, v) = {x v} M(v, v) = M(, ) = M(w 1, v 1 ) = σ 1 M( w 2, v 2 ) = σ 2 M((w 1, w 2 ), (v 1, v 2 )) = σ 1 σ 2 Tabella 3.4: Regole di matching è irrilevante, permettendo così di usare una notazione più semplice come [u 1,..., u n ] 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

40 CAPITOLO 3 Il linguaggio COWSlite n! ɛ [ ɛ] = v n v 0 (inv) σ {x v} s s (del com ) σ [x] s s {x v} g g + g s 1 α s α s (choice) n w s n v 1 s 2 s 2 s n? w.s α s [u] s s 1 s 1 s 2 n w s (rec) u / u(α) (del) α [u] s α s 1 σ s 1 s 2 s 1 s 2 α s s 1 s 1 s 2 s 2 s (str) α s s α s 1 s 2 (par) M( w, v)=σ (com) 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 sostituzione σ. 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

41 3.1 Il calcolo di processi COWS Un attività di ricezione rappresenta un operazione invocabile rispetto ad un determinato 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 eseguono 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 (del com )). 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 viene applicata la regola (open rec ) ad un servizio µcows m chiuso, il termine risultante potrebbe essere aperto 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à possono 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 [x p, x num ] (odds throw? first, x p, x num ).s s ) [x p, x num ] (odds throw! first, cba, 2 odds throw? first, x p, x num ).s s ) (s s ) {x p cba, x num 2} 41

42 CAPITOLO 3 Il linguaggio COWSlite Da notare che la sostituzione {x p cba, x num 2} è applicata a tutti i termini delimitati da [x p, x num ], 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 s A ) (srv op! first, cbb, 1 s B ) [x id, x p, x num, y p, y num ] srv throw? x id, x p, x num.srv op? x id, y p, y num.s Supponiamo che le prime due sincronizzazioni siano relative alle due invocazioni lo stato del servizio diventa: [x id, x p, x num, y p, y num ] (srv throw? x id, x p, x num.srv op? x id, y p, y num.s) [y p, y num ] (srv op? first, y p, y num.s) {x id first, x p cba, x num 2} [y p, y num ] (srv op? second, y p, y num.s) {x id second, x p cba, x num 3} s A (srv op! first, cbb, 1 s B ) dopo la terza sincronizzazione si ottiene: [x id, x p, x num, y p, y num ] (srv throw? x id, x p, x num.srv op? x id, y p, y num.s) s {x id first, x p cba, x num 2, y p cbb, y num 1} [y p, y num ] (srv op? second, y p, y num.s) {x id second, x p cba, x num 3} s A s B Le due invocazioni srv throw! generano due istanze diverse del blocco repli- 42

43 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 delimitazione 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: [x 1,..., x n ] p o? x 1.s Se lo poniamo in parallelo ad una invocazione del tipo p o! v 1 il risultato è un sistema che evolve nel seguente modo: [x 1,..., x n ] p o? x 1.s p o! v 1 [x 1,..., x n ] p o? x 1.s [x 2,..., x n ] s {x 1 v 1 } Allo stesso modo se prendiamo due clienti che tentano di utilizzare il medesimo servizio: [x 1,..., x n ] p o? x 1.s p o! v 1 p o! v 2 [x 1,..., x n ] p o? x 1.s [x 2,..., x n ] s {x 1 v 1 } [x 2,..., x n ] s {x 1 v 2 } 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

44 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.CU ST chargeok! ID + bank checkf ail? ID.CU ST 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 controllando 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 richiesta, 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

45 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 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 S 1 e S 2 e D è l insieme degli identificatori definiti in dec{...}, allora ogni istanza di S 1 avrà una copia di D condivisa fra tutte le istanze e ogni istanza di S 2 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

46 CAPITOLO 3 Il linguaggio COWSlite Programma: program = declaration? cows_service + 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,<list_of_values>) choice ide := assignable.proc assignable = expr const choice = +(choice, choice) nil?(partner_value,operation_name,<list_of_values>).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. Il terzo e il quarto gruppo sono relativi al blocco di definizione dei servizi. Il terzo 46

47 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 potrebbe 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 è importante 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 listato. 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 chiamate 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

48 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, moltiplicazione 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 Tipi di dato e vettori di variabili write-once Nella sintassi non sono state incorporate formalmente, per non appesantire la notazione, 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 letterale, 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

49 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 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 = x 1,.., x n e lv = x 1,.., x m si ha match(lv, lv ) = true se m = n e i : match(x i, 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

50 CAPITOLO 3 Il linguaggio COWSlite ma genera una sostituzione x v Semantica e differenze con µcows m 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

51 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: p 1 o 1! a + b c, a c/b deve essere tradotto nell equivalente COWSlite: tmp 1 := a + b x.tmp 2 := a c/b.!(p 1, o 1, < tmp 1, tmp 2 >) 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 costrutto 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 sono 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

52 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 sincronizzazione 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,<first,cba,2>), [xp,xnum] (?(odds,throw,<first,xp,xnum>).s,s )} service{ (s,s ) {xp cba, xnum 2}} 52

53 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,<first,cba,2>),s} service{[xp,xnum] (?(odds,throw,<first,xp,xnum>).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 { 53

54 CAPITOLO 3 Il linguaggio COWSlite [Xid:var(String);Xp:var(String);Xnum:var(int); Yp:var(String);Ynum:var(int);]?("srv","o1",<Xid,Xp,Xnum>).?("srv","o2",<Xid,Yp,Ynum>).nil } once service { ( (!(srv,"o1",<"first","cba",2>),!(srv,"o1",<"second","cba",3>)),!(srv2,"o2",<"first","cbb",1>) ) } 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",<Xid,Xp,Xnum>).?("srv","o2",<Xid,Yp,Ynum>).nil [Yp:var(String);Ynum:var(int);]?("srv","o2",<"first",Yp,Ynum>).nil {Xp cba, Xnum 2} [Yp:var(String);Ynum:var(int);]?("srv","o2",<"second",Yp,Ynum>).nil {Xp cba, Xnum 3} } once service {!(srv2,"o2",<"first","cbb",1>) } 54

55 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",<Xid,Xp,Xnum>).?("srv","o2",<Xid,Yp,Ynum>).nil nil {Xid first, Xp cba, Xnum 2, Y p cbb, Y num 2} [Yp:var(String);Ynum:var(int);]?("srv","o2",<"second",Yp,Ynum>).nil {Xp cba, Xnum 3} } once service {} Descrizione ed esecuzione di un servizio La principale differenza fra µcows m e COWSlite è proprio nella definizione iniziale, 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,<x1>).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",<x1>)} once service {!(p,"o",<v1>)} oppure nel caso di due richieste contemporanee once service { (!(p,"o",<v1>),!(p,"o",<v2>))} che produce dopo due comunicazioni, con un po di abuso di notazione: service {[x1:var(int)]?(p,"o",<x1>)} s {x1 v1} s {x1 v2} 55

56 CAPITOLO 3 Il linguaggio COWSlite Bank Account Riprendiamo la simulazione di un servizio bancario, soffermandoci sul servizio bancario vero e proprio individuato dal processo bank. dec{ clientendpoint : partner client "charge" " bankendpoint : partner bank "charge" " } service{ ( [CUST:var(String); CC:var(int); AMOUNT:var(int); ID:var(String);]?("bank", "charge", <CUST, CC, AMOUNT, ID>). (!("bank", "check", <ID, CC, AMOUNT>), +(?("bank", "checkok", <ID>).!(CUST, "chargeok", <ID>),?("bank", "checkfail", <ID>).!(CUST, "chargefail", <ID>) ) ), [CUSTID:var(String); CC:var(int); AMOUNT:var(int);]?("bank", "check", <CUSTID, CC, AMOUNT>). (!("bank","o",<>), +(?("bank", "o", <>).!("bank", "checkok", <CUSTID>),?("bank", "o", <>).!("bank", "checkfail", <CUSTID>)) ) ) } once service { ( (!(bankendpoint,"charge",<clientendpoint,1234,100,"id1">), 56

57 3.3 Esempi +(?("client", "chargeok", <"id1">).nil,?("client", "chargefail", <"id1">).nil)), (!(bankendpoint,"charge",<clientendpoint,1234,200,"id2">), +(?("client", "chargeok", <"id2">).nil,?("client", "chargefail", <"id2">).nil)) ) } Il processo bank è costituito da due endpoint di comunicazione uno esterno corrispondente 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 diversi 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 58

59 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

60 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 realizzazione 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

61 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 e i test sono stati effettuati utilizzando gli application server SUN Application Server Platform Edition 9.0 e Glassfish 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 comunicazione 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

62 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 recuperare 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

63 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 specifiche è molto semplice con le API fornite da Sun. Un servizio altro non è che una classe package _nomedelpackage_ ; import javax. jws. 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 ( ) 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

64 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 posta prima della dichiarazione della classe, si dichiara che quella classe dovrà essere convertita in un servizio web e poi si dichiarano le operazioni esposte anteponendo l 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 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 metodo ServiceCreator() e riempire il corpo dei metodi che corrispondono alle operazioni esposte dal servizio in modo che inoltrino le richieste all engine. successivamente con cosa riempire il corpo di questi metodi. Vedremo 4.3 Il package cowslite.engine Per poter completare il codice all interno dello scheletro del servizio visto precedentemente si fa uso del package cowslite.engine che è stato realizzato per fornire contemporaneamente 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

65 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 DataSpace è influenzato dalla logica del processo che genera nuove variabili e nuovi ambienti in funzione dello stato di esecuzione e contemporaneamente le variabili contenute negli ambienti possono subire modifiche da parte di azioni avvenute nel ServiceSpace 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 avvenute 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 passano attraverso il ServiceSpace, dove vengono elaborate oppure archiviate in attesa 65

66 CAPITOLO 4 Implementazione di COWSlite di una possibile esecuzione. Il metodo per scegliere e/o selezionare un elemento contenuto 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 ricezione 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 ServiceSpace. Analogamente, quando dall esecuzione del servizio COWSlite si ottiene un attività di ricezione, questa viene inviata al ServiceSpace che controlla la presenza 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 negativo 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 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 comunicazioni da e verso il servizio COWSlite. In particolare, il suo compito è quello di 66

67 4.3 Il package cowslite.engine trattare le operazioni di invoke e receive del linguaggio, discriminare quali richieste 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 esposte 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 comunicazione in maniera trasparente per lo sviluppatore del servizio, tanto che, come si è visto nello scheletro di codice del servizio, il programmatore che realizza un servizio 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 comunicazione. Queste classi rappresentano due aspetti presi in considerazione dall unità assolvendo ciascuna un compito ben preciso. Sono suddivisibili in base alla classe 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 sistema 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 implementazioni a runtime. Nell implementazione corrente l engine sceglie sempre come istanza la classe ComunicationService, per cui l altra può essere considerata soltanto 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

68 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 è necessaria, 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

69 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 contro. 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 scapito 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

70 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 informazione (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<Source> 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 <soapenv:body>, nella quale viene specificato il nome dell operazione e poi, delimitati da tag appositi, i valori dei parametri. 70

71 4.3 Il package cowslite.engine <?xml version=" 1. 0 " encoding="utf 8"?> <soapenv:envelope xmlns:soapenv=" h t t p : // schemas. xmlsoap. org / soap / envelope /" xmlns:xsd=" h t t p : //www. w3. org /2001/XMLSchema" xmlns:ns1=" h t t p : //bank/"> <soapenv: Body> <ns1:chargeok> <arg0>ok</ arg0> </ ns1:chargeok> </ soapenv: Body> </ soapenv:envelope> Tabella 4.3: Web Service - Messaggio SOAP 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), semplificando 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

72 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 interfaccia 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 variabili 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). Figura 4.5: Diagramma delle classi delle variabili WO Label e LabelKiller sono state definite solo in previsione di una estensione 72

73 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<T> è la classe che implementa le variabili semplici di tipo writeonce. È 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 variabili 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 assegnato 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

74 CAPITOLO 4 Implementazione di COWSlite public c l a s s WOVar<T> 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<T> 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<T> 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 writeonce, ha un duplice ruolo quello di tipo di dato e quello di contenitore dei parametri scambiati fra i servizi come vedremo fra poco. 74

75 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 poter 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

76 CAPITOLO 4 Implementazione di COWSlite DataSpace e ambienti annidati 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 esecuzione 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 processo è 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 mantiene 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 Descrizione del servizio COWSlite Uno dei problemi affrontati nella realizzazione dell engine di COWSlite è stato quello 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

77 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 concorrenti, 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 (Figura 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

78 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 comune per tutte le operazioni definendo un insieme di metodi che tutte le classi derivate (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