Un metodo non intrusivo per l’adattamento dinamico di ... · l’adattamento dinamico di processi BPEL Relatore: Prof. Luciano Baresi Correlatore: Ing. Liliana Pasquale ... 4.8

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 722538

Anno Accademico 2009-2010

Alla mia famiglia

Sommario

L’intento fondamentale per cui nasce questo lavoro e lo studio della possi-

bilita di superare i limiti posti dal linguaggio BPEL, dovuti alla staticita

intrinseca del linguaggio. Tale staticita e legata all’impossibilita di modifica-

re ulteriormente il processo dopo che ne e 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 du-

rante l’esecuzione di un processo. Inoltre data la forte dinamicita con cui

evolve un processo di business, e impossibile prevedere a priori i suoi futuri

cambiamenti.

Tale concetto si concretizza nello sviluppo di un componente, chiama-

to 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

del processo in esecuzione.

Indice

Elenco delle figure 7

Elenco delle tabelle 9

1 Introduzione 10

2 Analisi del Problema 13

2.1 I processi di business e le SOA . . . . . . . . . . . . . . . . . . 14

2.2 Service Oriented Architecture . . . . . . . . . . . . . . . . . . 15

2.2.1 Caratteristiche delle SOA . . . . . . . . . . . . . . . . 16

2.2.2 Web Service . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2.3 Enterprise Service Bus . . . . . . . . . . . . . . . . . . 20

2.3 BPEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3.1 Caratteristiche principali . . . . . . . . . . . . . . . . . 21

2.3.2 Struttura di un processo BPEL . . . . . . . . . . . . . 22

2.4 Limiti del linguaggio BPEL . . . . . . . . . . . . . . . . . . . 25

3 Progettazione concettuale 29

3.1 Scenario applicativo e obiettivi . . . . . . . . . . . . . . . . . . 29

3.2 Prodotto finale e scelte implementative . . . . . . . . . . . . . 31

5

4 Implementazione di DyBPEL 34

4.1 Visione d’insieme . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2 Changes Repository . . . . . . . . . . . . . . . . . . . . . . . . 36

4.3 Bpel Modifier . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.3.1 Deploy di un processo . . . . . . . . . . . . . . . . . . 39

4.3.2 Descrizione del Bpel Modifier . . . . . . . . . . . . . . 48

4.4 Process Runtime Modifier . . . . . . . . . . . . . . . . . . . . 50

4.4.1 Aspect Oriented Programming . . . . . . . . . . . . . . 51

4.4.2 Descrizione del componente . . . . . . . . . . . . . . . 56

4.5 Coordinator Modifier . . . . . . . . . . . . . . . . . . . . . . . 60

5 Caso d’uso 62

5.1 News Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.2 Operazione di modifica . . . . . . . . . . . . . . . . . . . . . . 66

5.3 Analisi delle prestazioni . . . . . . . . . . . . . . . . . . . . . 70

6 Stato dell’arte 72

6.1 WAWSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

6.2 AO4BPEL: An Aspect-oriented Extension to BPEL . . . . . . 75

6.3 Dynamo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

6.4 SHIWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

6.5 AOFSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

7 Conclusioni 82

Bibliografia 84

Elenco delle figure

2.1 Modalita di interazione con un processo BPEL . . . . . . . . . 22

3.1 Architettura di DyBPEL . . . . . . . . . . . . . . . . . . . . . 30

3.2 Operazioni di modifica messe a disposizione da DyBPEL . . . 31

4.1 Diagramma di sequenza - Operazione di modifica . . . . . . . 35

4.2 Diagramma di sequenza - Interazione tra il Process Runtime

Modifier e il Changes Repository . . . . . . . . . . . . . . . . 37

4.3 Modello entita-relazione del database a supporto di DyBPEL . 38

4.4 Classe BpelModifier . . . . . . . . . . . . . . . . . . . . . . . . 49

4.5 Weaving tra aspetti e componenti . . . . . . . . . . . . . . . . 54

4.6 Visione ad alto livello dell’organizzazione delle classi nel mo-

tore ActiveBPEL . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.7 Aspetto Instrumentations . . . . . . . . . . . . . . . . . . . . 58

4.8 Visione ad alto livello dell’interfaccia esposta dal servizio Coor-

dinatorModifier . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.1 Visione ad alto livello dell’architettura del caso d’uso . . . . . 63

5.2 Visualizzazione grafica della prima parte della definizione del

processo NewsProvider . . . . . . . . . . . . . . . . . . . . . . 64

5.3 Visualizzazione grafica della seconda parte della definizione del


7

5.4 Visualizzazione grafica della terza parte della definizione del


5.5 Frammento dell’XML del file .bpel del NewsProvider . . . . . 68

5.6 Frammento della definizione del processo BPEL precedente

alla modifica . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.7 Frammento della definizione del processo BPEL successivo alla

modifica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

6.1 Architettura di AO4BPEL . . . . . . . . . . . . . . . . . . . . 76

6.2 Il ciclo di controllo di adattamento proposto da SHIWS . . . . 78

Elenco delle tabelle

5.1 Analisi delle prestazioni del Coordinator Modifier e del Bpel

Modifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.2 Analisi delle prestazioni Process Runtime Modifier . . . . . . . 71

6.1 Confronto delle possibili operazioni di modifica in un processo

BPEL tra DyBPEL e gli approcci studiati . . . . . . . . . . . 73

9

Capitolo 1

Introduzione

I web service sono applicazioni autonome e distribuite con le quali si puo

accedere interattivamente attraverso il web. I web service sono spesso com-

binati tra loro per offrire un servizio a valore aggiunto. Tale servizio e definito

come una composizione di servizi o come un processo. Date le caratteristiche

di flessibilita e facilita di sviluppo le composizioni di servizi sono state spesso

usate a supporto dei processi di business aziendali.

Uno dei paradigmi piu noti delle composizioni di servizi e 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 e

BPEL (Business Process Execution Language for Web Services, conosciuto

anche come BPEL4WS) [15].

L’obiettivo di questo lavoro di tesi e di superare i limiti del linguaggio

BPEL, dovuti alla staticita intrinseca del linguaggio. Tale staticita e legata

all’impossibilita di modificare ulteriormente il processo dopo che ne e 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

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 dinamicita con cui evolve un processo di business, e 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 e compo-

sta da due sotto-soluzioni piu 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 e stato necessario aggiungere delle funzio-

nalita 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 e pensato di unire queste funzionalita in un unico componente, DyBPEL

(Dynamic BPEL).

La tesi e organizzata come segue. Nel capitolo 2 si introducono i proces-

si 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 funzionalita. Il capitolo 4 e totalmente dedicato alla descri-

zione 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 piu significativi che forniscono una

soluzione all’adattamento dei processi di business, e confronta le differenze

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.

Capitolo 2

Analisi del Problema

Uno dei punti di forza delle aziende di successo e la capacita di modificare

i propri processi di business a seconda delle esigenze del mercato. In que-

