un metodo non intrusivo per l’adattamento dinamico di ... · l’adattamento dinamico di processi...
TRANSCRIPT
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
processo NewsProvider . . . . . . . . . . . . . . . . . . . . . . 65
7
5.4 Visualizzazione grafica della terza parte della definizione del
processo NewsProvider . . . . . . . . . . . . . . . . . . . . . . 66
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),
2.2. Service Oriented Architecture 16
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
2.2. Service Oriented Architecture 17
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
2.2. Service Oriented Architecture 18
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. Service Oriented Architecture 19
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;
2.4. Limiti del linguaggio BPEL 26
• 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-
2.4. Limiti del linguaggio BPEL 27
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
2.4. Limiti del linguaggio BPEL 28
complessa (data dalla limitazione del linguaggio stesso) e non flessibile (ogni
cambiamento richiederebbe una modifica del processo di BPEL e il suo 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;
3.2. Prodotto finale e scelte implementative 32
• 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-
3.2. Prodotto finale e scelte implementative 33
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. Bpel Modifier 39
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-
4.3. Bpel Modifier 40
ste informazioni sono specifiche del motore ActiveBPEL e garantiscono il suo
corretto funzionamento.
Struttura del file WSDL
Un documento WSDL descrive un insieme di servizi e di operazioni offerte.
Esso 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>
4.3. Bpel Modifier 41
<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">
4.3. Bpel Modifier 42
<input message="tns:getUserRequest"/>
<output message="tns:getUserResponse"/>
</operation>
</portType>
L’elemento <portType>, che unisce diversi messaggi per formare un’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>
4.3. Bpel Modifier 43
<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
4.3. Bpel Modifier 44
permette di definire i <partnerLinkType> che caratterizzano il rapporto di
conversazione tra due servizi (come mostrato nell’esempio che segue). 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"?/>+
4.3. Bpel Modifier 45
</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.
4.3. Bpel Modifier 46
partnerLinkType="lns:customerLinkType"
myRole="customerRole"/>
<partnerLink name="partner"
partnerLinkType="lns:partnerLinkType"
partnerRole="partnerRole"/>
</partnerLinks>
<variables>
<variable messageType="lns:richiesta" name="request"/>
<variable messageType="lns:risposta" name="response"/>
</variables>
<sequence name="sequence1">
<receive name="receive1" createInstance="yes"
operation="request" partnerLink="customer"
portType="lns:bpelServerPT" variable="request"/>
<invoke name="invoke1" inputVariable="request"
operation="anteprimaOP" outputVariable="response"
partnerLink="partnerService" portType="lns:anteprimaPT"/>
<reply name="reply1" operation="request"
partnerLink="customer" portType="lns:bpelServerPT"
variable="response"/>
</sequence>
</process>
L’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.
4.3. Bpel Modifier 47
Struttura del file wsdlCatalog.xml
Il file wsdlCatalog.xml, mostrato nell’esempio che segue, deve contenere un
elemento (<wsdlEntry>) per ogni documento WSDL utilizzato dal processo
ed un elemento (<schemaEntry>) per ogni file XML Schema. Entrambi
gli elementi devono specificare gli attributi location e classpath (mostrato
nell’esempio che segue). L’attributo location mappa un file WSDL in due
modi possibili. In un primo caso il valore rappresentato da questo attributo
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"?>
4.3. Bpel Modifier 48
[... ws-addressing....]?
</partnerRole>?
<myRole service="name" allowedRoles="namelist"?
binding="MSG|RPC|EXTERNAL"/>?
</partnerLink>+
</partnerLinks>
<wsdlReferences>
<wsdl namespace="uri" location="uri"/>+
</wsdlReferences>?
</process>
Dichiarati i namespace, all’interno degli elementi <partnerLink> si 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
4.3. Bpel Modifier 49
• 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. Process Runtime Modifier 51
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
4.4. Process Runtime Modifier 52
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.
4.4. Process Runtime Modifier 53
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
4.4. Process Runtime Modifier 54
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
4.4. Process Runtime Modifier 55
a tale grafo; esempi di questi nodi possono essere i punti in cui un oggetto
riceve una chiamata ad un suo metodo, in cui effettua una chiamata ad un
altro metodo o ancora in cui accede a un qualche campo. Gli archi di tale
grafo costituiscono le relazioni del flusso di controllo tra i diversi nodi. In
questo modello il control flow attraversa ciascun nodo due volte: la prima
all’inizio dell’elaborazione individuata dal join point e la seconda alla fine di
tale computazione.
E’ possibile raggruppare insiemi coerenti di join point in pointcut ; questi
consentono di selezionare gruppi di nodi di interesse per il programmatore.
A ciascun pointcut 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
4.4. Process Runtime Modifier 56
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-
4.4. Process Runtime Modifier 57
ne. Quest’ultimo, durante la fase di deploy del processo, effettua il parsing
dei file XML (richiesti per la fase di deploy), creando la struttura 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
4.4. Process Runtime Modifier 58
il parsing dei file modificati, comportando uno spreco inutile di risorse.
Figura 4.7: Aspetto Instrumentations
Nella soluzione adottata si utilizza l’aspetto schematizzato in Figura 4.7.
Per ogni modifica di aggiunta di ogni specifica 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-
4.4. Process Runtime Modifier 59
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.
5.1. News Provider 64
Il NewsProvider utilizza tre web service. Il web service WebServiceLogin
fornisce al NewsProvider le operazioni di login e di registrazione dell’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
5.1. News Provider 65
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
5.2. Operazione di modifica 67
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
5.2. Operazione di modifica 68
vider. Inoltre inserisce due nuovi record, uno per ogni modifica effettuata,
nella tabella AdaptationTable del Changes Repository.
Il Bpel Modifier richiede al Changes Repository le informazioni essenziali
per la creazione di una nuova versione del NewsProvider, come l’URL del file
.bpel da modificare. Successivamente il Bpel Modifier modifica direttamente
l’XML di tale file, sostituendo la parte dell’XML evidenziata in Figura 5.5
con l’XML della nuova 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
5.2. Operazione di modifica 69
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.