Università degli Studi di Firenze Facoltà di Scienze Matematiche Fisiche e Naturali Tesi di Laurea in Informatica

Università degli Studi di Firenze Facoltà di Scienze Matematiche Fisiche e Naturali Tesi di Laurea in Informatica Progetto ed implementazione di uno strumento per il supporto allo sviluppo di applicazioni WS-BPEL Relatore: Prof. Rosario Pugliese Candidato: Luca Cesari Correlatori: Alessandro Lapadula Francesco Tiezzi Anno Accademico 2007/2008

A tutti quelli che mi vogliono bene.

Sommario Questa tesi illustra il progetto e la relativa implementazione di uno strumento che semplifica la scrittura e l esecuzione di applicazioni WS-BPEL. Le motivazioni del lavoro descritto in questa tesi nascono dalle difficoltà intrinseche nello sviluppo e nell esecuzione di applicazioni WS-BPEL, uno standard OASIS per lo sviluppo e l orchestrazione di servizi web. Infatti, soprattuto per i neofiti del linguaggio, la progettazione di applicazioni risulta difficile perché WS-BPEL, essendo il risultato di un compromesso tra varie proposte precedenti, supporta vari stili di programmazione fornendo molti costrutti alternativi ma con funzionalità simili. Inoltre, la sintassi di WS-BPEL si basa su XML. Ciò, se da un lato favorisce (almeno in linea di principio) la portabilità delle applicazioni, dall altro complica la scrittura dei programmi a causa della verbosità del linguaggio. Infine, la messa in esecuzione di programmi WS-BPEL è anche complicata dalla fase di deploy che richiede l associazione al programma di alcuni dati importanti per l esecuzione. Il nostro obiettivo è quindi stato quello di fornire uno strumento di supporto per la scrittura e l esecuzione di applicazioni WS-BPEL. A tale scopo abbiamo usato Blite, un linguaggio per la definizione e l orchestrazione di servizi, dotato di una semantica operazionale formale, che mette a disposizione del programmatore un insieme ridotto di costrutti, senza sostanzialmente diminuire il potenziale descrittivo di WS-BPEL. Lo strumento da noi sviluppato, che abbiamo chiamato BliteC, permette la generazione di codice WS-BPEL eseguibile a partire da un programma Blite. Sostanzialmente, BliteC è un compilatore di Blite in WS-BPEL che si fa carico della complessità di scrittura derivante dall uso di XML e delle problematiche relative al deploy del codice WS-BPEL generato.

Ringraziamenti Desidero innanzitutto ringraziare mio padre Marco, mia madre Marina, mia sorella Elisa, i nonni, la zia Patrizia e la mia ragazza Silvia per aver avuto fiducia nelle mie capacità e per avermi sostenuto nei momenti difficili, aiutandomi così a raggiungere questo importante traguardo. Uno speciale ringraziamento va a Geri Tollkuçi, grande amico e compagno di studi che, preparando la tesi in questo periodo ha vissuto e condiviso con me i momenti di gioia e di panico che caratterizzano questa fase. Ringrazio sentitamente il Prof. Rosario Pugliese e i suoi assistenti Alessandro Lapadula e Francesco Tiezzi per la disponibilità e l aiuto nella realizzazione di questo lavoro. Infine, ringrazio i miei compagni Daniele, Emanuela, Federico, Karen, Mirko, Massimiliano e Olta che con me hanno studiato e trascorso questi anni di università. Potrei aver dimenticato di ringraziare qualcuno che, comunque, ha contato molto per me in questi anni. Mi scuso della possibile dimenticanza e confido nella sua comprensione.

Indice 1 Introduzione 1 2 Nozioni Preliminari 7 2.1 I Servizi web e le tecnologie collegate.................. 7 2.1.1 XML Schema........................... 8 2.1.2 WSDL............................... 11 2.1.3 SOAP............................... 14 2.2 WS-BPEL: uno standard per l orchestrazione di servizi web...... 15 2.2.1 Processo WS-BPEL........................ 17 2.2.2 Variable Properties Schema................... 25 2.2.3 Partner Link Type Schema.................... 25 2.3 Blite: una variante snella di WS-BPEL................ 26 2.3.1 Sintassi.............................. 27 2.3.2 Semantica Operazionale..................... 29 3 Descrizione generale di BliteC 37 3.1 Implementazione............................. 38 3.2 Funzionamento.............................. 41 i

ii INDICE 3.3 Utilizzo.................................. 43 3.3.1 Esecuzione della compilazione con BliteC............ 44 3.3.2 Deploy del processo su ActiveVOS............... 45 3.3.3 Invocazione del servizio...................... 45 4 Generazione dei Parser 51 4.1 Uso di JavaCC.............................. 51 4.2 Mapper.................................. 55 4.2.1 Descrizione del File di Configurazione.............. 55 4.2.2 Funzionamento del Mapper................... 61 4.3 Parser Blite................................ 70 4.3.1 Analisi del documento e generazione dell albero........ 70 4.3.2 Controllo dell albero....................... 79 5 Generazione del Codice 83 5.1 Generatore WS-BPEL.......................... 83 5.1.1 Basic Activity........................... 84 5.1.2 Structured Activity........................ 87 5.1.3 Start Activity........................... 88 5.1.4 Service Activity.......................... 89 5.2 Generatore WSDL............................ 89 5.3 Deploy del processo WS-BPEL..................... 95 6 Casi di Studio 99 6.1 Comunicazione Asincrona........................ 99 6.1.1 Server Asincrono......................... 100 6.1.2 Client Asincrono......................... 104 6.2 Comunicazione con un servizio non Blite................ 109

INDICE iii 6.3 Shipping Service............................. 112 6.3.1 Back-end Service......................... 113 6.3.2 Shipping Service......................... 116 6.3.3 Shipping Client.......................... 124 7 Conclusioni 131

iv INDICE

Capitolo 1 Introduzione Negli ultimi anni, l aumento dell utenza di Internet ha evidenziato sempre più il successo del World Wide Web, che progressivamente si è popolato di risorse e funzionalità software di vario tipo. L aumento di queste risorse e la definizione di nuove tecnologie come e-business, e-learning e modelli simili ha evidenziato sempre più l importanza di una tecnologia che permetta l utilizzo automatico oltre all utilizzo da parte di utenti umani. Tale esigenza ha spinto il World Wide Web ad evolversi in un Architettura Orientata ai Servizi. Un Architettura Orientata ai Servizi (o SOA, dal nome inglese Service Oriented Architecture) è un architettura distribuita composta da uno o più nodi che mettono a disposizione servizi fruibili attraverso lo scambio di messaggi. Un servizio è assimilabile ad un entità autonoma, che può essere pubblicata, scoperta e assemblata con altre, per costruire applicazioni complesse. Da un punto di vista fisico il servizio permette di disaccoppiare l implementazione della risorsa dalla modalità di interazione con essa, permettendo così all utente di utilizzarla senza preoccuparsi di tutti gli altri dettagli inerenti all implementazione. In una architettura SOA, i servizi possono giocare tre differenti ruoli: il provider, il richiedente e il registro. I provider offrono funzionalità e pubblicano descrizioni di 1

2 1. Introduzione servizi su registri per abilitare la scoperta automatica e permetterne l invocazione da parte dei richiedenti. Ad oggi, sebbene esistano varie interpretazioni di SOA, quella maggiormente utilizzata descrive i servizi attraverso servizi web. Un servizio web è un sistema software progettato per garantire interoperabilità tra nodi diversi di una stessa rete. I servizi web sono descritti attraverso WSDL (Web Service Description Language [1]), un linguaggio di descrizione dei servizi web basato su XML (extensible Markup Language [2]). Il documento WSDL associato ad un servizio permette di specificare le funzionalità offerte senza entrare nei dettagli relativi all implementazione e allo stesso tempo permette all utilizzatore di capire come contattare il servizio. I nodi di un architettura SOA basata su servizi web inviano messaggi formattati in XML attraverso il protocollo SOAP (ma usano anche altri protocolli quali JAX- RPC [3], XML-RPC [4], REST [5]), che sono trasportati sulla rete attraverso protocolli come HTTP [6], SMTP [7], FTP [8] o XMPP [9]. Possono inoltre essere utilizzati particolari protocolli per garantire caratteristiche specializzate quali: UDDI [10] per l elencazione dei servizi, WS-Security [11] per l autenticazione e WS-Reliability [12] per la definizione di messaggi affidabili (ad esempio quelli necessari a transazioni monetarie sul web). Con il diffondersi dell architettura SOA composta da servizi web, si è delineata la necessità di comporre e gestire servizi in modo più articolato, erogandone di nuovi senza modificare quelli esistenti. Da questa necessità sono nate le specifiche WS-CDL (Web Service Choreography Description Language [13]) e WS-BPEL (Web Service Business Process Execution Language [14]) che regolano due diversi aspetti dello stesso problema. La prima definisce come garantire l interoperabilità necessaria a realizzare un sistema composto da vari servizi, ovvero definisce le regole con le quali i vari servizi si dovranno comportare per formare il sistema; la seconda invece genera