sto 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 e supportata dalle architetture orientate ai servizi (Ser-

vice 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 piu utilizzati per rappresentarle e 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 caratteri-

stiche e i componenti. Infine, si introduce il linguaggio BPEL, analizzandone

non solo le sue potenzialita ma soprattutto, i suoi limiti.

13

2.1. I processi di business e le SOA 14

2.1 I processi di business e le SOA

Un processo di business rappresenta un insieme di attivita 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 aggre-

gazioni di attivita finalizzate al raggiungimento di uno stesso obiettivo. Per

esempio, tutte le attivita svolte per trasformare le materie prime in prodotti

finiti costituiscono il processo di produzione.

L’esigenza di gestire quantita 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 piu 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 posso-

no reagire istantaneamente ai cambiamenti degli obiettivi aziendali. Infatti

modificare un’applicazione e un lavoro difficile che richiede molto tempo.

Tale difficolta deriva dalla necessita di capire in che modo l’applicazione

puo rispecchiare tali cambiamenti. Inoltre, il tempo necessario per creare

una nuova versione dell’applicazione (implementare, testare e distribuire le

modifiche) non e trascurabile.

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 potenzialita per soddisfare tali requisiti e 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 com-

ponenti fondamentali i servizi.

Le SOA si prestano bene ad essere utilizzate a supporto dei processi di

business, infatti ogni servizio componente puo essere associato ad una o piu

funzionalita di tale processo. Ciascun servizio e 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 puo rap-

presentare qualsiasi tipo di logica incorporando tante sorgenti, inclusi altri

servizi.

Visto che le SOA sono una composizione di funzionalita (implementate dai

servizi), e possibile applicare delle modifiche, in maniera relativamente piu

semplice rispetto al modello classico di programmazione, cambiando le moda-

lita di interazione tra i servizi oppure aggiungendo/rimuovendo/modificando

i servizi componenti.

SOA non e un’architettura radicalmente nuova, ma piuttosto l’evoluzione

di architetture distribuite e metodi di integrazione ben noti: l’EAI (Enter-

price Application Integration) [27]. L’EAI cercava di unire diversi scenari di

business utilizzando specifiche interfacce application-to-application (A2A),


progettate con l’obiettivo di incrementare le performance e l’affidabilita. Tut-

tavia, l’EAI non ha prodotto un’architettura di integrazione che si sia dimo-

strata 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 interdi-

pendenza. A fronte di qualsiasi cambiamento era infatti necessario eseguire

attivita 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.

2.2.1 Caratteristiche delle SOA

Le SOA si basano su un principio dell’ingegneria del software chiamato sepa-

ration of concerns. Questo principio afferma che e conveniente separare un

problema complicato in una serie di problemi piu piccoli. In questo modo, la

logica richiesta per risolvere un problema viene decomposta e, di conseguenza,

puo diventare piu semplice.

Qui di seguito si analizzano singolarmente le caratteristiche delle SOA.

Composizione

Le SOA permettono di combinare dei componenti gia esistenti o implemen-

tati appositamente (servizi) per realizzare diverse funzionalita (processi di

business). Questo porta a degli effetti positivi in ambito dello sviluppo e del-

la manutenzione delle applicazioni, in quanto cambiare una o piu funzionalita

di un processo di business si riflette nella sostituzione di uno o piu servizi.

Grazie a questa caratteristica si ha una maggiore rapidita di risposta alle


esigenze e ai cambiamenti di business, e una riduzione dei costi di sviluppo

e manutenzione.

Riusabilita

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 riusabilita porta anche dei benefici sia in termini di riduzione

dei costi per nuovi sviluppi e per la manutenzione, sia in termini di aumento

della rapidita di risposta al business per le modifiche dei processi esistenti e

per l’implementazione di nuovi processi.

Condivisione contratto formale

Il contratto del servizio e una descrizione che affianca un servizio specifican-

done lo scopo, le funzionalita, i limiti e l’utilizzo. Essa e l’unica informazione

presentata all’utilizzatore del servizio e quindi deve essere il piu 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 spie-

ghi come un servizio possa svolgere un particolare compito. Poiche questo

contratto e condiviso con gli altri servizi il suo design e molto importante.

Gli utilizzatori di un servizio che accettano il contratto dipendono dalla sua


definizione, quindi e molto importante mantenerli aggiornati nel caso in cui

le funzionalita del servizio cambino.

Loose coupling

Il Loose coupling (accoppiamento lasco) rappresenta un condizione di “indi-

pendenza” tra cliente e fornitore. L’unica mutua conoscenza che entrambi

devono possedere per usare e fornire servizi e il contratto. Grazie a que-

sta 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 stes-

so. 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 imple-

mentate. Grazie a questo principio si puo implementare il servizio nella

maniera piu conveniente e chiunque puo utilizzarlo indipendentemente dalla

piattaforma hardware/software adottata.


2.2.2 Web Service

Anche se le SOA non sono legate ad alcuna specifica tecnologia, molto spes-

so e in maniera sempre piu 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 machine-

processable format (specifically WSDL). Other systems interact with the Web

service in a manner prescribed by its descriptions using SOAP messages, ty-

pically 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’interoperabilita 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 e

lo standard de-facto per l’integrazione di dati. Infine, utilizzano i messaggi

SOAP (Simple Object Access Protocol) [21] trasmessi tipicamente trami-

te 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 se-

guire protocolli differenti (one-way, request/response, solicit response, o no-

tification). 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-

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’implemen-

tazione del servizio, in quanto il software puo 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: e possibi-

le riutilizzare software implementato precedentemente e renderlo disponibile

attraverso la rete.

2.2.3 Enterprise Service Bus

Spesso nell’utilizzo dei web service si rende necessario un EBS (Enterprise

Service Bus). Un ESB e un’infrastruttura che aggiunge flessibilita di co-

municazione 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 e un linguaggio basato su XML, che descrive le attivita e le caratte-

ristiche 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 cooperazio-

ne di diverse componenti (web service), generando cosı dei servizi dal valore

aggiunto che mantengono le caratteristiche di modularita e scalabilita.

2.3. BPEL 21

2.3.1 Caratteristiche principali

BPEL supporta due modalita 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 intera-

gisce, 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 appar-

tenenza, 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 e un paradigma piu flessibile:

e possibile individuare esattamente l’unico processo responsabile dell’intera

composizione e l’inserimento/rimozione/modifica di un web service puo es-

sere effettuato in modo piu 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 fara riferimento

solo all’orchestrazione e quindi, ai processi eseguibili.

BPEL permette di definire un processo come insieme di web service colla-

boranti. Questo nuovo servizio a valore aggiunto e 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 fun-

zionamento del processo e deve essere interpretato ed eseguito da un or-

chestratore (motore BPEL). Cio che avviene e, quindi, una divisione del

processo secondo due punti di vista mostrati in Figura 2.1: quello dell’u-

tente del processo (a sinistra) che puo supporre di interagire con un singolo

servizio, e quello dei servizi cooperanti all’interno del processo (a destra)

2.3. BPEL 22

che, descrivendo le proprie funzionalita attraverso WSDL, verranno invocati

dall’orchestratore nei tempi e nei modi definiti all’interno del processo.

Figura 2.1: Modalita di interazione con un processo BPEL

Entrando in dettaglio, il processo essenzialmente e composto da attivita

che possono gestire richieste da parte del client del processo (attivita di re-

ceive/pick) oppure inviare messaggi di risposta al client medesimo (attivita

di reply). Per poter soddisfare tale richiesta il processo si basa, come si e

detto precedentemente, su una serie di web service esterni, chiamati servizi

partner, che possono essere invocati attraverso l’attivita di invoke.

2.3.2 Struttura di un processo BPEL

Di seguito si descrivono le attivita, specificate all’interno dello standard

BPEL, maggiormente utilizzate nel corso dello sviluppo della tesi.

Un processo BPEL non contiene solo le attivita che costituiscono il flusso

del processo, ma anche le informazioni necessarie per la definizione e l’esecu-

zione di tali attivita. Queste informazioni sono suddivise in vari gruppi:

• <import>: specifica i documenti WSDL e gli XML Schema utilizzati

dal processo;

2.3. BPEL 23

• <partnerLinks>: definisce le relazioni tra i vari servizi componenti

(servizi partner);

• <variables>: dichiara le variabili utilizzate. Esse possono rappresen-

tare 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 attivita di un processo BPEL definiscono il suo flusso d’esecuzione.

Esse possono essere catalogate in quattro macro gruppi:

• attivita di base: interagiscono con l’esterno, come la ricezione di mes-

saggi da parte del client e l’invocazione dei servizi web;

• attivita short-lived: hanno un’esecuzione di breve durata e possono

essere viste come operazioni atomiche;

• attivita strutturate: possono contenere al loro interno attivita appar-

tenenti a qualsiasi macro gruppo;

• attivita per la gestione degli errori.

Le attivita di base utilizzate nel corso della tesi sono:

• <receive>: attende un messaggio da parte di un servizio partner o

dal client. Inoltre ha la possibilita di iniziare un processo, creandone

una nuova istanza;

• <reply>: invia un messaggio di risposta al servizio partner che ha

inviato un richiesta al processo;

2.3. BPEL 24

• <invoke>: invoca un servizio partner per eseguire un’operazione. La

chiamata puo essere di tipo one-way oppure request/response.

Le attivita short-lived utilizzate nel corso della tesi sono:

• <assign>: puo 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 attivita strutturate sono:

• <sequence>: esegue le attivita contenute al suo interno sequenzial-

mente, nell’ordine in cui sono definite;

• <flow>: esegue tutte le attivita contenute al suo interno in parallelo;

• <while>: esegue un insieme di attivita ripetutamente, finche la con-

dizione specificata nel corpo del while non e piu verificata;

• <repeatUntil>: si comporta come l’attivita <while>, con l’unica

differenza che l’insieme di attivita viene eseguito almeno una volta,

perche la condizione e verificata alla fine dell’esecuzione del ciclo;

• <pick>: esegue un’attivita scelta in base al verificarsi di un deter-

minato evento. Puo anche iniziare un processo, creandone una nuova

istanza.

Le attivita 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>, pero gesti-

sce degli eventi attesi invece che degli errori;

2.4. Limiti del linguaggio BPEL 25

• <compensationHandler>: esegue una serie di attivita di compensa-

zione 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

staticita intrinseca del linguaggio.

Tale staticita e legata all’impossibilita di modificare ulteriormente il pro-

cesso dopo che ne e 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 e un guscio al cui interno ci sono tutte le attivita neces-

sarie a comporre diversi servizi sviluppati da terze parti. Ad un certo punto

dell’esecuzione del processo BPEL questi servizi potrebbero essere sogget-

ti a un cambiamento radicale o potrebbero non essere piu disponibili. La

disponibilita di un servizio puo variare per diverse ragioni [13]:

• le operazioni di deploy e di undeploy possono essere effettuate in qual-

siasi 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 va-

riazioni dopo la fase di deploy del processo di business (ad esempio

durante la composizione). Per questo motivo, le modifiche nell’imple-

mentazione delle loro interfacce potrebbero renderli inutili per gli obiet-

tivi che il sistema vuole raggiungere. Inoltre, potrebbe essere necessa-

ria una ricodifica di alcune parti della composizione per compensare i

cambiamenti;


• il nodo su cui e stato effettuato il deploy del servizio potrebbe esse-

re troppo carico o in manutenzione o la rete stessa potrebbe essere

sovraccarica o subire malfunzionamenti.

La staticita del linguaggio BPEL non e 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 ser-

vizio che non e disponibile;

• errori esterni: si manifestano quando ci sono inesattezze nell’imple-

mentazione 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 funzionalita corrette dando dei risultati sbagliati. Oppure possono

causare l’infrazione di vincoli piu sottili imposti da interazioni parti-

colari, 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 puo

essere individuata con esattezza;

• errori di QoS (qualita di servizio) [29]: sono determinati dall’infrazione

di requisiti/vincoli non funzionali definiti dal progettista del processo,

quali ad esempio banda, disponibilita, affidabilita, prezzo e molte altre

dimensioni di qualita del servizio. La violazione di tali requisiti e legata

all’assenza, da parte del progettista, di un controllo completo sull’ese-

cuzione del processo, e quindi di eventuali cambiamenti nelle proprieta

funzionali e non funzionali dei servizi utilizzati dal processo stesso.

Per descrivere i punti di debolezza finora citati, si usera un esempio. Si

suppone di avere un processo BPEL di prenotazione di viaggi aerei. Il pro-


cesso si aspetta in ingresso i dati del volo (citta di partenza e destinazione,

ecc.). La ricerca dei voli, invece, viene effettuata attraverso i web servi-

ce delle compagnie aeree associate al servizio in questione. Se ad un certo

punto una compagnia rescinde il contratto di collaborazione (o un’altra com-

pagnia stipula un contratto di collaborazione), lo sviluppatore non ha modo

di prevedere questo cambiamento e quindi non puo 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 possi-

bili senza riscrivere l’intero processo e senza quindi rideployarne una nuova

versione.

Anche se il linguaggio BPEL fornisce costrutti per la gestione di eccezio-

ni (<compensationHandler>, <faultHandlers> e <eventHandlers>), e

meccanismi di time-out (<onAlarm>), tali costrutti non risultano sufficien-

ti per gestire tutte le situazioni di errore che possono verificarsi durante

l’esecuzione di un processo di business. Infatti, le funzionalita di monito-

raggio 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 prece-

dente, lo sviluppatore potrebbe dotare il processo BPEL di un meccanismo

di time-out. Nel caso in cui uno dei servizi partner non sia momentaneamen-

te disponibile, non si otterra una risposta prima dello scadere del time-out.

Nonostante cio, non sarebbe comunque possibile conoscere le cause del pro-

blema: 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


complessa (data dalla limitazione del linguaggio stesso) e non flessibile (ogni

cambiamento richiederebbe una modifica del processo di BPEL e il suo ride-

ploy). 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, cioe durante l’effetti-

va esecuzione del processo. Questo componente deve assicurare una grande

flessibilita, offrendo la possibilita 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.

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 e 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 attivita,

variabili o servizi partner senza bloccare l’esecuzione delle istanze del pro-

cesso. 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 e schematizzata in Figura 3.1. Dopo un at-

tenta analisi del problema si e pensato di suddividere la soluzione proposta

3.1. Scenario applicativo e obiettivi 30

Figura 3.1: Architettura di DyBPEL

in due sotto-soluzioni piu 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 e stato necessario aggiungere

delle funzionalita al motore BPEL in maniera non intrusiva, utilizzando la

programmazione orientata agli aspetti. Inoltre DyBPEL espone un’inter-

faccia 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 attivita;

• rimuovere un’attivita esistente;

• aggiungere un servizio partner;

• rimuovere un servizio partner esistente.

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 funzionalita del componente Process Runtime Modi-

fier e stato necessario utilizzare AOP e in particolare la sua implementazione

AspectJ [26], in quanto il motore modificato e scritto in JAVA. Per la scelta

del motore da modificare e stata fatta una valutazione sui motori BPEL piu

conosciuti e utilizzati:

• ActiveBPEL Engine [1]: e il motore open source della Active Endpoints

sviluppato in Java;


• Apache ODE [18]: e il motore open source della Apache Software

Fondation sviluppato in Java;

• Oracle BPEL Process Manager [17]: e il motore di BPEL scritto in

Java della nota societa di sviluppo software ORACLE; a differenza dei

precedenti motori, non e open source.

Per lo sviluppo della tesi si e scelto ActiveBpel Engine. Il motore di ORA-

CLE non e stato preso in considerazione perche non e open source e quindi

non ne permetteva la personalizzazione. Tra i due restanti candidati, la scel-

ta finale e 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 funzionalita del componente Bpel Modifier e

stato utilizzato XMLBeans per il parsing e la modifica dei file XML

Infine il componente Coordinator Modifier e 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 e indipendente dalla piattaforma. Il Coordinator Modifier e deployato

all’interno dell’application server Tomcat [2]. Questa scelta e stata effettuata

per comodita d’implementazione, in quanto anche il motore BPEL che e stato

modificato (ActiveBPEL) e deployato all’interno di Tomcat.

Per tenere traccia dei processi disponibili sul motore BPEL, delle versioni

create e delle modifiche da effettuare ci si e serviti di un database gratuito,

MySQL [16], che offre delle funzionalita di base per memorizzare le informa-

zioni nel tempo e di renderle velocemente recuperabili. Tra i vari database

disponibili sul mercato si e scelto MySQL poiche attualmente e quello mag-


giormente utilizzato e la complessita della base di dati implementata non ha

richiesto l’utilizzo di funzionalita avanzate.

Capitolo 4

Implementazione di DyBPEL

Questo capitolo descrive in dettaglio i singoli componenti di DyBPEL: Bpel

Modifier, Process Runtime Modifier, Coordinator Modifier e Changes Repo-

sitory.

Il componente Bpel Modifier permette di creare una nuova versione del

processo BPEL a cui le nuove istanze dovranno conformarsi. Questo compo-

nente 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 pro-

cesso per le istanze in esecuzione, inserendo nuove attivita o eliminando

attivita esistenti.

Il componente Coordinator Modifier rende disponibili le funzionalita di

DyBPEL nascondendo i componenti che le supportano (il Bpel Modifier e

il Process Runtime Modifier). Infatti, una volta ricevute in ingresso le mo-

difiche da effettuare, esso configura e invia delle apposite direttive ai due

componenti a valle.

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

4.2. Changes Repository 36

di modifica, l’attivita da intercettare per effettuare il cambiamento e il punto

in cui effettuare la modifica. Nel caso in cui la modifica aggiunga un’attivita,

e anche necessario fornire in ingresso la definizione (espressa in XML) di

tale attivita. 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 diagram-

ma di sequenza, poiche il suo funzionamento e 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’attivita, il Process Runti-

me Modifier la intercetta e interroga il Changes Repository per controllare se

e necessario applicare delle modifiche al suo flusso di esecuzione (fase 1a). Se

l’attivita intercettata compare in uno o piu record, precedentemente inseriti

nel Changes Repository dal Coordinator Modifier, allora il Changes Reposito-

ry invia i dati necessari per modificare il processo, aggiungendo o rimuovendo

attivita, 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 e in-

dispensabile introdurre il database a supporto di DyBPEL (Changes Reposi-

tory). Questo componente contiene le informazioni necessarie per configurare

i componenti in modo che effettuino le modifiche correttamente.

In Figura 4.3 e visualizzato il modello E/R (Entita/Relazione) del Chan-

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 e 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 e 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’attivita), l’attivita da intercettare per effettuare la modifica, l’attivita

