Un metodo non intrusivo per l adattamento dinamico di processi BPEL

Transcript

1 POLITECNICO DI MILANO Corso di Laurea Specialistica in Ingegneria Informatica Dipartimento di Elettronica e Informazione Un metodo non intrusivo per l adattamento dinamico di processi BPEL Relatore: Prof. Luciano Baresi Correlatore: Ing. Liliana Pasquale Tesi di Laurea Specialistica di: Patrik Montinari matricola Anno Accademico

2 Alla mia famiglia

3 Sommario L intento fondamentale per cui nasce questo lavoro è lo studio della possibilità di superare i limiti posti dal linguaggio BPEL, dovuti alla staticità intrinseca del linguaggio. Tale staticità è legata all impossibilità di modificare ulteriormente il processo dopo che ne è stato effettuato il deploy. Queste modifiche sono essenziali se si vuole mantenere un constante allineamento tra i processi di business e i processi BPEL che li supportano e se si vogliono gestire i problemi legati alla natura distribuita dei servizi che compongono un processo BPEL. Infatti anche se il linguaggio BPEL fornisce dei meccanismi per la gestione degli errori e meccanismi di time-out, questi non risultano sufficienti per gestire tutte le situazioni di errore che possono verificarsi durante l esecuzione di un processo. Inoltre data la forte dinamicità con cui evolve un processo di business, è impossibile prevedere a priori i suoi futuri cambiamenti. Tale concetto si concretizza nello sviluppo di un componente, chiamato DyBPEL, che rende possibili modifiche dinamiche alla struttura di un processo BPEL. DyBPEL permette di effettuare il deploy dinamico di una nuova versione del processo partendo da una versione precedente. Questo permette di conformare, alla nuova versione del processo, tutte le sue future istanze. Inoltre DyBPEL permette di modificare dinamicamente le istanze 2

4 del processo in esecuzione.

5

6 Indice Elenco delle figure 7 Elenco delle tabelle 9 1 Introduzione 10 2 Analisi del Problema I processi di business e le SOA Service Oriented Architecture Caratteristiche delle SOA Web Service Enterprise Service Bus BPEL Caratteristiche principali Struttura di un processo BPEL Limiti del linguaggio BPEL Progettazione concettuale Scenario applicativo e obiettivi Prodotto finale e scelte implementative

7 4 Implementazione di DyBPEL Visione d insieme Changes Repository Bpel Modifier Deploy di un processo Descrizione del Bpel Modifier Process Runtime Modifier Aspect Oriented Programming Descrizione del componente Coordinator Modifier Caso d uso News Provider Operazione di modifica Analisi delle prestazioni Stato dell arte WAWSO AO4BPEL: An Aspect-oriented Extension to BPEL Dynamo SHIWS AOFSA Conclusioni 82 Bibliografia 84

8 Elenco delle figure 2.1 Modalità di interazione con un processo BPEL Architettura di DyBPEL Operazioni di modifica messe a disposizione da DyBPEL Diagramma di sequenza - Operazione di modifica Diagramma di sequenza - Interazione tra il Process Runtime Modifier e il Changes Repository Modello entità-relazione del database a supporto di DyBPEL Classe BpelModifier Weaving tra aspetti e componenti Visione ad alto livello dell organizzazione delle classi nel motore ActiveBPEL Aspetto Instrumentations Visione ad alto livello dell interfaccia esposta dal servizio CoordinatorModifier Visione ad alto livello dell architettura del caso d uso Visualizzazione grafica della prima parte della definizione del processo NewsProvider Visualizzazione grafica della seconda parte della definizione del processo NewsProvider

9 5.4 Visualizzazione grafica della terza parte della definizione del processo NewsProvider Frammento dell XML del file.bpel del NewsProvider Frammento della definizione del processo BPEL precedente alla modifica Frammento della definizione del processo BPEL successivo alla modifica Architettura di AO4BPEL Il ciclo di controllo di adattamento proposto da SHIWS

10 Elenco delle tabelle 5.1 Analisi delle prestazioni del Coordinator Modifier e del Bpel Modifier Analisi delle prestazioni Process Runtime Modifier Confronto delle possibili operazioni di modifica in un processo BPEL tra DyBPEL e gli approcci studiati

11 Capitolo 1 Introduzione I web service sono applicazioni autonome e distribuite con le quali si può accedere interattivamente attraverso il web. I web service sono spesso combinati tra loro per offrire un servizio a valore aggiunto. Tale servizio è definito come una composizione di servizi o come un processo. Date le caratteristiche di flessibilità e facilità di sviluppo le composizioni di servizi sono state spesso usate a supporto dei processi di business aziendali. Uno dei paradigmi più noti delle composizioni di servizi è l orchestrazione, in base al quale un processo centralizzato interagisce con un insieme di servizi componenti. Il linguaggio utilizzato per la definizione di un orchestrazione è BPEL (Business Process Execution Language for Web Services, conosciuto anche come BPEL4WS) [15]. L obiettivo di questo lavoro di tesi è di superare i limiti del linguaggio BPEL, dovuti alla staticità intrinseca del linguaggio. Tale staticità è legata all impossibilità di modificare ulteriormente il processo dopo che ne è stato effettuato il deploy. Queste modifiche sono essenziali se si vuole mantenere un constante allineamento tra i processi di business e i processi BPEL che li 10

12 11 supportano e se si vogliono gestire i problemi legati alla natura distribuita dei servizi che compongono un processo BPEL. Infatti anche se il linguaggio BPEL fornisce dei meccanismi per la gestione degli errori e meccanismi di time-out, questi non risultano sufficienti per gestire tutte le situazioni di errore che possono verificarsi durante l esecuzione di un processo. Inoltre data la forte dinamicità con cui evolve un processo di business, è impossibile prevedere a priori i suoi futuri cambiamenti. Allo scopo di affrontare queste limitazioni, si propone una soluzione per l adattamento dinamico dei processi BPEL. La soluzione proposta è composta da due sotto-soluzioni più semplici. La prima permette la modifiche delle istanze del processo di business future, e la seconda consente di cambiare la definizione del processo per le istanze correnti. In particolare per poter modificare le istanze in esecuzione è stato necessario aggiungere delle funzionalità al motore ActiveBPEL [1] (un motore BPEL open source basato su Java) utilizzando la programmazione orientata agli aspetti (Aspect Oriented Programming AOP) [25]. Infine per semplificare l utilizzo di tali soluzioni si è pensato di unire queste funzionalità in un unico componente, DyBPEL (Dynamic BPEL). La tesi è organizzata come segue. Nel capitolo 2 si introducono i processi di business e come questi vengono supportati dai processi BPEL, inoltre si spiegano i limiti di tale linguaggio. Nel capitolo 3 viene genericamente esposto il funzionamento di DyBPEL e le scelte implementative adottate per raggiungere tali funzionalità. Il capitolo 4 è totalmente dedicato alla descrizione dettagliata di tutti i componenti che compongono DyBPEL. Il capitolo 5 descrive un caso di studio e analizza le prestazioni di DyBPEL. Il capitolo 6 presenta i lavori di ricerca attualmente più significativi che forniscono una soluzione all adattamento dei processi di business, e confronta le differenze

13 12 tra gli approcci individuati con quello adottato in questo lavoro di tesi. Infine il capitolo 7 discute i risultati ottenuti da questa tesi e gli sviluppi futuri che potranno derivarne.

14 Capitolo 2 Analisi del Problema Uno dei punti di forza delle aziende di successo è la capacità di modificare i propri processi di business a seconda delle esigenze del mercato. In questo modo le aziende possono rispondere in maniera veloce ed efficiente ai requisiti dei propri clienti che sono in continua evoluzione. Una soluzione a questi problemi è supportata dalle architetture orientate ai servizi (Service Oriented Architecture o SOA) [30], uno stile architetturale che gioca un ruolo fondamentale nel supporto e nella gestione dei processi di business. Le SOA rappresentano le applicazioni come composizioni di servizi, e uno dei linguaggio più utilizzati per rappresentarle è BPEL (Business Process Execution Language) [15]. In questo capitolo si discute il ruolo delle SOA a supporto dei processi di business. Inoltre si descrivono le architetture SOA, illustrandone le caratteristiche e i componenti. Infine, si introduce il linguaggio BPEL, analizzandone non solo le sue potenzialità ma soprattutto, i suoi limiti. 13

15 2.1. I processi di business e le SOA I processi di business e le SOA Un processo di business rappresenta un insieme di attività interrelate, svolte all interno dell azienda, che creano valore trasformando delle risorse (input del processo) in un prodotto (output del processo) destinato ad un soggetto interno o esterno all azienda (cliente) [28]. I processi sono quindi delle aggregazioni di attività finalizzate al raggiungimento di uno stesso obiettivo. Per esempio, tutte le attività svolte per trasformare le materie prime in prodotti finiti costituiscono il processo di produzione. L esigenza di gestire quantità sempre maggiori di informazioni ha portato le aziende ad automatizzare e supportare i processi di business attraverso delle apposite applicazioni. Di conseguenza tali applicazioni devono allinearsi il più possibile ai processi dell azienda. Con la continua evoluzione del mercato, gli obiettivi di un azienda sono soggetti a frequenti cambiamenti. Le aziende devono quindi modificare e adattare i processi di business in base alle esigenze dei propri clienti per poter mantenere i suoi profitti elevati. Inoltre, le modifiche nei processi di business devono riflettersi in un cambiamento delle applicazioni che li supportano. Solo le aziende che possono adattare rapidamente ed efficacemente le proprie applicazioni seguendo i cambiamenti dei processi di business, possono essere competitive sul mercato globale. Purtroppo le applicazioni che supportano i processi di business non possono reagire istantaneamente ai cambiamenti degli obiettivi aziendali. Infatti modificare un applicazione è un lavoro difficile che richiede molto tempo. Tale difficoltà deriva dalla necessità di capire in che modo l applicazione può rispecchiare tali cambiamenti. Inoltre, il tempo necessario per creare una nuova versione dell applicazione (implementare, testare e distribuire le modifiche) non è trascurabile.

16 2.2. Service Oriented Architecture 15 Per molti anni l industria del software ha cercato architetture efficienti, tecnologie e metodi che soddisfacessero i requisiti citati. Oggigiorno una delle architetture che offre molte potenzialità per soddisfare tali requisiti è la SOA, di cui parleremo nel prossimo paragrafo. Le SOA sono altamente flessibili e permettono di creare applicazioni partendo da servizi esistenti con costi ridotti. 2.2 Service Oriented Architecture Le SOA costituiscono un nuovo paradigma architetturale, avente come componenti fondamentali i servizi. Le SOA si prestano bene ad essere utilizzate a supporto dei processi di business, infatti ogni servizio componente può essere associato ad una o più funzionalità di tale processo. Ciascun servizio è un componente indipendente, definito ed erogato per rispondere a delle richieste di un utente, per risolvere dei problemi o per soddisfare determinati bisogni. Ogni servizio può rappresentare qualsiasi tipo di logica incorporando tante sorgenti, inclusi altri servizi. Visto che le SOA sono una composizione di funzionalità (implementate dai servizi), è possibile applicare delle modifiche, in maniera relativamente più semplice rispetto al modello classico di programmazione, cambiando le modalità di interazione tra i servizi oppure aggiungendo/rimuovendo/modificando i servizi componenti. SOA non è un architettura radicalmente nuova, ma piuttosto l evoluzione di architetture distribuite e metodi di integrazione ben noti: l EAI (Enterprice Application Integration) [27]. L EAI cercava di unire diversi scenari di business utilizzando specifiche interfacce application-to-application (A2A),

