Web Service Orchestration

I Web service e il Business Process Execution Language for Web Service (BPEL) stanno trasformando radicalmente il lato economico delle iniziative di integrazione.Vedremo come usare i Web Services esistenti per costruire Web Services più complessi.

L'integrazione dei processi di business

I processi di business delle aziende rappresentano uno degli elementi più importanti di differenziazione competitiva, descrivono le invocazioni dei servizi e i modelli d’interazione e sono la base per creare applicazioni distribuite ed eterogenee.La definizione ed l’esecuzione impeccabile di questi processi permette ad un'organizzazione di offrire prodotti o servizi più competitivi, ridurre i costi, migliorare il servizio ai clienti e reagire tempestivamente ad ogni evoluzione delle condizioni del mercato. Le soluzioni di integrazione tradizionali sono proprietarie, costose e si rivolgono soltanto alla fascia alta del mercato di integrazione. Sebbene siano stati sviluppati e adottati alcuni standard, quali J2EE Connector Architecture (JCA), Java Messaging Service (JMS) e RosettaNet, finalizzati alla soluzione di diversi aspetti di questo problema, sino ad ora è sempre mancato uno standard di orchestrazione dei processi davvero completo. L'implementazione di uno standard industriale per l'orchestrazione dei processi di business e dei Web services non permetterà soltanto di velocizzare l'implementazione e il deployment dei nuovi progetti di integrazione, ma ridurrà anche il costo complessivo di gestione, modifica, estensione e re-implementazione dei processi esistenti. Oltre ai risparmi tattici in termini di tempi e costi, questa soluzione offre anche un vantaggio di valore strategico: una reattività superiore alla costante evoluzione delle condizioni di mercato.

Perché comporre i Web services? Nel mondo reale un Web Service non offre solo servizi semplici e stateless come ad esempio il controllo di una carta di credito, ma questi possono essere combinati insieme o riusati e possono prevedere più interazioni con l’utente per offrire altri servizi.Ad esempio consideriamo l’applicazione per gli ordini di acquisto, nella quale vorremo poter cancellare un ordine di acquisto durante la sua creazione.L’esigenza di coordinare in modo automatico le attività svolte da attori diversi per il raggiungimento di un obiettivo comune quale, per esempio, l’approvazione di una richiesta, la concessione di un prestito e il rimborso di danni a un assicurato è caratteristica di processi con un elevato numero di istanze, regole di esecuzione precise e ripetibili.Le classiche applicazioni software per il supporto di flussi di lavoro con queste caratteristiche sono i sistemi di gestione dei workflow (WFMS, WorkFlow Management Systems), che consentono la gestione contemporanea di un numero, anche elevato, di istanze di processi seguendo schemi di processo predefiniti. In questo ambito, il processo viene definito come una rete di attività e di relazioni esistenti tra di esse, criteri per indicare l’inizio e la fine di un processo, e informazioni riguardo alle singole attività, quali: i partecipanti, le applicazioni IT (Information Technology) associate, i dati, e così via.

Nei sistemi di gestione di workflow le attività vengono schedulate, attivate e gestite sulla base delle risorse disponibili e grazie a ciò è possibile ottenere l’automazione completa o parziale di un business process in cui documenti, informazioni o compiti sono passati da un partecipante a un altro per svolgere attività, secondo un insieme di regole procedurali. I prodotti sul mercato consentono, in genere, di coordinare processi all’interno di una sola organizzazione, seguendo una logica essenzialmente centralizzata, anche se le singole attività possono essere svolte dagli operatori su postazioni di lavoro diverse.L’affermarsi dei Web Services rende naturale l’estensione dei concetti alla base dei sistemi di gestione di workflow anche per coordinare servizi in rete forniti da più organizzazioni.In questo ambito, l’obiettivo principale è quello di comporre più servizi forniti da fornitori diversi al fine di creare nuovi servizi a valore aggiunto. Tale composizione richiede però la definizione di standard per modellare le interazioni tra i servizi, e a tali standard stanno lavorando numerosi vendor e ricercatori.Al momento, la letteratura propone due principali approcci al coordinamento dei servizi in rete, che vengono designati sotto le denominazioni di “orchestrazione” e “coreografia”.Nell’orchestrazione, si fa riferimento a un processo di business che può interagire con altri servizi, interni o esterni.L’interazione avviene tramite messaggi scambiati tra i servizi. L’orchestrazione però presuppone il controllo sul processo da parte di una sola organizzazione e consente di gestire processi in esecuzione anche di lunga durata.La coreografia indica, invece, un approccio più collaborativo, in cui ogni partecipante descrive il proprio ruolo nell’interazione e il compito del sistema di coreografia è principalmente quello di tenere traccia delle interazioni avvenute tra le parti.

Modello di programmazione a due livelli

I Web Services possono essere o applicazioni tradizionali(elemental services) o Web Services compositi.I Web Services compositi possono essere implementati da processi complessi fatti da piùinvocazioni a Web Service che sono eseguite in un ordine specificato.I Web Services compositi e gli elemental services costituiscono il paradigma di programmazione a due livelli: un applicazione consiste di un process model e diun’implementazione di servizi.“Programmare in piccolo” significa implementare servizi elemental con linguaggi di programmazione tradizionali.“Programmare in grande” significa sviluppare servizi compositi in un linguaggio per i business process come BPEL.

Web Service Stateless e Stateful

I business process possono girare per lunghi periodi di tempo(long-running process) equindi i service requestor possono o iniziare un long-running process senza attendere i risultati o avere interazioni multiple con il processo.Nel secondo caso si ha bisogno di correlare(correlation) le interazioni con l’istanza stessa del Web Service.

Evoluzione dei linguaggi per i processi di business

BPEL4WS nasce a partire da WSFL(Web Service Flow Language) e XLANG.Il principale obiettivo di WSFL era di offrire un linguaggio XML per descrivere la composizione di Web Service. Con WSFL si specifica una collezione di Web Services, il modello di flusso, che è una descrizione del flusso di composizione.Un processo di business è descritto tramite un grafo di attività(i nodi) e dei connettori di controllo (gli archi) ed entrambi hanno un attributo che determina l’esecuzione del flusso.Inoltre si può utilizzare WSFL per specificare tutti i partner d’interazione, il modello globale, che è un meta modello di composizione ricorsivo che permette di descrivere l’interazione tra Web Services esistenti e definire nuovi Web Service.L’obiettivo di XLANG era di prevedere una nozione “per specificare il comportamento nello scambio di messaggi tra i Web Services partecipanti”.Un descrittore di Web Service XLANG estende il descrittore WSDL con gli aspetti comportamentali del servizio.Nel 2002 nasce BPEL (Business Process Execution Language) il quale offre alle aziende uno standard di settore per l'orchestrazione e l'esecuzione dei processi di business.Estende il modello di interazione dei Web Services e definisce un modello di integrazione interoperabile che supporta sia intraenterprise che B2B.

SkatesTown Requisiti

Siccome gli affari di SkatesTown sono cresciuti e la complessità dei WS è aumentata è sorta la necessità di dividere in parti di dimensione più piccola il sistema.Inoltre SkatesTown vuole dare la possibilità all’utente di poter cancellare un ordine d’acquisto durante la usa creazione.Infine, durante la creazione ed il processamento di un ordine d’acquisto esistono sia interazioni interne al sistema, che esterne con i fornitori.Le parti coinvolte nel sistema sono essenzialmente tre:

- L’acquirente(utente): può creare e cancellare un ordine di acquisto.- Il rivenditore(SkatesTown):Processa l’ordine interagendo con l’applicazione

interna e se necessario con i fornitori esterni.- I fornitori: riforniscono SkatesTown.

BPEL4WS