4.3. Bpel Modifier 38

target, che puo indicare l’attivita da rimuovere (nel caso di una modifica di

rimozione) oppure l’attivita dopo la quale e necessario inserire la modifica

(nel caso di una modifica di aggiunta di attivita), infine l’ultimo attributo

contiene il codice XML dell’attivita da inserire (nel caso di una modifica di

aggiunta di attivita).

Figura 4.3: Modello entita-relazione del database a supporto di DyBPEL

L’AdaptationTable permette anche di rappresentare le modifiche dei part-

nerLink, modificando le attivita in vengono sono utilizzati.

4.3 Bpel Modifier

Il componente Bpel Modifier permette di creare una nuova versione del pro-

cesso, effettuando delle modifiche a partire da una versione precedente op-

portunamente specificata.

Prima di descrivere il funzionamento del componente Bpel Modifier e

necessario descrivere la fase di deploy di un processo BPEL e i file che

rappresentano la definizione di un processo.


4.3.1 Deploy di un processo

Come gia accennato, per deploy di un processo si intende l’operazione che ren-

de 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 neces-

sari 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, e 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 diret-

tive necessarie per il corretto funzionamento del processo BPEL (ad esempio

informazioni sui partnerLink, sui protocolli e sui file WSDL utilizzati). Que-


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 e 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 dal-