17 2.2. Service Oriented Architecture 16 progettate con l obiettivo di incrementare le performance e l affidabilità. Tuttavia, l EAI non ha prodotto un architettura di integrazione che si sia dimostrata economicamente efficace nel lungo termine, bensì ha presentato diversi problemi. Anche se i tool dell EAI potevano collegare singole applicazioni, ai programmatori era richiesto comunque di comprendere i meccanismi interni di ciascuna delle applicazioni, cosa che portava a creare un eccessiva interdipendenza. A fronte di qualsiasi cambiamento era infatti necessario eseguire attività complesse e onerose di programmazione e di testing. Tali problemi sono stati superati grazie alle SOA, le quali astraggono il modo con cui sono stati implementati i singoli componenti, richiedendo ai programmatori solo di conoscere il comportamento esterno dei singoli componenti utilizzati Caratteristiche delle SOA Le SOA si basano su un principio dell ingegneria del software chiamato separation of concerns. Questo principio afferma che è conveniente separare un problema complicato in una serie di problemi più piccoli. In questo modo, la logica richiesta per risolvere un problema viene decomposta e, di conseguenza, può diventare più semplice. Qui di seguito si analizzano singolarmente le caratteristiche delle SOA. Composizione Le SOA permettono di combinare dei componenti già esistenti o implementati appositamente (servizi) per realizzare diverse funzionalità (processi di business). Questo porta a degli effetti positivi in ambito dello sviluppo e della manutenzione delle applicazioni, in quanto cambiare una o più funzionalità di un processo di business si riflette nella sostituzione di uno o più servizi. Grazie a questa caratteristica si ha una maggiore rapidità di risposta alle

18 2.2. Service Oriented Architecture 17 esigenze e ai cambiamenti di business, e una riduzione dei costi di sviluppo e manutenzione. Riusabilità Le SOA incoraggiano il riuso dei servizi. Il riuso di componenti permette sia di ridurre la ridondanza dei servizi esistenti che di semplificare lo sviluppo del software. La riusabilità porta anche dei benefici sia in termini di riduzione dei costi per nuovi sviluppi e per la manutenzione, sia in termini di aumento della rapidità di risposta al business per le modifiche dei processi esistenti e per l implementazione di nuovi processi. Condivisione contratto formale Il contratto del servizio è una descrizione che affianca un servizio specificandone lo scopo, le funzionalità, i limiti e l utilizzo. Essa è l unica informazione presentata all utilizzatore del servizio e quindi deve essere il più completa possibile. I contratti fornisco una definizione formale: dell endpoint del servizio; di ogni operazione del servizio; di tutti i messaggi di input ed output supportati dalle operazioni; dei ruoli e caratteristiche del servizio e delle sue operazioni. Un buon contratto deve anche fornire una descrizione semantica, che spieghi come un servizio possa svolgere un particolare compito. Poiché questo contratto è condiviso con gli altri servizi il suo design è molto importante. Gli utilizzatori di un servizio che accettano il contratto dipendono dalla sua

19 2.2. Service Oriented Architecture 18 definizione, quindi è molto importante mantenerli aggiornati nel caso in cui le funzionalità del servizio cambino. Loose coupling Il Loose coupling (accoppiamento lasco) rappresenta un condizione di indipendenza tra cliente e fornitore. L unica mutua conoscenza che entrambi devono possedere per usare e fornire servizi è il contratto. Grazie a questa caratteristica le SOA favoriscono l integrazione di processi tra differenti aziende, migliorano l apertura dell azienda all esterno sia attraverso l offerta di servizi a terzi, sia attraverso l acquisizione di servizi da terzi e permettono la scelta tra approccio make-buy (implementare l applicazione o comprarla da terze parti) per il reperimento dei servizi mancanti. Stato I servizi possono essere sia stateless che stateful. Il termine stateless significa che le informazioni di stato sono trasportate direttamente nel messaggio che arriva al servizio, e non vengono memorizzate all interno del servizio stesso. Al contrario un servizio stateful memorizza le informazioni dello stato e assume un comportamento differente in base al suo stato interno. Astrazione dalla logica sottostante Il principio di astrazione permette ai servizi di funzionare come una scatola chiusa, nascondendo i loro dettagli al resto del mondo. Un servizio espone delle operazioni in modo standard, astraendone il modo in cui sono implementate. Grazie a questo principio si può implementare il servizio nella maniera più conveniente e chiunque può utilizzarlo indipendentemente dalla piattaforma hardware/software adottata.

20 2.2. Service Oriented Architecture Web Service Anche se le SOA non sono legate ad alcuna specifica tecnologia, molto spesso e in maniera sempre più frequente i servizi che le compongono vengono sviluppati come web service. Un web service viene definito secondo il W3C come:... a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machineprocessable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its descriptions using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards [24]. Come espresso nella definizione essi forniscono le basi tecnologiche per supportare l interoperabilità tra applicazioni che usano piattaforme software, sistemi operativi e linguaggi di programmazione differenti. Essi espongono le loro operazioni attraverso un interfaccia WSDL (Web Services Description Language) [23], espressa in XML (exensible Markup Language)[20], che è lo standard de-facto per l integrazione di dati. Infine, utilizzano i messaggi SOAP (Simple Object Access Protocol) [21] trasmessi tipicamente tramite protocolli, quali HTTP (Hyper Text Transfer Protocol), o anche SMTP (Simple Mail Transfer Protocol), FTP (File Transfer Protocol), e MIME (Multipurpose Internet Mail Extensions). I messaggi scambiati da cliente e fornitore di un web service possono seguire protocolli differenti (one-way, request/response, solicit response, o notification). Inoltre i web service supportano interazioni sincrone e asincrone, e sono indipendenti dalla piattaforma: mediante l uso dei protocolli Internet standard per il trasporto dei messaggi i web service non necessitano, nor-

21 2.3. BPEL 20 malmente, che vengano effettuate modifiche alle regole di sicurezza utilizzate come filtro sui firewall. Inoltre i web service sono indipendenti dall implementazione del servizio, in quanto il software può anche subire delle modifiche senza cambiare la definizione dell interfaccia e quindi senza che all esterno si noti il cambiamento. Infine favoriscono il riuso del software: è possibile riutilizzare software implementato precedentemente e renderlo disponibile attraverso la rete Enterprise Service Bus Spesso nell utilizzo dei web service si rende necessario un EBS (Enterprise Service Bus). Un ESB è un infrastruttura che aggiunge flessibilità di comunicazione tra i servizi e ne semplifica l integrazione e il riutilizzo. Tale infrastruttura permette di collegare in maniera semplice i servizi anche se sono stati implementati con diverse tecnologie, fungendo da mediatore tra i protocolli e prodotti middleware che spesso sono diversi e incompatibili. 2.3 BPEL BPEL è un linguaggio basato su XML, che descrive le attività e le caratteristiche dei processi di business, garantendo la suddivisione dei compiti tra attori diversi. BPEL rappresenta sicuramente uno strumento fondamentale per supportare le SOA. Esso, infatti, permette l integrazione e la cooperazione di diverse componenti (web service), generando così dei servizi dal valore aggiunto che mantengono le caratteristiche di modularità e scalabilità.

22 2.3. BPEL Caratteristiche principali BPEL supporta due modalità di composizione dei servizi all interno di un processo: l orchestrazione e la coreografia. L orchestrazione prevede che il controllo del workflow venga mantenuto da un solo gestore logico, che interagisce, anche per processi di lunga durata, con altri servizi, interni o esterni. Nella coreografia non esiste un coordinatore centrale: tutti i partecipanti della composizione necessitano di conoscere il processo di business di appartenenza, le operazioni da eseguire, i messaggi da scambiare e la tempistica dello scambio dei messaggi. Nell orchestrazione esiste un coordinatore in grado di gestire l intera esecuzione del processo, controllando i messaggi e le interazioni tra i partecipanti. L orchestrazione è un paradigma più flessibile: è possibile individuare esattamente l unico processo responsabile dell intera composizione e l inserimento/rimozione/modifica di un web service può essere effettuato in modo più semplice rispetto alla coreografia. BPEL fornisce il supporto per l orchestrazione attraverso processi di business eseguibili e il supporto per la coreografia attraverso processi di business astratti. I processi astratti sono raramente usati e per tutto il resto della tesi si farà riferimento solo all orchestrazione e quindi, ai processi eseguibili. BPEL permette di definire un processo come insieme di web service collaboranti. Questo nuovo servizio a valore aggiunto è esso stesso un web service che espone a sua volta un interfaccia WSDL. Dal punto di vista tecnico, un processo BPEL esprime la logica di funzionamento del processo e deve essere interpretato ed eseguito da un orchestratore (motore BPEL). Ciò che avviene è, quindi, una divisione del processo secondo due punti di vista mostrati in Figura 2.1: quello dell utente del processo (a sinistra) che può supporre di interagire con un singolo servizio, e quello dei servizi cooperanti all interno del processo (a destra)

23 2.3. BPEL 22 che, descrivendo le proprie funzionalità attraverso WSDL, verranno invocati dall orchestratore nei tempi e nei modi definiti all interno del processo. Figura 2.1: Modalità di interazione con un processo BPEL Entrando in dettaglio, il processo essenzialmente è composto da attività che possono gestire richieste da parte del client del processo (attività di receive/pick) oppure inviare messaggi di risposta al client medesimo (attività di reply). Per poter soddisfare tale richiesta il processo si basa, come si è detto precedentemente, su una serie di web service esterni, chiamati servizi partner, che possono essere invocati attraverso l attività di invoke Struttura di un processo BPEL Di seguito si descrivono le attività, specificate all interno dello standard BPEL, maggiormente utilizzate nel corso dello sviluppo della tesi. Un processo BPEL non contiene solo le attività che costituiscono il flusso del processo, ma anche le informazioni necessarie per la definizione e l esecuzione di tali attività. Queste informazioni sono suddivise in vari gruppi: <import>: specifica i documenti WSDL e gli XML Schema utilizzati dal processo;

24 2.3. BPEL 23 <partnerlinks>: definisce le relazioni tra i vari servizi componenti (servizi partner); <variables>: dichiara le variabili utilizzate. Esse possono rappresentare i messaggi scambiati dal processo con i servizi partner e lo stato del processo di business. Le variabili possono anche contenere i dati necessari per l esecuzione del processo; <correlationsets>: assicurano che i messaggi siano smistati alle istanze del processo corrette. Le attività di un processo BPEL definiscono il suo flusso d esecuzione. Esse possono essere catalogate in quattro macro gruppi: attività di base: interagiscono con l esterno, come la ricezione di messaggi da parte del client e l invocazione dei servizi web; attività short-lived: hanno un esecuzione di breve durata e possono essere viste come operazioni atomiche; attività strutturate: possono contenere al loro interno attività appartenenti a qualsiasi macro gruppo; attività per la gestione degli errori. Le attività di base utilizzate nel corso della tesi sono: <receive>: attende un messaggio da parte di un servizio partner o dal client. Inoltre ha la possibilità di iniziare un processo, creandone una nuova istanza; <reply>: invia un messaggio di risposta al servizio partner che ha inviato un richiesta al processo;