E’ un linguaggio che permette di modellare il comportamento dei partecipanti nelle interazioni di business basate sui Web Services.Essendo l’obiettivo di BPEL quello di specificare un modello di comportamento dei servizi Web durante un processo di business, questo linguaggio si pone a un livello più alto rispetto ai linguaggi esaminati fin qui.Un processo BPEL si manifesta o esso stesso come Web Service che può essere consumato da altri partner di business o come requestor di Web Services offerti da altri partner.Dal punto di vista prettamente tecnico, BPEL esprime la logica di funzionamento del processo attraverso una grammatica basata su XML interpretabile da un orchestration engine opportunamente progettato per supportare questo linguaggio e il cui compito sarà quello di coordinare i vari servizi che compongono il processo.

Una delle particolarità di BPEL è la sua visione ricorsiva di composizione dei Web Services. Infatti, il processo definito come insieme di Web Services collaboranti, può essere esso stesso un Web Service. Questo nuovo servizio a valore aggiunto, così creato, sarà visibile all’esterno come un servizio semplice di cui è definita l’interfaccia WSDL. Ciò che avviene è, quindi, una divisione del processo secondo due punti di vista (Figura 3): quello dell’utente del processo, a sinistra, che può supporre di interagire con un singolo servizio, e quello dei servizi cooperanti all’interno del processo, a destra, che, descrivendo le proprie funzionalità attraverso WSDL, verranno invocati dall’orchestration engine nei tempi e nei modi definiti all’interno del processo.

Entrando più in dettaglio, il processo essenzialmente è composto da attività che possono gestire richieste da parte del client del processo (attività di receive) oppure inviare messaggi di risposta al client medesimo (attività di reply). Per poter soddisfare tale richiesta il processo si basa, come si è detto, su una serie di Web Services esterni chiamati partner, invocati attraverso l’attività di invokeche potrà corrispondere a un servizio sincrono o asincrono che dipende dalle caratteristiche del Web Service chiamato.Come è facile intuire, il paradigma sottostante basato sui messaggi ben si coniuga con i quattro modelli di interazione (one-way, notification, request-response, solicit-response) definiti in WSDL.

Obiettivi

Obiettivi del linguaggio BPEL:- I processi di business interagiscono con il mondo esterno tramite i Web Services

e le interazioni sono descritte utilizzando le definizioni di portType WSDL. Il binding dei processi(l’associazione di portTypes a servizi endpoint concreti) è indirizzato dal process deployment e/o da un’infrastruttura a runtime. Le operazioni dei portType sono delle entry point nei processi.

- I processi di business sono descritti tramite un linguaggio basato su XML e la sintassi è definita dal corrispondente XML schema. Questa è una conseguenza del fatto che BPEL è costruito sul top dei Web Services.

• Questo linguaggio definisce dei concetti per una vista astratta dei protocolli business e una vista interna dei processi. I processi business eseguibili modellano l’attuale comportamento di un partecipante in un interazione business. I protocolli di business, al contrario, usano la descrizione del processo che specifica un messaggio per lo scambio del comportamento mutuamente visibile di ognuna delle parti coinvolta nel protocollo, senza rivelare il loro comportamento interno.

• Il linguaggio combina i benefici dei linguaggi gerarchici (XLANG) e dei linguaggi orientati ai grafi(WSFL).

• E’ previsto un insieme limitato di costrutti, sufficiente per semplici manipolazioni di dati necessarie per definire dati relativi ai processi e ai flussi di controllo. BPEL non intende essere un linguaggio per la manipolazione dei dati con scopo generale.

• Le istanze dei processi possono essere identificate con i dati dell’applicazione definiti dai partner di business. Non sono richiesti espliciti pattern factory o particolari istanze per identificare i concetti.

• Le istanze dei processi sono implicitamente create e terminate. Inoltre si possono aggiungere in futuro altre operazioni per il ciclo di vita dei processi.

• Il linguaggio definisce dei modelli per le transazioni long-running basati sullo scoping e sulle azioni di compensazione, offrendo recovery backward ad una granularità scelta dall’autore del processo modellato.

• I processi sono scelti come semplici modelli modulari ricorsivi per la decomposizione e l’assemblaggio dei processi. BPEL permette di combinare attività strutturate per esprimere algoritmi arbitrariamente complessi che rappresentano l’implementazione del servizio.

• Il linguaggio è compatibile con altri standard per i Web Services i quali possono svilupparsi in maniera ortogonale al linguaggio stesso.

Il modello dei dati BPEL è costruito sui messaggi WSDL 1.1 e sui tipi di XML Schema. Tutti i tipi utilizzati in un process model sono definiti utilizzando la definizione di messaggi WSDL e gli elementi ed i tipi di XML schema.XPath 1.0 è usato per la manipolazione dei dati. Le espressioni utilizzate per la scelta dei dati, per le condizioni e per altri scopi sono specificati come espressioni XPath.

Interfacce esterne di un processo

BPEL è costruito sui Web Services, quindi WSDL gioca un ruolo fondamentale nella definizione delle interfacce usate ed esposte dai processi.

portType e message

Come richiesto implementiamo tre nuovi messaggi, uno per la cancellazione dell’ordine e due per gestire i fault:

<message name=”poSubmissionRequest”><part name=”purchaseOrder” element=”po:po”/>

</message>

<message name=”poSubmissionResponse”><part name=”invoice” element=”inv:invoice”/>

</message>

<message name=”poSubmissionFaultInvalidPO”><part name=”customerID” element=”xsd:ID”/><part name=”orderNumber” element=”xsd:positiveInteger”/>

</message>

<message name=”poSubmissionFaultOutOfStock”><part name=”customerID” element=”xsd:ID”/><part name=”orderNumber” element=”xsd:positiveInteger”/>

</message>

<message name=”cancelPurchaseOrderRequest”><part name=”purchaseOrder” element=”po:po”/>

</message>

L’interfaccia del Web Service prevista dal portType WSDL determina i messaggi usati come input, output o fault.

<portType name=”poSubmissionPortType”><operation name=”doSubmission”>

<input message=”pos:poSubmissionRequest”/><output message=”pos:poSubmissionResponse”/><fault name=”invalidPO ”

message=”pos:poSubmissionFaultInvalidPO”/><fault name=”outOfStock ”

message=”pos:poSubmissionFaultOutOfStock”/></operation>

</portType>

Durante il processing dell’ordine, il processo stesso può chiamare altri Web Services offerti dai fornitori di SkateTown.Queste invocazioni esterne sono definite tramite questa interfaccia:

<portType name=”orderSuppliesPortType”><operation name=”orderSupplies”>

<input message=”asp: orderSuppliesRequest”/></operation>

</portType>

I servizi sono operazioni one-way cosi come le risposte, che però vengono effettuate nella direzione opposta.Vediamo quindi questa interfaccia di callback:

<portType name=”orderSuppliesCallbackPortType”><operation name=”orderSuppliesOk”>

<input message=”asp: orderSuppliesResponse”/></operation>

<operation name=”orderSuppliesFailed”><input message=”asp: orderSuppliesFailed”/>

</operation></portType>

Estensioni WSDL per l’interazione con un business process

Per descrivere le relazioni tra due Web Services, BPEL introduce un estensione di WSDL chiamatapatnerLinkType, la quale contiene uno o due ruoli che definiscono le responsabilità di ognuno.L’elemento role si riferisce al portType e le operazioni tra le parti sono o one-way o request-response, non esistono notification e solicit-response.

Vediamo quindi un esempio con un solo ruolo(venditore) :

<plnk:partnerLinkType name=”purchaseOrderPartnerLinkType”><plnk:role name=”seller”>

<plnk:portType name=”pos:poSubmissionPortType”/><plnk:role>

</plnk:partnerLinkType>

L’implementazione di questo servizio è un processo BPEL associato al portType che è chiamato nel ruolo di patnerLinkType. Vediamo quindi un esempio con due ruoli(venditore e fornitore) :

<plnk:partnerLinkType name=”orderSuppliesPartnerLinkType”><plnk:role name=”supplier”>

<plnk:portType name=”sup:orderSuppliesPortType”/><plnk:role><plnk:role name=”seller”>

<plnk:portType name=” sup:orderSuppliesCallbackPortType”/><plnk:role>

</plnk:partnerLinkType>

Struttura completa di un processo