l’elemento <portType> saranno trasmesse sulla rete;

• <service> indica l’indirizzo HTTP da cui poter accedere al web ser-

vice.

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 e associato tale numero.

<?xml version="1.0"?>

<definitions xmlns:xs="http://www.w3.org/2001/XMLSchema"

xmlns:tns="http://www.esempio.it"

xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"

targetNamespace="http://www.esempio.it">

<types>


<xs:schema targetNamespace="http://www.esempio.it">

<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="email" type="xs:string"/>

</xs:all>

</xs:complexType>

</xs:schema>

</types>

Gli attributi dell’elemento <definitions> determinano i namespace uti-

lizzati 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 riporta-

to sopra. Il primo messaggio (getUserRequest) riceve l’intero corrispondente

all’idUtente inviato dal cliente, mentre il secondo messaggio (getUserRespon-

se) contiene la risposta del web service. L’elemento <part> (ogni messaggio

puo averne piu 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">


<input message="tns:getUserRequest"/>

<output message="tns:getUserResponse"/>

</operation>

</portType>

L’elemento <portType>, che unisce diversi messaggi per formare un’o-

perazione, e associato a un nome (attributo name) e a una o piu operazioni

tramite l’elemento <operation>. Ogni operazione puo 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 e usata un’operazione del tipo request-response.

L’elemento <binding> si occupa del collegamento con il protocollo di

comunicazione (SOAP in questo caso) ed e mostrato nel frammento WSDL

sottostante.

<binding name="gestioneUtentiBinding" type="tns:gestioneUtentiType">

<soap:binding style="rpc"

transport="http://schemas.xmlsoap.org/soap/http"/>

<operation name="getUserById">

<soap:operation soapAction="" style="rpc"/>

<input>

<soap:body use="encoded" namespace="http://www.esempio.it"

encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>

</input>

<output>


<soap:body use="encoded" namespace="http://www.esempio.it"

encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>

</output>

</operation>

</binding>

L’elemento <binding> e del tipo <portType> definito precedentemen-

te. Il secondo binding specifica meglio il protocollo SOAP ed ha due at-

tributi: style, che indica la codifica con cui e 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 (soli-

tamente 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 messag-

gio 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="http://www.esempio.it/webservice"/>

</port>

</service>

Infine l’elemento <service>, mostrato sopra, individua il nome del ser-

vizio (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 sara in attesa di richieste.

Nel caso in cui si voglia definire un file WSDL a supporto di un processo

BPEL, e necessario specificare altri elementi. Il piu importante e defini-

to nel namespace “http://schemas.xmlsoap.org/ws/2003/05/partner-link” e


permette di definire i <partnerLinkType> che caratterizzano il rapporto di

conversazione tra due servizi (come mostrato nell’esempio che segue). Cia-

scun <partnerLinkType> e 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 so-

no 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="http://docs.oasis-open.org/wsbpel/2.0/process/executable">

<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"?/>+


</variables>

<correlationSets>?

<correlationSet name="NCName" properties="QName-list" />+

</correlationSets>

activity

</process>

Gli attributi dell’elemento <process> descrivono i namespace utilizza-

ti 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’attivita al suo interno. 1

In genere, ogni processo BPEL contiene al suo interno almeno un’attivita

strutturata che, come specificato nel capitolo 2, puo contenere al suo interno

altre attivita.

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 e

stato contattato.

<process name="esempioBPEL" suppressJoinFailure="yes"

targetNamespace="www.esempio.bpel"

xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable"

xmlns:lns="www.esempio.wsdl">

<import importType="http://schemas.xmlsoap.org/wsdl/"

location="project:/BPEL_Samples/Resources/WSDL/esempio.wsdl"

namespace="www.esempio.wsdl"/>

<partnerLinks>

<partnerLink name="customer"

1Le attivita di ciascun processo sono state gia descritte nel capitolo 2.


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’attivita iniziale e una sequence la quale contiene una serie di attivita

che verranno eseguite sequenzialmente. Come si puo notare dall’esempio, ad

ogni attivita viene associato un attributo opzionale (name) che individua il

nome dell’attivita. Tale attributo e essenziale per il corretto funzionamen-

to di DyBPEL in quanto, essendo univoco, facilita la ricerca delle attivita

all’interno del processo.


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

e uguale a quello dell’attributo location dell’elemento <wsdl> all’interno

del file PDD. Nel secondo caso il valore rappresentato da questo attributo e

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="http://schemas.active-endpoints.com/pdd/2005/09/pdd.xsd"

location="relativeDeploymentLocation"

persistenceType="full|none|final"?>

<partnerLinks>

<partnerLink name="ncname">

<partnerRole

endpointReference="static|dynamic|invoker|principal"

customInvokeHandler="java:class:args"?>


[... 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 de-

finiscono, tramite ws-addressing2 [22], gli endpoint reference che permettono

di conoscere gli indirizzi e le porte utili per comunicare con i web service

utilizzati dal processo. Infine, e anche necessario specificare, all’interno di

<wsdlReferences> le dipendenze da altri file WSDL utilizzati all’interno

del processo.

4.3.2 Descrizione del Bpel Modifier

Le funzionalita del componente Bpel Modifier sono principalmente svolte

dalla classe schematizzata in Figura 4.4. Questo componente mette a dispo-

sizione un metodo pubblico (modifica) che viene chiamato dal componente

Coordinator Modifier. Gli altri metodi sono privati e sono a supporto del pri-

mo. 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 univoca-

mente il processo;

2Il ws-addressing e uno standard per costruire gli endpoint reference utilizzati


• la versione di partenza dalla quale applicare le modifiche per raggiunge-

re 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 attivita, ecc.);

• un insieme di attributi che specificano delle informazioni aggiuntive

necessarie per descrivere completamente le azioni individuate dal pa-

rametro 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 molte-

plici e per questo motivo si fara riferimento solo a quelli principali.

Il metodo modifica richiede al componente Changes Repository le infor-

mazioni essenziali per la creazione di una nuova versione, come il nome del

file e la cartella di destinazione della versione di partenza. Prima di passa-

re alle modifiche dei file che rappresentano un processo, effettua una copia

4.4. Process Runtime Modifier 50

di backup sulla quale lavorera, 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 e necessaria poiche ogni versione del

processo deve essere identificata univocamente e deve quindi avere un nome

diverso. In seguito, il Bpel Modifier modifica le attivita del processo seguendo

in ordine i metodi specificati come parametro d’ingresso. Infine crea un nuo-

vo file .bpr, effettua la fase di deploy (copiandolo nella cartella /tomcat/bpr)

e inserisce un nuovo record nella tabella VersionTable che indica che e stato

effettuato correttamente il deploy della nuova versione. Da questo punto in

poi la nuova versione e disponibile direttamente sull’application server, in

maniera totalmente trasparente per gli utenti.

4.4 Process Runtime Modifier

Questo paragrafo e dedicato alla descrizione del componente Process Runtime

Modifier. Come gia 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, e necessario

introdurre la programmazione orientata agli oggetti (AOP).


4.4.1 Aspect Oriented Programming

Uno dei principi fondamentali dell’approccio moderno alla progettazione di

sistemi software e quello del divide et impera; in particolare:

“Separation of concerns allows us to deal with different aspects of a pro-

blem, 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 dif-

ficult 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


appropriate isolation, composition and reuse of the aspect code.” [19]

Mediante l’utilizzo di tale approccio e effettivamente possibile identificare

ed isolare — oltre che a livello di design, anche a livello implementativo — le

funzionalita 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. Poiche pero

“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].

3Come 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.


In seguito verranno presentate le astrazioni concettuali alla base dell’ap-

proccio Aspect-Oriented: inizialmente si analizzera come AOP si relaziona

con OOP e successivamente verranno presentati i nuovi concetti introdotti

dall’approccio.

Componenti, aspetti, weaving

Un generico sistema software puo essere suddiviso in parti piu semplici dette

componenti che possono essere viste come fornitori di risorse computazionali

o servizi [5]. In particolare devono soddisfare requisiti di localita e di facilita

di accesso e composizione [9]. Come precedentemente detto, la modularizza-

zione di un sistema in componenti secondo l’approccio OOP puo comportare

dispersione del codice relativo a requisiti che hanno impatto su piu com-

ponenti e che quindi non puo essere isolato o incapsulato in uno specifico

componente.

Per migliorare la qualita e facilitare la manutenzione del sistema, e uti-

le aggregare in un unico punto il codice che implementa una funzionalita

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

lo d’implementazione. Ad esempio, trovandosi nella necessita di implementa-

re la funzionalita di logging per un’applicazione complessa, il codice relativo

andrebbe “disperso” all’interno del resto dell’applicazione. E’ quindi conve-

niente 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 e possibile incap-

sulare nei componenti unicamente il codice relativo alla realizzazione delle


Figura 4.5: Weaving tra aspetti e componenti

specifiche della decomposizione dominante. Cosı facendo, tuttavia, il siste-

ma risulta “incompleto”, in quanto tutte le funzionalita relative ai concetti

trasversali sono separate negli aspetti. Gli attuali ambienti di esecuzione non

supportano il paradigma AOP: non riescono infatti ad “eseguire” nativamen-

te un aspetto. E’ quindi necessario tradurre il sistema ottenuto mediante la

modularizzazione ad aspetti in un programma effettivamente eseguibile dal-

l’ambiente di esecuzione prescelto: tale operazione e 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

e un punto ben definito nell’esecuzione di un componente [11]. Considerando

il grafo di esecuzione di un programma, un join point e un nodo appartenente


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 e possibile associare un advice, che specifica il comporta-

mento 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’e-

secuzione di un componente (un insieme di join point). Esempi di pointcut

possono essere le chiamate ad un particolare metodo, gli accessi ad uno speci-

fico 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 e possibile effettuare ulteriori discriminazioni

sulla scelta dei join point (ad esempio le chiamate ad un particolare metodo

i cui parametri soddisfino determinate condizioni). La granularita con cui e

possibile definire un join point dipende dalla scelta del particolare framework

AOP.

Un advice e un costrutto utilizzato per collegare un determinato com-

portamento di un aspetto a ciascun join point individuato da un partico-

lare pointcut. La definizione di un advice si compone quindi di due par-

ti: una specifica il comportamento dell’aspetto, mentre l’altra indica se tale

comportamento debba essere inserito prima, dopo, o al posto dei join point


individuati.

4.4.2 Descrizione del componente

Per poter implementare le funzionalita di questo componente si e dovuto

modificare il motore ActiveBPEL.

Figura 4.6: Visione ad alto livello dell’organizzazione delle classi nel motore

ActiveBPEL

Ogni volta che viene eseguita una nuova istanza del processo, il moto-

re crea una rappresentazione dello stato dell’esecuzione e delle attivita da

eseguire. Nella Figura 4.6 e schematizzata una visione ad alto livello della

struttura utilizzata da ActiveBPEL per supportare le istanze in esecuzio-


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

ca appena introdotta. Questa verra successivamente utilizzata per la crea-

zione delle istanze del processo. L’attivita principale e rappresentata dalla

classe AeBusinessProcess (Process), all’interno della quale ci sono i riferi-

menti alle liste delle variabili, partnerLink e correlationSets. Ogni attivita

del linguaggio BPEL viene rappresentata dal motore ActiveBPEL attraverso

la classe AeActivityImpl, la quale viene estesa da altre classi, ognuna delle

quali implementa una attivita specifica. Ad esempio, la Figura 4.6 mostra

le classi: AeActivitySequenceImpl (Sequence), AeActivityReceiveImpl (Recei-

ve), AeActivityInvokeImpl (Invoke) e AeActivityReplyImpl (Reply). Le classi

che rappresentano le attivita sono collegate tra di loro attraverso una struttu-

ra gerarchica. La classe AeBusinessProcess rappresenta un’attivita la quale

si differenzia dalle altre solo dal fatto che e l’attivita radice del processo e

quindi non e contenuta in nessun’altra attivita. Come si vede in Figura 4.6

l’AeBusinessProcess e il nodo radice e puo contenere una sola attivita, invece

le seguenti attivita hanno sia il riferimento al padre, sia il riferimento alla

lista contenente tutte le sotto-attivita.

Come soluzione preliminare al problema di adattamento dinamico delle

istanze del processo si e cercato di utilizzare il parser messo a disposizione dal

motore ActiveBPEL. Tuttavia, in questo modo, non e possibile modificare

la struttura precedentemente costruita, in quanto e necessario ricostruire

tutta la struttura del processo, anche nel caso in cui si debba effettuare una

semplice modifica. Infatti il parser e 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


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 attivita del processo e stato im-

plementato un metodo privato (aggiungi* ). Ognuno di questi metodi richiede

in ingresso i parametri seguenti: una stringa contenente il nome dell’attivita

target, una stringa contenente l’XML dell’attivita inserire e l’attivita padre.

Inoltre e stato implementato un metodo generico per la rimozione di ogni

attivita del processo (rimuoviAttivita). Il pointcut activityExecuted intercet-

ta l’esecuzione di ogni singola attivita. 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-


fiche, verra chiamato uno dei metodi precedentemente introdotti (aggiungi*

e rimuoviAttivita).

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

care all’interno del motore BPEL. L’attributo modEff e una HashMap che

tiene traccia delle modifiche effettuate per ogni istanza del processo BPEL.

La chiave di questa HashMap e una stringa composta dall’attributo id e

dal parametro cod adp della tabella AdaptationTable del Changes Reposito-

ry. Quindi, prima di effettuare ogni modifica, il Process Runtime Modifier

controlla che non sia stata gia effettuata una modifica, controllando che ta-

le modifica non sia gia 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 nu-

mero 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 piu utilizza-

te, 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){}

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 funzionalita di DyBPEL e attraverso que-

sto componente. Il Coordinator Modifier espone un’interfaccia WSDL, at-

traverso la quale e possibile indicare le modifiche da effettuare sui processi

BPEL.

L’interfaccia WSDL del Coordinator Modifier e 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 iden-

tificato univocamente il processo;

• un insieme di operazioni (operazioniArray): specifica le modifiche da

effettuare nel processo (aggiunta variabile, aggiunta di un attivita,

ecc.);

• un insieme di attributi (attributiArray): specifica delle informazioni

aggiuntive necessarie per descrivere completamente le azioni individua-

te dal parametro precedente. Per esempio per una azione che aggiunge

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 e 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 CoordinatorMo-

difier

Capitolo 5

Caso d’uso

In questo capitolo si presenta un’applicazione di DyBPEL ad un caso di stu-

dio, 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 opera-

zioni 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, ef-

fettuare la registrazione, effettuare il login (nel caso in cui l’utente sia gia

registrato) e visualizzare le notizie (solo dopo previa autenticazione). Se l’u-

tente sceglie di registrarsi al servizio, verranno richiesti i suoi dati, tra cui

5.1. News Provider 63

nome utente e password. Successivamente, verra richiesto all’utente di ef-

fettuare il login e, una volta effettuato il login, l’utente puo visualizzare le

notizie presenti sul servizio ed effettuare il logout. Sono state previste due

modalita di erogazione delle notizie: testo con relativa immagine o solo te-

sto. Quest’ultima modalita essendo meno dispendiosa in termini di banda

consumata, e utilizzata solo in caso di rallentamenti da parte del servizio.

News DB

Login DB

.../axis/services/NewsSrcPort?wsdl

.../active-bpel/services/NewsProvider?wsdl

.../axis/services/NewsSrc2Port?wsdl

Web Service News(With Image)

Web Service News(Without Image)

Web Service Login

News ProviderClient

.../axis/services/UserManagerPort?wsdl

Figura 5.1: Visione ad alto livello dell’architettura del caso d’uso

In Figura 5.1 e schematizzata una visione ad alto livello dell’architettura

del caso d’uso. Il componente NewsProvider e il processo principale che si

occupa delle gestione del servizio di news. Esso e 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.


Il NewsProvider utilizza tre web service. Il web service WebServiceLogin

fornisce al NewsProvider le operazioni di login e di registrazione dell’uten-

te, 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 no-

tiziaOP 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 modalita 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 spieghera in dettaglio il funziona-

mento 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


In Figura 5.2 si mostra un frammento della definizione del processo BPEL.

Se l’esecuzione del processo e nel ciclo G11While, l’utente puo 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’esecuzio-

ne del processo puo raggiungere questo punto solo se l’utente si e appena

registrato (il flusso d’esecuzione e 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 e mostrata la terza e ultima parte del processo BPEL. Se

il flusso d’esecuzione e entrato in G13Seq l’utente puo effettuare la richiesta

di notizie (ReqNewsSeq) o effettuare il logout LogoutSeq. Se effettua il lo-

gout, puo successivamente richiedere le anteprime delle notizie o rieffettuare

il login, permettendo all’utente di richiedere le notizie.

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) puo essere la so-

stituzione dell’attivita ReqNewsInv che invoca l’operazione notiziaOP dal

servizio NewsSrc, con l’attivita che invoca la stessa operazione sul servizio

NewsSrc2. Questa e una modifica necessaria quando ci sono molte utenze


sul servizio, o magari quando il server su cui risiede il servizio e rallentato

per varie cause, o ancora per motivi di lentezza nella trasmissione.

Per effettuare tale modifica l’amministratore del servizio deve interagi-

re con il Coordinator Modifier inviando i dati necessari per effettuare sia la

modifica di aggiunta della nuova attivita, che la modifica di rimozione del-

l’attivita 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’attivita del processo BPEL da intercettare per

effettuare la modifica di aggiunta, in questo caso

../invoke[@name=’ReqNewsInv’] ;

• l’XPath che identifica l’attivita del processo BPEL dopo la quale inse-

rire la nuova attivita, in questo caso ../invoke[@name=’ReqNewsInv’] ;

• l’XML della nuova attivita 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’attivita del processo BPEL da intercettare per

effettuare la modifica di rimozione, in questo caso

../invoke[@name=’ReqNewsInv’] ;

• l’XPath che identifica l’attivita da rimuovere, in questo caso

../invoke[@name=’ReqNewsInv’].

Ricevuti questi dati il Coordinator Modifier chiama il metodo modifica1

del Bpel Modifier, per creare una nuova versione del processo BPEL NewsPro-

1Si veda capitolo 4


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 attivita. Infine il Bpel Modifier effettua il deploy della

nuova versione del processo NewsProvider e comunica al Changes Repository

la disponibilita di tale versione.

Figura 5.5: Frammento dell’XML del file .bpel del NewsProvider

Il Process Runtime Modifier intercetta l’esecuzione di ogni attivita che

viene eseguita dal motore BPEL, e per ognuna di esse controlla se esiste

uno o piu record con il campo at intercettare2 della tabella AdaptationTable

del Changes Repostory che corrisponde all’XPath dell’attivita intercettata.

Nel nostro caso, quando l’esecuzione del processo arriva all’attivita ReqNew-

sInv evidenziata in Figura 5.6, il Process Runtime Modifier la sostituisce

2Si guardi la Figura 4.3 del capitolo 4


con la nuova invoke. Questa nuova attivita (ReqNewsInv2 ) a differenza della

vecchia, invoca il web service NewsSrc2Port il quale fornisce le notizie in

modalita testuali senza le immagini.

Figura 5.6: Frammento della definizione del processo BPEL precedente alla modifica

Nella Figura 5.7 e visualizzata la definizione del processo BPEL nell’i-

stante successivo della modifica.

Figura 5.7: Frammento della definizione del processo BPEL successivo alla modifica

5.3. Analisi delle prestazioni 70

5.3 Analisi delle prestazioni

Per verificare l’effettiva usabilita 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

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

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,00352513

Bpel Modifier 0,1302 0,115 0,00432550

Tabella 5.1: Analisi delle prestazioni del Coordinator Modifier e del Bpel Modifier

Nella Tabella 5.2 vengono visualizzati i tempi relativi all’esecuzione del-

l’operazione di richiesta della notizia (NewsOpC ). Il tempo della NewsOpC

comprende oltre al tempo di esecuzione delle attivita 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 attivita che compone l’operazione di NewsOpC. Anche

se la modifica del processo viene effettuata durante l’attivita ReqNewsInv, il

5.3. Analisi delle prestazioni 71

Process Runtime Modifier consuma delle risorse per intercettare l’esecuzione

di ogni attivita e di conseguenza per controllare sul Changes Repository se

si devono effettuare delle modifiche sull’attivita intercettata. Il tempo im-

piegato 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 attivita e dell’operazione di modifica.

Media [s] Mediana [s] Varianza

Monitoring 0,0463 0,045 0,00001881

Modifica 0,0198 0,019 0,00001216

NewsOpC 0,2472 0,2485 0,00013496

Tabella 5.2: Analisi delle prestazioni Process Runtime Modifier

Si puo notare che i tempi di modifica dinamica a tempo d’esecuzione sono

trascurabili (circa 19%), infatti il tempo impiegato per eseguire tale modifica

e molto piu basso rispetto all’esecuzione dell’attivita stessa (circa 8%).

Capitolo 6

Stato dell’arte

Il problema di adattamento dei processi BPEL e stato ampiamente investi-

gato in letteratura. In questo capitolo si presentano i lavori di ricerca at-

tualmente piu 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 e 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 e completamente supportata, N indica

che la modifica non e supportata, infine P indica che modifica e parzialmente

supportata). Inoltre tutti gli approcci descritti in questo capitolo permetto-