1. Introduzione 3 un nuovo servizio che si comporrà di servizi preesistenti. Nel dettaglio, un programma scritto in WS-BPEL è detto processo, ed è eseguito su appositi engine WS-BPEL che mettono a disposizione i costrutti necessari all esecuzione del programma. L engine è un elemento fondamentale per l esecuzione di codice WS-BPEL, perché fornisce al programmatore un implementazione delle complesse funzionalità dei costrutti WS-BPEL, che altrimenti non troverebbero corrispondenza immediata in un normale linguaggio di programmazione. Esistono molti engine che permettono l esecuzione di un processo WS-BPEL, tra i più noti troviamo ActiveVOS [15] di Active Endpoints, Apache ODE [16] del progetto Apache, ORACLE Bpel Process Manager [17] di Oracle, WebSphere [18] di IBM. Per eseguire correttamente un processo, oltre al documento che ne descrive il comportamento, un engine necessita di informazioni che permettano ai dati astratti presenti nella definizione del processo di legarsi a quelli corrispondenti alla definizione fisica dei servizi utilizzati, permettendo così all engine di eseguire le operazioni richieste. Questa fase di configurazione dell engine è chiamata deploy. Per essere eseguito da un engine un processo WS-BPEL deve contenere almeno un operazione di ricezione, la quale viene utilizzata per impostare i valori iniziali che ne caratterizzeranno l esecuzione. Infatti, a seguito dell esecuzione dell operazione, una istanza del processo è creata. Questa rappresenta il controllo di flusso esercitato dal processo applicato ad un insieme di variabili inizializzate. Ovviamente un engine permette di eseguire simultaneamente più istanze di uno stesso processo, in modo da servire più richieste contemporaneamente. La presenza di più istanze dello stesso processo comporta però alcune complicazioni nello smistamento dei messaggi, infatti il motore deve riuscire a consegnare ogni messaggio ricevuto all istanza corretta. Per risolvere il problema lo standard

4 1. Introduzione permette di definire delle variabili di correlazione, che dovranno fungere da chiave per distinguere ogni istanza di uno stesso processo. Queste variabili sono scelte dall utente e non in automatico dall engine; quindi in fase di progettazione deve essere fatta una scelta oculata. Infatti una scelta sbagliata vanificherà la funzione delle variabili di correlazione nella politica di smistamento, provocando ovviamente problemi di consegna alle varie istanze. La definizione dello standard WS-BPEL in linguaggio naturale, cioè senza una specifica formale della semantica, e la mancanza di una convenzione per la fase di deploy, ha portato allo sviluppo di engine che, a volte, interpretano la stessa specifica in modo diverso ed utilizzano documenti differenti per la fase di deploy. Tutto ciò si traduce nell impossibilità di eseguire un processo WS-BPEL su un qualunque engine essendo sicuri di avere lo stesso comportamento. Inoltre, i documenti generati per l esecuzione su di un engine, non mantengono la portabilità su di un altro, vanificando in parte l uso di XML. Tali inconvenienti sono stati ampiamente e dettagliatamente descritti nei documenti [19] e [20]. La grande quantità di costrutti messi a disposizione dallo standard WS-BPEL permette all utilizzatore di definire un servizio in modi diversi in base al contesto in cui dovrà lavorare. Questa capacità però rende difficile il lavoro al programmatore perché, oltre a dover scrivere il codice utilizzando una sintassi XML, deve avere una discreta conoscenza dello standard per creare un servizio in modo corretto. In alternativa possono essere utilizzate delle interfacce grafiche che permettono la semplificazione della progettazione in WS-BPEL, come ad esempio Active Designer [21] di Active Endpoints o Intalio Designer [22] di Intalio. Questi strumenti permettono di definire facilmente processi molto semplici (con poche operazioni), ma quando la complessità dei processi aumenta ben presto la definizione grafica diventa di difficile gestione e comprensione.

1. Introduzione 5 Lo scopo di questa tesi consiste nel fornire una soluzione ai problemi che rendono difficile la progettazione e lo sviluppo di applicazioni WS-BPEL. La soluzione proposta è un strumento software, BliteC, che accetta in ingresso un servizio scritto in Blite [19], un linguaggio in stile imperativo semplice e intuitivo, e restituisce in uscita la traduzione in WS-BPEL utilizzando solo un sottoinsieme dei costrutti dello standard, per facilitarne la comprensione. Questa soluzione non perde il potere descrittivo iniziale, infatti la maggior parte dei costrutti WS-BPEL omessi possono comunque essere codificati in Blite. Utilizzando BliteC è possibile progettare e scrivere un nuovo servizio concentrandosi solo sul problema da risolvere piuttosto che sulla scelta dei dettagli. La definizione testuale proposta da BliteC permette di mantenere semplice la comprensione dei processi che svolgono funzionalità complesse, risolvendo così il problema riscontrato nell utilizzo di interfacce grafiche. BliteC, inoltre, automatizza il processo di deploy sugli engine WS-BPEL. Infatti, oltre a generare il documento WS-BPEL e il WSDL associato al servizio passato in ingresso, BliteC genera anche i documenti necessari al deploy. Infine, tutti i documenti generati sono inseriti in un pacchetto organizzato in maniera appropriata secondo le specifiche di ActiveVOS. La scelta di questo engine è dovuta alla fedele interpretazione delle specifiche dello standard WS-BPEL, come riportato dalle analisi svolte in [19] e [20]. Il meccanismo di deploy usato da BliteC risolve i problemi precedentemente elencati e facilita il lavoro dell utente, che si dovrà semplicemente occupare della scrittura del codice Blite e di fornire alcuni dati di configurazione. BliteC è sviluppato in modo tale da permettere il deploy su vari engine, fornendo così una soluzione alla mancanza di standard per i documenti caratterizzanti questa fase; ciò permette a BliteC di essere più versatile rispetto ad altri strumenti di supporto grazie alla capacità di adattamento ai vari engine.

6 1. Introduzione Il resto della tesi è organizzato come segue. Nel Capitolo 2 sono introdotti i principali standard necessari alla definizione dei servizi web, una breve descrizione dei costrutti WS-BPEL utilizzati da BliteC e una descrizione del linguaggio Blite. Nel Capitolo 3 è presentata una breve introduzione all architettura di BliteC, mentre nei Capitoli 4 e 5 sono dettagliate le implementazioni dei parser e la generazione del codice. Nel Capitolo 6 sono proposti alcuni esempi significativi per meglio evidenziare il funzionamento di BliteC. Il Capitolo 7 riporta alcune osservazioni conclusive.

Capitolo 2 Nozioni Preliminari In questo capitolo verranno introdotte le tecnologie utilizzate da BliteC per effettuare la traduzione da Blite a WS-BPEL, per poi fornire al lettore una breve introduzione su WS-BPEL e sulla sua variante leggera Blite. 2.1 I Servizi web e le tecnologie collegate I servizi web utilizzano per la loro definizione alcuni standard basati su XML. XML [2] è un metalinguaggio di markup, ovvero un linguaggio marcatore che definisce un meccanismo sintattico tale da consentire il controllo o l estensione del significato di altri linguaggi di markup. In particolare, XML è un linguaggio di markup di tipo descrittivo perché si concentra sulla sintassi dei linguaggi descritti, prescindendo dal significato che i costrutti avranno in lettura. Ciò permette agli standard scritti in XML fruibilità su qualunque tipo di piattaforma facilitando quindi l interoperabilità. In questa tesi lavoreremo e genereremo servizi web utilizzando i seguenti standard basati su XML: XML Schema, 7

8 2. Nozioni Preliminari WSDL, SOAP. 2.1.1 XML Schema XML Schema è un linguaggio che descrive il contenuto di un documento XML. I documenti prodotti con questo linguaggio saranno indicati nella trattazione come schema. XML Schema permette la definizione di tipi di dato che possono essere usati per stabilire la conformità di un qualsiasi documento XML rispetto a un dato schema. Ovviamente, anche uno schema prima di essere usato per la validazione di altri documenti, deve risultare ben formato rispetto ai tipi base del linguaggio XML Schema. Questa operazione non differisce dalla validazione degli altri documenti XML, perché anche lo standard XML Schema è definito attraverso uno schema. L operazione di validazione non è automatica ma deve essere effettuata attraverso l ausilio di appositi strumenti software che, avendo in ingresso uno schema, riescono a controllare altri documenti XML verificandone la conformità rispetto al documento passato in ingresso. Un esempio di validatore di schema si trova sul sito del W3C [23], mentre un esempio di programma che effettua validazione di documenti XML rispetto a schema è l Eclipse XSD Editor [24]. In dettaglio XML Schema definisce: gli elementi che possono apparire in un documento; gli attributi che possono apparire negli elementi ; quali elementi possono comparire come figli di altri elementi; l ordine di apparizione degli elementi; il numero di elementi che possono comparire;

2. Nozioni Preliminari 9 quando un elemento può essere vuoto o può contenere del testo; i tipi di dati per elementi ed attributi; valori di default e valori fissati per elementi ed attributi. Prima di procedere, riportiamo un esempio che ci aiuterà a comprendere il funzionamento di XML Schema. Il seguente documento XML fornisce un insieme di campi necessari all identificazione di una persona. <? xml version ="1.0" encoding =" UTF -8"?> <persona > <nome > Paolo </ nome > <cognome > Rossi </ cognome > < codicefiscale > PLARSS73A01D612D </ codicefiscale > <nascita >01/01/1973 </ nascita > < statocivile > Celibe </ statocivile > </ persona > Una possibile descrizione XML Schema del documento precedente potrebbe essere: <? xml version ="1.0" encoding =" UTF -8"?> <xs: schema xmlns =" http :// www. example. org " xmlns :so =" http :// www. example. org " xmlns :xs =" http :// www.w3.org /2001/ XMLSchema " targetnamespace =" http :// www. example. org "> < xs: simpletype name =" codicefiscaletype " > <xs: restriction base =" xs: string "> <xs: pattern value ="[a-za -Z ]{6}\ d\d[a-za -Z]\d\d[a-zA -Z]\d \d\d[a-za -Z]"/ > </xs: restriction > </xs: simpletype > <xs: complextype name =" personatype "> <xs: sequence > <xs: element name =" nome " type =" xs: string "/ > <xs: element name =" cognome " type =" xs: string "/ > <xs: element name =" codicefiscale " type =" so: codicefiscaletype "/ > <xs: element name =" nascita " type =" xs: date "/ > <xs: element name =" statocivile " type =" xs: string "/ > </xs: sequence > </xs: complextype > <xs: element name =" persona " type =" so: personatype "/ > </xs:schema > Analizziamo adesso la definizione XML Schema in dettaglio.