25 2.3. BPEL 24 <invoke>: invoca un servizio partner per eseguire un operazione. La chiamata può essere di tipo one-way oppure request/response. Le attività short-lived utilizzate nel corso della tesi sono: <assign>: può essere usata per copiare valori da una variabile ad un altra oppure per assegnare nuovi valori alle variabili; <onalarm>: corrisponde ad un allarme basato su un timer. Le attività strutturate sono: <sequence>: esegue le attività contenute al suo interno sequenzialmente, nell ordine in cui sono definite; <flow>: esegue tutte le attività contenute al suo interno in parallelo; <while>: esegue un insieme di attività ripetutamente, finché la condizione specificata nel corpo del while non è più verificata; <repeatuntil>: si comporta come l attività <while>, con l unica differenza che l insieme di attività viene eseguito almeno una volta, perché la condizione è verificata alla fine dell esecuzione del ciclo; <pick>: esegue un attività scelta in base al verificarsi di un determinato evento. Può anche iniziare un processo, creandone una nuova istanza. Le attività offerte da BPEL per la gestione di errori sono: <faulthandler>: definisce il comportamento del processo nel caso si presentino degli errori; <eventhandler>: si comporta come il <faulthandler>, però gestisce degli eventi attesi invece che degli errori;

26 2.4. Limiti del linguaggio BPEL 25 <compensationhandler>: esegue una serie di attività di compensazione nel caso in cui si verificano degli errori. 2.4 Limiti del linguaggio BPEL In questo paragrafo si discutono i limiti del linguaggio BPEL, dovuti alla staticità intrinseca del linguaggio. Tale staticità è legata all impossibilità di modificare ulteriormente il processo dopo che ne è stato effettuato il deploy. Queste modifiche sono essenziali se si vuole mantenere un constante allineamento tra i processi di business e i processi BPEL che li supportano e se si vogliono gestire i problemi legati alla natura distribuita dei servizi che compongono un processo BPEL. Il processo BPEL è un guscio al cui interno ci sono tutte le attività necessarie a comporre diversi servizi sviluppati da terze parti. Ad un certo punto dell esecuzione del processo BPEL questi servizi potrebbero essere soggetti a un cambiamento radicale o potrebbero non essere più disponibili. La disponibilità di un servizio può variare per diverse ragioni [13]: le operazioni di deploy e di undeploy possono essere effettuate in qualsiasi istante di tempo. I fornitori potrebbero disinstallare alcuni dei servizi offerti, generando dei problemi in altri servizi che li usano; la natura disaccoppiata dei servizi non permette di controllarne le variazioni dopo la fase di deploy del processo di business (ad esempio durante la composizione). Per questo motivo, le modifiche nell implementazione delle loro interfacce potrebbero renderli inutili per gli obiettivi che il sistema vuole raggiungere. Inoltre, potrebbe essere necessaria una ricodifica di alcune parti della composizione per compensare i cambiamenti;

27 2.4. Limiti del linguaggio BPEL 26 il nodo su cui è stato effettuato il deploy del servizio potrebbe essere troppo carico o in manutenzione o la rete stessa potrebbe essere sovraccarica o subire malfunzionamenti. La staticità del linguaggio BPEL non è in grado di gestire errori non previsti correlati alla natura dei processi di business. Ad esempio: errori di comunicazione: si manifestano quando viene invocato un servizio che non è disponibile; errori esterni: si manifestano quando ci sono inesattezze nell implementazione o nel protocollo utilizzato dai servizi esterni, invocati dal processo. Questi errori possono determinare la violazione di semplici requisiti funzionali, ad esempio nel caso in cui un servizio non fornisca le funzionalità corrette dando dei risultati sbagliati. Oppure possono causare l infrazione di vincoli più sottili imposti da interazioni particolari, ad esempio nel caso in cui la risposta del servizio non rispetti il protocollo richiesto dal cliente. In entrambi i casi, il processo che invoca l applicazione ottiene dei risultati inattesi, la cui causa non può essere individuata con esattezza; errori di QoS (qualità di servizio) [29]: sono determinati dall infrazione di requisiti/vincoli non funzionali definiti dal progettista del processo, quali ad esempio banda, disponibilità, affidabilità, prezzo e molte altre dimensioni di qualità del servizio. La violazione di tali requisiti è legata all assenza, da parte del progettista, di un controllo completo sull esecuzione del processo, e quindi di eventuali cambiamenti nelle proprietà funzionali e non funzionali dei servizi utilizzati dal processo stesso. Per descrivere i punti di debolezza finora citati, si userà un esempio. Si suppone di avere un processo BPEL di prenotazione di viaggi aerei. Il pro-

28 2.4. Limiti del linguaggio BPEL 27 cesso si aspetta in ingresso i dati del volo (città di partenza e destinazione, ecc.). La ricerca dei voli, invece, viene effettuata attraverso i web service delle compagnie aeree associate al servizio in questione. Se ad un certo punto una compagnia rescinde il contratto di collaborazione (o un altra compagnia stipula un contratto di collaborazione), lo sviluppatore non ha modo di prevedere questo cambiamento e quindi non può gestirlo con i costrutti messi a disposizione nel linguaggio BPEL. Per attuare questa modifica si dovrebbe ridefinire l intero processo eliminando (o includendo) l invocazione del servizio della compagnia che ha deciso di recidere (stringere) il (nuovo) contratto. Questi piccoli cambiamenti invece dovrebbero essere resi possibili senza riscrivere l intero processo e senza quindi rideployarne una nuova versione. Anche se il linguaggio BPEL fornisce costrutti per la gestione di eccezioni (<compensationhandler>, <faulthandlers> e <eventhandlers>), e meccanismi di time-out (<onalarm>), tali costrutti non risultano sufficienti per gestire tutte le situazioni di errore che possono verificarsi durante l esecuzione di un processo di business. Infatti, le funzionalità di monitoraggio offerte da BPEL possono essere utilizzate solo per le variabili interne, e qualsiasi reazione a comportamenti eccezionali dovrebbe essere codificata all interno del flusso di esecuzione principale. Tornando all esempio precedente, lo sviluppatore potrebbe dotare il processo BPEL di un meccanismo di time-out. Nel caso in cui uno dei servizi partner non sia momentaneamente disponibile, non si otterrà una risposta prima dello scadere del time-out. Nonostante ciò, non sarebbe comunque possibile conoscere le cause del problema: il servizio partner potrebbe avere un ritardo dovuto al sovraccarico della rete o potrebbe realmente non essere raggiungibile. In conclusione, la soluzione proposta da BPEL potrebbe essere molto

29 2.4. Limiti del linguaggio BPEL 28 complessa (data dalla limitazione del linguaggio stesso) e non flessibile (ogni cambiamento richiederebbe una modifica del processo di BPEL e il suo rideploy). Dalle considerazioni fatte in questo paragrafo emerge la mancanza di un componente di adattamento/recovery, che ha il compito di modificare la struttura di un processo BPEL dopo la fase di deploy, cioè durante l effettiva esecuzione del processo. Questo componente deve assicurare una grande flessibilità, offrendo la possibilità di effettuare sia piccoli cambiamenti, come l invocazione di un servizio invece di un altro, sia di ristrutturare il flusso di esecuzione dell intero processo.

30 Capitolo 3 Progettazione concettuale In questo capitolo si descrive la soluzione adottata in questa tesi al problema dell adattamento/recovery dei processi BPEL e le scelte implementative che sono state intraprese. 3.1 Scenario applicativo e obiettivi Lo scopo principale di questa tesi è quello di sviluppare un componente di recovery per l adattamento dinamico dei processi BPEL. Per adattamento dinamico dei processi BPEL si intende l aggiunta o la rimozione di attività, variabili o servizi partner senza bloccare l esecuzione delle istanze del processo. Il componente responsabile di eseguire le azioni di adattamento sul processo prende il nome di DyBPEL (Dynamic BPEL). In particolare DyB- PEL fornisce una soluzione al problema di modifica delle istanze future e correnti del processo BPEL in esecuzione. L architettura di DyBPEL è schematizzata in Figura 3.1. Dopo un attenta analisi del problema si è pensato di suddividere la soluzione proposta

31 3.1. Scenario applicativo e obiettivi 30 Figura 3.1: Architettura di DyBPEL in due sotto-soluzioni più semplici. Una soluzione permette la modifica delle istanze del processo future (BPEL Modifier), e l altra consente di cambiare la struttura delle istanze correnti (Process Runtime Modifier). In particolare per poter modificare le istanze in esecuzione è stato necessario aggiungere delle funzionalità al motore BPEL in maniera non intrusiva, utilizzando la programmazione orientata agli aspetti. Inoltre DyBPEL espone un interfaccia per essere configurato dall esterno tramite il componente Coordinator Modifier. Le possibili modifiche che possono essere effettuate sul processo da DyB- PEL sono visualizzate in Figura 3.2: aggiungere una nuova variabile; rimuovere una variabile esistente; aggiungere una nuova attività; rimuovere un attività esistente; aggiungere un servizio partner; rimuovere un servizio partner esistente.

32 3.2. Prodotto finale e scelte implementative 31 Figura 3.2: Operazioni di modifica messe a disposizione da DyBPEL 3.2 Prodotto finale e scelte implementative Dopo aver definito lo scenario applicativo e gli obiettivi di tale tesi, in questo paragrafo si descrivono le scelte implementative che sono state effettuate nel corso di questo lavoro. Per implementare le funzionalità del componente Process Runtime Modifier è stato necessario utilizzare AOP e in particolare la sua implementazione AspectJ [26], in quanto il motore modificato è scritto in JAVA. Per la scelta del motore da modificare è stata fatta una valutazione sui motori BPEL più conosciuti e utilizzati: ActiveBPEL Engine [1]: è il motore open source della Active Endpoints sviluppato in Java;

33 3.2. Prodotto finale e scelte implementative 32 Apache ODE [18]: è il motore open source della Apache Software Fondation sviluppato in Java; Oracle BPEL Process Manager [17]: è il motore di BPEL scritto in Java della nota società di sviluppo software ORACLE; a differenza dei precedenti motori, non è open source. Per lo sviluppo della tesi si è scelto ActiveBpel Engine. Il motore di ORA- CLE non è stato preso in considerazione perché non è open source e quindi non ne permetteva la personalizzazione. Tra i due restanti candidati, la scelta finale è ricaduta su ActiveBPEL Engine in quanto, come enunciato da Daniele Nucci [14], nonostante in termini di prestazioni i due candidati siano quasi a pari merito, le specifiche dello standard di OASIS sono maggiormente supportate dal motore ActiveBPEL. Inoltre per implementare le funzionalità del componente Bpel Modifier e stato utilizzato XMLBeans per il parsing e la modifica dei file XML Infine il componente Coordinator Modifier è stato implementato come un web service attraverso Axis [3]. Esso funge solo da coordinatore: riceve le richieste dall esterno e le smista ai due componenti a valle (Bpel Modifier e Process Runtime Modifier). Un web service espone un interfaccia standard ed è indipendente dalla piattaforma. Il Coordinator Modifier è deployato all interno dell application server Tomcat [2]. Questa scelta è stata effettuata per comodità d implementazione, in quanto anche il motore BPEL che è stato modificato (ActiveBPEL) è deployato all interno di Tomcat. Per tenere traccia dei processi disponibili sul motore BPEL, delle versioni create e delle modifiche da effettuare ci si è serviti di un database gratuito, MySQL [16], che offre delle funzionalità di base per memorizzare le informazioni nel tempo e di renderle velocemente recuperabili. Tra i vari database disponibili sul mercato si è scelto MySQL poiché attualmente è quello mag-