no una modifica solo temporanea delle attivita del processo BPEL, mentre

DyBPEL oltre a supportare la modifica dinamica delle istanze gia in esecu-

zione, crea dinamicamente una nuova versione del processo BPEL e la rende

disponibile in maniera trasparente per le istanze future.

72

6.1. WAWSO 73

Attivita [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 piu 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.

6.1. WAWSO 74

Inoltre per facilitare il lavoro agli utenti meno esperti, gli autori scelgo-

no di sviluppare un linguaggio che supporta gli aspetti dedicato a BPEL.

I pointcut sono identificati tramite l’XPath mentre gli advice sono espres-

si 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 potenzialita che presenta questo approccio sono comparabili con quel-

le presentate nel lavoro svolto nel corso di questa tesi. Infatti entrambi

gli approcci permettono di inserire, eliminare o sostituire attivita, variabili,

partnerLink, ecc. in maniera dinamica all’interno del flusso d’esecuzione del

processo BPEL. Le soluzioni adottate sono pero totalmente differenti. In

quanto WAWSO e un motore BPEL molto primitivo: esso implementa solo

alcune funzionalita di base del linguaggio BPEL ed e ancora in uno stadio

prototipale. Invece nella soluzione proposta in questa tesi e stato modifi-

cato direttamente il motore ActiveBPEL, che supporta tutte le funzionalita

del linguaggio BPEL ed e un prodotto gia utilizzato in ambito sia di ricerca

che industriale. Inoltre anche le modalita con cui e stato affrontato il pro-

blema 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 attivita ese-

guita dal processo e verifica (sul Changes Repository) se e quali modifiche e

necessario applicare sul processo a partire da quella attivita. In tal caso, la

modifica richiesta viene applicata opportunamente.

6.2. AO4BPEL: An Aspect-oriented Extension to BPEL 75

6.2 AO4BPEL: An Aspect-oriented Extension

to BPEL

AO4BPEL [6] si propone di risolvere due problemi fondamentali. Il primo

problema e dovuto alla mancanza di un meccanismo per definire dei cros-

scutting concern (logging, sicurezza, persinstenza) nel linguaggio BPEL. Il

secondo problema e dovuto alla mancanza di un supporto appropriato per

l’adattamento dinamico della composizione all’interno del linguaggio BPEL.

AO4BPEL e implementato come una estensione che puo adattarsi a qual-

siasi motore BPEL. Il prototipo implementato permette di effettuare il wea-

ving solo in corrispondenza di tre attivita (invoke, receive, reply). L’architet-

tura del prototipo implementato e mostrata in Figura 6.1. Essa estende un

motore BPEL con un componente chiamato aspect runtime, il quale costrui-

sce 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 attivita. Per fare questo, il BPEL interpreter manda i dati dell’attivita

in esecuzione (nome del processo, varabili, nome dell’attivita, attivita padre,

ecc.) all’aspect runtime. Quest’ultimo mantiene una lista di tutti gli aspet-

ti disponibili e per ogni attivita eseguita dal BPEL interpreter controlla se

corrisponde a uno o piu pointcut dichiarati. In questo caso, l’aspect runtime

esegue l’advice associato al pointcut indicato.

L’aspect deployment tool e una web application che permette di effettua-

re il deploy, l’undeploy e di elencare tutti gli aspetti attualmente disponi-

bili. Questo permette all’utente di capire e prevedere il comportamento del

processo modificato.

Il problema dell’adattamento dinamico viene affrontato in maniera si-

mile nei due approcci proposti (AO4BPEL e DyBPEL), in quando si effet-

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. In-

fine AO4BPEL non prevede nessuna modifica sulle variabili e partnerLink,

argomento che e stato affrontato nel corso di questa tesi.

6.3 Dynamo

Dynamo [4] si propone come soluzione ai problemi di inaffidabilita dei web

service. Questi sono dovuti alla natura distribuita dei processi BPEL e dal

fatto che i servizio partner possono cambiare dinamicamente le loro funzio-

nalita e/o i loro parameri di qualita del servizio. Non si puo 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

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 e unicamente finalizzato alla risoluzione dei problemi legati al-

l’interazione tra processo BPEL e servizi esterni. Per questo motivo esso

permette di intercettare solo le attivita di Invoke, Receive e Pick. Le possi-

bili modifiche che Dynamo permette di su queste attivita del processo sono:

sostituzione del partnerLink dell’attivita intercettata, riesecuzione (fino ad

un certo numero di volte) dell’ultima operazione di invoke fatta, invocazio-

ne di un web service esterno indicato opportunamente ed esecuzione di un

eventHandler precedentemente definito nel processo BPEL.

Il problema della flessibilita di un processo BPEL viene affrontato in ma-

niera 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 so-

lo un insieme limitato delle attivita 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 inne-

sca un monitor mechanisms che verifica se l’implementazione dei servizi e

6.4. SHIWS 78

cambiata dall’ultima invocazione. Se l’implementazione del servizio e cam-

biata, il diagnosis mechanism lancia una serie di test per rilevare le possi-

bili 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 e 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 puo verificare a tempo d’esecuzione.

Le possibili discordanze sono dovute a differenze di: cardinalita di parametri,

6.5. AOFSA 79

tipo di parametri, protocolli di interazione coi servizi, comportamento del

servizio utilizzato. Per esempio nel caso in cui si verifiche discordanza dovuta

al fatto che il servizio richiedente utilizza una variabile intera, mentre il

servizio fornitore utilizza una stringa, un possibile metodo di adattamento

da definire potrebbe essere la conversione della variabile stessa.

Per la tipologia dei problemi affrontati Dynamo puo essere considerato

un approccio complementare a quello presentato in questo lavoro. Esso si

concentra sui problemi legati all’interoperabilita tra web service che possono

esporre la stessa interfaccia, ma un diverso protocollo di interazione, ovvero

servizi aventi implementazioni differenti dello stesso contratto. Mentre nel-

l’approccio presentato in questa tesi si mira ad una piu vasta gamma di pro-

blematiche dovute ai malfunzionamenti dei servizi esterni, e al cambiamento

delle funzionalita che un processo di business deve offrire. Inoltre le possibili

operazioni proposte da SHIWS sono molto limitate, infatti e possibile effet-

tuare una sostituzione delle variabili e definire aggiungere dei comportamenti

al processo, ma non e possibile rimuovere, sostituire attivita o invocare un

partner service invece che un altro. Infine SHIWS presenta una soluzione po-

co flessibile in quanto gli integratori di software devono analizzare e quindi

creare i test e le strategie di adattamento durante la fase di progettazione, e

non a tempo d’esecuzione come viene permesso nella soluzione proposta da

questa tesi.

6.5 AOFSA

AOFSA (an Aspect-Oriented Framework for Service Adaptation) [12] e un

framework orientato al weaving dinamico degli aspetti che mira a risolvere

il problema di allineamento tra l’implementazione di un processo e la sue

6.5. AOFSA 80

specifiche esposte all’esterno. Esso definisce i) una serie di possibili tipi di