10 2. Nozioni Preliminari Il tag <?xml version=1.0 encoding=utf-8?> presente nell intestazione indica al lettore che sta leggendo un documento XML nella versione 1.0. Di seguito c è il tag radice dell XML Schema, che indica l inizio della dichiarazione. Il tag <schema> può essere corredato di alcuni attributi per personalizzare il linguaggio risultante. Gli attributi più comuni sono presenti anche nell esempio: xmlns=http://www.example.org : imposta il namespace a cui far riferimento nel caso gli elementi non siano affiancati da un prefisso; xmlns:xs=http://www.w3.org/2001/xmlschema: imposta il prefisso da utilizzare nel caso si voglia far riferimento ad elementi presenti nella definizione XML Schema; targetnamespace=http://www.example.org: definisce il namespace cui apparterranno gli elementi definiti nel documento. I tag <simpletype> e <complextype> definiscono nuovi tipi da utilizzare nella definizione degli elementi. <simpletype> definisce un tipo semplice che può contenere solo testo; <complextype> invece definisce un tipo complesso che può contenere altri elementi e/o attributi. Il tag <element> permette di definire elementi di tipo semplice o complesso da utilizzare nel documento. La differenza tra i due tipi di elemento è contraddistinta dall attributo type che imposta il tipo di dato descritto nell elemento. Nel nostro caso abbiamo definito un nuovo tipo codicefiscaletype che utilizza il tipo primitivo string e lo raffina attraverso una espressione regolare. Il tipo personatype, invece, definisce un tipo complesso formato da una sequenza ordinata di elementi necessari all identificazione di un individuo. Infine è stato definito l elemento <persona> che fungerà da elemento radice in un documento XML scritto utilizzando il linguaggio.

2. Nozioni Preliminari 11 2.1.2 WSDL Lo standard WSDL [1] descrive come e dove contattare i servizi messi a disposizione da un host. Un documento WSDL si compone, solitamente, dai seguenti tag: <types>: la sezione contraddistinta da questo tag è opzionale e si usa per integrare la definizione di tipo dei dati, scritti in XML Schema, da utilizzare nel documento WSDL; <message>: definisce il tipo di messaggio usato dal servizio web per comunicare con un client; <porttype>: definisce il tipo di porta di comunicazione, elencando le operazioni pubblicate e i messaggi da utilizzare con ciascuna di esse; <binding>: definisce le modalità con cui contattare una porta di comunicazione; <service>: indica l indirizzo per contattare il servizio. Il seguente esempio di documento WSDL descrive un servizio che mette a disposizione dei client un operazione o req. <? xml version ="1.0" encoding =" UTF -8"? > <wsdl : definitions xmlns : wsdl =" http :// schemas. xmlsoap. org / wsdl /" xmlns : tns =" http :// example / OneWayServer. wsdl " xmlns :xs =" http :// www.w3.org /2001/ XMLSchema " xmlns : soap =" http :// schemas. xmlsoap. org / wsdl / soap /" targetnamespace =" http :// example / OneWayServer. wsdl "> <wsdl : types > < xsd : schema targetnamespace =" http :// example / OneWayServer. wsdl "> <xsd : element name =" x_idel " type =" xsd : integer " /> </ xsd : schema > </ wsdl : types > <wsdl : message name =" req "> <wsdl : part name =" id" element =" tns : x_idel " /> </ wsdl : message > <wsdl : porttype name =" OW_serverPT "> <wsdl : operation name =" o_req "> <wsdl : input message =" tns : req " />

12 2. Nozioni Preliminari </ wsdl : operation > </ wsdl : porttype > <wsdl : binding name =" OW_serverBinding " type =" tns : OW_serverPT "> <soap : binding style =" document " transport =" http :// schemas. xmlsoap. org / soap / http " /> <wsdl : operation name =" o_req "> < soap : operation soapaction =" http :// example / OneWayServer. wsdl / o_req " style =" document " /> <wsdl : input > <soap : body use =" literal " /> </ wsdl : input > </ wsdl : operation > </ wsdl : binding > <wsdl : service name =" OW_serverService "> <wsdl : port name =" OW_serverPort " binding =" tns : OW_serverBinding "> <soap : address location =" http :// localhost :8080/ active - bpel / services / OW_ serverservice " / > </ wsdl :port > </ wsdl : service > </ wsdl : definitions > Il tag di apertura del documento WSDL è <definition>, nel quale possono essere dichiarati tutti i namespace necessari alla definizione delle sezioni successive. Nella sezione <types> è definito l elemento utile alla descrizione del messaggio necessario all operazione o req. <message> contiene un tag <part> che definisce il tipo della parte di messaggio id; ovviamente all interno di un messaggio possono comparire più <part> che contraddistinguono varie parti del messaggio. Come per <part>, anche <message> può occorrere più volte all interno dello stesso documento, definendo ovviamente messaggi diversi. Ogni <porttype> è contraddistinto da una serie di operazioni <operation> che supportano vari tipi di comunicazione: One-Way: la comunicazione si ottiene inviando un messaggio al servizio che non restituirà nessuna risposta;

2. Nozioni Preliminari 13 Request-Response: la comunicazione si compone di un messaggio inviato dal client e uno inviato dal servizio; Solicit-Response: la comunicazione si compone di un messaggio inviato dal servizio e una risposta correlata inviata dal client; Notification: il servizio invia una notifica ad un client. Il tipo di comunicazione non è indicato esplicitamente, ma è definito dalla presenza dei tag <input> e <output>. Il tag <input> indica i messaggi in ricezione e il tag <output> quelli di risposta; i precedenti tag hanno come argomento il tipo di messaggio atteso. Nel nostro esempio essendo l operazione o req di tipo one-way, comparirà solo il tag <input> che impone un messaggio di tipo req in ingresso al servizio. Il tag <binding> specifica le informazioni sul protocollo da utilizzare per contattare il servizio per un <porttype> definito in precedenza. In generale, come anche nell esempio, il protocollo di comunicazione è SOAP. Per impostarne l utilizzo sono aggiunti alcuni tag definiti nel namespace di SOAP. Il primo tag utilizzato è <soap:binding>, che definisce il tipo di comunicazione (style="document") ed il protocollo di trasporto (transport="http://schemas.xmlsoap.org/soap/http"). Di seguito sono definite tutte le operazioni da rendere raggiungibili. Dunque, per ogni operazione, saranno aggiunti due tag <operation>: uno con namespace WSDL e l altro con namespace SOAP. Il primo indica il nome dell operazione e il secondo definisce la modalità con cui contattare il servizio. Ad ogni <operation> saranno aggiunti dei tag <input> e/o <output> contenenti un tag <soap:body> per indicare come saranno strutturate le parti del messaggio all interno del corpo del messaggio SOAP.

14 2. Nozioni Preliminari L ultima sezione dell esempio è contraddistinta dal tag <service>. Questo tag prende in argomento un binding e aggiunge informazioni sulla locazione del servizio. Ovviamente, utilizzando il protocollo SOAP, l indirizzo HTTP a cui reperire il servizio è posto all interno del tag <soap:address>. Infine, oltre ai costrutti definiti nel linguaggio, WSDL permette di utilizzare elementi definiti in altri documenti per estendere il linguaggio. Questa capacità permette di aggiungere informazioni ad un documento WSDL in modo pratico e veloce, senza dover modificare la definizione del linguaggio. Come vedremo in seguito questa capacità si rivelerà molto utile per aggiungere informazioni necessarie al funzionamento di un processo WS-BPEL. Per ulteriori delucidazioni riguardo WSDL invitiamo il lettore a visionare la specifica W3C [1]. 2.1.3 SOAP Il protocollo SOAP (Simple Object Access Protocol [25]) gestisce lo scambio di informazioni strutturate per la comunicazione con i servizi web. L utilizzo di questo protocollo permette la comunicazione tra applicazioni sviluppate con linguaggi diversi e residenti su architetture, sia hardware che software, eterogenee. Le principali sezioni che compongono un documento SOAP sono: <Envelope>: definisce che il documento a seguire è un messaggio SOAP e permette la dichiarazione dei namespace utili alle dichiarazioni successive; <Header>: è una sezione opzionale che permette al client di inviare informazioni aggiuntive al servizio web; <Body>: contiene i dati inviati dal client al servizio web;

2. Nozioni Preliminari 15 <Fault>: è una sezione opzionale, dichiarabile all interno del tag precedente, che fornisce informazioni riguardanti gli errori rilevati nei messaggi. Riportiamo ora un piccolo esempio che fornisce un messaggio SOAP per comunicare con il servizio utilizzato nelle precedenti sezioni. < soapenv : Envelope xmlns : soapenv =" http :// schemas. xmlsoap. org / soap / envelope /" xmlns : onew =" http :// example / OneWayServer. wsdl "> < soapenv : Header /> < soapenv :Body > <onew : x_idel >42 </ onew : x_idel > </ soapenv :Body > </ soapenv : Envelope > Nel tag <envelope> sono definiti i namespace utili nel documento, mentre all interno del tag <body> sono definiti quelli necessari all interpretazione dei messaggi. Questo approccio permette al servizio web di interpretare i messaggi senza bisogno di dati aggiuntivi oltre al messaggio SOAP. Una volta costruito il messaggio non dovremo far altro che inviarlo all indirizzo contenuto nel tag <soap:address> presente nella sezione <service> del documento WSDL associato al servizio web. Per avere ulteriori dettagli su questo protocollo, si rimanda alla lettura della specifica ufficiale [25]. 2.2 WS-BPEL: uno standard per l orchestrazione di servizi web WS-BPEL (Web Service Business Process Execution Language [14]) è un linguaggio basato su XML che permette di costruire processi di business utilizzando in modo trasparente servizi messi a disposizione da vari attori. Il linguaggio WS-BPEL fornisce costrutti che permettono l esecuzione di attività in modo concorrente o