34 3.2. Prodotto finale e scelte implementative 33 giormente utilizzato e la complessità della base di dati implementata non ha richiesto l utilizzo di funzionalità avanzate.

35 Capitolo 4 Implementazione di DyBPEL Questo capitolo descrive in dettaglio i singoli componenti di DyBPEL: Bpel Modifier, Process Runtime Modifier, Coordinator Modifier e Changes Repository. Il componente Bpel Modifier permette di creare una nuova versione del processo BPEL a cui le nuove istanze dovranno conformarsi. Questo componente agisce direttamente sui file che descrivono la definizione del processo. La nuova versione del processo viene deployata e resa disponibile sul motore BPEL in maniera trasparente all utente. Il componente Process Runtime Modifier modifica la definizione del processo per le istanze in esecuzione, inserendo nuove attività o eliminando attività esistenti. Il componente Coordinator Modifier rende disponibili le funzionalità di DyBPEL nascondendo i componenti che le supportano (il Bpel Modifier e il Process Runtime Modifier). Infatti, una volta ricevute in ingresso le modifiche da effettuare, esso configura e invia delle apposite direttive ai due componenti a valle.

36 4.1. Visione d insieme 35 Il componente Changes Repository contiene le informazioni necessarie per il corretto funzionamento degli altri componenti di DyBPEL. 4.1 Visione d insieme Avendo chiari gli obiettivi, lo scenario applicativo e le funzioni da svolgere, in questo paragrafo si illustrano le interazioni tra i vari componenti di DyBPEL, tramite i diagrammi di sequenza. Figura 4.1: Diagramma di sequenza - Operazione di modifica La Figura 4.1 descrive le interazioni tra i vari componenti di DyBPEL e l utente esterno. L operazione di modifica inizia con l invio di un messaggio, dell utente al Coordinator Modifier, il quale contiene i dati necessari per effettuare tale operazione (fase 1 ). Il Coordinator Modifier, a sua volta, si connette al Changes Repository (fase 2a) per richiedere la versione corrente del processo in uso (fase 2b), in modo da apportare le modifiche sulla versione corrente del processo e successivamente, inserisce sul Changes Repository le modifiche da applicare sulle istanze in esecuzione (fase 3 ) specificando: il tipo

37 4.2. Changes Repository 36 di modifica, l attività da intercettare per effettuare il cambiamento e il punto in cui effettuare la modifica. Nel caso in cui la modifica aggiunga un attività, è anche necessario fornire in ingresso la definizione (espressa in XML) di tale attività. Nella fase 4 il Coordinator Modifier invia le modifiche al Bpel Modifier, che a sua volta, crea una nuova versione del processo, modificando quella precedente, ne effettua il deploy sul motore BPEL (fase 5 ) e inserisce un nuovo record nel Changes Repository per indicare l avvenuto inserimento della nuova versione (fase 6 ). Il componente Process Runtime Modifier non compare in questo diagramma di sequenza, poiché il suo funzionamento è legato all esecuzione di tutte le relative istanze e i processi disponibili sul motore BPEL (vedi figura 4.2). Ogni volta che una istanza del processo esegue un attività, il Process Runtime Modifier la intercetta e interroga il Changes Repository per controllare se è necessario applicare delle modifiche al suo flusso di esecuzione (fase 1a). Se l attività intercettata compare in uno o più record, precedentemente inseriti nel Changes Repository dal Coordinator Modifier, allora il Changes Repository invia i dati necessari per modificare il processo, aggiungendo o rimuovendo attività, partnerlink o variabili (fase 1b). Infine il Process Runtime Modifier effettua le modifiche desiderate (fase 2 ). 4.2 Changes Repository Per capire a fondo il funzionamento dei singoli componenti di DyBPEL è indispensabile introdurre il database a supporto di DyBPEL (Changes Repository). Questo componente contiene le informazioni necessarie per configurare i componenti in modo che effettuino le modifiche correttamente. In Figura 4.3 è visualizzato il modello E/R (Entità/Relazione) del Chan-

38 4.2. Changes Repository 37 Figura 4.2: Diagramma di sequenza - Interazione tra il Process Runtime Modifier e il Changes Repository ges Repository. Esso si compone di tre tabelle: ProcessTable, VersionTable e AdaptationTable. La ProcessTable permette di tenere traccia dei processi BPEL che sono disponibili sul motore. Questa tabella deve essere inizialmente configurata, per assicurare un corretto funzionamento di DyBPEL. A tal fine è necessario inserire il nome e l indirizzo di tutti processi disponibili sul motore BPEL. La VersionTable tiene traccia delle versioni esistenti per ogni processo. I campi di questa tabella indicano: il nome del file sorgente del processo BPEL (.bpr), l URL della cartella in cui risiede il codice sorgente del processo BPEL, l URL in cui è stato deployato il file.bpr (../tomcat/bpr), il nome del servizio che rappresenta il processo BPEL, il numero delle istanze attive per quella specifica versione del processo e la data della corrispondente versione del processo. La AdaptationTable tiene traccia degli adattamenti da effettuare sulle istanze in esecuzione per ciascuna versione di ogni processo. Gli attributi di questa tabella specificano: il tipo di modifica (aggiunta o rimozione di un attività), l attività da intercettare per effettuare la modifica, l attività

39 4.3. Bpel Modifier 38 target, che può indicare l attività da rimuovere (nel caso di una modifica di rimozione) oppure l attività dopo la quale è necessario inserire la modifica (nel caso di una modifica di aggiunta di attività), infine l ultimo attributo contiene il codice XML dell attività da inserire (nel caso di una modifica di aggiunta di attività). Figura 4.3: Modello entità-relazione del database a supporto di DyBPEL L AdaptationTable permette anche di rappresentare le modifiche dei partnerlink, modificando le attività in vengono sono utilizzati. 4.3 Bpel Modifier Il componente Bpel Modifier permette di creare una nuova versione del processo, effettuando delle modifiche a partire da una versione precedente opportunamente specificata. Prima di descrivere il funzionamento del componente Bpel Modifier è necessario descrivere la fase di deploy di un processo BPEL e i file che rappresentano la definizione di un processo.

40 4.3. Bpel Modifier Deploy di un processo Come già accennato, per deploy di un processo si intende l operazione che rende disponibile l esecuzione di un processo su un motore BPEL. Qui si analizza in dettaglio l esecuzione del deploy di un processo sul motore ActiveBPEL. Questo motore richiede la creazione di un archivio, avente estensione.bpr (Business Process Archive), il quale contiene al suo interno tutti i file necessari per la definizione del processo. Tale archivio viene creato con il comando jar cf nomefile.bpr *.pdd META-INF bpel wsdl. Per avviare il deploy del processo all interno del motore ActiveBPEL, è necessario copiare il file.bpr all interno della cartella bpr di Tomcat. In dettaglio l archivio.bpr deve contenere le cartelle seguenti: bpel: contiene il file.bpel che descrive il comportamento del processo e le variabili e partnerlink utilizzati; META-INF: deve racchiudere il file wsdlcatalog.xml, il quale elenca i file WSDL e XML Schema utilizzati dal processo. Nei file WSDL vengono specificati i tipi di dati e i tipi di partnerlink utilizzati dal file.bpel, inoltre viene descritta l interfaccia che viene esposta all esterno dal processo BPEL. Nei file XML Schema vengono definiti nuovi tipi di dato semplici o complessi; wsdl: contiene fisicamente i file WSDL e XML Schema elencati nel file wsdlcatalog.xml. All esterno delle tre directory, deve esserci un file con estensione.pdd Process Deployment Descriptor (PDD), il quale viene utilizzato per contenere le direttive necessarie per il corretto funzionamento del processo BPEL (ad esempio informazioni sui partnerlink, sui protocolli e sui file WSDL utilizzati). Que-

41 4.3. Bpel Modifier 40 ste informazioni sono specifiche del motore ActiveBPEL e garantiscono il suo corretto funzionamento. Struttura del file WSDL Un documento WSDL descrive un insieme di servizi e di operazioni offerte. Esso è composto da cinque elementi principali: <types> definisce i tipi di dato utilizzati; <message> descrive i messaggi usati dai web service per comunicare con il client; <porttype> caratterizza una porta di comunicazione, le operazioni disponibili ed i messaggi utilizzati nelle operazioni; <binding> fornisce le indicazioni su come le operazioni definite dall elemento <porttype> saranno trasmesse sulla rete; <service> indica l indirizzo HTTP da cui poter accedere al web service. Nel seguito sono riportati dei frammenti del file WSDL che descrive un servizio che, ricevuto un numero intero (idutente), restituisce informazioni sull utente a cui è associato tale numero. <?xml version="1.0"?> <definitions xmlns:xs=" xmlns:tns=" xmlns:soap=" xmlns:wsdl=" targetnamespace=" <types>

42 4.3. Bpel Modifier 41 <xs:schema targetnamespace=" <xs:complextype name="utente"> <xs:all> <xs:element name="nickname" type="xs:string"/> <xs:element name="nome" type="xs:string"/> <xs:element name="cognome" type="xs:string"/> <xs:element name=" " type="xs:string"/> </xs:all> </xs:complextype> </xs:schema> </types> Gli attributi dell elemento <definitions> determinano i namespace utilizzati all interno del file WSDL. L elemento <types> definisce tipi di dato, complessi e semplici. In questo caso definisce il tipo utente. <message name="getuserrequest"> <part name="idutente" type="xs:integer"/> </message> <message name="getuserresponse"> <part name="utente" type="tns:utente"/> </message> I messaggi scambiati dal servizio sono mostrati nel frammento riportato sopra. Il primo messaggio (getuserrequest) riceve l intero corrispondente all idutente inviato dal cliente, mentre il secondo messaggio (getuserresponse) contiene la risposta del web service. L elemento <part> (ogni messaggio può averne più di uno) specifica le informazioni di cui si compone ciascuna parte di un messaggio e le associa a un nome (name) e a un tipo (type). <porttype name="gestioneutentitype"> <operation name="getuserbyid">

43 4.3. Bpel Modifier 42 <input message="tns:getuserrequest"/> <output message="tns:getuserresponse"/> </operation> </porttype> L elemento <porttype>, che unisce diversi messaggi per formare un operazione, è associato a un nome (attributo name) e a una o più operazioni tramite l elemento <operation>. Ogni operazione può essere di quattro tipi: one-way: riceve un messaggio; request-response: riceve un messaggio e invia una risposta; solicit-response: invia una richiesta e attende una risposta; notification: invia un messaggio. In questo caso, si è usata un operazione del tipo request-response. L elemento <binding> si occupa del collegamento con il protocollo di comunicazione (SOAP in questo caso) ed è mostrato nel frammento WSDL sottostante. <binding name="gestioneutentibinding" type="tns:gestioneutentitype"> <soap:binding style="rpc" transport=" <operation name="getuserbyid"> <soap:operation soapaction="" style="rpc"/> <input> <soap:body use="encoded" namespace=" encodingstyle=" </input> <output>