disallineamenti tra specifiche esposte e implementazione del processo, ii) un

archivio di modelli basati sugli aspetti per automatizzare il compito di gestire

i disallineamenti tra i servizi, iii) uno strumento per supportare l’istanziazione

e l’esecuzione dei modelli, insieme all’implementazione dei servizi.

AOFSA classifica i disallineamenti che possono avvenire tra due servizi

nel modo seguente:

• vincoli di parametri: i due servizi hanno differenti vincoli sui parametri

in ingresso;

• messaggio extra: il processo di business richiede un messaggio che non

e specificato nel web service esterno;

• mancanza di messaggio: il processo di business non richiede un mes-

saggio specificato nel web service esterno;

• divisione del messaggio: il web service specifica un singolo messaggio

per effettuare una funzionalita, mentre il processo di business richiede

piu di un messaggio per la stessa funzionalita;

• unione del messaggio: il web service specifica piu messaggi per effet-

tuare una funzionalita, mentre il processo di business ne richiede solo

uno.

Per ogni disallineamento AOFSA fornisce un modello personalizzabile, che

specifica quale aspetto applicare per l’adattamento. In particolare, tale mo-

dello contiene un set <pointcut, advice> che definisce dove la logica di adat-

tamento deve essere applicata e cosa rappresenta questa logica. In questo

