BPEL: Business Process Execution Language

Ingegneria dei processi aziendali
BPEL:
Business Process Execution Language
Ghilardi Dario
Manenti Andrea
753708
755454
Docente: Prof. Ernesto Damiani
BPEL - definizione
 Business Process Execution Language
 Linguaggio di programmazione testuale basato su XML
costruito per descrivere formalmente i processi commerciali
ed industriali in modo da permettere una suddivisione dei
compiti tra attori diversi.
 ll linguaggio BPEL permette di descrivere un business
process mediante un insieme di attività, semplici o composte
 Lo standard che definisce l'uso di BPEL nelle interazioni tra
Web services è chiamato WS-BPEL. BPEL è nato come
integrazione delle ricerche svolte da IBM e Microsoft su
WSFL e XLANG, entrambi superati da BPEL. Nel 2003
BPEL è stato standardizzato da OASIS.
BPEL – concetti chiave (1/2)
 Processo di business:
descrive le procedure aziendali
chiave e la loro organizzazione in funzione delle attività
semplici, delle risorse e degli attori.
 Workflow management system: tenta di coordinare, in
modo più automatizzato possibile, processi di business
tenendo conto di chi, cosa e come si devono svolgere le
attività; al fine di ridurre costi e tempo e avere un mapping tra
IT e business process efficace.
 BPEL
è particolarmente adatto a modellare workflow
completamente automatizzati, per la composizione di web
service e l'integrazione di servizi eterogenei.
BPEL – concetti chiave (2/2)
 Composition:
modella
la
struttura
interna
e
l’implementazione di un servizio (comportamento interno di
un W.S.).
 Coordination: Gestisce le interazioni esterne tra più servizi
(scambio di messaggi tra W.S.).
 In realtà sono molto legate tra loro. Non si può pensare ad
una sola delle due senza considerare l’altra!
 BPEL ha come obiettivo quello di descrivere composition e
coordination in modo semplice ed efficace.
BPEL – caratteristiche base
 Il BPEL permette di creare servizi composti in modo
dichiarativo.
 I servizi composti sono quelli distribuiti su più server e su
diverse unità. Il BPEL permette di effettuare una sola
chiamata da client per avere un servizio composto da più
servizi semplici opportunamente coordinati.
 Una Engine che riceve in in input il Bpel e si occuperà di
fare le chiamate e passare i dati nei tempi e nei modi
specificati.
Elementi del BPEL composition model (1/2)
Un composition model definisce come combinare i vari
elementi (cioè i W.S.) che compongono un servizio
complesso. Gli elementi possono essere eterogenei ma deve
essere possibile accedervi attraverso semplici invocazioni.
1. Service Selection Model: specifica quali servizi devono
inviare o ricevere quali messaggi e quando.
Inoltre, specifica come i servizi sono legati alla composition:
 Static Binding
 Dynamic binding by reference: URL del servizio
memorizzata in una variabile.
 Dynamic binding by lookup: URL del servizio cercata
tramite query ad un registry.
 Dynamic operation selection: non viene fatta alcuna
assunzione sul servizio da invocare.
Elementi del BPEL composition model (2/2)
2.
Data Model: specifica chiaramente strutture e tipi di dato
per le variabili scambiate tra i servizi.
3.
Data Transfer Model: definisce lo scambio di dati tra i
servizi, utilizzando:
 White Board: contenitore di tutte le variabili (subito
disponibili alla engine).
 Data Flow Graph: specifica come e quando i dati
vengono rilasciati alla engine (non tutti subito
disponibili, ma on-demand per evitare side effect).
4.
Exception Handling: permette la gestione di diversi tipi di
eccezioni in diverse modalità (timeout, try-catch).
BPEL: altri aspetti
 Transazioni: Con BPEL è possibile creare servizi composti
di natura transazionale. Le transazioni vere e proprie
devono soddisfare le proprietà ACID (tipiche dei Database)
e devono permettere di fare roll-back. In SOA non è sempre
possibile effettuare roll-back,ma a questo si può ovviare con
l’operazione di compensation handling.
 Properties: Con properties si definiscono gli elementi che
si intendono usare per collegare i messaggi da scambiare
alle istanze di processo. Un correlation set è un gruppo di
properties che individua una certa conversazione di un dato
processo.
WS-BPEL in pratica (1/2)
 Composition e Coordination: WS-BPEL è lo standard per
la specificazione di business process solo per web service.
Viene usato per definire processi eseguibili (composition) e
processi astratti (coordination) in modo semplice ed
efficace.
 Composition: si aggregano le interfacce WSDL dei vari