16 2. Nozioni Preliminari sequenziale, la manipolazione di dati, la gestione del flusso, compreso il trattamento di casi particolari dell esecuzione attraverso eccezioni e compensazioni. Un programma WS-BPEL è chiamato processo ed è una collezione di attività messe a disposizione dal linguaggio. Ogni processo per comunicare con servizi esterni utilizza dei partner link, che sono un astrazione di dati utili a contattare un servizio. I partner link non possono essere dichiarati all interno del processo, ma devono essere forniti attraverso l utilizzo di Partner Link Type Schema come estensione al linguaggio WSDL. Solitamente troveremo i partner link all interno del documento WSDL che accompagna il servizio da contattare. Un esempio per chiarire meglio la funzione dei partner link è il seguente, se consideriamo: un servizio web equivale nel mondo reale ad una descrizione di come contattare un ristorante ed ordinare del cibo, allora un partner link può essere visto come un foglio contenente il numero di un ristorante al quale l utente può telefonare senza preoccuparsi dei dettagli della comunicazione. Dunque un partner link risulta una semplificazione del metodo di comunicazione con un servizio utile all esigenza di astrazione di un processo WS-BPEL. Per eseguire un processo dobbiamo utilizzare appositi engine. L engine è un interprete che trasforma i costrutti astratti del linguaggio WS-BPEL in operazioni eseguibili da un elaboratore. Vista l astrazione di un processo WS-BPEL l engine ha bisogno di una serie di documenti che gli permettano di configurare tutti i dettagli relativi alle interazioni con il mondo esterno, come ad esempio i partner link. La fase nella quale l engine effettua la combinazione delle informazioni tra i documenti di configurazione e il processo, è chiamata fase di deploy. Quando si è effettuato il deploy di un processo su di un engine, questo può passare alla fase dinamica, ovvero è possibile creare un istanza del processo. Un istanza può essere creata solo attraverso un operazione di ricezione iniziale, che

2. Nozioni Preliminari 17 imposterà i valori di inizializzazione delle variabili del processo. Ovviamente, la scelta dell istanziazione solo attraverso operazioni di ricezione è dovuta al contesto di lavoro del processo. Infatti il processo è visto dall esterno come un servizio web, quindi, l unica motivazione per l istanziazione del processo è la richiesta da un partner esterno. Su di un engine, uno stesso processo può avere più istanze attive per poter servire tutte le richieste ricevute dall esterno. Avere più istanze però introduce un problema per lo smistamento dei messaggi; infatti l engine dovrà instradare ogni messaggio all istanza giusta del processo. A questo problema si possono trovare varie soluzioni, ma la più semplice ed elegante è la dichiarazione di parti del messaggio che permettano di distingure un istanza da un altra in relazione al valore contenuto. Questo sistema fornisce un metodo di correlazione sia per i messaggi entranti sia per quelli uscenti. Come per i partner link non è possibile dichiarare quali saranno le parti del messaggio che specificano la correlazione all interno della specifica del processo. La correlazione sui messaggi può essere descritta utilizzando l estensione Variable Properties Schema del linguaggio WSDL, che fornisce dei costrutti per definire la parte di correlazione di un messaggio. Nel resto di questa sezione introdurremo la struttura di un documento WS-BPEL. 2.2.1 Processo WS-BPEL Un processo WS-BPEL è definito in un documento contenente le seguenti sezioni:. <process> contiene tutte le seguenti sezioni e la descrizione del comportamento normale del processo; <partnerlink> definisce i partner con cui il processo di business può interagire durante l esecuzione;

18 2. Nozioni Preliminari <variables> definisce le variabili usate dal processo, provvedendo alla loro definizione in termini di tipi di messaggio WSDL, XML Schema type oppure XML Schema element. Le variabili permettono al processo di mantenere informazioni di stato tra scambi di messaggi successivi; <correlationsets> dichiara le variabili di correlazione utilizzate dal processo. Le occorrenze di questa sezione importano le proprietà delle variabili per la correlazione; <faulthandlers> contiene le attività da eseguire nel caso si verifichino degli errori. Attività WS-BPEL Un processo WS-BPEL si compone di attività che ne descrivono il comportamento. Nel seguito della trattazione saranno introdotti i costrutti utilizzati da BliteC per la traduzione da Blite a WS-BPEL. Per facilitare la lettura riportiamo le notazioni utilizzate nella descrizione delle attività: la sintassi utilizzata è di tipo XML,; i quantificatori "?" (0 o 1), "*" (0 o più) e "+" (1 o più) servono ad indicare le occorrenze degli elementi e degli attributi; gli elementi e gli attributi separati da " " rappresentano una scelta alternativa (OR); NSName rappresenta il prefisso associato ad un namespace ed è caratterizzato da una sequenza di lettere, cifre,"_", "-", "." (period) che non può iniziare con una cifra;

2. Nozioni Preliminari 19 NCName rappresenta un tipo di dato in un namespace ed è caratterizzato da una sequenza di lettere, cifre,"_", "-", "." (period) che non può iniziare con una cifra; Qname è un sequenza corrispondente a NSName ":" NCName. Introduciamo adesso le attività WS-BPEL di base per poi introdurre quelle più complesse. L attività <invoke> permette al processo di contattare un web service per richiedere l esecuzione di un operazione. < invoke partnerlink =" NCName " porttype =" QName "? operation =" NCName " inputvariable =" BPELVariableName "? outputvariable =" BPELVariableName "? > < correlations >? < correlation set =" NCName " initiate =" yes join no "? pattern =" request response request - response "? / >+ </ correlations > <catchall >? activity </ catchall > < compensationhandler >? activity </ compensationhandler > </ invoke > Le invocazioni one-way richiedono solo l utilizzo di inputvariable perché non è attesa una risposta dal servizio web. In caso di invocazione request-response, sono richiesti sia l attributo inputvariable, sia l attributo outputvariable. Nel corpo del costrutto possono comparire zero o più correlationset per correlare il processo di business ad una precisa istanza del processo. Una <correlation> può essere usata con tre possibili valori in relazione allo stato del processo. L attività <receive> attende un messaggio in input per una operazione da parte di un client.

20 2. Nozioni Preliminari < receive partnerlink =" NCName " porttype =" QName "? operation =" NCName " variable =" BPELVariableName "? createinstance =" yes no "? messageexchange =" NCName "? > <correlations >? < correlation set =" NCName " initiate =" yes join no "? / >+ </ correlations > </ receive > Un attività di receive specifica un partnerlink contenente il ruolo da utilizzare per la ricezione del messaggio, un porttype (opzionale) e una operation che il partner dovrà invocare. Inoltre, deve essere indicata nel campo variable una variabile per memorizzare il messaggio in ingresso. La <receive> gioca un ruolo molto importante nel ciclo di vita di un processo, infatti insieme al costrutto <pick>, è il costrutto che può istanziare un processo di business in WS-BPEL. L attributo che permette di impostare questo comportamento è createinstance impostato con valore yes (il valore di default è no). Inoltre, possono essere definiti dei correlationset per istanziare la correlazione di una variabile. L attività <reply> è usata per rispondere a richieste precedentemente accettate attraverso un attività <receive>. < reply partnerlink =" NCName " porttype =" QName "? operation =" NCName " variable =" BPELVariableName "? faultname =" QName "? messageexchange =" NCName "? > <correlations >? < correlation set =" NCName " initiate =" yes join no "? / >+ </ correlations > </ reply > Questa operazione ha significato solo nella comunicazione request-response. Il costrutto deve essere corredato da una variabile specificata nel campo variable, da un partnerlink e da una operation.

2. Nozioni Preliminari 21 L attività di assegnazione <assign> contiene una o più operazioni elementari. <assign > ( <copy keepsrcelementname =" yes no "? ignoremissingfromdata =" yes no "? > from - spec to - spec </copy > )+ </ assign > L attività <assign> copia tipi di valori compatibili tra la sorgente (from-spec) e la destinazione (to-spec) usando l elemento <copy>. Il contenuto di from-spec deve essere uno dei seguenti: < from variable =" BPELVariableName " part =" NCName "? > < query querylanguage =" anyuri "? >? querycontent </ query > </from > < from partnerlink =" NCName " endpointreference =" myrole partnerrole " /> < from variable =" BPELVariableName " property =" QName " / > < from expressionlanguage =" anyuri "? > expression </ from > <from >< literal > literal value </ literal > </ from > <from /> Il contenuto di to-spec, invece, deve essere uno dei seguenti: < to variable =" BPELVariableName " part =" NCName "? > < query querylanguage =" anyuri "? >? querycontent </ query > </to > <to partnerlink =" NCName " /> < to variable =" BPELVariableName " property =" QName " / > < to expressionlanguage =" anyuri "? > expression </ to > <to/> L attività <empty> non effettua nessuna operazione. <empty /> L attività <exit> se utilizzata termina immediatamente il processo.

22 2. Nozioni Preliminari <exit /> <throw> lancia un eccezione indicando una condizione di errore. < throw faultname =" QName " faultvariable =" BPELVariableName "? / > Le attività assign, throw, exit sono dette short-lived activity, in quanto hanno un tempo di esecuzione molto breve, e per questo saranno eseguite anche in caso di eccezioni. Passeremo adesso all introduzione delle attività strutturate, ovvero le attività, che permettono di organizzare i precedenti costrutti in architetture più articolate. <sequence> è l attività che permette di definire una collezione di attività da eseguire sequenzialmente. <sequence > activity + </ sequence > <flow> è il costrutto che permette l esecuzione delle attività indicate in modo concorrente. <flow > activity + </flow > L attività <while> è usata per ripetere l esecuzione di una data attività fin quando la condizione specificata non sia più verificata. <while > < condition expressionlanguage =" anyuri "? > bool - expr </ condition > activity </ while > L attività <if> permette di scegliere di eseguire esattamente una attività tra due possibili sulla base del risultato restituito dalla valutazione di una condizione.