approccio, i pointcut sono specificati come query sull’esecuzione del processo

di business. Gli advice invece sono specificati in BPEL, come frammenti che

6.5. AOFSA 81

modificano il comportamento dei processi nel punto specificato dal pointcut.

Infine tramite un estensione del motore ActiveBPEL viene fatto il weaving

dinamico di questi aspetti.

Confrontando l’approccio proposto da AOFSA con quello di DyBPEL, il

primo risulta molto limitato rispetto al secondo. Infatti il primo non supporta

l’aggiunta e la rimozione di attivita e di partnerLink, in quanto mette a di-

sposizione dei modelli solo per la modifica di variabili e la modifica dell’ordine

in cui vengono eseguite le attivita del processo dal motore BPEL.

Capitolo 7

Conclusioni

Questo lavoro di tesi si propone di rendere i processi BPEL piu flessibili e

in grado di gestire tutti i problemi e i malfunzionamenti legati alla natura

disaccoppiata e distribuita dei servizi partner in maniera dinamica.

Gli obiettivi sono stati raggiunti implementando un componente, chia-

mato 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

del processo in esecuzione.

Per quanto riguarda la modifica delle istanze future del processo, DyB-

PEL supporta modifiche riguardanti l’inserimento/rimozione di partnerLink,

variabili e di qualunque attivita messa a disposizione dal linguaggio BPEL.