servizi secondo le regole scelte. Ricorsivamente si ottiene
il WSDL del servizio composto.
 Coordination: definizione di vincoli e regole sul WSDL del
servizio composto.
 Partner Link: sono la definizione del web service da
invocare come parte del servizio composto in BPEL.
Rappresentano una istanza del W.S. attraverso una
mappatura del WSDL del servizio.
WS-BPEL in pratica (2/2)
 Operazioni:
 Semplici:
 <receive>: mette in attesa finché non arriva un messaggio.
 <reply>: manda un messaggio di risposta ad uno ricevuto.
 <invoke>: manda un messaggio per invocare un’operazione remota.
 <assign>: aggiorna il valore di una variabile.
 <wait>: sospende l’esecuzione per un dato periodo di tempo.
 <empty>: nessuna operazione usata per sincronizzare.
 <terminate>: termina il processo.
 <throw>, <rethrow>: lancia un fault per l’apposito gestore.
 <catch>, <catchAll>: cattura fault di una certa natura lanciati da throw.
 <compensate>: annulla gli effetti di una attività già completata.
 Composte:
 <sequence>: esegue un insieme di attività, una dopo l’altra.
 <switch>: sceglie tra due insiemi di attività.
 <while>: ripete al verificarsi di una certa condizione.
 <flow>: esegue attività in parallelo .
 <pick>: divide il flusso in più rami ed esegue quello relativo al messaggio che arriva
primo.
 <scope>: definisce un blocco di attività.
Progetto: terminale SIFA (1/4)
 Strumenti: Per realizzare il nostro progetto abbiamo usato
come ambiente di sviluppo NetBeans 6.0.1, che supporta il
Plug-in SOA. Abbiamo inoltre utilizzato l’application server
open source Glassfish.
 Primo Passo, i Web Service: Abbiamo scelto di realizzare
per il nostro progetto due Web Service: “Gestore_Esami” e
“Mailer”. Abbiamo scritto i prototipi delle funzioni che
volevamo avessero, specificando la tipologia di dati in Input
e Output per ciascuna. Effettuando le operazioni di Build e di
Deploy abbiamo generato il WSDL di entrambi i servizi
semplici.
Progetto: terminale SIFA (2/4)
 Secondo
Passo, il Client: Abbiamo realizzato una
interfaccia Client (WSDL), pensando a come si sarebbe
mostrato agli studenti il nostro terminale SIFA. Il client può
effettuare le operazioni di “iscrizione” e “cancellazione”,
oltre che di “scelta” dell’operazione da eseguire.
 Terzo Passo, il BPEL: Innanzitutto abbiamo linkato al
BPEL le interfacce WSDL dei W.S. e del client che
diventano così i partner links del progetto. Abbiamo poi
realizzato il control flow gestendo lo scambio di messaggi e
di dati tra i partner links. Per realizzare il servizio composto
abbiamo utilizzato le operazioni semplici di recieve, assign,
invoke, reply e throw; e le operazioni composte di sequence
e switch (“if” per la scelta iniziale).
Progetto: terminale SIFA (3/4)
 Scelte:
 Abbiamo
pensato che la prima operazione chiesta
all’utente fosse quella di scegliere l’attività da eseguire
(nel nostro caso tra 2 possibilità). Il workflow si presenta
così diviso in due rami alternativi in cui sono presenti due
sequenze di operazioni.
 L’utente per iscriversi o cancellarsi ad un appello può
scegliere tra una lista di esami a cui può iscriversi o a cui
è già iscritto. La lista verrà quindi elaborata dal W.S.
“Gestore_Esami” in base alla matricola inviata.
 L’iscrizione o la cancellazione comportano l’invio di una
mail di conferma allo studente; operazione è gestita del
W.S. “Mailer”.
Progetto: terminale SIFA (4/4)
 Commenti:
pur trattandosi di un progetto basilare,
l’ambiente di sviluppo utilizzato si è rivelato spesso
macchinoso e complesso. A nostro parere i principi e i
concetti teorici non hanno ancora un valido strumento per la
messa in pratica.
 Conclusioni: Abbiamo approfondito i concetti teorici alla
base del linguaggio descrittivo BPEL e ne abbiamo appreso
le principali operazioni e funzionalità pratiche. Realizzando il
progetto abbiamo potuto sperimentare un ambiente di
sviluppo e ci siamo misurati con un problema concreto,
applicando quanto studiato.