<!—process definition (1) ����<process name=”purchaseOrderProcess”targetnamespace=”http://www.skatestown.com/processes/ purchaseOrderProcess”xmlns:pos=”http://www.skatestown.com/services/interface/poSubmission.wsdl”xmlns:skt=”http://www.skatestown.com/services/interface/skatestown.wsdl”xmlns:sup=”http://www.wheelsandboards.com/services/interface/orderSupplier.wsdl”xmlns:plt=”http://www.skatestown.com/services/process/poSubmissionPLT”xmlns:ppa=”http://www.skatestown.com/services/process/poSubmissionPPA”xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”xmlns=”http://schemas.xmlsoap.org/ws/2003/03/busuness-process/”

<!-- Partner link definition (2) --><partnerLinks>

<partnerLink name=”buyer”partnerLinkType=”plt:purchaseOrderPartnerLinkType” myRole=”seller” />

<partnerLink name=”supplier” partnerLinkType=”plt:allocateStockPartnerLinkType”myRole=”seller” partnerRole=”supplier”/>

</partnerLinks><!-- Partner definition (3) -->

<partners><partner name=”skatetownCustomer”>

<partnerLink name=”buyer”/></partner><partner name=”skatetownSupplier”>

<partnerLink name=”supplier”/></partner>

......</partners>

<!-- Variable definition (4) -->

La definizione di un processo (1) inizia con gli attributi specifici del processo inseriti nell’elemento root, nome del processo, target namespace o tipo di processo.BPEL distingue due tipi di processi:

- Implementazione di processi eseguibili- Descrizione di processi astratti non eseguibili.

Ci interesseremo del primo. BPEL definisce le interazioni tra partner tramite i partner link (2).La sezione partner (3) serve per raggruppare più partner link ed esprime le capacita richieste da un partner business.A supporto del mantenimento dello stato tra le diverse chiamate, il processo può, inoltre, contemplare la definizione di variabili (4) che consentono di memorizzare i dati corrispondenti alle richieste ricevute o alle risposte di invocazioni di servizi. È anche possibile effettuare manipolazioni di tali variabili all’interno del processo, attraverso l’attività di assign, il che rende il linguaggiodi descrizione del processo simile a un linguaggio di programmazione.Siccome l’interazione tra partner di business avviene tramite lo scambio di messaggi, servono dei meccanismi per immagazzinare tali messaggi. Queste variabili inoltre possono tenere dati non scambiati con i partner ma che sono utili per l’esecuzione interna del processo di business.Dato che i partner possono interagire tra loro più volte in una specifica istanza di un processo di business che ha una durata di tempo notevole, servono dei meccanismi per identificare una particolare istanza di un processo legata ad uno specifico ordine. Quindi BPEL introduce la nozione di correlation set (5).Inoltre per trattare i processi usa differenti tipi di handler:

- Fault handler per catturare i fault a livello di processo (6)- Event handler per trattare eventi inattesi.

Infine c’è una singola attività che specifica l’implementazione del processo BPEL (8), che in generale consiste di attività innestate.Di solito un processo di business è sempre iniziato con la ricezione di un messaggio e quindi il primo passo è quello di avere un’attività che può ricevere un messaggio da un partner.Per riassumere la struttura di un processo BPEL è la seguente:

- Specifiche del processo e attributi top-level- Specifiche dei partner correlati (partner link e partners)- Variabili- Correlation set- Fault handler e Event handler- Un’attività che specifica la logica di business per tutto il processo.

Attività base e strutturate

Le attività rappresentano l’elemento base della logica di business di un processo BPEL e si dividono in base e strutturate.Le attività base sono operazioni atomiche di un processo di business, mentre le attività strutturate specificano collezioni di attività innestate e l’ordine di esecuzione.Attività base:

- receive: Attende di ricevere un messaggio di richiesta da un partner- invoke: Invoca un operazione su un portType WSDL offerto da un partner- reply: Offre una risposta ad un messaggio di richiesta ricevuto da un’attività di

receive- terminate: Termina l’intero processo- throw: Indica una situazione eccezionale lanciando un fault - assign: Permette la manipolazione dei dati delle variabili- wait: Aspetta o per un periodo di tempo o fino al raggiungimento di un

specifico punto- empty: Prevede un’istruzione no-op- compensate: Causa la compensazione di un gruppo di attività completate, ma

che non sono andate a buon fine.-

Le attività base possono essere combinate in attività più complesse, le attività strutturate.BPEL prevede dei costrutti orientati ai grafi (flow) cosi come dei costrutti algebrici (while eswitch).

Attività strutturate:- while: Permette di specificare un ciclo- switch: Offre un modo strutturato di prendere decisioni, potendo scegliere

esattamente un ramo tra più scelte.- pick: Permette di eseguire uno dei molti rami non appena arriva un messaggio

appropriato o se si verifica un timeout.- sequence: Specifica un gruppo di attività che sono eseguite in maniera

sequenziale.- flow: Specifica una collezione di attività che possono essere eseguite in parallelo.- scope: Permette di definire delle attività innestate con i propri insiemi di

varabili, correlation set, fault handler, event handler, compensation handler.Queste attività strutturate, inoltre possono essere ulteriormente combinate per esprimere attività più complesse.Le attività possono avere attributi opzionali standard per esprimere ad esempio il nome.

Ciclo di vita di un processo e attività correlate

La definizione di un processo serve come template da cui è creata una specifica istanza di un processo.Il ciclo di vita di un’istanza di un processo inizia con la creazione dell'istanza e termina o con il completamento con successo della logica di business o a causa della terminazione dell’istanza del processo (es: a causa di un fault).La creazione di un'istanza avviene nel momento in cui riceve un messaggio e la logica di business inizia con un’attività capace di ricevere messaggi (pick o receive).Se l’istanza di un processo è terminata esplicitamente o dopo un fault il completamento è considerato anormale.Per l’esplicita terminazione di un’istanza di un processo, BPEL offre l’attività terminate.La si può usare come parte della logica di business e forza la terminazione immediata dell’istanza del processo, comprese tutte le attività correntemente attive(es: la cancellazione dell’ordine d’acquisto).

<terminate/>

Partner Links

I processi di business in BPEL sono descritti come una composizione di servizi astratti. Questo approccio offre un grado maggiore di riusabilità per i processi modellati. Infatti, invece di far riferimento a servizi concreti, vengono utilizzati solo un nome logico – ad esempio “cliente” o “fornitore” - ed una service interface. La risoluzione ad un endpoint concreto si avrà solo in seguito, ad esempio in fase di deploy.In BPEL , questo costrutto logico è detto partner link. La figura 12.2 mostra la relazione tra i partner Links, i partner Link Type e il portTypes.

I partner Link sono utilizzati per operazioni offerte o invocati da un processo di business.Nel diagramma, ogni processo invoca un Web Services offerto da un altro processo. L’ orderSuppliesProcess del fornitore esiste solo virtualmente.Nel codice che segue , ogni partner Link dichiara il ruolo del processo nella comunicazione con il compratore , il servizio locale della SkateTown , e col fornitore:

Partner Link Binding

I partner Link Type puntano ai portType WSDL tramite un interfaccia astratta di un Web Service. Prima che il Web Service venga invocato, il partnerLink associato deve essere risolto con un endpoint concreto. La specifica BPEL non indirizza la risoluzione del partnerLink e lascia ciò all’infrastruttura. In altre parole, quando viene eseguito il deploy di un processo BPEL con i portType WSDL che rendono le interfacce del Web Service utilizzabili o offerte dal processo, sono necessarie informazioni addizionali per stabilire la relazione tra il costrutto logical partner Link e l’indirizzo fisico del Web Service. Nel caso più semplice e statico, occorre un mapping tra ogni partner Link ed il ruolo , per ogni porta WSDL.