Invece per la modifica delle istanze in esecuzione, DyBPEL supporta solo

modifiche riguardanti l’inserimento/rimozione di partnerLink, e di una delle

attivita fornite da BPEL. Infatti per motivi di tempo, le modifiche sono sup-

83

portate solo per le seguenti attivita: receive, invoke, reply, assign, sequence,

pick e onMessage.

La validita dell’approccio adottato in questa tesi e stata confermata at-

traverso l’effettiva realizzazione di un prototipo, che e stato utilizzato per il

supporto di un processo (NewsProvider) che aggrega e offre le notizie. Inol-

tre e stata condotta un’analisi delle prestazioni, per controllare i tempi medi

di modifica e per verificare l’impatto delle operazioni di intercettazione di

ogni singola attivita sull’esecuzione del processo BPEL. Da questa analisi si

e potuto constatare che l’utilizzo di questo approccio porta ad una perdita

minima di prestazioni (circa il 19%), aggiungendo una notevole flessibilita ai

processi BPEL.

Il lavoro svolto in questa tesi puo essere migliorato nei modi seguenti:

• estendere lo sviluppo della modifica dinamica sulle istanze in esecuzio-

ne (componente Process Runtime Modifier) a tutte le attivita messe

a disposizione da BPEL. Per fare questo si deve aggiungere un me-

todo privato per ogni modifica di aggiunta di ogni specifica attivita

nell’aspetto Instrumentation1;

• studiare quale delle possibili attivita, messe a disposizione da BPEL, e

utile intercettare per attuare le operazioni di modifica a tempo d’esecu-

zione. In questo modo si possono migliorare le prestazioni riducendo il

tempo necessario per intercettare e verificare quali modifiche applicare

sul processo;

• implementare un meccanismo di decisione per attuare le modificare

al processo BPEL automaticamente sulla base dei requisiti raccolti

durante la fase di progettazione.

1Si veda capitolo 4

Bibliografia

[1] ActiveBPEL. BPEL - The Business Process Execution Language. http:

//activevos.com/community-open-source.php.

[2] Apache. Apache Tomcat. http://tomcat.apache.org/.

[3] Apache. Web Service - Axis. http://axis.apache.org/axis/.

[4] Luciano Baresi and Sam Guinea. A dynamic and reactive approach

to the supervision of bpel processes. In Proceedings of the 1st India

software engineering conference, ISEC ’08, pages 39–48, New York, NY,

USA, 2008. ACM.

[5] M. Jazayeri C. Ghezzi and D. Mandrioli. Fundamentals of Software

Engineering. 2003.

[6] Anis Charfi and Mira Mezini. Ao4bpel: An aspect-oriented extension to

bpel. World Wide Web, 10:309–344, 2007. 10.1007/s11280-006-0016-3.

[7] C. Courbis and A. Finkelstein. Weaving aspects into web service orche-

strations. In Web Services, 2005. ICWS 2005. Proceedings. 2005 IEEE

International Conference on, pages 219 – 226 vol.1, 2005.

[8] Giovanni Denaro, Mauro Pezze, and Davide Tosi. Shiws: A self-healing

integrator for web services. In Companion to the proceedings of the 29th

84

BIBLIOGRAFIA 85

International Conference on Software Engineering, ICSE COMPANION

’07, pages 55–56, Washington, DC, USA, 2007. IEEE Computer Society.

[9] A. Mendhekar C. Maeda C. V. Lopes J.-M. Loingtier G. Kiczales,

J. Lamping and J. Irwin. Aspect-oriented programming. In procee-

dings of the European Conference on Object-Oriented Programming

(ECOOP), 1997.

[10] M. Kersten. Aop@work: Aop tools comparison. http://www-106.ibm.

com/developerworks/java/library/j-aopwork1.

[11] J. Hugunin M. Kersten J. Palm Kiczales, E. Hilsdale and W. G. Gri-

swold. An overview of aspectj. In proceedings of the 15th European

Conference on Object-Oriented Programming, 2001.

[12] Woralak Kongdenfha, Regis Saint-Paul, Boualem Benatallah, and Fabio

Casati. An aspect-oriented framework for service adaptation. In Asit

Dan and Winfried Lamersdorf, editors, Service-Oriented Computing –

ICSOC 2006, volume 4294 of Lecture Notes in Computer Science, pages

15–26. Springer Berlin / Heidelberg, 2006. 10.1007/11948148 2.

[13] Pasquale Liliana. Un sistema a regole per l’orchestrazione self-healing

di processi bpel. Master’s thesis, Politecnico di Milano.

[14] Daniele Nucci. Sperimentazione e confronto di alcuni Engine BPEL.

2007.

[15] OASIS. Web Services Business Process Execution Langua-

ge Version 2.0. http://docs.oasis-open.org/wsbpel/2.0/

wsbpel-specification-draft.html.

BIBLIOGRAFIA 86

[16] Oracle. MySQL 5.5 performance and scalability. http://dev.mysql.

com.

[17] Oracle. Oracle BPEL Process Manager. http://www.oracle.com/

technetwork/middleware/bpel/overview/index.html.

[18] Oracle. Welcome to Apache ODE. http://ode.apache.org/.

[19] W. H. Harrison P. L. Tarr, H. Ossher and S. M. S. Jr. N degrees of

separation: Multi-dimensional separation of concerns. pages 107–119.

In International Conference on Software Engineering (ICSE’99), 1999.

[20] W3C. Extensible Markup Language (XML). http://www.w3.org/XML/.

[21] W3C. Simple Object Access Protocol (SOAP) 1.1 . http://www.w3.

org/TR/2000/NOTE-SOAP-20000508/.

[22] W3C. Web Services Addressing (WS-Addressing). http://www.w3.

org/Submission/ws-addressing/.

[23] W3C. Web Services Description Language (WSDL) 1.1. http://www.

w3.org/TR/wsdl.

[24] W3C. Web Services Glossary. http://www.w3.org/TR/ws-gloss/.

[25] Wikipedia. Aspect-oriented programming. http://en.wikipedia.org/

wiki/Aspect-oriented_programming.

[26] wikipedia. AspectJ. http://it.wikipedia.org/wiki/AspectJ.

[27] Wikipedia. Enterprise application integration. http://en.wikipedia.

org/wiki/Enterprise_application_integration.

BIBLIOGRAFIA 87

[28] Wikipedia. Processo aziendale. http://it.wikipedia.org/wiki/

Processo_aziendale.

[29] Wikipedia. Qualita di servizio. http://it.wikipedia.org/wiki/

Qualit%C3%A0_di_servizio.

[30] wikipedia. Service-oriented architecture. http://it.wikipedia.org/

wiki/Service-oriented_architecture.

Documents

Un metodo non intrusivo per l’adattamento dinamico di ... · l’adattamento dinamico di processi BPEL Relatore: Prof. Luciano Baresi Correlatore: Ing. Liliana Pasquale ... 4.8