2. Nozioni Preliminari 23 <if > < condition expressionlanguage =" anyuri "? > bool - expr </ condition > activity <else >? activity </else > </if > L attività <pick> è utilizzata per attendere l arrivo di un messaggio tra un insieme di messaggi possibili. Se uno di questi è ricevuto l attività ad esso associata viene eseguita e le altre possibilità vengono scartate. Quando l attività termina, anche il costrutto <pick> è completato. <pick createinstance =" yes no "? > < onmessage partnerlink =" NCName " porttype =" QName "? operation =" NCName " variable =" BPELVariableName "? messageexchange =" NCName "? >+ < correlations >? < correlation set =" NCName " initiate =" yes join no "? / >+ </ correlations > activity </ onmessage > </pick > L attività <scope> è utilizzata per definire attività annidate che condividono variabili e partner link, e hanno un trattamento specializzato per quanto riguarda le attività di compensazione e fallimento. Ovviamente tutte le sezioni definite all interno del costrutto hanno solo valore locale. Nella traduzione da Blite a WS-BPEL utilizzeremo soltanto la capacità di specificare attività di fallimento e compensazione specializzate. Un attività di fallimento rappresenta l insieme di operazioni che il processo effettuerà nel caso sia lanciata una eccezione, invece le attività di compensazione sono delle operazioni da effettuare nel caso tutte le altre terminino senza errori.

24 2. Nozioni Preliminari < scope exitonstandardfault =" yes no "? > < faulthandlers >?... </ faulthandlers > < compensationhandler >?... </ compensationhandler > activity </ scope > Avendo introdotto tutti i costrutti necessari alla traduzione del codice Blite forniremo adesso un semplice esempio di processo WS-BPEL che utilizzi quest ultimi. <? xml version ="1.0" encoding =" UTF -8"? > < process xmlns =" http :// docs. oasis - open. org / wsbpel /2.0/ process / executable " xmlns : bpel =" http :// docs. oasis - open. org / wsbpel /2.0/ process / executable " xmlns : xsd =" http :// www.w3.org /2001/ XMLSchema " xmlns : mwl =" http :// example / OneWayServer. wsdl " suppressjoinfailure =" yes " name =" OneWayServerProcess " targetnamespace =" http :// example / OneWayServer. bpel " > < import location =" OneWayServer. wsdl " namespace =" http :// example / OneWayServer. wsdl " importtype =" http :// schemas. xmlsoap. org / wsdl /" /> < partnerlinks > < partnerlink name =" OW_ serverpl " partnerlinktype =" mwl : OW_serverPLT " myrole =" OW_server " /> </ partnerlinks > < variables > < variable name =" var0 " messagetype =" mwl : req " /> </ variables > < correlationsets > < correlationset name =" x_idcorr " properties =" mwl : x_idprop " /> </ correlationsets > < faulthandlers > <catchall > <empty /> </ catchall > </ faulthandlers > <sequence > < receive partnerlink =" OW_ serverpl " operation =" o_ req " variable =" var0 " createinstance =" yes "> < correlations > < correlation set =" x_idcorr " initiate =" yes " /> </ correlations > </ receive > <empty /> </ sequence > </ process >

2. Nozioni Preliminari 25 2.2.2 Variable Properties Schema Variable Properties Schema definisce le modalità con cui mappare le variabili di correlazione WS-BPEL, dette proprietà (una sorta di variabile write-once), con le parti di un messaggio WSDL. Riportiamo un esempio e, per semplificare la spiegazione, utilizziamo i tipi definiti nella precedente sezione. <prop : property name =" x_idprop " type =" xsd : integer " /> < prop : propertyalias propertyname =" tns : x_ idprop " messagetype =" tns : req " part =" id" /> Il prefisso prop indica il namespace http://docs.oasis-open.org/wsbpel/2.0/varprop. Il tag <property> permette di definire il nome ed il tipo della proprietà per definire una correlazione. Il tag <propertyalias> permette di specificare la parte di messaggio da utilizzare nella correlazione. Il tag deve essere associato ad una proprietà attraverso propertyname, oltre ad aver specificato il messaggio (messagetype) e la parte di messaggio (part) a cui fare riferimento. 2.2.3 Partner Link Type Schema Partner Link Type Schema permette di definire i partner link utilizzati dai processi WS-BPEL. Ogni partner link è un astrazione delle informazioni riguardanti un porttype contenute in un documento WSDL. Infatti grazie a questi costrutti possiamo utilizzare un porttype senza occuparci dei relativi dettagli. Riportiamo adesso un esempio di definizione di partner link. < plnk : partnerlinktype name =" OW_ serverplt " > <plnk : role name =" OW_server " porttype =" tns : OW_serverPT " /> </ plnk : partnerlinktype > Il prefisso plnk indica il namespace http://docs.oasis-open.org/wsbpel/2.0/plnktype.

26 2. Nozioni Preliminari Il tag <partnerlinktype> definisce un tipo di partner link e vi associa un nome. All interno di questo tag è possibile definire un massimo di due ruoli ai quali va associato un nome ed un porttype cui appoggiarsi. In questo modo il processo WS-BPEL assocerà ad ogni partner un ruolo e comunicherà con esso attraverso il partner associato. Un partnerlinktype con un solo ruolo indica un partner che offre funzionalità senza fissare nessuna richiesta per gli altri partner. Invece un partnerlinktype definito con due ruoli, esplicita che entrambi i partner dovranno offrire delle funzionalità. 2.3 Blite: una variante snella di WS-BPEL Il linguaggio Blite è una versione semplificata di WS-BPEL modellata sulle peculiarità dello standard quali partner link, terminazione dei processi, correlazione dei messaggi, transazioni a lungo termine e attività di compensazione. Per mantenere semplice la progettazione, sono stati omessi aspetti quali timeout, eventi e attività di terminazione, grafi di flusso e sofisticate forme di manipolazione dei dati. Blite fornisce una descrizione formale del deploy di servizi semplicemente ritenendo importanti dettagli implementativi quali partner link, definizioni di servizi e insiemi di correlazione. Ad esempio, i ruoli che partecipano ad una interazione tra servizi sono indicati esplicitamente attraverso partner link e partner, mentre aspetti come i binding del documento WSDL associato sono tralasciati. Questa omissione è visibile nelle interazioni Request-Response dove i partner link indicano due partner perché la parte richiedente deve fornire una operazione di callback attraverso la quale il provider potrà rispondere. I partner link in comunicazioni One-Way, invece, sono indicati da un unico partner perché soltanto una delle due parti fornisce tutte le operazioni da utilizzare. Oltre alle invocazioni asincrone, WS-BPEL fornisce un costrutto per invocazioni sincrone di un servizio remoto. Questo costrutto forza il

2. Nozioni Preliminari 27 Basic activities b ::= inv l i o x rcv l r o x x := e invoke, receive, assign empty throw exit empty, throw, exit Structured a ::= b if(e){a 1 }{a 2 } while(e) {a} basic, conditional, iteration activities a 1 ; a 2 j J rcv l j r o j x j ; a j sequence, pick ( J > 1) a 1 a 2 [a a f a c ] parallel, scope Start activities r ::= rcv l r o x j J rcv l j r o j x j ; a j receive, pick r ; a r 1 r 2 [r a f a c ] sequence, parallel, scope Services s ::= [r a f ] µ a µ a, s definition, instance, multiset Deployments d ::= {s} c d 1 d 2 deployment, composition Tabella 2.1: Sintassi di Blite chiamante ad attendere una risposta dal servizio invocato, che effettua una coppia di operazioni receive-reply. In Blite questo comportamento è simulato da una coppia di invoke-receive eseguite dal client e da una coppia di attività receive-invoke da parte del fornitore del servizio. 2.3.1 Sintassi La sintassi di Blite è riportata in Tabella 2.1. I servizi sono attività strutturate composte da attività di base, come una invocazione inv, un attività di ricezione rcv, assegnamento :=, l attività vuota empty, generazione di eccezioni throw e terminazione forzata exit. I costrutti di organizzazione utilizzati nelle attività strutturate sono la scelta condizionale if( ){ }{ }, il ciclo while( ) { }, la composizione sequenziale ;, l attività pick j J rcv ;, la composizione parallela e l attività di scope [ ]. Un attività di scope [a a f a c ] raggruppa un attività primaria a con un attività di gestione dei fallimenti a f e una di compensazione a c. Le Start Activities r sono attività strutturate che inizialmente possono eseguire solo un attività di receive. Nella seguente trattazione useremo + per indicare la scelta binaria esterna.

28 2. Nozioni Preliminari Daremo priorità all attività di sequenzializzazione piuttosto che alle attività di composizione o scelta esterna, ad esempio a 1 ; a 2 a 3 ; a 4 sarà equivalente a (a 1 ; a 2 ) (a 3 ; a 4 ) e a 1 ; a 2 + a 3 equivarrà a (a 1 ; a 2 ) + a 3. Ogni volta che all interno di uno scope saranno omesse l attività di compensazione e di fallimento saranno rispettivamente inserite al loro posto una attività empty e una throw. I dati potranno essere condivisi attraverso variabili condivise (x, x,... ). L insieme di valori (v, v,... ) non è specificato, comunque assumeremo che includa perlomeno un insieme di nomi di partner (p, q,... ) e un insieme di nomi di operazioni (o, o,... ). Inoltre, con u indicheremo partner e variabili, e con w valori e variabili. Le Espressioni (e, e,...) sono lasciate non specificate, ma devono contenere almeno un valore o una variabile. In BliteC invece le espressioni sono caratterizzate da regole ben precise come possiamo vedere a Pagina 72. La notazione è utilizzata per indicare tuple di oggetti, ad esempio x denota la tupla di variabili x 1,..., x h (con h 0). Assumiamo che le variabili nella stessa tupla siano distinte due a due. La notazione speciale indica tuple di uno o due oggetti, ad esempio p denota p 1, p 2 oppure p 1. Le tuple possono essere costruite utilizzando l operatore di concatenamento :, che per p, u : x 1,..., x h restituisce p, u, x 1,..., x h. Scriveremo Z W per assegnare il nome simbolico Z al termine W. I partner link l r delle attività di ricezione possono essere sia p, u che p, dove p è un partner che fornisce l operazione ed u è il partner usato per spedire i messaggi di risposta. I partner per ricevere i messaggi devono essere noti al momento della scrittura del codice, invece i partner usati per rispondere possono essere determinati dinamicamente. I partner link l i utilizzati nelle operazioni di invoke possono essere sia u, p che u, dove u è il partner che fornisce l operazione e p è il partner utilizzato per riceve