Binding di due ruoli di un partner link ad un endpoint del Web Service dal punto di vista del purchaseOrderProcess della SkateTown.Per il ruolo del venditore, la porta WSDL contiene l’indirizzo dove le operazioni del processo sono offerte. Per il ruolo del fornitore, la porta WSDL contiene l’indirizzo del Web Service offerto dal partner business della SkateTown. Come alternativa all’associazione statica dei partner Link con gli endpoint, il processo deployer può specificare che l’endpoint è associato al partner Link a run time e offre una politica che specifica come questo binding dinamico si realizza.Per il binding dinamico, BPEL usa il concetto di “endpoint reference”. Questi, definiti dalla specifica WS-Addressing, sono definiti come un meccanismo per identificare e descrivere dinamicamente i servizi e le istanze degli endpoint. Un endpoint reference contiene:

• L’indirizzo di un service endpoint• Proprietà opzionali di reference utilizzate dall’endpoint per consegnare un

messaggio alla destinazione finale• Elementi opzionali che identificano il portType WSDL, i servizi e la porta

dell’endpoint referenziato• Politiche opzionali per descrivere il comportamento , i requisiti, o le capacità di un

service endpoint

In BPEL, inoltre, gli endpoint reference possono essere assegnati a o da parti di messaggi.Per mostrare un utilizzo di endpoint reference, consideriamo l’interfaccia del fornitore , il fornitore non pensa di fare affari con la SkateTown, dal suo punto di vista , chi vuole fare affari con lui utilizza il Web Service orderSupplies. Per far si che il fornitore risponda in maniera asincrona al corretto partner ( chi fa affari con lui), questi partner devono potersi identificare. Inoltre, il messaggio di richiesta dell’operazione orderSupplies contiene un endpoint reference al servizio di callback del richiedente. Nel processo di ordine di acquisto della SkateTown, questa parte è eseguita con l’indirizzo del service endpoint del processo di ordine di acquisto.Abbiamo visto dunque come l’indirizzo di un endpoint di un Web Service possa essere cambiato dinamicamente con i partner business così da consentire conversazione asincrona tra loro. Il nostro esempio utilizza un indirizzo di callback. In aggiunta, avremmo bisogno di indirizzare la risposta asincrona al giusto ordine di acquisto. Vediamo come correlare i massaggi con servizi individuali stateful.

Proprietà e Correlation Set

L’interfaccia esterna di un processo BPEL è descritta dal portType; comunque, WSDL non ha conoscenza di un servizio Web stateful. Ogni volta che arriva una richiesta di ordine di acquisto alla port WSDL della SkateTown, viene creata una nuova istanza del processo di ordine di acquisto. Per ogni istanza del processo dovremmo eseguire interazione asincrona con il Web Service del fornitore. Inoltre, un utente può cancellare l’ordine di acquisto. Quindi abbiamo bisogno di un modo che ci assicuri che tutte queste operazioni vengano eseguite sulla stessa istanza dell’ordine di acquisto. Per far si che vi sia

correlazione di messaggi con le istanze del processo, ogni messaggio deve poter essere identificato univocamente , quindi occorre associare una chiave unica all’istanza del processo quando questo inizia , oppure associare ad un application data un'unica chiave di istanza.BPEL non richiede una chiave separata per istanza. I campi all’interno dell’application data sono utilizzati per identificare l’istanza del processo BPEL. Questi campi sono chiamati “properties”. Una properties è un data element con un nome ed un tipo che è definito come un WSDL extension element. Il valore di una property è estratto da un’ istanza del messaggio WSDL applicando una specifica espressione XPath. Un “porpertyAlias” definisce la relazione tra la property ed i campi data nel messaggio. A volte un singolo campo dati non è sufficiente. Immaginiamo che un utente invii un secondo ordine di acquisto prima che il primo sia stato processato. A questo punto all’utente risultano associati due ordini di acquisto. Quindi non basta avere un ID unico per associare un utente ad un’istanza, ma occorre associare all’ID anche un numero per l’ordine di acquisto. Allora , l’ID dell’utente e il numero dell’ordine insieme formano una chiave unica dell’istanza del processo chiamata “correlation set”. Un esempio è dato dalla figura 12.4

Il seguente frammento di codice mostra una definizione delle properties con il loro tipo XML schema.

Per ogni property, deve essere offerta una definizione di propertyAlias per ogni tipo di messaggio WSDL che potrebbe contenere quella property. Continuiamo l’esempio, ogni property definita prima è mappata in una definizione di messaggio WSDL per la richiesta di ordine di acquisto. Oltre al tipo del messaggio, il property alias menziona anche la parte del messaggio e l’X-Path all’interno della parte che consente l’estrazione del valore della property:

Le due properties definite su sono usate insieme nel correlation set orderCorrelationSet. Questa è una chiave che identifica una particolare istanza del processo ordine di acquisto:

Quando un correlation set è usato per la prima volta in un processo, l’insieme delle properties deve essere inizializzato. In una conversazione multipartner, il partner che inizia lo scambio di messaggi e che crea i valori della property è detto “initiator”. Gli altri partner “followers” dello scambio di messaggi. L’inizializzazione potrebbe verificarsi sia quando un messaggio viene ricevuto che quando viene inviato. Nel primo caso il partner che invia un messaggio al processo sta settando il correlation data. Nel secondo caso, il correlation data è creato del processo. Il codice seguente indica che il correlation set è inizializzato quando viene utilizzato per la prima volta.

Dopo l’inizializzazione, il correlation set è considerato immutabile. Tutte le altre attività che fanno riferimento a quel correlation set non possono modificare nessuna proprietà

Invoking Web Services e Providing Web Services

Vediamo ora come invocare le operazioni offerte da un partner , e introdurremo le attività che ci consentiranno di esporre l’intero processo BPEL come un Web Service.

Invocare operazioni dei Web Services

BPEL mette a disposizione un’attività specifica, l’attività invoke , che consente ad un processo di chiamare un Web Service offerto da un partner come parte della specifica di una invoke, selezioniamo il partner con cui interagire usando un partner link. Inoltre specifichiamo la portType WSDL e l’operazione da invocare sul partner. L’operazione può anche essere di tipo request-response o di tipo one-way. Per entrambi i tipi di operazione è richiesta una variabile di input che offre il messaggio di richiesta per l’invocazione. Nel caso di request-response abbiamo bisogno di identificare e salvare il messaggio di risposta mediante una variabile di output , sostanzialmente il risultato dell’operazione.La SkateTown si serve dei servizi del fornitore come se fossero servizi locali per processare gli ordini di acquisto . I seguenti frammenti di codice mostrano l’utilizzo della invoke. Il primo lo mostra in ambito one-way per richiedere forniture supplementari:

Il secondo invece in ambito request-response per validare una richiesta di ordine di acquisto

Ovviamente , come abbiamo detto prima, a volte risulta necessario mettere insieme, correlare, più operazioni per una stessa istanza di processo. A questo scopo, la invoke supporta l’utilizzo di correlation set che potrebbero essere inizializzati in qualsiasi fase del processo, durante una richiesta, una risposta , o in fase di invocazione.Nel codice che segue , il corrlation set orderCorrelationSet è offerto come parte del messaggio di richiesta durante l’invocazione del servizio del fornitore. Questo particolare correlation set è già stato inizializzato ed in particolare l’esempio mostra l’utilizzo di un

secondo correlation set : anAdditionalCorrelationSet ancora non inuizializzato. L’attributo initiate specifica se l’inizializzazione dovrebbe verificarsi in fase di invocazione, e l’attributo pattern indica se il correlation set è associato con l’input (pattern= “in”) o con l’output (pattern= “out”) di un operazione request-response:

Offrire operazioni di Web Services