44 4.3. Bpel Modifier 43 <soap:body use="encoded" namespace=" encodingstyle=" </output> </operation> </binding> L elemento <binding> è del tipo <porttype> definito precedentemente. Il secondo binding specifica meglio il protocollo SOAP ed ha due attributi: style, che indica la codifica con cui è scritto il file e transport, che indica il protocollo utilizzato, in questo caso HTTP. In seguito, si richiama l operazione definita in <porttype> e gli si associa una soapaction (solitamente viene lasciata vuota). Per finire, tramite gli elementi <input> e <output>, si definisce il tipo del messaggio. All interno dei due elementi si dichiara il <soap:body>, il quale specifica come saranno le parti del messaggio all interno del protocollo SOAP, indicandone, se presente, anche il tipo di codifica. <service name="servizioutenti"> <port name="gestioneutenti" binding="tns:gestioneutentibinding"> <soap:address location=" </port> </service> Infine l elemento <service>, mostrato sopra, individua il nome del servizio (attributo name) e permette di associare una porta (elemento <port>) ad un binding. Esso definisce anche l indirizzo HTTP (elemento <address>) sul quale il web service sarà in attesa di richieste. Nel caso in cui si voglia definire un file WSDL a supporto di un processo BPEL, è necessario specificare altri elementi. Il più importante è definito nel namespace e

45 4.3. Bpel Modifier 44 permette di definire i <partnerlinktype> che caratterizzano il rapporto di conversazione tra due servizi (come mostrato nell esempio che segue). Ciascun <partnerlinktype> è caratterizzato dal ruolo (role) svolto dal servizio corrispondente all interno della conversazione e dal <porttype> fornito dal servizio per ricevere i messaggi del contesto della conversazione. <partnerlinktype name="gestionelt"> <role name="gestionerole" porttype="buy:gestioneutentitype"/> </partnerlinktype> Oltre all elemento <partnerlinktype> nel corso di questa tesi si sono utilizzati gli elementi <property> e <propertyalias> per definire i correlationsets illustrati precedentemente (si veda il capitolo 2). Struttura del file BPEL In questo paragrafo si discute la struttura di un file BPEL, concentrandosi sugli elementi principalmente utilizzati. Di seguito si riporta lo schema di un file BPEL: <process name="ncname" targetnamespace="anyuri" xmlns=" <import namespace="anyuri"? location="anyuri"? importtype="anyuri"/>* <partnerlinks>? <partnerlink name="ncname" partnerlinktype="qname" myrole="ncname"? partnerrole="ncname"? initializepartnerrole="yes no"?/>+ </partnerlinks> <variables> <variable name="bpelvariablename" messagetype="qname"? type="qname"? element="qname"?/>+

46 4.3. Bpel Modifier 45 </variables> <correlationsets>? <correlationset name="ncname" properties="qname-list" />+ </correlationsets> activity </process> Gli attributi dell elemento <process> descrivono i namespace utilizzati all interno del file BPEL e assegnano un nome univoco al processo per identificare i processi disponibili all interno dello stesso motore BPEL. Un processo, oltre a contenere gli elementi descritti fin ora, deve contenere obbligatoriamente un attività al suo interno. 1 In genere, ogni processo BPEL contiene al suo interno almeno un attività strutturata che, come specificato nel capitolo 2, può contenere al suo interno altre attività. Nel seguito si mostra un esempio di processo BPEL, il quale aspetta una richiesta dal client, invoca un partner service e risponde al client da cui è stato contattato. <process name="esempiobpel" suppressjoinfailure="yes" targetnamespace=" xmlns=" xmlns:lns=" <import importtype=" location="project:/bpel_samples/resources/wsdl/esempio.wsdl" namespace=" <partnerlinks> <partnerlink name="customer" 1 Le attività di ciascun processo sono state già descritte nel capitolo 2.

47 4.3. Bpel Modifier 46 partnerlinktype="lns:customerlinktype" myrole="customerrole"/> <partnerlink name="partner" partnerlinktype="lns:partnerlinktype" partnerrole="partnerrole"/> </partnerlinks> <variables> <variable messagetype="lns:richiesta" name="request"/> <variable messagetype="lns:risposta" name="response"/> </variables> <sequence name="sequence1"> <receive name="receive1" createinstance="yes" operation="request" partnerlink="customer" porttype="lns:bpelserverpt" variable="request"/> <invoke name="invoke1" inputvariable="request" operation="anteprimaop" outputvariable="response" partnerlink="partnerservice" porttype="lns:anteprimapt"/> <reply name="reply1" operation="request" partnerlink="customer" porttype="lns:bpelserverpt" variable="response"/> </sequence> </process> L attività iniziale è una sequence la quale contiene una serie di attività che verranno eseguite sequenzialmente. Come si può notare dall esempio, ad ogni attività viene associato un attributo opzionale (name) che individua il nome dell attività. Tale attributo è essenziale per il corretto funzionamento di DyBPEL in quanto, essendo univoco, facilita la ricerca delle attività all interno del processo.

48 4.3. Bpel Modifier 47 Struttura del file wsdlcatalog.xml Il file wsdlcatalog.xml, mostrato nell esempio che segue, deve contenere un elemento (<wsdlentry>) per ogni documento WSDL utilizzato dal processo ed un elemento (<schemaentry>) per ogni file XML Schema. Entrambi gli elementi devono specificare gli attributi location e classpath (mostrato nell esempio che segue). L attributo location mappa un file WSDL in due modi possibili. In un primo caso il valore rappresentato da questo attributo è uguale a quello dell attributo location dell elemento <wsdl> all interno del file PDD. Nel secondo caso il valore rappresentato da questo attributo è uguale all attributo location dell elemento elemento <import> in uno dei file WSDL. L attributo classpath indica invece il percorso relativo del file WSDL all interno del file.bpr. <wsdlcatalog> <wsdlentry location="string" classpath="slash/separated/ classpath/esempio.wsdl"/> </wsdlcatalog> Struttura del file PDD ActiveBPEL definisce il seguente schema per il file.pdd: <process name="qname" xmlns=" location="relativedeploymentlocation" persistencetype="full none final"?> <partnerlinks> <partnerlink name="ncname"> <partnerrole endpointreference="static dynamic invoker principal" custominvokehandler="java:class:args"?>

49 4.3. Bpel Modifier 48 [... ws-addressing...]? </partnerrole>? <myrole service="name" allowedroles="namelist"? binding="msg RPC EXTERNAL"/>? </partnerlink>+ </partnerlinks> <wsdlreferences> <wsdl namespace="uri" location="uri"/>+ </wsdlreferences>? </process> Dichiarati i namespace, all interno degli elementi <partnerlink> si definiscono, tramite ws-addressing 2 [22], gli endpoint reference che permettono di conoscere gli indirizzi e le porte utili per comunicare con i web service utilizzati dal processo. Infine, è anche necessario specificare, all interno di <wsdlreferences> le dipendenze da altri file WSDL utilizzati all interno del processo Descrizione del Bpel Modifier Le funzionalità del componente Bpel Modifier sono principalmente svolte dalla classe schematizzata in Figura 4.4. Questo componente mette a disposizione un metodo pubblico (modifica) che viene chiamato dal componente Coordinator Modifier. Gli altri metodi sono privati e sono a supporto del primo. Questo metodo riceve in ingresso una serie di parametri che permettono la modifica di una delle vecchie versioni del processo per generare una nuova versione. Questi parametri sono: nome del processo BPEL; tramite il quale viene identificato univocamente il processo; 2 Il ws-addressing è uno standard per costruire gli endpoint reference utilizzati

50 4.3. Bpel Modifier 49 la versione di partenza dalla quale applicare le modifiche per raggiungere la nuova versione, se non la si specifica viene presa l ultima versione disponibile; un insieme di metodi che specificano le modifiche da effettuare sul processo (aggiunta variabile, aggiunta di un attività, ecc.); un insieme di attributi che specificano delle informazioni aggiuntive necessarie per descrivere completamente le azioni individuate dal parametro precedente. Per esempio per una azione che aggiunge una variabile, si dovranno specificare nell insieme degli attributi anche il nome e il tipo della variabile da modificare. Figura 4.4: Classe BpelModifier I passi che esegue questo metodo per arrivare alla soluzione sono molteplici e per questo motivo si farà riferimento solo a quelli principali. Il metodo modifica richiede al componente Changes Repository le informazioni essenziali per la creazione di una nuova versione, come il nome del file e la cartella di destinazione della versione di partenza. Prima di passare alle modifiche dei file che rappresentano un processo, effettua una copia

51 4.4. Process Runtime Modifier 50 di backup sulla quale lavorerà, in modo tale da mantenere sempre il codice sorgente di tutte le versioni. Inoltre prima di modificare la struttura del processo, applica delle modifiche, necessarie per poter effettuare il deploy di una nuova versione del processo. Alcune di queste vengono effettuate sul file.pdd. In particolare viene modificato il nome dell endpoint da utilizzare per invocare il processo. Tale procedura è necessaria poiché ogni versione del processo deve essere identificata univocamente e deve quindi avere un nome diverso. In seguito, il Bpel Modifier modifica le attività del processo seguendo in ordine i metodi specificati come parametro d ingresso. Infine crea un nuovo file.bpr, effettua la fase di deploy (copiandolo nella cartella /tomcat/bpr) e inserisce un nuovo record nella tabella VersionTable che indica che è stato effettuato correttamente il deploy della nuova versione. Da questo punto in poi la nuova versione è disponibile direttamente sull application server, in maniera totalmente trasparente per gli utenti. 4.4 Process Runtime Modifier Questo paragrafo è dedicato alla descrizione del componente Process Runtime Modifier. Come già accennato questo componente utilizza la programmazione AOP, in particolare la sua implementazione AspectJ, per poter monitorare, e se necessario, modificare la struttura del processo in esecuzione. Prima di descrivere in dettaglio il Process Runtime Modifier, è necessario introdurre la programmazione orientata agli oggetti (AOP).

52 4.4. Process Runtime Modifier Aspect Oriented Programming Uno dei principi fondamentali dell approccio moderno alla progettazione di sistemi software è quello del divide et impera; in particolare: Separation of concerns allows us to deal with different aspects of a problem, so that we can concentrate on each individually. [5] tuttavia, When different design decisions are strongly interconnected, it would be useful to take all the issues into account at the same time and by the same people, but this is not usually possible in practice. [5] I formalismi esistenti forniscono infatti meccanismi molto limitati per la decomposizione e la composizione, non permettendo quindi di mantenere separate tali decisioni. Questi meccanismi inducono a considerare una sola dimensione nella separazione dei concetti: tale dimensione si rivela quindi dominante nei confronti delle altre; questo effetto viene chiamato tirannia della decomposizione dominante [19]. In [9], Kiczales et al. analizzano il problema e propongono una possibile soluzione nella forma di un nuovo paradigma di programmazione: We present an analysis of why some code decisions have been so difficult to cleanly capture in actual code. We call the issues these decisions address aspects, and show that the reason they have been hard to capture is that they cross-cut the system s basic functionality. We present the basis for a new programming technique, called Aspect-Oriented Programming, that makes it possible to clearly express programs involving such aspects, including

