Relazione

ALMA MATER STUDIORUM – UNIVERSITA’ DI BOLOGNA
FACOLTA’ DI INGEGNERIA
Corso di Laurea Specialistica in Ingegneria Informatica
Reti di Calcolatori L-S
21 Giugno 2006
ORCHESTRAZIONE DI SERVIZI WEB
Progetto di:
CUTILLO LUCA
DELLE NOCI DAVIDE GIROLAMO
DI LORETO PATRICK
Relazione di:
DELLE NOCI DAVIDE GIROLAMO
MATR: 0000212479
ANNO ACCADEMICO 2005/2006
Indice
1. Abstract…………...……………………………………………….
3
2. Introduzione………………………………………………………
3
3. Definizione dei web services e pubblicazione……………………
4
4. Definizione del processo master…………………………………
6
5. Servizi aggiuntivi………………………………………………...
8
6. Conclusioni e sviluppi futuri………………………………………
9
7. Riferimenti………………………………………………………... 10
1. Abstract
L’orchestrazione dei servizi web rientra nel settore noto come Business process
management. Questo si pone, appunto, come obiettivo la possibilità di gestire diversi
servizi web, intesi come web services, al fine di poter coadiuvare tutte le funzionalità
di tali servizi, tramite un unico processo, che potremmo chiamare “processo master”,
in modo efficiente e centralizzato.
Per soddisfare tale obiettivo, il progetto è stato suddiviso in tre macrocategorie,
ciascuna assegnata ad ogni singolo componente del gruppo, al fine di una
realizzazione più gerarchica e efficiente, e solo alla fine, in fase di definizione del
processo master, ha visto interessati tutti i membri in un lavoro di gruppo.
2. Introduzione
Il Business Process Management definito in questo processo è volto
all’orchestrazione di vari web services. Ma, prima di procedere con la definizione di
un processo generale, è opportuno definire le motivazioni che spingono alla
composizione e quindi orchestrazione di più web services.
In particolare, ogni web services, rappresenta un servizio fruibile dalla rete, dal più
semplice al più complesso, prevedendo quindi un’architettura di base, nota come
client/server. A tal proposito, quindi, risulta chiaro, che il server sarà quello che offre
tal servizio, e il client quello interessato ad utilizzarlo.
Definito ciò, si denota subito la possibilità di utilizzare tale struttura in diversi settori
commerciali, risalendo così a quelle tipologie di interazioni note nella letteratura
informatica come Business-to-business(B2B), o business-to-consumer (B2C), ovvero
interazioni tra due organizzazioni commerciali, o tra un organizzazione e un
consumatore finale.
Ma, allora risulta evidente, come componendo tra loro diversi servizi, tutti in uno, si
ottiene così una migliore offerta da parte di una qualunque organizzazione,
permettendo così l’utilizzo di servizi più competitivi, una riduzione dei costi e quindi
una maggior soddisfazione del cliente, che sia esso impresa o consumatore privato.
Quindi, l’esigenza di coordinare tra loro le diverse attività svolte dai vari attori del
processo master, per il raggiungimento di un obiettivo comune, porta alla definizione
di un flusso di lavoro, detto workflow management, che permette così l’interazione
con i diversi servizi da parte di un unico processo.
Inoltre, a seconda della tipologia di interazione tra client/server, in base a quelle su
descritte, si delineano diversi requisiti di qualità, con differente complessità, che
vanno aggiunti e definiti sia per i singoli servizi, che per il processo master.
Tutti questi aspetti saranno analizzati in seguito, rispettando l’ordine di esecuzione di
sviluppo del progetto.
Qui di seguito si riporta un esempio di composizione e orchestrazione di servizi web
nel caso più generale, dalla quale si partirà per analizzare step by step i diversi attori.
Introduzione
4
Figura 1
3. Definizione dei web services e pubblicazione
Il primo passo per arrivare a definire il processo master, è la progettazione e
realizzazione dei singoli attori principali, ovvero i web services.
Per soddisfare tale obiettivo, a partire dai requisiti richiesti dal progetto si è scelto di
definire come processo principale, un servizio di prenotazione di pacchetti turistici.
Questo ha comportato quindi, una prima suddivisione del progetto, in diverse
categorie, così come accennato precedentemente, ovvero:

Realizzazione di un servizio di prenotazione dei voli;

Realizzazione di un servizio di prenotazione degli hotels;

Realizzazione di un servizio di prenotazione per il noleggio delle auto.
Ciascuna categoria è stata assegnata ad ogni singolo componente del gruppo.
Io personalmente, mi sono occupato della definizione del web services per fornire un
servizio di prenotazione in loco di un veicolo, in modo tale da dar la possibilità ai
turisti di potersi spostare, una volta raggiunta la destinazione turistica.
Definizione dei web services e pubblicazione
5
La logica utilizzata è stata quella di imporre il vincolo che un turista possa spostarsi
con il veicolo noleggiato solo all’interno delle nazione di arrivo, perché risulterebbe
alquanto inefficiente e dispendioso raggiungere una meta turistica internazionale con
un veicolo. Ciò non toglie in ogni caso la possibilità per un cliente di noleggiare un
auto, depositarla ad una città limite, varcare la nazione, e noleggiare nelle nuova città
della nuova nazione un altro veicolo.
A tal fine sono stati predisposti quindi i campi relativi alle città di noleggio e città di
deposito, in modo tale da fornire all’utente la massima flessibilità.
Oltre ai consueti campi relativi all’inserimento delle date di noleggio e restituzione,
peraltro utili sia a fini burocratici per inserimento nel database e sia per il calcolo del
costo del noleggio, è stata fornita la possibilità all’utente di scegliere un veicolo tra
una tipologia di veicoli (auto, moto, furgoncini…) in modo tale da venire incontro
alle diverse esigenze.
Detto ciò, una volta che l’utente inserisce questi dati, innescando così l’invocazione
volta per volta delle diverse funzionalità offerte dai vari web services, l’utente può
confermare la sua scelta, e inserire così i propri dati personali, che comportano
l’inserimento nel database, ma anche utili in fase di pagamento.
A tal punto, l’utente va ad invocare la funzionalità principale corrispondente alla
prenotazione, che innesca diverse operazioni, quali quella di registrazione, calcolo del
costo finale, gestione della forma di pagamento e soprattutto aggiorno il conteggio
reale dei veicoli a disposizione, per ogni tipologia di veicolo prevista.
Infatti, già durante la fase di inserimento dei dati relativi al veicolo, per come è stato
progettato il sistema, all’utente son proposti solo quei veicoli effettivamente
disponibili in quel periodo, in modo tale che è esclusa così la possibilità di prenotare
un veicolo, già prenotato magari da un altro cliente in un periodo sovrapposto.
Parallelamente sono stati definiti dagli altri due membri gli altri due web services,
quello per la prenotazione dei voli e quello per la prenotazione degli hotels,
rispettivamente, con logiche simili a quella da me utilizzata per realizzare il mio web
services.
Dopo la definizione dei web services e il successivo deployment, si è reso necessario
creare un registry per la pubblicazione degli stessi, in modo tale da permettere ai
diversi clienti di poter interagire con essi.
E’ stato così realizzato un registry locale, non potendo utilizzare quelli della
Microsoft (), in cui depositare tutti i rispettivi file WSDL deployati.
Come descritto in fase di pianificazione del progetto, si è gestita la qualità sia a
livello dei singoli servizi, che a livello del processo master.
A tal proposito infatti, risulta evidente come si presentino tutti i possibili problemi
derivanti dall’interazione remota, visto che in linea di principio, i client dovrebbero
risiedere su macchine diverse rispetto ai server. Ma questo rappresenta dapprima una
Definizione dei web services e pubblicazione
6
caratteristica intrinseca della rete, ma potrebbe anche essere un problema di singolo
server.
Per cui, per far fronte a questi problemi, si è deciso di definire più copie degli stessi
web services, e pubblicarli su server diversi, in modo tale che in caso di server-down,
o problemi sulla rete, sia comunque possibile fruire di quel determinato servizio.
Per questo motivo, si è definito, a supporto della replicazione, anche un opportuno
sistema di naming, che permettesse la definizione e gestione delle diverse copie dei
web services a fronte di guasti, garantendo così una continuità del servizio.
4. Definizione del processo master
Una volta che sono stati definiti i diversi componenti rappresentati dai web services,
è possibile procedere con la definizione del processo in grado di orchestrare i diversi
servizi.
La logica di fondo di tale processo è che l’utente può:

Invocare il singolo web service;

Invocare tutti i web services.
Infatti, per come sono stati realizzati, i web services tra loro sono completamente
indipendenti, lasciando così la totale libertà al cliente di scegliere quello che più
soddisfa le sue esigenze. Così ad esempio, il cliente può decidere di prenotare solo un
volo, o solo l’hotel oppure anche solo il noleggio di un auto.
A differenza dal caso precedente, l’altra possibilità è quella che permette la
prenotazione di un intero pacchetto vacanze, all inclusive, e quindi che permetta la
possibilità di usufruire e quindi interagire con tutti i web services.
In base a quanto previsto dal linguaggio BPEL4WS, il tutto inizia dalla ricezione
della richiesta da parte del cliente tramite un’operazione di “receive”, e mano a mano
si avanza nel flusso del processo, segnalando lo stato attuale tramite un token, fino a
quando non si raggiunge uno stato finale, in cui si invia la risposta al cliente stesso,
tramite un’operazione di “reply”.
Si precisa, che il linguaggio BPEL, capostipite di tutte le sue varianti, permette la
definizione dello schema di flusso in diversi modi, quali possono essere sia
l’esecuzione parallela, si quelle sequenziale, in modo tale da poter soddisfare le
diverse esigenze del progetto.
Infatti, un’attività sequenziale richiede che venga prima completata l’operazione
precedente, mentre quella parallela viene svolta contemporaneamente alle altre.
A ciò, poi, è possibile definire delle condizioni di transizione, che indicano al
processo, che percorso percorrere a seconda della verifica o meno di una determinata
condizione.
Definizione del processo master
7
In figura è riportato un esempio rappresentativo di processo BPEL, che come risulta,
è anch’esso a sua volta un web service, descritto da un suo file WSDL, in cui si
orchestrano i vari WSDL dei singolo servizi.
Figura 2
L’operazione mediante la quale si invocano i diversi web services è tramite la
“invoke”.
Nel caso particolare del nostro progetto sarà quindi necessario definire un unico
WSDL, che permetta di orchestrare l’interazione con un servizio di prenotazione voli,
con un servizio di prenotazione alberghiera e infine con un servizio di noleggio di
veicoli, dando la possibilità all’utente sia di scegliere di utilizzarli tutti sia di
utilizzarne solo uno.
Per soddisfare tale obiettivo, dopo la fase iniziale di ricezione della richiesta, si
avranno tre macroattività in parallelo, invocabili anche singolarmente, a seconda del
tipo di richiesta proveniente dall’utente, che si ricongiungeranno alla fine, per il
calcolo del prezzo finale, dato dalla somma dei singoli costi dei singoli servizi
richiesti dall’utente.
A questo punto, si riporta la logica del processo di business definita per il nostro
specifico progetto, in cui si evidenziano le attività sequenziali e parallele, e i rispettivi
servizi correlati:
Definizione del processo master
Receive
8
Start
Flight
Reservation
Invoke
Invoke
Vehicle
Reservation
Invoke
Reply
Price
calculation
Hotel
Reservation
Figura 3
5. Servizi aggiuntivi
Dopo aver definito il processo master, si è passati all’ultima fase, ovvero poter gestire
anche la qualità del servizio generale.
In particolare, come si è detto in precedenza, si è data massima priorità alla continuità
del servizio, garantendo prima di tutto la disponibilità dei singoli servizi anche a
fronte di guasti. A questo punto, però occorre precisare che, oltre ai singoli servizi,
bisogna anche considerare il processo generale, ovvero garantire che le operazioni
terminino comunque in uno stato consistente, a fronti di guasti.
Per questo motivo, è stato necessario ricorrere alle transazioni, attraverso operazioni
di “compensate” e gestione dei fault, mediante le quali si definisco degli opportuni
fault handler che invocati nelle suddette operazioni, a fronte di guasti, effettuano un
undo delle operazioni fatte fino a quel momento, riportando sempre il processo in uno
stato consistente.
Servizi aggiuntivi
9
Inoltre, come detto prima, questo processo per interagire con i diversi servizi, fa
riferimento ad un registry, tramite il quale riesce a reperire le informazioni sulla
locazione dei diversi servizi.
Ma altro aspetto di cui si è tenuto conto è stato il tempo di risposta dei singoli servizi
e quindi del processo generale.
A tal proposito sono stati utilizzati una serie di strumenti per monitorare i tempi di
risposta sia dei singoli servizi, sia del processo master, impostando così anche il
valore di parametri che permettano di definire casi di server-down o il caso in cui sia
caduta accidentalmente la connessione.
Per cui, a fronte di questi problemi, dopo vengono automaticamente invocate quelle
procedure di gestione di questi fault, precedentemente definite.
6. Conclusioni e sviluppi futuri
Lo svolgimento di questo progetto ci ha permesso di venir a conoscenza del moderno
settore emergente dei processi di business basati su coordinazione di vari web
services.
Questo quindi ci ha visti particolarmente impegnati in una lunga fase di ricerca di
documentazione sull’argomento dell’orchestrazione, visto che purtroppo non si è
ancora raggiunto uno standard preciso in merito, ma d’altra parte ci ha visti stimolati
nella definizione di tutte quelle logiche alla base della coordinazione, ponendoci via
via davanti a vari problemi, alcuni dei quali sono stati risolti.
A tal proposito occorre sottolineare che molti degli aspetti quindi, in tal progetto sono
stati appositamente trascurati, quali ad esempio la gestione dei pagamenti, la
sicurezza, ma anche a livello di business logic del processo, si è scelto di utilizzare
come semantica di interazione, una semantica sincrona, per raggiungere anche una
certa affidabilità. Quindi, è anche possibile pensare ad una probabile semantica
asincrona, rimettendoci però dal punto di vista dell’affidabilità, ma probabilmente
riuscendo così ad ottenere un miglioramento dell’efficienza come tempi di risposta.
Il progetto realizzato ha così un’architettura semplice, ma considerando che è anche
distribuita, sono state fatte tutte le scelte mirate all’efficienza. In ogni caso, tutti
quegli aspetti non considerati possono comunque essere introdotti, ma bisognerebbe
considerare a quel punto, anche il calo delle performance del processo generale. Per
questo specifico progetto, per come lo si è realizzato si reputa che il sistema abbia
comunque un buon rapporto costo-prestazioni.
7. Riferimenti
Slides del corso di Reti di calcolatori L-S
Specifiche WS-BPEL
v1.1: http://www-128.ibm.com/developerworks/library/specification/ws-bpel/
v2.0: http://www.oasis-open.org/committees/documents.php
Risorse su BPEL
http://en.wikipedia.org/wiki/BPEL
http://bpelsource.com
BPEL Subprocesses – white paper
http://www-128.ibm.com/developerworks/webservices/library/specification/ws-bpelsubproc/
BPEL4People – white paper
http://www-128.ibm.com/developerworks/webservices/library/specification/ws-bpel4people/
BPEL-J – white paper
http://www-128.ibm.com/developerworks/library/specification/ws-bpelj/
Engine opensource:
ActiveBPEL Engine:http://www.activebpel.org/
JBoss jBPM:http://jbpm.org/