Vediamo ora come specificare i servizi che un processo offre ai suoi partner. Un processo può offrire sia operazioni one-way che di tipo request-response. I processi implementano le loro operazioni usando l’attività receive e reply.Un’attività receive specifica l’operazione dell’interfaccia del processo WSDL che un partner ha invocato. La signature dell’operazione specifica quale messaggio di richiesta deve essere passato al processo e se il partner dovrà aspettarsi o meno un messaggio di risposta dal processo. Questa invocazione può presentarsi in una creazione di una nuova istanza di un processo , oppure la richiesta può essere sottomessa ad una istanza di un processo già esistente.Il processo di esempio PurchaseOrderProcess offre l’operazione doSubmission – di tipo request-response. Implementa l’operazione utilizzando la receive e la reply così come mostrato dal codice. In più, la receive deve creare una nuova istanza di processo per l’ordine di acquisto specificato dall’input dell’operazione doSubmission.Ciò si realizza settando l’attributo createInstance della receive a “yes”. Inoltre, c’è bisogno di inizializzare il correlation set orderCorrelationSet all’interno della receive per eventuali utilizzi futuri.

Come detto prima , la receive creerà una nuova istanza del processo se l’attributo createInstance ha come valore “yes”. Nel caso in cui queste richieste risultino essere multiple, solo il primo messaggio creerà la nuova istanza, gli altri messaggi si comporteranno come se avessero il loro attributo createInstance settato a “no”.Il codice seguente mostra un’ interazione con un’istanza già esistente. Viene data al fornitore la possibilità di fare un’ aggiunta al proprio ordine , e ciò risulta possibile solo se la richiesta del fornitore sia stata precedentemente accolta. Viene richiesta una specifica per identificare univocamente l’istanza usando la correlazione. Il correlation set orderCorrelationSet, inizializzato precedentemente, serve allo scopo:

L’attività pick è una variante della receive. Se la receive consente solo la specifica di un messaggio all’arrivo, la pick o aspetta la ricezione di tutti i messaggi specificati, o aspetta che un timeout scada. Il timeout può essere specificato sia per durata ( tramite espressione X-Path) che puntualmente ( indicando una data precisa , una deadline , sempre tramite X-Path).Il codice seguente sostituisce l’esempio precedente utilizzando l’attività pick. Ora , prima di processare l’ordine di acquisto si attende che arrivino due messaggi , e solo uno di

questi avrà luogo. Se il fornitore non risponde all’interno di un dato periodo , scadrà il timeout ed il processo continuerà con l’attività specificata all’interno dell’elemento onAlarm:

Gestione dei dati e attività collegate

Ogni invocazione di un Web Service che è “orchestrato” da un processo si basa sullo scambio di messaggi. Tutti questi messaggi sono specificati come parte dell’interfaccia esterna del processo di business, il suo portType. Guardando i messaggi dal punto di vista della definizione del processo, BPEL offre il costrutto variables per memorizzare questi messaggi . Le variables sono utilizzate per:

• Messaggi ricevuti da un processo• Messaggi che sono necessari come input per l’invocazione di un’operazione di un

Web Service• Il risultato di un’invocazione di un servizio• Dati intermedi utilizzabili dalla logica di business

Le varibles possono avere come tipo sia i message type WSDL che gli XML schema type. I primi devono essere specificati per messaggi che sono scambiati con i partner.Mentre le varibles utilizzate per gestire dati interni posso essere di qualsiasi tipo. Le variables hanno un proprio scope , che può essere globale o locale. Lo scope di una variable determina la sua visibilità e il sua periodo di vita. Una variable è visibileall’interno dello scope in cui è dichiarata e in tutti gli scope annidati al primo. I prossimi due esempi mostrano esempi di variable globale e all’interno di uno scope.

e

L’attività Assign

BPEL offre un’attività per aggiornare la variable: l’attività assign . Consente di copiare dati di tipo compatibile da una variable ad un ‘altra; e risulta anche possibile costruire ed inserire nuovi dati utilizzando espressioni X-Path. Mostriamo una serie di frammenti dicodice che ci permetteranno di osservare alcuni utilizzi.Copia di un’intera variable:

Copia di una determinata parte di una variable in un’altra:

Copia di due elementi selezionati da una variable ad un’altra. Questa operazione di assegnamento è vista come un’operazione atomica. Vi è l’utilizzo di query di tipo X-Path.

Inizializzare una variable utilizzando una valore concreto

Utilizzare un’espressione per realizzare una semplice computazione

L’assign può anche copiare riferimenti ad endpoint da e per partner link. Questo aspetto risulta utile ogni qual volta i riferimenti ad endpoint sono trattati come dati.

Estensione di funzioni X-Path

Abbiamo bisogno di accedere ad un processo non solo come assignment, ma anche per controllare il comportamento di un processo. Per consentire ad espressioni X-path di accedere arbitrariamente ai dati da parte di un processo, BPEL introduce molte estensioni di funzioni. La funzione getVariableData estrae valori arbitrari dalla variable. Gli argomenti portName e locationPath sono opzionali:

getVariableData (“variableName”, “portName”, “locationPath”);

Possiamo anche estrarre informazioni da proprietà globali, con la funzione getVariableProperty utilizzando un nome qualificato della proprietà globale:

getVariableProperty(“variableName”, “propertyQName”);

getLinkStatus riporta lo stato di un link mediante un valore booleano.

getLinkStatus(“linkName”);

L’estensione di espressioni possono essere utilizzate per qualsiasi tipo di espressione: condizioni di transizione, while, switch, timeout e deadline.

Altre attività di base: wait , empty

L’attività wait consente al processo di business di attendere per un determinato intervallo di tempo ( specificato con un’espressione X-Path) o fino al raggiungimento di una deadline (specificato con un’espressione X-Path). La wait seguente indica che si aspetterà fino alla vigilia del 2005.

Oppure per tre giorni e dieci ore:

L’attività empty non fa nulla. Potrebbe, per esempi o, essere utilizzata come implementazione di un fault handler se c’è bisogno di catturare e sopprimere un fault:

Flussi

I costrutti orientati a i grafi costituiscono un comune approccio per controllare il flusso di esecuzione di molte attività. L’attività offerta da BPEL flow ci consente di definire una serie di attività , parte delle quali dovrebbero essere eseguite in parallelo. Le attività in un flusso possono essere collegate insieme tramite dei links che specificano l’ordine di esecuzione tra le attività, compreso la sincronizzazione di esecuzioni parallele dei rami all’interno del flusso. Inoltre, le condizioni di transizione determinano i rami del flusso che devono essere attraversati, e le condizioni di join specificano i requisiti circa l’unione di attività parallele rispetto ad un’ attività; devono essere soddisfatte per compiere quell’attività.Nel processo di ordine di acquisto della SkateTown , un’ attività flow controlla lo sviluppo principale dell’ordine di acquisto, partendo dalla sua validazione e finendo con la creazione della fattura e l’inizio della consegna dell’ordine. La figura che segue mostra il grafo di questo flusso , le sua attività sono rappresentate dai nodi , e i links dagli archi.

Sicuramente possiamo notare che:• Alcune attività di questo flusso devono essere eseguite prima di altre, ad esempio la

validazione deve essere posta prima di tutte le altre attività• Alcune attività possono essere eseguite in parallelo, come la creazione della fattura

e l’inizio della consegna• Il flusso può anche usare delle condizioni sulle transazioni. Per esempio, basandosi

sul risultato dell’attività validatePurchaseOrder, decidere se continuare normalmente o lanciare un fault

Semantiche del link

Vediamo come sono definiti i link e le condizioni affinché supportino il comportamento del flusso:

• Un link tra due attività prescrive il loro ordine di esecuzione: un’attività posta come target di un link dovrà essere eseguita dopo che l’attività associata alla sorgente del link sia stata completata

• Un link può avere associate delle condizioni di transizione. Queste sono specificate tramite espressioni X-Path con valore Booleano basandosi sullo stato dell’istanza del processo. Se la condizione di transizione non è specificata, il link è considerato essere vero e sarà sempre seguito

• Un’attività può essere la sorgente di più link, ciò comporta che più rami possono essere eseguiti in parallelo. Questa attività si comporta come un’attività fork

• Un’attività può anche essere la destinazione di più link. Questa stabilisce un punto di sincronizzazione, poiché risulterà pronta solo se tutti i link entranti sono stati valutati. Agisce come un’attività join. Inoltre ci potrebbe essere specificata una condizione di join

• Le attività di un flusso senza link entranti iniziano appena il flusso è attivato. E girano in parallelo