2. Nozioni Preliminari 29 i messaggi di risposta. Come precedentemente detto, il partner per riceve i messaggi deve essere staticamente noto, e dunque non può essere una variabile. Le attività di Deploy sono composizioni finite di multiset di istanze µ a, contenenti al più una definizione [r a f ] associata ad un insieme di variabili di correlazione. Una definizione di servizio fornisce uno scope di alto livello (che non può essere compensato) e può offrire una scelta di ricezioni alternative su attività multiple di inizializzazione. Ogni istanza di servizio µ a ha il suo stato (privato) µ. Uno stato è una funzione (parziale) che mappa variabili in valori, scritti come {x v}. Lo stato ottenuto aggiornando µ con µ, scritto µ µ, è induttivamente definito da: µ µ (x) = µ (x) se x dom(µ ) (dove dom(µ) denota il dominio di µ) e µ(x) altrimenti. Lo stato vuoto è denotato da. Forniamo adesso un breve esempio di specifica scritta con il linguaggio. {[rcv l r OW server o req x id ; empty empty]} xid 2.3.2 Semantica Operazionale La semantica è definita su di una sintassi arricchita rispetta quella presentata in Tabella 2.1, che include anche attività protette a, terminazione con fallimento stop, messaggi p : o : v e scope della forma [a a f a c a d ]. Le prime tre attività ausiliarie sono utilizzate per rimpiazzare, rispettivamente, scope completati senza successo (con la loro attività di compensazione standard), servizi terminati con fallimento o forzatamente (con stop), e attività di invocazione (con il messaggio che producono). Invece, scope della forma [a a f a c a d ] sono dinamicamente generati per salvare in a d l attività di compensazione di uno scope interno che è terminato con successo, insieme all ordine in cui le attività devono essere eseguite. Nel seguito, empty, exit, throw, stop e i messaggi saranno chiamati attività short-lived e saranno

30 2. Nozioni Preliminari a empty a empty ; a a ; empty a stop stop stop stop ; a stop a a sh sh p:o: v a p:o: v a [a a f a c ] [a a f a c empty] ( p:o: v a 1 ) ; a 2 p:o: v (a 1 ; a 2 ) [ p:o: v a a f a c a d ] p:o: v [a a f a c a d ] if a throw a a a f a f a c a c a d a d [a a f a c a d ] [a a f a c a d ] r r a f a f a a {[r a f ], s} c {s, [r a f ]} c {µ a, s} c {s, µ a } c d 1 d 2 d 2 d 1 (d 1 d 2 ) d 3 d 1 (d 2 d 3 ) {µ empty, s} c {s} c {µ stop, s} c {s} c {µ empty} c d d {µ stop} c d d Tabella 2.2: Congruenza strutturale per le attività Blite e per il deployment generalmente indicate con sh. La semantica operazionale delle attività di deploy Blite è definita in termini di una congruenza strutturale e una relazione di riduzione. La congruenza strutturale, indicata con, identifica termini sintattici diversi che intuitivamente rappresentano lo stesso termine ed è definita come la minima relazione di congruenza indotta da un certo insieme di leggi. In Tabella 2.2 è mostrato esplicitamente, nella parte alta, le leggi per empty, stop, attività protette, messaggi e scope e, nella parte bassa, le leggi per i servizi e il deployment. Proprietà standard quali, per esempio, il fatto che la sequenzializzazione è associativa, la composizione parallela è commutativa e associativa, sono omesse. Commentiamo ora le regole riportate in Tabella 2.2. L attività empty si comporta come l elemento identità sia per la sequenzializzazione sia per l attività di composizione parallela. stop multipli in parallelo sono esattamente equivalenti ad uno stop; inoltre stop disabilita le attività che lo seguono. L operatore di protezione è idempotente e le attività short-lived sono implicitamente protette, così i messaggi possono comparire dentro o fuori dall operatore di protezione senza problemi. L attività di compensazione iniziale è empty. I messaggi non bloccano

2. Nozioni Preliminari 31 attività susseguenti e il completamento di uno scope, eccetto quando una throw è attiva nello scope (questo è controllato dal predicato throw più avanti illustrato). La congruenza strutturale è estesa a scope, istanze e deployment in modo ovvio. Inoltre, l ordine in cui le definizioni e le istanze occorrono in un deployment non importa, e la composizione di deployment è sia commutativa sia associativa. Istanze come µ empty e µ stop sono terminate e, quindi rimovibili. Similmente, deployment contenenti solo istanze teminate sono terminati e possono essere rimossi. La relazione di riduzione sui deployment, indicata con, sfrutta una relazione di transizione etichettata tra attività strutturate, scritta come dalla grammatica: α, dove α è generata α ::= τ x v! p:o: v? l r :o: x (a) Il significato delle etichette è il seguente: τ indica produzione di messaggi, valutazione delle guardie per cicli e scelte o installazione/attivazione di compensazioni; x v indica l assegnamento del valore v alla variabile x;! p : o : v e? l r : o : x indicano l esecuzione di una attività di invocazione e di ricezione per l operazione o, dove p e v corrispondono con l r e x, rispettivamente; indica la terminazione forzata di una istanza di servizio; indica la produzione del segnale di fallimento all interno di uno scope; (a) indica l esecuzione con successo di uno scope che può essere compensato da una attività strutturata a. La relazione α è definita dalle regole in Tabella 2.3 rispetto ad uno stato µ, omesso quando non necessario (scriveremo a α a invece di µ a α a ). Prima di commentare le regole, introdurremo le funzioni ausiliarie e i predicati utilizzati. In modo specifico, i predicati a exit e a throw controllano la possibilità di eseguire una exit o una throw, rispettivamente. Questi sono definiti induttivamente sulla sintassi