53 4.4. Process Runtime Modifier 52 appropriate isolation, composition and reuse of the aspect code. [19] Mediante l utilizzo di tale approccio è effettivamente possibile identificare ed isolare oltre che a livello di design, anche a livello implementativo le funzionalità che interessano in modo trasversale il resto del sistema. Queste parti sono dette cross-cutting e vengono raggruppate in aspetti. Gli attuali linguaggi di programmazione ad oggetti e le relative tecniche di design non dispongono di meccanismi adeguati a supportare la separazione di concetti cross-cutting, tendendo a disperdere le parti trasversali all interno degli altri componenti del sistema. Poiché però A design process and a programming language work well together when the programming language provides abstraction and composition mechanisms that cleanly support the kinds of units the design process breaks the system into. [19] ne deriva che l approccio AOP, fornendo meccanismi di astrazione e di composizione adatti alla gestione dei concetti trasversali, rappresenta un buon candidato per gestire tali problematiche. L Aspect-Oriented Programming tenta di superare le limitazioni appena citate, introducendo nuovi concetti [9] e meccanismi di composizione che sono applicabili in linea di principio ai Generalized Procedure Languages 3, anche se i linguaggi orientati agli oggetti sono quelli che meglio si prestano a supportare la programmazione in stile Aspect-Oriented [10]. 3 Come si afferma in [9], molti dei linguaggi di programmazione esistenti (tra cui i linguaggi orientati agli oggetti, procedurali e funzionali) hanno interazioni basate su una qualche forma generica di procedura. I linguaggi appartenenti a questo insieme vengono quindi definiti come Generalized Procedure Languages.

54 4.4. Process Runtime Modifier 53 In seguito verranno presentate le astrazioni concettuali alla base dell approccio Aspect-Oriented: inizialmente si analizzerà come AOP si relaziona con OOP e successivamente verranno presentati i nuovi concetti introdotti dall approccio. Componenti, aspetti, weaving Un generico sistema software può essere suddiviso in parti più semplici dette componenti che possono essere viste come fornitori di risorse computazionali o servizi [5]. In particolare devono soddisfare requisiti di località e di facilità di accesso e composizione [9]. Come precedentemente detto, la modularizzazione di un sistema in componenti secondo l approccio OOP può comportare dispersione del codice relativo a requisiti che hanno impatto su più componenti e che quindi non può essere isolato o incapsulato in uno specifico componente. Per migliorare la qualità e facilitare la manutenzione del sistema, è utile aggregare in un unico punto il codice che implementa una funzionalità trasversale (cross-cutting): con l approccio AOP sono stati resi disponibili i meccanismi adatti a mantenere coesi anche in fase di design componenti che invece l approccio OOP tende a disperdere. A tal proposito AOP definisce un aspetto come un requisito a livello di design che ha impatto ortogonale al livello d implementazione. Ad esempio, trovandosi nella necessità di implementare la funzionalità di logging per un applicazione complessa, il codice relativo andrebbe disperso all interno del resto dell applicazione. E quindi conveniente raggruppare il codice deputato alla gestione del logging in un unico aspetto, che risulta quindi agire sui diversi componenti dell applicazione. Raggruppando in questo modo i concetti trasversali è possibile incapsulare nei componenti unicamente il codice relativo alla realizzazione delle

55 4.4. Process Runtime Modifier 54 Figura 4.5: Weaving tra aspetti e componenti specifiche della decomposizione dominante. Così facendo, tuttavia, il sistema risulta incompleto, in quanto tutte le funzionalità relative ai concetti trasversali sono separate negli aspetti. Gli attuali ambienti di esecuzione non supportano il paradigma AOP: non riescono infatti ad eseguire nativamente un aspetto. E quindi necessario tradurre il sistema ottenuto mediante la modularizzazione ad aspetti in un programma effettivamente eseguibile dall ambiente di esecuzione prescelto: tale operazione è definita weaving. Essa consiste nell inframmezzare il codice degli aspetti nel codice dei componenti in base a particolari regole, come mostrato in Figura 4.5. Join point model L interazione tra aspetti e componenti si basa sul concetto di join point, che è un punto ben definito nell esecuzione di un componente [11]. Considerando il grafo di esecuzione di un programma, un join point è un nodo appartenente

56 4.4. Process Runtime Modifier 55 a tale grafo; esempi di questi nodi possono essere i punti in cui un oggetto riceve una chiamata ad un suo metodo, in cui effettua una chiamata ad un altro metodo o ancora in cui accede a un qualche campo. Gli archi di tale grafo costituiscono le relazioni del flusso di controllo tra i diversi nodi. In questo modello il control flow attraversa ciascun nodo due volte: la prima all inizio dell elaborazione individuata dal join point e la seconda alla fine di tale computazione. E possibile raggruppare insiemi coerenti di join point in pointcut; questi consentono di selezionare gruppi di nodi di interesse per il programmatore. A ciascun pointcut è possibile associare un advice, che specifica il comportamento dell aspetto da applicarvi. Di seguito verranno approfonditi i concetti di pointcut e advice. Un pointcut permette di individuare un insieme di punti precisi nell esecuzione di un componente (un insieme di join point). Esempi di pointcut possono essere le chiamate ad un particolare metodo, gli accessi ad uno specifico campo di un componente o ancora le invocazioni di un costruttore. Oltre a definire l insieme di join point, un pointcut ha anche accesso al loro contesto di esecuzione. In questo modo è possibile effettuare ulteriori discriminazioni sulla scelta dei join point (ad esempio le chiamate ad un particolare metodo i cui parametri soddisfino determinate condizioni). La granularità con cui è possibile definire un join point dipende dalla scelta del particolare framework AOP. Un advice è un costrutto utilizzato per collegare un determinato comportamento di un aspetto a ciascun join point individuato da un particolare pointcut. La definizione di un advice si compone quindi di due parti: una specifica il comportamento dell aspetto, mentre l altra indica se tale comportamento debba essere inserito prima, dopo, o al posto dei join point

57 4.4. Process Runtime Modifier 56 individuati Descrizione del componente Per poter implementare le funzionalità di questo componente si è dovuto modificare il motore ActiveBPEL. Figura 4.6: ActiveBPEL Visione ad alto livello dell organizzazione delle classi nel motore Ogni volta che viene eseguita una nuova istanza del processo, il motore crea una rappresentazione dello stato dell esecuzione e delle attività da eseguire. Nella Figura 4.6 è schematizzata una visione ad alto livello della struttura utilizzata da ActiveBPEL per supportare le istanze in esecuzio-

58 4.4. Process Runtime Modifier 57 ne. Quest ultimo, durante la fase di deploy del processo, effettua il parsing dei file XML (richiesti per la fase di deploy), creando la struttura gerarchica appena introdotta. Questa verrà successivamente utilizzata per la creazione delle istanze del processo. L attività principale è rappresentata dalla classe AeBusinessProcess (Process), all interno della quale ci sono i riferimenti alle liste delle variabili, partnerlink e correlationsets. Ogni attività del linguaggio BPEL viene rappresentata dal motore ActiveBPEL attraverso la classe AeActivityImpl, la quale viene estesa da altre classi, ognuna delle quali implementa una attività specifica. Ad esempio, la Figura 4.6 mostra le classi: AeActivitySequenceImpl (Sequence), AeActivityReceiveImpl (Receive), AeActivityInvokeImpl (Invoke) e AeActivityReplyImpl (Reply). Le classi che rappresentano le attività sono collegate tra di loro attraverso una struttura gerarchica. La classe AeBusinessProcess rappresenta un attività la quale si differenzia dalle altre solo dal fatto che è l attività radice del processo e quindi non è contenuta in nessun altra attività. Come si vede in Figura 4.6 l AeBusinessProcess è il nodo radice e può contenere una sola attività, invece le seguenti attività hanno sia il riferimento al padre, sia il riferimento alla lista contenente tutte le sotto-attività. Come soluzione preliminare al problema di adattamento dinamico delle istanze del processo si è cercato di utilizzare il parser messo a disposizione dal motore ActiveBPEL. Tuttavia, in questo modo, non è possibile modificare la struttura precedentemente costruita, in quanto è necessario ricostruire tutta la struttura del processo, anche nel caso in cui si debba effettuare una semplice modifica. Infatti il parser è costruito in modo da poter partire solo dal nodo radice (AeBusinessProcess), per poi collegare i nodi successivi. Di conseguenza per poter adottare questa soluzione bisogna prima di tutto modificare staticamente i file XML del processo BPEL e successivamente fare

59 4.4. Process Runtime Modifier 58 il parsing dei file modificati, comportando uno spreco inutile di risorse. Figura 4.7: Aspetto Instrumentations Nella soluzione adottata si utilizza l aspetto schematizzato in Figura 4.7. Per ogni modifica di aggiunta di ogni specifica attività del processo è stato implementato un metodo privato (aggiungi* ). Ognuno di questi metodi richiede in ingresso i parametri seguenti: una stringa contenente il nome dell attività target, una stringa contenente l XML dell attività inserire e l attività padre. Inoltre è stato implementato un metodo generico per la rimozione di ogni attività del processo (rimuoviattività). Il pointcut activityexecuted intercetta l esecuzione di ogni singola attività. Di conseguenza nell advise associato a questo pointcut si effettua una interrogazione al Changes Repository per richiedere se sia necessario effettuare modifiche in quel punto dell esecuzione del processo. In generale, nel caso in cui sia necessario effettuare delle modi-

60 4.4. Process Runtime Modifier 59 fiche, verrà chiamato uno dei metodi precedentemente introdotti (aggiungi* e rimuoviattività). Nel seguito si mostra il codice sorgente del pointcut e dell advice appena introdotti: pointcut activityexecuted(aeactivityimpl aeact): call(void execute()) && target(aeact); before(aeactivityimpl aeact): activityexecuted(aeact){} L attributo id identifica univocamente l istanza del processo da modificare all interno del motore BPEL. L attributo modeff è una HashMap che tiene traccia delle modifiche effettuate per ogni istanza del processo BPEL. La chiave di questa HashMap è una stringa composta dall attributo id e dal parametro cod adp della tabella AdaptationTable del Changes Repository. Quindi, prima di effettuare ogni modifica, il Process Runtime Modifier controlla che non sia stata già effettuata una modifica, controllando che tale modifica non sia già presente nell HashMap modeff. Successivamente, a modifica effettuata, si inserisce un nuovo elemento in modeff. Il pointcut startprocess intercetta l avvio di ogni istanza e tramite l advise la segnala al Changes Repository, incrementando il campo che indica il numero delle istanza attive per la versione del processo utilizzata per questa istanza. Inoltre all interno di questo advice viene lanciato un thread che si sveglia periodicamente per eliminare le vecchie versioni, non più utilizzate, dei processi disponibili sul motore BPEL. Di seguito si riporta il codice sorgente dell advice e del pointcut appena introdotti: pointcut termprocess(aebusinessprocess process): execution(public void AeBusinessProcess.processEnded(IAeFault)) && target(process); after (AeBusinessProcess process): termprocess(process){}

