Ingegneria dei processi aziendali BPEL: Business Process Execution Language Ghilardi Dario 753708 Manenti Andrea 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.
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: WS-BPEL in pratica (2/2) <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).
Scelte: Progetto: terminale SIFA (3/4) 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.