32 2. Nozioni Preliminari µ inv l i o x µ x := e exit τ µ(l i ):o:µ( x) (inv) rcv l r? l o x r :o: x empty (rec) x µ(e) empty (asg) throw stop (thr) stop (term) p:o: v! p:o: v empty (msg) µ a 1 α a 1 α µ a 1 ; a 2 a 1 ; a 2 a = { a 1 if µ(e) tt if µ(e) = ff a 2 µ if(e){a 1 }{a 2 } τ a (seq) (if) j J rcv l r j o j x j ; a j a = { µ a α a µ a? l r h :o h: x h a h a ; while(e) {a} empty α a (prot) (h J) (pick) if µ(e) tt if µ(e) = ff µ while(e) {a} τ a (while) µ a 1 α a 1 α / {, } (a 2 throw a 2 exit ) µ a 1 a 2 α a 1 a 2 (par 1 ) a 1 α a 1 α {, } a 1 a 2 α a 1 end(a 2 ) (par 2 ) [empty a f a c a d ] (a c) τ empty (done 1 ) [stop a f a c a d ] a d ; a f (done 2 ) µ a α a α / {, (a )} µ [a a f a c a d ] α [a a f a c a d ] (exec) a (a ) a (done 3 ) τ [a a f a c a d ] [a a f a c a ; a d ] a a [a a f a c a d ] τ [a a f a c a d ] (fault) Tabella 2.3: Attività di base, ausiliarie e strutturate delle attività e sono false, tranne che per i seguenti casi exit exit throw throw a exit [a a f a c a d ] exit a throw/exit a throw/exit a 1 throw/exit a 1 ; a 2 throw/exit a 1 throw/exit a 2 throw/exit a 1 a 2 throw/exit La funzione end( ), data una attività a, restituisce l attività ottenuta conservando soltanto le attività short-lived e le attività protette all interno di a. end( ) è definita

2. Nozioni Preliminari 33 induttivamente sulla sintassi delle attività, i casi più significativi sono end(sh) = sh end( a ) = a end(a 1 ; a 2 ) = end(a 1 ) end([a a f a c a d ]) = [end(a) a f a c a d ] dove a 1 non deve essere congruente a empty, o alla composizione parallela di questo. Nei restanti casi, end( ) ritorna stop, eccetto per la composizione parallela per la quale si comporta come un omomorfismo. Commentiamo ora brevemente le regole di Tabella 2.3. Le regole (inv) e (asg) indicano che l invocazione e l assegnazione possono procedere solo se il loro argomento è un espressione chiusa (ovvero una espressione senza variabili non inizializzate) e può essere valutata (cioè µ( ) restituisce un valore). Dalla regola (rec), una attività di ricezione offre una operazione invocabile su un dato partner link. Le regole (thr) e (term) comunicano la produzione di un segnale di fallimento o di un segnale di terminazione forzata, rispettivamente. Le attività ausiliarie si comportano come previsto: un messaggio può sempre essere inviato (msg) ed una attività protetta a si comporta come a (prot). (seq) si prende cura di attività eseguite sequenzialmente, mentre (pick) permette di scegliere fra un insieme di attività di ricezione. Le regole per la scelta condizionale e l iterazione ((if) e (while), rispettivamente) sono standard. Le esecuzioni di attività in parallelo sono intervallate ((par 1 ) e (par 2 )), eccetto a una attività di terminazione/fallimento può essere eseguita (par 2 ), in questi casi tutte le attività parallele sono immediatamente terminate eccetto le attività short-lived e handler di compensazione/fallimento che sono protetti. In altre parole, le attività di terminazione throw e exit sono eseguite in modo eager. Dalle regole (done 1 ) e (done 3 ), il completamento di uno scope può essere compensato in accordo con il comportamento di default della compensazione in WS-BPEL (cioè in ordine inverso di completamento), a partire dal primo scope che racchiude l attività.

34 2. Nozioni Preliminari { match(c, µ, v, v) = match(c, µ, x, v) = {x v} if x / c (x c x / dom(µ)) if x c {x v} µ match(c, µ,, ) = match(c, µ, w 1, v 1 ) = µ match(c, µ, w 2, v 2 ) = µ match(c, µ, (w 1, w 2 ), (v 1, v 2 )) = µ µ match(c, µ, l r :o: x, p:o: v) < n h J. match(c, µ, l r h :o h : x h, p:o: v) < n µ rcv l r o x ; a c,n p:o: v µ a c,n p:o: v µ a c,n p:o: v µ a 1 c,n p:o: v µ a 1 ; a 2 c,n p:o: v µ a c,n p:o: v µ [a a f a c a d ] c,n p:o: v µ j J rcv l r j o j x j ; a j c,n p:o: v µ a 1 c,n p:o: v µ a 2 c,n p:o: v µ a 1 a 2 c,n p:o: v µ a c,n p:o: v s c,n p:o: v µ a, s c,n p:o: v Tabella 2.4: Regole di match / C è un attività di ricezione in p e o che si sincronizzi con v? In particolare, scope come [empty a f a c a d ] non sono ancora terminati e, quando lo scope terminerà, l attivita di compensazione a d dello scope interno non è passata a quello esterno (done 1 ). La regola (exec) permette di eseguire qualunque azione primaria eccetto l emissione di un fallimento e la compensazione di un scope. In particolare, le terminazioni forzate interne sono propagate all esterno dello scope. Differentemente dalla terminazione forzata, i fallimenti derivati da uno scope sono gestiti internamente (fault) ed il corrispondente handler è installato quando l attività principale termina (done 2 ). Per la regola (done 2 ), la compensazione di default è effettuata dopo la terminazione dell attività primaria e prima della gestione del fallimenti. Da notare che questa attività di compensazione non memorizza nessuna informazione con le precedenti, quindi, se lo stato cambia tra il salvataggio e l esecuzione di quest ultima, lo stato attuale è utilizzato. Alcune altre attività ausiliarie sono usate nella semantica delle attività di deployment in Tabella 2.5. Le regole per la comunicazione e l aggiornamento delle variabili ((com), (new) e (var)) necessitano di un meccanismo per controllare se l assegnazione

2. Nozioni Preliminari 35? t 1 a 1 a! t 2 1 a 2 a 2 match(c 1, µ 1, t 1, t 2 ) = µ 1 ( µ 1 a 1, s 1 c1, µ 1 t 2 ) {µ 1 a 1, s 1 } c1 {µ 2 a 2, s 2 } c2 {µ 1 µ 1 a 1, s 1 } c1 {µ 2 a 2, s 2 } c2 [r a f empty]? t 1 a1 a 2! t 2 a 2 match(c 1,, t 1, t 2 ) = µ 1 (s 1 c1, µ1 t 2 ) {[r a f ], s 1 } c1 {µ 2 a 2, s 2 } c2 {µ 1 a 1, [r a f ], s 1 } c1 {µ 2 a 2, s 2 } c2 (com) (new) µ a x v a match(c, µ, x, v) = µ (var) {µ a, s} c {µ µ a, s} c d 1 d 1 d 1 d 2 d 1 d 2 (part) µ a α a α / {? t 1,! t 2, x v} {µ a, s} c {µ a, s} c (enab) d d 1 d 1 d 2 d 2 d (cong) d d Tabella 2.5: Regole di riduzione per deployment Blite (dove t 1 = l r :o: x e t 2 = p:o: v) di alcuni valori v a w è conforme al vincolo imposto dall insieme di correlazione c e dallo stato µ e, in caso di affermativo, restituire lo stato µ per le variabili in w che salva l effetto dell assegnazione. Questo meccanismo è implementato da una funzione match(,,, ) definita attraverso le regole riportate nella parte alta della Tabella 2.4. Da notare che match(,,, ) non è definita quando w e v hanno dimensioni diverse o quando x c e {x v } µ per qualche v v (finché lo stato {x v} non è in accordo a c e µ). Anche le regole (com) e (new) hanno bisogno del predicato ausiliare s c,n p:o: v, definito induttivamente nella parte bassa della Tabella 2.4, che controlla la capacità di s di effettuare una ricezione sull operazione o sfruttando il partner link p, che corrisponde alla tupla dei valori v e genera uno stato con una coppia di n che corrispondono con c e lo stato corrente dell attività che effettua la ricezione. Infine, soffermiamoci brevemente sulle regole in Tabella 2.5. La regola (com) indica che la comunicazione può avere luogo quando due istanze di servizio si sincronizzano eseguendo attività di ricezione ed invocazione che rispettano l insieme di correlazione dell istanza ricevente. Da notare che la corrispondenza coinvolge sia il partner link p sia i dati di business v. La comunicazione genera uno stato che aggiorna quello

36 2. Nozioni Preliminari dell istanza ricevente. Se più di una ricezione può gestire una data invocazione, solo la più precisa (cioè la ricezione che genera lo stato più piccolo ) progredisce (il predicato, è utilizzato per questo scopo). Questo meccanismo permette di correlare messaggi di istanze di servizio diverse e di modellare la precedenza di un istanza di servizio esistente su di una nuova istanziazione (regole (new)). Nelle regole (com) e (new), viene utilizzata l assunzione di correttezza del deployment cosicché non c è bisogno di controllare ogni singolo deployment cercando possibili conflitti tra le attività di ricezione. La regola (new) indica che una istanziazione può avere luogo quando la definizione di un sevizio e un istanza di un servizio si sincronizzano su una receive e una attività di invocazione, rispettivamente. La regola (var) indica che le variabili di correlazione non possono essere riassegnate se un nuovo valore non corrisponde a quello precedente. Inoltre, se un assegnazione è eseguita, il suo effetto coinvolge tutta l istanza, ovvero lo stato è aggiornato. La regola (enab) indica che l esecuzione di attività diverse dalla comunicazione o dall assegnazione può essere sempre eseguita. Infine, se una parte di un grande deployment evolve, l intera composizione evolve in accordo (part) e, ovviamente, deployment strutturalmente congruenti hanno le stesse riduzioni (cong).

Capitolo 3 Descrizione generale di BliteC Questo capitolo riporta una breve descrizione dell architettura e del funzionamento di BliteC, in modo da rendere la lettura dei capitoli seguenti più semplice. Se avviato con input corretto, BliteC esegue le seguenti fasi principali: 1. analisi lessicale e sintattica; 2. generazione dell albero sintattico; 3. generazione dei file e del package. Il documento in ingresso è composto da una parte dichiarativa e da una parte in codice Blite. La prima fase è necessaria a garantire dati corretti in ingresso al traduttore evitando così di accettare un documento malformato e la conseguente generazione di codice non corretto. La generazione dell albero sintattico è utile per ottimizzare il programma. Infatti il parser costruirà l albero sintattico dell input, gli altri componenti di BliteC si limiteranno a leggerlo e ad effettuare le operazioni richieste. L ultima fase genera tutti i file necessari alla descrizione del servizio e al deploy su un engine utilizzando l albero costruito in precedenza e i dati di configurazione ricevuti 37

38 3. Descrizione generale di BliteC in ingresso. L engine utilizzato in questa prima versione di BliteC è ActiveVOS perché, dopo alcuni studi svolti in [19] e [20], risulta essere quello che interpreta in modo più fedele lo standard WS-BPEL. 3.1 Implementazione Il linguaggio scelto per la realizzazione del progetto è Java 1 perché rende il programma multi-piattaforma senza nessuno sforzo aggiuntivo, possiede molte librerie che gestiscono i documenti XML in modo semplice ed efficace ed è il linguaggio di riferimento per la maggior parte delle applicazioni che lavorano con WS-BPEL. Nella realizzazione, oltre alle librerie comprese nella distribuzione di Java, si è reso necessario l utilizzo della libreria JDOM [26] per la gestione dei documenti XML e del generatore di parser JavaCC [27] per creare in modo semplice le componenti che validano il documento in input. JDOM è una libreria che fornisce una soluzione robusta e leggera, per leggere e scrivere file XML senza dover ricorrere a complesse ed inefficienti opzioni delle librerie standard. JDOM riesce ad interoperare bene con SAX (Simple Api for XML) e DOM (Document Object Model), senza essere né un astrazione né un miglioramento per quest ultime. JavaCC, o Java Compiler Compiler, è un popolare generatore di parser in Java. Il programma legge un file di definizione fornito dall utente e lo converte in un programma Java che riconoscerà la grammatica definita. Nel pacchetto di JavaCC è inoltre fornito un preprocessore JJTree che permette di integrare nel parser la generazione di un albero sintattico. JJTree inoltre può predisporre i nodi componenti l albero, per l interoperabilità con il pattern Visitor, in modo da poter aggiungere funzioni specializzate senza modificare il codice generato da JavaCC. 1 JRE e JDK versione 1.6

3. Descrizione generale di BliteC 39 La fase di analisi sintattica e semantica è effettuata attraverso l utilizzo di due parser: uno per il codice Blite ed uno per la parte descrittiva. Questa divisione ha permesso di rendere più semplici le due grammatiche perché compaiono meno regole, oltre a rendere indipendente la grammatica di Blite da quella per la descrizione dei dati di configurazione. Grazie a questo approccio la modifica della grammatica dei dati di configurazione, o l implementazione di un nuovo sistema di configurazione, risulta semplice perché non comporta cambiamenti agli altri componenti. L implementazione dei parser è stata effettuata attraverso l utilizzo di JavaCC, che grazie alla combinazione con JJTree ha permesso di integrare anche la generazione dell albero sintattico. Il preprocessore genera tutte le classi necessarie a descrivere ogni costrutto delle grammatiche e permette inoltre di predisporre queste classi per l utilizzo con un pattern Visitor. Questo approccio rende possibile anche l aggiunta di nuovi costrutti senza troppi problemi nel mantenimento del vecchio codice. In dettaglio, il parser della parte dichiarativa colleziona i dati da inserire in una tabella dei simboli attraverso una serie di Visitor. Il parser Blite genera l albero associato al codice inserito e, attraverso una serie di Visitor, controlla se il codice inserito è consistente con i dati della tabella dei simboli. La fase di generazione dei file può essere divisa in due parti: una indipendente dal tipo di engine usato e l altra caratterizzata da quest ultimo. La prima utilizza l albero del codice da tradurre e la tabella dei simboli per generare il documento WS-BPEL e il file WSDL del nuovo servizio; la seconda invece genera i file necessari all esecuzione del servizio sull engine selezionato e costruisce il pacchetto contenente tutti i file prima descritti. Introduciamo adesso i principali componenti di BliteC (si veda Figura 3.1): Mapper Con Mapper si intende il parser e l insieme di Visitor che si occupano di

40 3. Descrizione generale di BliteC Generatore WS-BPEL Parser Blite Generatore WSDL BliteC Mapper Deployer Figura 3.1: Componenti di BliteC reperire le informazioni necessarie a mappare i simboli del codice Blite nei relativi costrutti XML. Parser Blite Con questo nome ci riferiamo al parser e ai visitor che si occupano della generazione e della validazione dell albero di conoscenza associato al nuovo servizio. Generatore WS-BPEL Questo generatore si occupa della traduzione del codice rappresentato dall albero sintattico in un documento WS-BPEL. Generatore WSDL Questo generatore si occupa di creare la descrizione WSDL del nuovo servizio.

3. Descrizione generale di BliteC 41 File Blite Mapper Generatore WS-BPEL Parser Blite Generatore WSDL Blitec Deployer Pacchetto WS-BPEL Figura 3.2: Funzionamento di BliteC Generatore dei file di Deploy Questo componente genera il package e tutti i documenti necessari al deploy su di un engine WS-BPEL. 3.2 Funzionamento BliteC applicato ad un documento (si veda Figura 3.2) contenente la specifica e le informazioni di configurazione di un processo Blite, passa il riferimento del file in ingresso al Mapper. Il Mapper scorre il documento controllando che sia conforme alla grammatica e ne genera un albero di conoscenza per permettere l accesso ai dati presenti nel file senza doverlo riscorrere. Dopo la generazione dell albero di conoscenza il mapper applica

42 3. Descrizione generale di BliteC una serie di Visitor per controllare la correttezza delle dichiarazioni e per importare i dati indicati nel file. Se la fase di controllo va a buon fine il Mapper costruisce la tabella dei simboli con le informazioni ricavate dall albero di conoscenza. Il componente successivo nella computazione è il Parser Blite che, come il precedente parser, scorre la specifica Blite del processo presente nel documento passato in ingresso e ne ricava un albero di conoscenza (nel caso non siano stati trovati errori di consistenza con il linguaggio Blite). Dopo aver ricavato l albero, vengono applicati dei Visitor all albero stesso per verificare la consistenza dei dati ottenuti nella precedente fase con quelli trovati nella specifica. Se tutti i dati utilizzati sono corretti, si passa alla fase di controllo delle assegnazioni e, nel caso che anche questa operazione vada a buon fine, viene effettuata l aggiunta alla tabella dei simboli dei dati relativi ai partner link di ricezione usati per contattare il nuovo processo. Dopo l esecuzione del Parser Blite nella tabella dei simboli sono contenute tutte le informazioni necessarie alla generazione di tutti i documenti per il deploy. Il primo documento generato da BliteC è la specifica WS-BPEL del processo Blite. Anche il generatore WS-BPEL è un Visitor dell albero di conoscenza relativo al codice Blite. Infatti, il componente si aspetta in ingresso l albero di conoscenza e la tabella dei simboli con i quali effettuerà la conversione dei costrutti Blite nei rispettivi WS-BPEL. La successiva generazione è quella riguardante il documento WSDL che permetterà ai servizi esterni di contattare il processo. A differenza del precedente componente, questo necessita in ingresso soltanto della tabella dei simboli, che verrà utilizzata per generare tutti i dati necessari alla corretta comunicazione con il processo WS-BPEL. L ultimo passo effettuato da BliteC è la generazione dei file necessari al deploy del servizio su di un engine WS-BPEL. Il componente che effettua queste generazioni è il Deployer. Questo si aspetta di avere in ingresso i file generati in precedenza e

3. Descrizione generale di BliteC 43 la tabella dei simboli, dove troverà le informazioni necessarie alla generazione dei documenti di configurazione dell engine. Il Deployer dopo aver generato i documenti di configurazione è in possesso di tutte le informazioni necessarie all esecuzione del processo e le organizza in un pacchetto del formato accettato dall engine. Il funzionamento di BliteC sarà descritto in modo più dettagliato nei successivi due capitoli. 3.3 Utilizzo Descriviamo adesso una tipica esecuzione di BliteC per la generazione di un pacchetto eseguibile dall engine ActiveVOS e il relativo test di funzionamento del nuovo servizio. Nell esempio si suppone che l utente disponga di: Java aggiornato alla versione 1.6; lo strumento BliteC; l engine ActiveVOS Community Edition versione 5.0.2 in esecuzione sulla macchina di lavoro 2 ; un programma per generare messaggi SOAP con cui contattare il nuovo servizio; un browser. Nell esempio è utilizzato soapui [28], un software che genera automaticamente i messaggi SOAP necessari per contattare il nuovo servizio. Il file esempio.bl rappresenta nell esempio il file che contiene la specifica Blite del processo e la relativa configurazione per BliteC. 2 Il significato dell esempio non cambia anche se l utente non dispone di una installazione locale, infatti è necessario soltanto che l indirizzo localhost venga sostituito con quello dell engine.

44 3. Descrizione generale di BliteC Per semplificare la comprensione al lettore la trattazione è stata divisa nelle seguenti fasi: esecuzione della compilazione con BliteC; deploy del processo su ActiveVOS; invocazione del servizio. 3.3.1 Esecuzione della compilazione con BliteC In questa parte eseguiremo lo strumento sul file esempio.bl ottenendo come prodotto dell esecuzione il pacchetto eseguibile dall engine ActiveVOS. L utente può decidere se creare il pacchetto di deploy nella directory del file da compilare con il comando java -jar blitec.jar esempio.bl oppure può specificare la directory di generazione del pacchetto di deploy aggiungendo un argomento al comando precedente java -jar blitec.jar esempio.bl directory di deploy evitando così lo spostamento manuale del pacchetto nella cartella desiderata. Nel primo caso, al termine dell esecuzione di BliteC saranno disponibili nella directory del file da compilare il documento WSDL (example.wsdl) che descrive le operazioni messe a disposizione dal nuovo servizio e il pacchetto accettato da ActiveVOS (exampleprocess.bpr).

3. Descrizione generale di BliteC 45 Nel caso sia stata eseguita la seconda variante del comando troveremo il documento WSDL all interno della cartella del file da compilare il pacchetto eseguibile, invece, sarà generato nella cartella indicata dall utente. 3.3.2 Deploy del processo su ActiveVOS Questa fase è effettuata dall engine quando il pacchetto generato è caricato nella directory dedicata alle esecuzioni di nuovi processi (bpr). Per verificare che il deploy ha avuto successo dobbiamo collegarci attraverso un browser all indirizzo http://localhost:8080/bpeladmin/ e controllare se il nuovo processo è stato eseguito con successo. A questo punto, per verificare il successo del deploy bisogna selezionare la voce Deployed Processes e controllare se il nuovo processo è presente nella lista restituita,illustrata di seguito. Se l operazione ha successo è possibile contattare il nuovo servizio utilizzando il documento WSDL messo a disposizione dall engine all interno della voce Deployed Services. La voce nella lista avrà lo stesso nome del partner link utilizzato dal processo per colloquiare con l esterno. 3.3.3 Invocazione del servizio Quest ultima fase permette all utente di simulare un interazione del servizio con un client.

46 3. Descrizione generale di BliteC Per contattare il nuovo servizio attraverso soapui dobbiamo creare un nuovo progetto, dargli un nome, e inserire nel campo adiacente alla voce Initial WSDL/WADL l URI del file WSDL del servizio. Inserite queste informazioni è sufficiente cliccare sul pulsante OK per eseguire l importazione del documento WSDL e la conseguente generazione delle richieste SOAP. Finito il processo di creazione, saremo posti di fronte ad un interfaccia che permette la navigazione attraverso tutti i messaggi inviabili al servizio per fruire di una risorsa. Per inviare un messaggio SOAP dovremo semplicemente selezionare un servizio e cliccare su una Request. Questa operazione aprirà una nuova finestra nella parte destra dell interfaccia, dove l utente dovrà inserire i valori all interno dei campi contraddistinti dal carattere?, prima di inviare il messaggio (si veda Figura 3.3). Effettuata quest ultima operazione siamo pronti ad inviare il messaggio al nostro nuovo servizio. L invio del messaggio può essere effettuato cliccando sul pulsante in alto a sinistra nella barra presente sopra l editor del messaggio. Inviato il messaggio, per verificare se il servizio ha elaborato la richiesta, dovremo tornare con il browser sulla pagina di ActiveVOS e controllare lo stato del processo all interno della lista presente alla voce Active Processes (si veda Figura 3.4).

3. Descrizione generale di BliteC 47 Figura 3.3: soapui - campo da riempire Nel caso il processo abbia terminato l esecuzione con successo, alla destra del nome sarà presente lo stato completed. È inoltre possibile visualizzare dettagli sull esecuzione cliccando sul nome del processo all interno della lista. La pagina caricata (si veda Figura 3.5) visualizzerà una rappresentazione grafica dell esecuzione del processo, oppure, nel caso l utente sia interessato, permetterà il controllo dei log dell esecuzione (cliccando sull apposito bottone in alto nella barra).

48 3. Descrizione generale di BliteC Figura 3.4: Lista dei processi attivi

3. Descrizione generale di BliteC 49 Figura 3.5: Pagina di descrizione dell esecuzione di un processo