61 4.5. Coordinator Modifier 60 Infine il pointcut termprocess intercetta la fine dell esecuzione di ogni istanza e tramite l advice la segnala al Changes Repository, decrementando il numero delle istanze attive della versione del processo utilizzato per questa istanza. Di seguito si riporta il codice sorgente dell advice e del pointcut appena introdotti: pointcut startprocess(aebusinessprocess process): execution(public void AeBusinessProcess.execute()) && target(process); before (AeBusinessProcess process): startprocess(process){} 4.5 Coordinator Modifier L unica maniera per accedere alle funzionalità di DyBPEL è attraverso questo componente. Il Coordinator Modifier espone un interfaccia WSDL, attraverso la quale è possibile indicare le modifiche da effettuare sui processi BPEL. L interfaccia WSDL del Coordinator Modifier è visualizzata in Figura 4.8. Questo componente espone solo l operazione modificaop, la quale ha come parametri di ingresso: nome del processo BPEL (nomeprocesso); tramite il quale viene identificato univocamente il processo; un insieme di operazioni (operazioniarray): specifica le modifiche da effettuare nel processo (aggiunta variabile, aggiunta di un attività, ecc.); un insieme di attributi (attributiarray): specifica delle informazioni aggiuntive necessarie per descrivere completamente le azioni individuate dal parametro precedente. Per esempio per una azione che aggiunge

62 4.5. Coordinator Modifier 61 una variabile, si dovranno specificare il nome e il tipo della variabile nell insieme degli attributi. Inoltre restituisce un stringa (risposta) nel quale indica se l operazione di modifica è andata a buon fine. Il Coordinator Modifier quindi si occupa soltanto di ricevere i parametri in ingresso, per poi distribuirli ai componenti a valle. Figura 4.8: Visione ad alto livello dell interfaccia esposta dal servizio CoordinatorModifier

63 Capitolo 5 Caso d uso In questo capitolo si presenta un applicazione di DyBPEL ad un caso di studio, con l obiettivo di descrivere il funzionamento e l utilizzo degli strumenti messi a disposizione per l attuazione delle strategie di adattamento ad un esempio reale. Nel primo paragrafo si descrive il caso di studio, illustrando i processi e i servizi coinvolti. Nel secondo paragrafo si descrivono le possibili operazioni di modifica da applicare nel caso d uso. Infine nell ultimo paragrafo si analizzano le prestazioni dei singoli componenti di DyBPEL. 5.1 News Provider Il caso di studio rappresenta un servizio che recupera e aggrega le notizie. Tale servizio permette all utente di ottenere le anteprime delle notizie, effettuare la registrazione, effettuare il login (nel caso in cui l utente sia già registrato) e visualizzare le notizie (solo dopo previa autenticazione). Se l utente sceglie di registrarsi al servizio, verranno richiesti i suoi dati, tra cui

64 5.1. News Provider 63 nome utente e password. Successivamente, verrà richiesto all utente di effettuare il login e, una volta effettuato il login, l utente può visualizzare le notizie presenti sul servizio ed effettuare il logout. Sono state previste due modalità di erogazione delle notizie: testo con relativa immagine o solo testo. Quest ultima modalità essendo meno dispendiosa in termini di banda consumata, è utilizzata solo in caso di rallentamenti da parte del servizio..../axis/services/newssrcport?wsdl Web Service News (With Image) News DB.../active-bpel/services/NewsProvider?wsdl.../axis/services/NewsSrc2Port?wsdl Client News Provider Web Service News (Without Image) Login DB.../axis/services/UserManagerPort?wsdl Web Service Login Figura 5.1: Visione ad alto livello dell architettura del caso d uso In Figura 5.1 è schematizzata una visione ad alto livello dell architettura del caso d uso. Il componente NewsProvider è il processo principale che si occupa delle gestione del servizio di news. Esso è modellato come un processo BPEL: gestisce le richieste degli utenti e coordina i servizi web a valle. Inoltre espone un interfaccia WSDL verso i clienti, con cinque operazioni possibili: PreviewOpC : restituisce le anteprime delle ultime notizie disponibili; LoginOpC : permette all utente di effettuare il login; RegisterOpC : supporta la registrazione di nuovi utenti; NewsOpC : restituisce un particolare notizia richiesta; LogoutOpC : permette all utente di effettuare il logout.

65 5.1. News Provider 64 Il NewsProvider utilizza tre web service. Il web service WebServiceLogin fornisce al NewsProvider le operazioni di login e di registrazione dell utente, utilizzando un apposito data base per memorizzare i dati degli utenti (LoginDB). Invece il web service NewsSrcPort espone al NewsProvider due operazioni: anteprimaop fornisce solo l anteprima della notizia, mentre notiziaop fornisce sia l intera notizia che la sua relativa immagine. Infine il web service NewsSrc2Port viene utilizzato solo nel caso in cui si vogliano fornire le notizie in modalità testuale senza le immagini. Il motore ActiveBPEL offre una console di amministrazione che permette di visualizzare i processi disponibili all interno del motore, mostrandone la loro definizione graficamente. Di seguito si spiegherà in dettaglio il funzionamento del NewsProvider, mostrando le diverse parti della rappresentazione grafica del processo in questione. Figura 5.2: Visualizzazione grafica della prima parte della definizione del processo NewsProvider

66 5.1. News Provider 65 In Figura 5.2 si mostra un frammento della definizione del processo BPEL. Se l esecuzione del processo è nel ciclo G11While, l utente può interagire con il servizio di news richiedendo le anteprime delle notizie, effettuando la registrazione o il login. Negli ultimi due casi, dopo aver concluso l operazione di registrazione o di login, viene eseguita un operazione di break la quale interrompe il ciclo G11While. In Figura 5.3 si mostra la seconda parte del processo BPEL. L esecuzione del processo può raggiungere questo punto solo se l utente si è appena registrato (il flusso d esecuzione è entrato in RegisterSeq). Tale frammento permette di effettuare la fase di login. Figura 5.3: Visualizzazione grafica della seconda parte della definizione del processo NewsProvider In Figura 5.4 è mostrata la terza e ultima parte del processo BPEL. Se il flusso d esecuzione è entrato in G13Seq l utente può effettuare la richiesta di notizie (ReqNewsSeq) o effettuare il logout LogoutSeq. Se effettua il logout, può successivamente richiedere le anteprime delle notizie o rieffettuare il login, permettendo all utente di richiedere le notizie.

67 5.2. Operazione di modifica 66 Figura 5.4: Visualizzazione grafica della terza parte della definizione del processo NewsProvider 5.2 Operazione di modifica Una possibile modifica sul processo BPEL (NewsProvider) può essere la sostituzione dell attività ReqNewsInv che invoca l operazione notiziaop dal servizio NewsSrc, con l attività che invoca la stessa operazione sul servizio NewsSrc2. Questa è una modifica necessaria quando ci sono molte utenze

68 5.2. Operazione di modifica 67 sul servizio, o magari quando il server su cui risiede il servizio è rallentato per varie cause, o ancora per motivi di lentezza nella trasmissione. Per effettuare tale modifica l amministratore del servizio deve interagire con il Coordinator Modifier inviando i dati necessari per effettuare sia la modifica di aggiunta della nuova attività, che la modifica di rimozione dell attività da sostituire. Di seguito i primi tre parametri sono relativi modifica di aggiunta, gli ultimi due alla modifica di rimozione: l XPath che identifica l attività del processo BPEL da intercettare per effettuare la modifica di aggiunta, in questo caso../invoke[@name= ReqNewsInv ]; l XPath che identifica l attività del processo BPEL dopo la quale inserire la nuova attività, in questo caso../invoke[@name= ReqNewsInv ]; l XML della nuova attività da inserire: <invoke name="reqnewsinv2" inputvariable="newsrequest" operation="newsop" outputvariable="newsresponse" partnerlink="newssrc2" porttype="lns:newssrc2pt"> <correlations> <correlation set="trace" initiate="no" pattern="request-response"/> <correlations> <invoke> l XPath che identifica l attività del processo BPEL da intercettare per effettuare la modifica di rimozione, in questo caso../invoke[@name= ReqNewsInv ]; l XPath che identifica l attività da rimuovere, in questo caso../invoke[@name= ReqNewsInv ]. Ricevuti questi dati il Coordinator Modifier chiama il metodo modifica 1 del Bpel Modifier, per creare una nuova versione del processo BPEL NewsPro- 1 Si veda capitolo 4

69 5.2. Operazione di modifica 68 vider. Inoltre inserisce due nuovi record, uno per ogni modifica effettuata, nella tabella AdaptationTable del Changes Repository. Il Bpel Modifier richiede al Changes Repository le informazioni essenziali per la creazione di una nuova versione del NewsProvider, come l URL del file.bpel da modificare. Successivamente il Bpel Modifier modifica direttamente l XML di tale file, sostituendo la parte dell XML evidenziata in Figura 5.5 con l XML della nuova attività. Infine il Bpel Modifier effettua il deploy della nuova versione del processo NewsProvider e comunica al Changes Repository la disponibilità di tale versione. Figura 5.5: Frammento dell XML del file.bpel del NewsProvider Il Process Runtime Modifier intercetta l esecuzione di ogni attività che viene eseguita dal motore BPEL, e per ognuna di esse controlla se esiste uno o più record con il campo at intercettare 2 della tabella AdaptationTable del Changes Repostory che corrisponde all XPath dell attività intercettata. Nel nostro caso, quando l esecuzione del processo arriva all attività ReqNewsInv evidenziata in Figura 5.6, il Process Runtime Modifier la sostituisce 2 Si guardi la Figura 4.3 del capitolo 4

70 5.2. Operazione di modifica 69 con la nuova invoke. Questa nuova attività (ReqNewsInv2 ) a differenza della vecchia, invoca il web service NewsSrc2Port il quale fornisce le notizie in modalità testuali senza le immagini. Figura 5.6: Frammento della definizione del processo BPEL precedente alla modifica Nella Figura 5.7 è visualizzata la definizione del processo BPEL nell istante successivo della modifica. Figura 5.7: Frammento della definizione del processo BPEL successivo alla modifica

71 5.3. Analisi delle prestazioni Analisi delle prestazioni Per verificare l effettiva usabilità dell approccio presentato in questo lavoro di tesi, sono state analizzate le prestazioni di DyBPEL. In particolare, sono stati calcolati i tempi necessari per l esecuzione della modifica appena citata sul processo BPEL, al fine di quantificare l impatto sulle prestazioni del servizio sul processo stesso. Per distinguere l impatto delle modifiche statiche da quelle dinamiche si è preferito suddividere i risultati ottenuti in due tabelle differenti. La Tabella 5.1 mostra i valori di media, mediana e varianza del tempo d esecuzione del Coordinator Modifier e del BPEL Modifier. Questi tempi sono strettamente legati, in quanto tempo impiegato dal BPEL Modifier è una porzione di quello impiegato dal Coordinator Modifier. I tempi di questa tabella vengono calcolati eliminando il tempo dovuto alla trasmissione dei messaggi SOAP. Media [s] Mediana [s] Varianza Coordinator Modifier 0,1515 0,141 0, Bpel Modifier 0,1302 0,115 0, Tabella 5.1: Analisi delle prestazioni del Coordinator Modifier e del Bpel Modifier Nella Tabella 5.2 vengono visualizzati i tempi relativi all esecuzione dell operazione di richiesta della notizia (NewsOpC ). Il tempo della NewsOpC comprende oltre al tempo di esecuzione delle attività che compongono tale operazione (ReqNewsSeq, ReqNewsInv, ReqNewsRep, G13While e G13Pick), anche i tempi dovuti alla modifica introdotta nel paragrafo precedente e al monitoring di ogni attività che compone l operazione di NewsOpC. Anche se la modifica del processo viene effettuata durante l attività ReqNewsInv, il