Join Failure e Path Elimination

Come si comporta il flusso se una condizione di join fallisce ( viene valutata false) e l’attività non viene eseguita?BPEL offre due risposte a questa domanda. Specificando l’attributo suppressJoinFailure, possiamo selezionare il comportamento che vogliamo sia applicato al nostro processo e alle sue attività.Di default, il risultato del fallimento di una join condition lancia un fault standard BPEL chiamato joinFailure e viene processato in maniera usuale.Alternativamente, il fault standard BPEL joinFailure può essere eliminato settando l’attributo suppressJoinFailure a “yes”, e ci sarà invece l’eliminazione del path “morto”. Se la join condition fallisce, l’attività corrispondente viene saltata, e tutte le attività dei link di uscita saranno settate a false ( le loro condizioni di transizione saranno ignorate). Da quel punto, la navigazione del flusso procederà in maniera usuale. L’attributo suppressJoinFailure può essere specificato globalmente al livello del processo e ignorato selettivamente al livello attività. ( Posso decidere in linea di massimo che comportamento avere a livello globale, per poi specificare al livello di ogni attività un comportamento preciso).

Mettiamo insieme l’esempio del flusso

Il codice che seguirà sarà una rappresentazione del diagramma visto precedentemente in figura utilizzando l’attività flow. La definizione di un’attività flow inizia sempre con lo specificare i suoi link. Le attività di un flow diventano la sorgente e/o la destinazione di questi link riferendosi a loro tramite gli elementi delle attività source e target. La condizione transition è un attributo opzionale dell’elemento source dell’attività.

Altre attività strutturate: sequence, while, switch , scope

Dietro le attività pick e flow, BPEL offre molti altri tipi di attività strutturate. L’attività sequence che ci consente di specificare quali attività devono essere eseguite nell’ordine nel quale sono offerte. Il codice che segue mostra tre attività del processo ordine di acquisto. Queste girano sempre nell’ordine specificato, la richiesta di ordine di acquisto viene prima ricevuta, poi processata, ed infine ottiene una risposta:

L’attività while è un’attività che viene eseguita ripetutamente finchè un valore specificato da una condizione Booleana resta vero. La condizione è sotto forma di espressione X-Path. Nel nostro esempio viene posta nel punto in cui il magazzino deve essere rifornito.

L’attività switch può essere confrontata con i costrutti simili a quelli dei linguaggi di programmazione, dove per ogni possibile scelta viene offerta una lista di elementi case con una condizione booleana , e con specificate all’interno altre attività. Vi è anche l’elemento default .

L’attività scope è usata per specificare confini di visibilità. Gli scope devono avere la stessa struttura in tutto il processo , tranne che per partnerLinks e i partner , i quali possono essere solo dichiarati globalmente nel processo.

Fault Handling

BPEL introduce i fault handlers così che possiamo occuparci di situazioni eccezionali, come le seguenti:

• Un fault ricevuto come risultato di un’invocazione di un Web Service• Un fault lanciato esplicitamente dalla logica del processo• Un fault causato da un problema riscontrato dall’infrastruttura a runtime

Analizziamo questi tre tipi di fault nel dettaglio.Situazioni di fault

Il risultato di un’invocazione di un Web Service può essere sia output regolare che un fault, così come specificato dall’operazione WSDL. L’esempio mostra la definizione di un’operazione WSDL con due fault. I fault WSDL hanno un nome ed un riferimento alla definizione di un messaggio, così come mostrato:

BPEL consente anche di lanciare esplicitamente un fault per mezzo dell’attività throw . Questa attività dichiara un nome qualificato di un fault o opzionalmente mette a disposizione una variabile che consenta di associare dei dati al fault. Il codice seguente mostra un’attività throw. E’ utilizzata per terminare l’esecuzione di un path regolare del processo poiché la validazione dell’ordine di acquisto ricevuta è fallita :

Alla fine, l’infrastruttura di BPEL a runtime riconosce un numero di situazioni eccezionali predefinite all’interno di un’istanza del processo. Se si presentano tali situazioni, viene lanciato un fault standard BPEL. Esempi di fault standard sono:

• MismatchAssignmentFailure – tipi incompatibili in un’attività assign• forcedTermination • correlationViolation- messaggio contenuto nella receive, reply, invoke o

pick/onMessage non corrisponde con il correlation data• uninitializedVariable - tentativo di accedere ad una parte non inizializzata di una

mesagge variable• invalidReply - si cerca di eseguire una reply per la quale non è stata processata

una attività receive corrispondente

Fault Handlers

In BPEL, i fault handlers sono il meccanismo per catturare esplicitamente questi fault e rispondere loro con un’appropriata logica di business. I fault handlers sono associati con l’attività scope o con l’intero processo. Quando si riscontra un fault, lo scope o il processo innanzitutto bloccano le loro attività interne. Le attività strutturate vengono terminate immediatamente. Vengono anche interrotte alcuni tipi di attività di base, incluse la wait, receive, reply, e invoke. Le altre attività sono considerate short-lived ( a vita breve ) e non vengono interrotte ( termineranno autonomamente a breve). Un fault handler contiene un’attività che stava girando nel momento in cui si è verificato il fault. Ad esempio, un fault handler dovrebbe contenere un’attività reply che notifica ad un partner che la normale esecuzione della logica non sarà completata.Sintatticamente, un fault handler è un elemento catch o catchAll. Il primo ci consente di specificare il nome qualificato di un fault, di una fault variable, o entrambi. La fault variable può essere omessa nel caso in cui i fault non hanno dati addizionali associati a loro. L’elemento catchAll non ha attributi.Vediamo un esempio della dichiarazione di un fault handler per l’intero processo:

Allo stesso modo , i fault handlers possono essere dichiarati all’interno degli scope. Possono anche essere dichiarati per attività invoke, che è una notazione abbreviata per definire che uno scope si chiude con un fault handler.

Esempio di Fault Handler

Il processo di ordine di acquisto della SkateTown ha molti posti che si dedicano alla gestione di eventuali fault. Ad esempio, la figura 12.6 mostra l’invocazione del passo di validazione dell’ordine e il flow delle attività successive. Le condizioni di transizione sui links determinano se il risultato della validazione è OK o meno. Nel secondo caso, viene lanciato un fault esplicitamente. Il fault handler associato invia un messaggio fault reply, di risposta al fault , all’utente.Può capitare che uno stesso fault handler possa lanciare un fault nel caso in cui la gestione del fault non vada a buon termine. Questo sarà catturato dal fault handler del prossimo scope. Non tutti gli scope hanno fault handler specifici per qualsiasi tipo possibile di fault. Quando un fault non è catturato da un fault handler, allora si applica il fault handler di default. Il concetto di fault handler in BPEL è simile a quello della gestione delle eccezioni in Java . Comunque, il processo di business prevede altri passi nella gestione degli errori.

Compensation Handling

Fino ad ora , abbiamo discusso di fault handler come il mezzo per catturare fault e rispondere a situazioni eccezionali con appropriata logica di business. Come parte di tale logica , è possibile utilizzare un fault in modo da correggere una situazione. Ad esempio, supponiamo che capiti un fault durante il processo di ordine di acquisto dopo che la merce sia stata già allocata nel magazzino. Quando gestiamo questo fault, l’allocazione deve

essere annullata ( il processo deve tornare indietro) per ristabilire uno stato consistente dal quale il processo ordine di acquisto può ripartire.Per fare ciò, BPEL introduce la nozione di compensation handlers, che ci consentono di specificare la logica di compensazione per annullare le attività precedentemente completate con successo nel caso di fault. L’unità di compensazione è , nel caso più semplice, un’unica attività. Può anche essere uno scope BPEL che formi un’unità logica di lavoro costituita da molte attività. Un compenstion handler definisce in maniera dettagliata come invertire il risultato di una particolare unità a cui è associato.Il seguente frammento di codice BPEL specifica la logica di compensazione per una particolare attività dell’esempio PurchaseOrderProcess , l’allocazione della merce nel magazzino. L’attività checkAndAllocateLocalStock ha associato un compensation handlar che è implementato da un’altra attività di tipo invoke. L’attività deallocateLocalStock annulla ciò che è accaduto durante l’allocazione degli elementi per l’ordine di acquisto:

E’ altresì possibile associare un compensation handler con uno scope , il seguente codice dimostra come farlo:

Durante l’esecuzione a runtime, i compensation handler diventano attivi una volta che la corrispondente attività invoke o lo scope hanno terminato con successo, in caso contrario – in presenza di terminazione anormale ( ad esempio un fault) – un compensation handler non sarà mai attivo. Se un’attività invoke fallisce , BPEL presume che non ci sia bisogno di

alcuna compensazione per il servizio invocato. In presenza di scope e di una terminazione anormale, il compensation handler deve prendersi cura della compensazione delle attività interne. Ora rimane da definire come sono causati i compensation handler. Se non specifichiamo un fault o compensation handler per la nostra attività o scope, ci sarà un implementazione di default. I compensation handler saranno chiamati nell’ordine inverso dell’invocazione delle loro rispettive attività. BPEL offre anche un’attività speciale, l’attività compensate, per avviare esplicitamente un compensation handlers. Questo costrutto può solo essere usato all’interno di un fault handler o compensation handler. È applicabile esclusivamente ad attività invoke o scope. Utilizzando l’attributo scope dell’attività compensate, selezioniamo l’unità che deve essere gestita – cioè il nome dello scope o della attività invoke. Eccone un esempio:

La specifica dell’attributo scope è opzionale, se è omesso vengono immediatamente gestite tutte le attività racchiuse nello scope

Per concludere, tramite i compenstion handler e le attività di compensazione, la logica di compensazione diviene parte della logica di business di un processo. La compensazione è locale ad ogni singola istanza del processo di business.

Event Handling

Un Event handler può essere associato ad uno scope o ad un processo per l’esecuzione concorrente di eventi. BPEL definisce due tipo di eventi:

• message event – implementano un’operazione request-respone o oneway invocata da un partner

• alarm event - implementano un comportamento dipendente dal tempo

quando uno scope è attivo, allora l’event handler associato allo scope viene messo in condizione di ricevere messaggi concorrenti o alarm event. Gli event handler sono disabilitati quando l’esecuzione di uno scope termina. Gli eventi possono essere solo

eseguiti quando il corrispondente event handler è attivo. Quando un event handler per uno scope diventa inattivo, è consentito agli event handler in esecuzione di completare il loro lavoro. Lo scope viene terminato quando tutti gli event handler hanno terminato.Durante l’esecuzione di un message event, l’event handler rimane attivo. Inoltre, può processare concorrentemente più eventi dello stesso tipo. Quindi, oltre all’attività flow, questa è la seconda volta che è possibile la concorrenza in BPEL. È da notare però che gli event handler per un processo non possono creare nuove istanze di processo.Se un alarm event handler è specificato con una durata, allora il calcolo della durata inizia nel momento in cui l’event handler per lo scope diviene attivo.Nel seguente esempio, viene definito un event handler che consenta ad un partner di terminare il ciclo di vita di un’istanza del processo:

Se un acquirente sceglie di cancellare l’ordine di acquisto inoltrato, la richiesta di cancellazione viene processata a un event handler concorrente. Viene localizzata la corretta istanza del processo utilizzando la definizione del correlation set. In questo esempio, l’event handler è implementato da un’attività terminate, la quale porta le attività su rami paralleli del processo a fermarsi immediatamente.

BPEL (Sezione applicativa)

Dopo aver esaminato la struttura di un documento BPEL ci proponiamo di comprendere con maggior dettaglio come effettivamente possono essere utilizzate le funzionalità che questa tecnologia ci mette a disposizione. Per mostrare concretamente cosa sia possibile realizzare con BPEL esaminiamo due esempi estremamente semplici: Echo e StockQuote. Gli esempi sono stati tratti dalla documentazione allegata a uno dei software che sono attualmente disponibili per lo sviluppo e il deploy di applicazioni web che utilizzano BPEL. Il software in questione è stato sviluppato dalla IBM e si chiama BPWS4J (Business Process Execution Language for Java) ed è ormai giunto alla versione 2.1. Stando alla documentazione esso è stato testato sia sotto WebSphere che sotto Tomcat, tuttavia si suggerisce di utilizzare una versione di Java inferiore alla 1.4.1 altrimenti potrebbero verificarsi dei conflitti; il che non è un buon biglietto da visita essendo l’interoperabilità uno dei principali obiettivi dei web services, ma nonostante questo abbiamo scelto questo tool perché per scopi puramente dimostrativi appare piuttosto semplice e intuitivo.

Il primo esempio considerato è una semplice operazione di echo per la quale occorre considerare solo tre file: un file echo.wsdl che descrive il servizio, un file echo.bpel che descrive le interfacce offerte ai client e il file del client che invoca il servizio. Il file WSDL è in pratica un documento XML avente come elemento radice <definition> e si compone di una prima parte che definisce i namespace e i tipi di messaggi; poi l’elemento <portType> che definisce le operazioni consentite e i tipi di messaggi utilizzati per ognuna di esse e l’elemento <partnerLinkType> che contiene i partner coinvolti (in questo caso ve ne è uno solo in quanto esiste solo un partner che offre il servizio e uno che lo consuma). Infine l’elemento <service> contiene solo il nome del servizio :

Echo.wsdl<definitions targetNamespace="urn:echo:echoService" xmlns:tns="urn:echo:echoService" xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.xmlsoap.org/wsdl/">

<message name="StringMessageType"> <part name="echoString" type="xsd:string"/> </message> <portType name="echoPT"> <operation name="echo"> <input message="tns:StringMessageType"/> <output message="tns:StringMessageType"/>

</operation> </portType> <plnk:partnerLinkType name="echoPLT"> <plnk:role name="service"> <plnk:portType name="tns:echoPT"/> </plnk:role> </plnk:partnerLinkType>

<!-- The service name and the TNS represent my service ID QName --><service name="echoServiceBP">

</service>

</definitions>

Il file Echo.bpel invece risulta un documento XML che ha come unico elemento radice <process> al’interno del quale si specificano i namespace; segue un elemento <partnerLink> che costituiscono un riferimento ai portType WSDL con l’interfacce astratte del Web Service. Poi mentre nell’elemento <variables> vengono definiti i possibili tipi di messaggi nell’elemento <sequence> si specifica la catena di operazioni da eseguire quando viene ricevuta una richiesta.

Echo.bpel<process name="echoString" targetNamespace="urn:echo:echoService" xmlns:tns="urn:echo:echoService" xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/">

<partnerLinks> <partnerLink name="caller"

partnerLinkType="tns:echoPLT" myRole="service"/>

</partnerLinks>

<variables> <variable name="request" messageType="tns:StringMessageType"/> </variables>

<sequence name="EchoSequence"> <receive partnerLink="caller" portType="tns:echoPT" operation="echo" variable="request" createInstance="yes" name="EchoReceive"/> <reply partnerLink="caller" portType="tns:echoPT" operation="echo" variable="request" name="EchoReply"/>

</sequence>

</process>

Il client è lo stesso usato a corso avndo cura di modificare l’URL del servizio e specificare con un QName il tipo di servizio richiesto.Quindi

String endpoint ="http://localhost:8083/bpws4j/axisengine";

in luogo di

String endpoint =http://localhost:8083/axis/EchoService.jws";e

QName qn=new QName("urn:echo:echoService#echoServiceBP#caller#urn:echo:echoService#echoPT","echo");call.setOperationName(qn);

in luogo di

call.setOperationName("echo");