72 5.3. Analisi delle prestazioni 71 Process Runtime Modifier consuma delle risorse per intercettare l esecuzione di ogni attività e di conseguenza per controllare sul Changes Repository se si devono effettuare delle modifiche sull attività intercettata. Il tempo impiegato per effettuare tali operazioni prende il nome di tempo di monitoring. Nel dettaglio la Tabella 5.2 mostra i valori di media, mediana e varianza del tempo totale d esecuzione dell operazione di richiesta, della somma dei tempi di monitoring delle attività e dell operazione di modifica. Media [s] Mediana [s] Varianza Monitoring 0,0463 0,045 0, Modifica 0,0198 0,019 0, NewsOpC 0,2472 0,2485 0, Tabella 5.2: Analisi delle prestazioni Process Runtime Modifier Si può notare che i tempi di modifica dinamica a tempo d esecuzione sono trascurabili (circa 19%), infatti il tempo impiegato per eseguire tale modifica è molto più basso rispetto all esecuzione dell attività stessa (circa 8%).

73 Capitolo 6 Stato dell arte Il problema di adattamento dei processi BPEL è stato ampiamente investigato in letteratura. In questo capitolo si presentano i lavori di ricerca attualmente più significativi che forniscono una soluzione all adattamento dei processi di business, o, in particolare dei web service. Per fornire un quadro generale dello stato dell arte, si è preferito selezionare approcci molto diversi fra di loro, sia dal punto di vista delle problematiche affrontate che dal punto di vista delle soluzioni adottate. Prima di spiegare in dettaglio ogni approccio selezionato, nella tabella 6.1 vengono introdotte le operazioni di modifica supportate da ogni approccio descritto (X indica che la modifica è completamente supportata, N indica che la modifica non è supportata, infine P indica che modifica è parzialmente supportata). Inoltre tutti gli approcci descritti in questo capitolo permettono una modifica solo temporanea delle attività del processo BPEL, mentre DyBPEL oltre a supportare la modifica dinamica delle istanze già in esecuzione, crea dinamicamente una nuova versione del processo BPEL e la rende disponibile in maniera trasparente per le istanze future. 72

74 6.1. WAWSO 73 Attività [s] Variabili [s] PartnerLink DyBPEL X X X WAWSO X X X AO4BPEL P - - Dynamo P - X SHIWS P P - AOFSA P X - Tabella 6.1: Confronto delle possibili operazioni di modifica in un processo BPEL tra DyBPEL e gli approcci studiati Di seguito si spiegheranno e si confronteranno i lavori scelti con quello svolto in questa tesi. 6.1 WAWSO Gli autori di WAWSO (Weawing Aspect into Web Service Orchestration) [7] sostengono che per rendere un processo più flessibile, in modo da soddisfare le esigenze di nuovi clienti e delle condizioni di mercato, si devono rispettare due requisiti: consentire la modifica dinamica e l esecuzione di codice all interno dei processi BPEL. Per risolvere questi problemi gli autori propongono di utilizzare gli aspetti sul motore BPEL. Questi aspetti devono poter essere inseriti dinamicamente, in quanto non possono essere previsti al momento del deploy, e inoltre devono essere facilmente disattivati in qualsiasi momento per motivi di prestazioni. Con questa tecnica, nuovi comportamenti (specifiche o funzioni) possono essere aggiunti ai processi di business durante la fase di esecuzione.

75 6.1. WAWSO 74 Inoltre per facilitare il lavoro agli utenti meno esperti, gli autori scelgono di sviluppare un linguaggio che supporta gli aspetti dedicato a BPEL. I pointcut sono identificati tramite l XPath mentre gli advice sono espressi direttamente in linguaggio BPEL. Con questo meccanismo, le istruzioni BPEL possono essere inserite, eliminate o sostituite come anche partnerlink, variabili, eccezioni, compensation handler e fault handler. Le potenzialità che presenta questo approccio sono comparabili con quelle presentate nel lavoro svolto nel corso di questa tesi. Infatti entrambi gli approcci permettono di inserire, eliminare o sostituire attività, variabili, partnerlink, ecc. in maniera dinamica all interno del flusso d esecuzione del processo BPEL. Le soluzioni adottate sono però totalmente differenti. In quanto WAWSO è un motore BPEL molto primitivo: esso implementa solo alcune funzionalità di base del linguaggio BPEL ed è ancora in uno stadio prototipale. Invece nella soluzione proposta in questa tesi è stato modificato direttamente il motore ActiveBPEL, che supporta tutte le funzionalità del linguaggio BPEL ed è un prodotto già utilizzato in ambito sia di ricerca che industriale. Inoltre anche le modalità con cui è stato affrontato il problema sono molto diverse. WAWSO necessita di creare un nuovo aspetto ed effettuarne il weaving per ogni modifica da applicare sul processo BPEL. DyBPEL, invece, prevede un unico aspetto che intercetta ogni attività eseguita dal processo e verifica (sul Changes Repository) se e quali modifiche è necessario applicare sul processo a partire da quella attività. In tal caso, la modifica richiesta viene applicata opportunamente.

76 6.2. AO4BPEL: An Aspect-oriented Extension to BPEL AO4BPEL: An Aspect-oriented Extension to BPEL AO4BPEL [6] si propone di risolvere due problemi fondamentali. Il primo problema è dovuto alla mancanza di un meccanismo per definire dei crosscutting concern (logging, sicurezza, persinstenza) nel linguaggio BPEL. Il secondo problema è dovuto alla mancanza di un supporto appropriato per l adattamento dinamico della composizione all interno del linguaggio BPEL. AO4BPEL è implementato come una estensione che può adattarsi a qualsiasi motore BPEL. Il prototipo implementato permette di effettuare il weaving solo in corrispondenza di tre attività (invoke, receive, reply). L architettura del prototipo implementato è mostrata in Figura 6.1. Essa estende un motore BPEL con un componente chiamato aspect runtime, il quale costruisce un involucro intorno al BPEL interpreter. Il motore offerto da AO4BPEL chiama l aspect runtime per controllare se ci siano advice prima o dopo di ogni attività. Per fare questo, il BPEL interpreter manda i dati dell attività in esecuzione (nome del processo, varabili, nome dell attività, attività padre, ecc.) all aspect runtime. Quest ultimo mantiene una lista di tutti gli aspetti disponibili e per ogni attività eseguita dal BPEL interpreter controlla se corrisponde a uno o più pointcut dichiarati. In questo caso, l aspect runtime esegue l advice associato al pointcut indicato. L aspect deployment tool è una web application che permette di effettuare il deploy, l undeploy e di elencare tutti gli aspetti attualmente disponibili. Questo permette all utente di capire e prevedere il comportamento del processo modificato. Il problema dell adattamento dinamico viene affrontato in maniera simile nei due approcci proposti (AO4BPEL e DyBPEL), in quando si effet-

77 6.3. Dynamo 76 Figura 6.1: Architettura di AO4BPEL tua un estensione del motore BPEL utilizzando gli aspetti. Tuttavia DyB- PEL supporta un numero maggiore di modifiche rispetto a quelle offerte da AO4BPEL che permette di modificare solo l invoke, la receive e la reply. Infine AO4BPEL non prevede nessuna modifica sulle variabili e partnerlink, argomento che è stato affrontato nel corso di questa tesi. 6.3 Dynamo Dynamo [4] si propone come soluzione ai problemi di inaffidabilità dei web service. Questi sono dovuti alla natura distribuita dei processi BPEL e dal fatto che i servizio partner possono cambiare dinamicamente le loro funzionalità e/o i loro parameri di qualità del servizio. Non si può quindi escludere a priori che la cooperazione tra le parti coinvolte non possa avere qualche errore imprevisto. Per risolvere questo problema Dynamo definisce due nuovi linguaggi. Il WSCoL (Web Service Constraint Language) usato per definire le regole con cui i processi dovranno essere monitorati e WSRel (Web Service Reaction

78 6.4. SHIWS 77 Language) usato per definire le strategie di recovery. Dynamo propone un framework composta da tre componenti principali: l execution engine, basato su una versione modificata di ActiveBPEL con AspectJ, il sottosistema di monitoraggio e recovery. Dynamo è unicamente finalizzato alla risoluzione dei problemi legati all interazione tra processo BPEL e servizi esterni. Per questo motivo esso permette di intercettare solo le attività di Invoke, Receive e Pick. Le possibili modifiche che Dynamo permette di su queste attività del processo sono: sostituzione del partnerlink dell attività intercettata, riesecuzione (fino ad un certo numero di volte) dell ultima operazione di invoke fatta, invocazione di un web service esterno indicato opportunamente ed esecuzione di un eventhandler precedentemente definito nel processo BPEL. Il problema della flessibilità di un processo BPEL viene affrontato in maniera simile dai due approcci proposti (Dynamo e DyBPEL). Infatti entrambi gli approcci estendono il motore ActiveBPEL con AspectJ, permettendo in questo modo di poter monitorare l esecuzione del processo BPEL e cambiarne l esecuzione a runtime. Tuttavia Dynamo, rispetto a DyBPEL, intercetta solo un insieme limitato delle attività presenti in BPEL e mette a disposizione delle azioni di recovery limitate. 6.4 SHIWS SHIWS (Self Healing Integrator for Web Services) [8] si propone di risolvere i problemi dovuti alla incoerenza tra web service richiedenti e fornitori. Per affrontare questo problema SHIWS mette a disposizione il ciclo di adattamento mostrato in Figura 6.2. L invocazione di un web service innesca un monitor mechanisms che verifica se l implementazione dei servizi è

79 6.4. SHIWS 78 cambiata dall ultima invocazione. Se l implementazione del servizio è cambiata, il diagnosis mechanism lancia una serie di test per rilevare le possibili differenze. Se il diagnosis mechanism rileva qualche differenza, allora l adaptation mechanisms esegue la strategia di adattamento associata alla differenza trovata per risolvere i problemi. Figura 6.2: Il ciclo di controllo di adattamento proposto da SHIWS Il ciclo di controllo è istanziato per ogni insieme di servizi che rispettano uno specifico contratto. La personalizzazione consiste in una serie di test che possono rilevare le discordanze tra le differenti implementazioni dello stesso contratto e una serie di strategie di adattamento per classificare le possibili discordanze. SHIWS permette allo sviluppatore di proporre una serie di metodi di adattamento per ogni discordanza che si può verificare a tempo d esecuzione. Le possibili discordanze sono dovute a differenze di: cardinalità di parametri,