Il secondo esempio mostra realmente l’interazione tra due web services pur mantenendo una grande semplicità. In pratica si tratta di un servizio offerto ai clienti per conoscere il prezzo di una data merce. I client inviano una stringa descrittiva al primo web service che ne interroga un altro per determinare il prezzo e rispedirlo al client . In questo caso i file da considerare sono quattro; vediamoli nel dettaglio:il primo file simple.wsdl descrive il servizio; dopo la definizione dei namespace e dei messaggi descrive il portType che consiste in un meccanismo request-response. Poi dopo la definizione dei partner osserviamo che il tag <service> risulta vuoto perché il binding viene fatto a runtime e pertanto questa operazione non è a carico di chi scrive il BPEL.

Simple.wsdl<definitions targetNamespace="urn:simple:stockQuoteService" xmlns:tns="urn:simple:stockQuoteService"

xmlns:plt="http://schemas.xmlsoap.org/ws/2003/05/partner-link/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.xmlsoap.org/wsdl/">

<message name="request"> <part name="symbol" type="xsd:string"/> </message>

<message name="response"> <part name="quote" type="xsd:float"/> </message>

<portType name="StockQuotePT"> <operation name="gimmeQuote"> <input message="tns:request"/> <output message="tns:response"/> </operation> </portType>

<plt:partnerLinkType name="StockQuotePLT"> <plt:role name="service"> <plt:portType name="tns:StockQuotePT"/> </plt:role> </plt:partnerLinkType>

<!-- The service name and the TNS represent my service ID QName --> <service name="stockQuoteServiceBP"> <!-- the bindings etc. for this service will be generated by the runtime; that is, the author of the BPEL does not have to write

those down. --> </service>

</definitions>

Il file BPEL questa volta appare un po‘ più complesso; infatti dopo la solita definizione dei namespace osserviamo un tag che non compariva nell’esempio precedente: <variables>. Al suo interno vengono definiti i tipi di messaggi scambiati durante il processo. Inoltre in questo caso i partner coinvolti sono due: il chiamante e il fornitore del servizio. All’interno del tag <sequenze> viene descritta la sequenza di operazioni da effettuare quando viene richiesto il servizio; possiamo notare che la richiesta del client viene copiata in un nuovo messaggio e viene inoltrato al fornitore del servizio. In seguito il messaggio di risposta viene copiato in un nuovo messaggio e rispedito al client.

Simple.bpel <process name="simple" targetNamespace="urn:simple:stockQuoteService" xmlns:tns="urn:simple:stockQuoteService" xmlns:tns-utils="urn:simple:stockQuoteService-Utils" xmlns:sqp="http://tempuri.org/services/stockquote" xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"> <variables> <variable name="request" messageType="tns:request"/> <variable name="response" messageType="tns:response"/> <variable name="invocationrequest" messageType="sqp:GetQuoteInput"/> <variable name="invocationresponse" messageType="sqp:GetQuoteOutput"/>

</variables> <partnerLinks> <partnerLink name="caller" partnerLinkType="tns:StockQuotePLT"/> <partnerLink name="provider" partnerLinkType="tns-utils:StockQuotePLT"/> </partnerLinks> <partners>

<partner name="invoker"><partnerLink name="caller"/>

</partner> <partner name="serviceProvider"> <partnerLink name="provider"/> </partner> </partners>

<sequence name="sequence"> <receive name="receive" partnerLink="caller" portType="tns:StockQuotePT" operation="gimmeQuote" variable="request" createInstance="yes"/> <assign> <copy> <from variable="request" part="symbol"/> <to variable="invocationrequest" part="symbol"/> </copy> </assign> <invoke name="invoke" partnerLink="provider" portType="sqp:StockQuotePT" operation="getQuote" inputVariable="invocationrequest" outputVariable="invocationresponse"/> <assign> <copy> <from variable="invocationresponse" part="quote"/> <to variable="response" part="quote"/> </copy> </assign> <reply name="reply" partnerLink="caller" portType="tns:StockQuotePT"

operation="gimmeQuote" variable="response"/> </sequence>

</process>

Il terzo file da considerare è stockQuote.wsdl che descrive il servizio descritto in precedenza, ovvero a partire da una stringa descrittiva della merce restituisce il valore. La nota rilevante in questo file è il tag di <binding> e quello di <service> che mostrano come il servizio venga implementato da una classe java.

stockQuote.wdsl<?xml version="1.0" ?>

<definitions targetNamespace="http://tempuri.org/services/stockquote" xmlns:tns="http://tempuri.org/services/stockquote" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

xmlns:format="http://schemas.xmlsoap.org/wsdl/formatbinding/" xmlns:java="http://schemas.xmlsoap.org/wsdl/java/" xmlns="http://schemas.xmlsoap.org/wsdl/">

<message name="GetQuoteInput"> <part name="symbol" type="xsd:string"/> </message>

<message name="GetQuoteOutput"> <part name="quote" type="xsd:float"/>

</message>

<portType name="StockquotePT"> <operation name="getQuote"> <input message="tns:GetQuoteInput"/> <output message="tns:GetQuoteOutput"/> </operation> </portType>

<binding name="JavaBinding" type="tns:StockquotePT"> <java:binding/> <format:typeMapping encoding="Java" style="Java"> <format:typeMap typeName="xsd:string" formatType="java.lang.String" /> <format:typeMap typeName="xsd:float" formatType="java.lang.Float" /> </format:typeMapping> <operation name="getQuote"> <java:operation methodName="getQuote" methodType="instance"/> <input/> <output/> </operation> </binding>

<service name="StockquoteService"><documentation>Stock quote service</documentation>

<port name="JavaPort" binding="tns:JavaBinding"><java:address className="samples.services.stockquote.StockQuote"/>

</port> </service>

</definitions>

Infine il file del client appare estremamente semplice: prende in input l’URL del servizio e il nome descrittivo della merce e effettua la chiamata del servizio utilizzando l’URN generata all’atto del deploy.

GetQuote.javapublic class GetQuote { public static void main (String[] args) throws Exception { if (args.length != 2 && (args.length != 3 || !args[0].startsWith ("-"))) { System.err.println ("Usage: java " + GetQuote.class.getName () + " [-encodingStyleURI] SOAP-router-URL symbol"); System.exit (1); }

// Process the arguments. int offset = 3 - args.length; String encodingStyleURI = args.length == 3 ? args[0].substring(1)

: Constants.NS_URI_SOAP_ENC;URL url = new URL (args[1 - offset]);

String symbol = args[2 - offset];

// Build the call. Call call = new Call (); call.setTargetObjectURI ("urn:simple:stockQuoteService#stockQuoteServiceBP#caller#urn:simple:stockQuoteService#StockQuotePT"); call.setMethodName ("gimmeQuote"); call.setEncodingStyleURI(encodingStyleURI); Vector params = new Vector (); params.addElement (new Parameter("symbol", String.class, symbol, null)); call.setParams (params);

// make the call: note that the action URI is empty because the // XML-SOAP rpc router does not need this. This may change in the // future. Response resp = call.invoke (/* router URL */ url, /* actionURI */ "" );

// Check the response. if (resp.generatedFault ()) { Fault fault = resp.getFault (); System.out.println ("Ouch, the call failed: "); System.out.println (" Fault Code = " + fault.getFaultCode ()); System.out.println (" Fault String = " + fault.getFaultString ()); System.out.println (" Fault = " + fault); } else { Parameter result = resp.getReturnValue (); if (result != null)

System.out.println(result.getValue()); else

System.out.println("No response was returned. Perhaps there was an error with the flow.");

} }}

Considerazioni avanzate

Come è possibile notare un protocollo di business specifica l’interazione dei partner mediante messaggi e la loro possibile sequenza, ovvero l’ordibne con cui i messaggi devono essere scambiati per raggiungere un obiettivo fissato. Un processo di business non è quindi in generale qualcosa di eseguibile, tuttavia i protocolli di business si distinguono dai processi astratti perché a differenza di questi ultimi contengono maggiori informazioni; infatti essi oltre a fornire una visione del protocollo di business dal punto di vista dei partner definisce ulteriori dettagli come ad esempio la costruzione dei messaggi e la definizione di particolari condizioni. Il linguaggio BPEL inoltre può essere esteso con altri elementi di differenti namespace XML purchè non si alteri la semantica degli elementi BPEL esistenti.