Orchestrazione e coreografia
BPEL vs WS-CDL
Service Oriented Architecture
 Architettura basata su servizi
 Servizi
 Funzioni di business auto-contenute
 Eseguono unità di lavoro discrete
 non posso invocare un servizio “a metà”
 Indipendenti dalla tecnologia (interoperabilità)
 Invocabili utilizzando standard di comunicazione
 Disaccoppiati
 Si conoscono unicamente tramite un’interfaccia pubblica
 Devo poter modificare l’implementazione di un servizio
senza toccare gli altri
 Trasparenti rispetto alla locazione
 Recuperabili interrogando un repository
Basic SOA
Service
Provider
Publish
Service
Registry
Bind
Find
Service
Client
Web Services
XML
XSD
Service
Provider
Caso tipico
HTTP
WSDL
Publish
Bind
UDDI
Service
Registry
Find
Service
Client
Messaggi
SOAP
WS Stack
Composition - Processes
BPEL, BPELJ, WS-CDL
Coordination - Context - Transactions - Security
WS-Coordination, WS-AtomicTransactions, WS-Security, …
Description
WSDL, WS-Policy
Advertisement
UDDI
Messaging
SOAP, WS-Addressing, WS-ReliableMessaging
Transport
HTTP, SMTP, HTTPS
Format
XML
Simple Object Access
Protocol
Envelope
Header
Body
Document
Messaggio, parametri,
valori
Fault
 Protocollo indipendente dal
livello di trasporto per lo
scambio di documenti XMLbased
 Messaggio SOAP:
 Header con informazioni
aggiuntive - infrastrutturali (es:
gestione della sicurezza)
 Body con il messaggio da
comunicare
 Fault per l’eventuale gestione
di errori e eccezioni
Modalità di interazione
 Determinate dall’encoding SOAP
 Tipo di interazione
 Tipo di codifica
 Due modalità fondamentali:
 RPC (sempre meno utilizzata)
 Document-based (message passing)
 Si tende a realizzare una invocazione con
risultato con una coppia di messaggi
 ma non c’è più attesa del cliente
Web Services Description
Language 1/3
 Dialetto XML per la descrizione
dell’interfaccia pubblica di un servizio
 Cosa fa il servizio (operazioni e relativi parametri)
 Dove si trova
 Come si invoca
 La descrizione si compone di una parte
astratta (interfaccia) e di una concreta
(realizzazione del servizio)
WSDL 2/3
 Parte astratta
 Messaggio
 informazione effettivamente scambiata tra requestor e
provider (per input, output, fault)
 Associato a parametri
 Tipi XSD
 Operation
 descrizione astratta di un’attività supportata dal servizio
 si aggancia a messaggi
 Interface (o Port Type) = insieme di operazioni
astratte
WSDL 3/3
 Parte concreta
 Types
 definizione dei tipi (tramite XSD)
 Binding
 Specifica i protocolli di comunicazione e i formati dei dati
per le operazioni e i messaggi definiti da un’interfaccia
 Port (Endpoint)
 Specifica l’indirizzo per legarsi al servizio
 Service
 aggregazione di un insieme di porte
Esempio 1/2
 Tipo
<element name=“TradePrice”>
<complexType>
<all>
<element name=“price” type=“float”/>
</all>
</complexType>
</element>
 Messaggio
<message name=“GetLastTradePriceOutput”>
<part name=“body” element=“xsdl:TradePrice”/>
</message>
Esempio 2/2
 portType (request-response)
<portType name=“StockQuotePortType”>
<operation name=“GetLastTradePrice”>
<input message=“tns:GetLastTradePriceInput”/>
<output message=“tns:GetLastTradePriceOutput”/>
</operation>
</portType>
Modalità di interazione
 In base a come una operation viene legata ai
messaggi otteniamo 4 diverse modalità di
interazione
 One way
 Un solo messaggio in input all’endpoint
 Request response
 L’endpoint riceve un messaggio ed emette in output una
risposta
 Solicit response (?)
 L’endpoint invia un messaggio al client (sollecitazione) e
attende un messaggio di risposta
 Notification (?)
 L’endpoint invia un messaggio di notifica in output
Composizione di servizi
 Possiamo comporre servizi semplici per
realizzare applicazioni più complesse
 Da servizi a processi di business
 Due approcci
 Orchestrazione
 Si definisce un servizio in termini di interazione con altri
servizi + parti “private”
 Coreografia
 Si definisce, assumendo un punto di vista globale, come
devono interagire differenti servizi al fine di raggiungere
l’obiettivo della composizione
 L’interfaccia di comportamento di un servizio rappresenta
la parte del servizio che interagisce con l’esterno
Business Process Execution
Language (for Web Services)
 Linguaggio XML-based per l’orchestrazione
di una serie di servizi al fine di realizzare un
processo di business
 Il coordinatore è, in fase di esecuzione, il
BPEL-engine che esegue la specifica
 Standard de-facto proposto dall’IBM
 A partire da una serie di servizi stateless
costruisco un processo con stato…
 …che può eventualmente esporsi a sua volta
come servizio
Le due visioni di BPEL
 Linguaggio core per definire i ruoli (abstract WSDL)
che interagiscono con il processo e specificare i
pattern di interazione con tali ruoli
 Questo core si può poi istanziare su due differenti
realtà
 La specifica di un protocollo di business o processo
astratto (interfaccia di comportamento)
 La specifica di un processo eseguibile (processo
astratto + attività private, interne al processo stesso)
 Idea fondamentale: finchè un processo espone la
stessa interfaccia di comportamento, possiamo
aggiornarlo senza toccare il mondo esterno
Parti fondamentali
 Variables
 Dati utilizzati dal processo
 WSDL message types
 Tipi semplici o elementi XSD
 partnerLinks
 Identificazione di chi interagisce con il processo
 Definizione del processo
 Definizione dei fault handlers
 Sia per cause interne che per cause esterne (vedi
WSDL)
 Definizione degli handler di compensazione
Partner del processo
 Un partner è un insieme di partnerLink
 Deve fornire le funzionalità richieste
 Un partnerLink rappresenta un servizio con cui il
processo interagisce
 È identificato da un partnerLinkType
 Un partnerLinkType è associato ad un ruolo e
ad un portType (vedi WSDL)
 Nota: una port implementa un portType
 A livello di definizione, rimaniamo in astratto
 In fase di esecuzione è possibile definire
staticamente o dinamicamente l’istanza con cui si
interagirà
Dati
 I dati costituiscono lo stato del processo
 Sono i messaggi scambiati, i valori intermedi delle
variabili, i valori dei time-out…
 Lo scoping è quello classico (vale l’innestamento)
 Variabili o globali o valide all’interno di uno scope
 Problemi nel caso di uso di variabili ancora non
inizializzate
 Ci sono anche delle “proprietà” definite
globalmente (tipi XSD semplici che
rappresentano le informazioni principali del
processo)
Correlazione
 In alcuni casi il processo vuole dialogare
sempre con la stessa istanza di un partner
 In OO si usa un object reference
 Paradigma inutilizzabile nel contesto WS
 Si ricorre all’uso dei dati (che determinano lo
stato) e dei protocolli di comunicazione
 Usiamo un business token, dichiarando la sua
struttura e la sua posizione nell’envelope
 Dichiariamo che un gruppo di attività è correlato
dicendo quali token di correlazione vengono
condivisi dalle attività (correlation set)
 All’inizio il correlation set non ha valore
 viene assegnato allo scambio di un certo messaggio
Inizio e fine di un processo
 BPEL descrive un processo con stato
 E che quindi ha un ciclo di vita
 Un processo viene istanziato implicitamente
 Attributo createInstance=YES sulla ricezione di un
messaggio (receive o pick)
 Il processo viene istanziato sempre su stimolo esterno
 Terminazione…
 Quando non c’è più nulla da fare (terminazione
implicita)
 Quando viene sollevato un fault
 Utilizzando <terminate> (terminazione anomala,
solo per processi concreti)
Attività
 Utilizzate per modellare il comportamento del
processo e degli handlers
 Attività semplici e costrutti complessi
(diramazione del flusso, sincronizzazione,
cicli)
 BPEL eredita da
 XLANG (Microsoft)
 Linguaggio strutturato
 WSFL(IBM)
 Basato su grafi
Invocazione di un servizio
 Invoke
 Invocazione di un servizio su un partner
 Invocazione asincrona
 Si specifica la variabile di input
 Invocazione sincrona
 Si specifica sia l’input che l’output
 Si può eventualmente verificare (e gestire localmente o
rilanciare) un fault
 Associabile ad un handler di compensazione (inline)
Ricezione di una richiesta
 Receive
 Ricezione di un messaggio da parte di un
partnerLink, il quale indica portType e operation
che vuole invocare
 Eventualmente si utilizza una variabile per
accogliere i dati spediti (fondamentale per un
processo concreto)
 Può istanziare il processo
 Se è l’unica attività iniziale (non preceduta da nessuno)
 Nel caso sia in parallelo con altre receive di questo tipo,
tutte devono appartenere allo stesso correlation set
 Non è possibile l’attivazione simultanea di due
receive esattamente identiche
Risposta
 Reply
 Utilizzata per rispondere ad una richiesta sincrona
(rilevata con una precedente receive)
 In caso di richiesta asincrona, l’eventuale risposta si
spedisce con una invoke
 Eventualmente associabile alla variabile
contenente la risposta
 Semantica indefinita nel caso di una reply “isolata”
 Si può specificare se si tratta di una risposta
normale o di un fault
Altre attività semplici
 Assign
 Assegna il contenuto di una variabile ad un’altra
variabile (anche tra parti di messaggi)
 Throw
 Genera un fault interno
 Wait
 Sospende il processo per un certo tempo o fino ad
una certa deadline (es. attiva una attività il tal
giorno)
 Empty
 No-op (utilizzato ad es. per catturare un fault e
non fare nulla)
Attività complesse 1/3
 Specificano il flusso di esecuzione
 Sequence
 Ordinamento sequenziale delle attività innestate
 Switch
 Scelta di uno e un solo percorso fra una serie, in
base a una condizione logica (ramo otherwise per
indicare l’else)
 Si sceglie il primo ramo valutato vero (non
deterministicamente)
 Se nessuna condizione è true e non c’è l’else si
suppone ci sia un implicito
<otherwise><empty/></otherwise>
Attività complesse 2/3
 While
 Ripetizione finchè una condizione non diventa vera
 Pick
 Mette il processo in attesa di una serie di messaggi
o di un allarme
 Attesa di un messaggio: tag onMessage (= a receive)
 Allarme: tag onAlarm (stessi attributi della wait)
 Appena scatta l’allarme o arriva uno dei messaggi
 il processo si risveglia (se arrivano due messaggi
“simultanei” scelta non deterministica)
 Il pick viene disattivato
 Può creare un’istanza del processo
 Non ci dev’essere un’allarme
Attività complesse 3/3
 Flow
 Concorrenza/sincronizzazione di attività
 Si può imporre l’ordinamento fra attività concorrenti
utilizzando dei link (reminiscenza di WSFL)
 Posso realizzare sincronizzazioni intermedie
 Ad una attività qualsiasi possiamo associare uno o
più link sia in ingresso che in uscita
 Ogni link può essere associato ad una condizione logica
A
B
A
C
E
D
F
B
sequenza
C
Links
 Un’attività è associata ad una condizione di
join sullo stato dei link entranti
 Default: true se almeno uno dei link dà valutazione
positiva
 Valutazione dei link:
 A termina tutti i suoi link uscenti sono valutati
  B dipendente da A tramite link valuta
 Se B è “strutturalmente” pronto a partire
 Se lo stato di tutti i suoi link entranti è stato valutato
 Se sì viene valutata la condizione di join
 Se vera B viene attivata
 Altrimenti viene sollevato un fault speciale
Dead Path Elimination
 Attributo (a livello di scope) per dire che non
vogliamo questo tipo di fault
 In caso di condizione di join negativa:
 L’attività B viene saltata
 Tutti i link uscenti da B vengono valutati
negativamente
 La valutazione negativa si propaga finchè
non si trova un punto in cui la condizione di
join dà riscontro positivo (DPE)
Esempio
 I link possono scavalcare le attività
strutturate (entro certi limiti ben fissati)
Join condition: C1  C2
sequence
A
B
C1
X
C
C2
Y
Compensation handlers
 Gestione a livello applicativo della
compensazione
 L’handler di compensazione non può
modificare lo stato del processo (agisce solo
sull’esterno)
 In futuro ci sarà interazione
 L’handler viene installato quando la parte di
processo a cui si riferisce è completata
 È può in seguito essere invocato con
<compensate> da
 Un fault handler
 L’handler di compensazione dello scope che lo contiene
Event handlers
 Possiamo associare a uno scope degli
eventi che
 scattano in maniera asincrona rispetto al
processo
 Attivano un’attività (complessa)
 La regola di triggering è l’arrivo di un
messaggio o un timer
 L’evento rimane sempre abilitato (può
riscattare arbitrariamente)
Estensione: processi
eseguibili
 Gestione più approfondita di
 Espressioni
 Variabili
 Assegnamenti
 Possibilità di terminare esplicitamente il
processo con <terminate>
 Maggior numero di fault
Estensione: business
protocols
 Le variabili possono essere utilizzate anche se
non inizializzate
 Potrebbero essere state manipolate da attività private
 Si possono omettere parametri nei messaggi
 Output: suppongo che siano gestiti implicitamente
 Input: il dato non mi interessa a livello pubblico
 Ipotesi sulle correlazioni…
 Assegnamento con copia da una variabile opaca
 Non sappiamo qual è il suo valore
 Ne viene preso uno non deterministicamente dal suo
spazio dei valori
Esempio
receive
Event
onMsg
initiate
Initiate
message
correlation
kill
invoke
evalClaim
terminate
pick
onMsg
Task
response
onTaskResult
onAlarm
10 days
invoke
evalClaim
end
pick
Task
response
client
Initiate
message
receive
recTaskResult
status
Initiate
message
Task
response
evaluate
claim
assign
Extract status status=‘rejected’
Rejection
handling
status=‘accepted’
Acceptance
hangling
otherwise
throw
illegalStatus
end
escalate
claim
agent
Implementazioni
 Lo standard lascia alcuni punti non specificati
 Es: al processo viene consegnato un messaggio
quando non se lo aspetta
 Lo butta via? Segnala un errore? Lo tiene in sospeso?
 Solitamente il BPEL-engine mantiene una coda in
cui inserisce i messaggi in arrivo per consumarli
quando possibile
B A
Receive A
Receive B
A
B
B
B
A
Qualche nota
 Problematiche
 Nessuna interazione con l’utente
 Nessuna possibilità di invocare attività private
 BPELJ rende possibile inserire sezioni di codice JAVA
all’interno del processo BPEL
 Descrive davvero un processo di business?
 Composizione di servizi con un approccio fortemente
centralizzato
 Ogni interazione deve per forza riguardare l’orchestratore
 Non c’è la possibilità di invocare un (sotto)processo
BPEL
WS-CDL
The Web Services Choreography Description
Language (WS-CDL) is a declarative XML-based
language that describes peer-to-peer collaborations
of participants by defining, from a global viewpoint,
their common and complementary observable
behavior; where ordered message exchanges
result in accomplishing a common business goal.
WS1
WS2
WS3
WS4
Note generali
 WS-CDL: contratto collaborativo che specifica come
i partecipanti devono interagire
 Interazione non più legata ad un centro di controllo
 Si separa l’interazione dai partecipanti
 I partecipanti devono esibire un’interfaccia di comportamento
conforme alla coreografia
 Interoperabilità garantita dall’interfaccia
 Fornisce uno strumento per superare le resistenze
ad integrare servizi propri con quelli di altre parti
 La coreografia è a tutti gli effetti un contratto
 È un linguaggio descrittivo, non eseguibile
 Non per forza i partecipanti devono essere servizi!
Panoramica di WS-CDL
 Principalmente abbiamo
 Una parte dichiarativa
 Ruoli partecipanti
 Relazioni fra ruoli (commitments)
 Canali di comunicazione fra partecipanti
 Una parte conversazionale
 Descrizione dell’interazione
 Contempla anche la possibilità di specificare
l’avanzamento della collaborazione in termini di
informazioni e stato dei partecipanti
 Che possono eventualmente sincronizzarsi
Semantica degli elementi
 WS-CDL permette di agganciare agli
elementi una descrizione
 Opzionale
 In maniera
 Testuale
 Specificando un URI
 Agganciandosi ad OWL oppure RDF
Parte dichiarativa
 Descrizione delle funzionalità e dei legami
che i peer devono esibire per poter
collaborare
 roleType
 Ruolo che un peer può giocare
 Enumera una serie di comportamenti che il ruolo
esibisce
 Ogni comportamento può essere opzionalmente
agganciato a un’interfaccia WSDL
 participantType
 Collezione dei ruoli assunti da un partecipante
Relazioni
 relationshipType
 Relazione tra due ruoli che interagiranno
(mutual commitments)
 Si possono anche inserire esplicitamente quali
comportamenti sono richiesti dalla relazione
(default: tutti quelli del ruolo)
 Ovviamente un partecipante può
partecipare alla relazione se realizza il
ruolo richiesto
Canali 1/2
 Identificano come e dove scambiarsi
informazioni per realizzare la collaborazione
 I canali possono essere passati come
argomenti di un messaggio (PI calcolo…)
 Comunicazione dinamica
 Esempio
 il cliente spedisce il “canale di consegna” al provider
 Il provider effettua il forward al fornitore
 Il fornitore utilizza questo canale per spedire il bene al
cliente (che prima non conosceva)
 Il canale può vincolare il suo uso
 Numero massimo di messaggi supportati
 Restrizione delle informazioni trasportabili (canali compresi)
Canali 2/2
 Utilizzo possibile di un canale
 Once: una volta da un partecipante
 Distinct: più volte da un partecipante
 Shared: più volte da più partecipanti
 Azioni:
 Receive, Respond o Receive/Respond
 Associato al ruolo (comportamento) che chi lo
utilizza deve esibire
 Specifica vincoli sui messaggi che possono
transire
 Eventualmente agganciandosi ad altri canali
Esempio
<channelType name=“OrderChannel”
action=“request”
usage=“distinct”>
<roleType typeRef=“Supplier”/>
Messaggi accettati
<identity usage="primary">
dal canale:
<token name="OrderId" />
•All’inizio solo
</identity>
messaggi contenenti
<identity usage="alternate"> OrderID
•Poi messaggi
<token name="TxnId" />
contenenti OrderID
</identity>
o TxnId
</channelType>
Variabili
 Utilizzate per più scopi
 Memorizzare le informazioni scambiate via messaggi
 Catturare lo stato di un partecipante
 Es: quando il cliente spedisce l’ordine salva in una variabile
di stato ORDER_SENT
 Descrivere i canali (politiche, URL, …)
 Variabili globali o relative a un ruolo
 Se due ruoli di un partecipante def. la stessa c’è
condivisione
 Attributi per specificare
 Politiche di lettura/scrittura della variabile
 Passaggio di variabili da una sotto-coreografia
 Token referenziano parti di variabili (via Xpath)
Coreografie
 Definiscono i contratti di interazione
 Attività, eccezioni, finalizers
 Nel documento si inseriscono una o più toplevel choreographies
 Una può essere dichiarata root (abilitata per
default)
 Le altre vengono abilitate quando eseguite
 Una coreografia può richiamarne un’altra
(riusabilità)
 O definita localmente
 O richiamandone una di top-level (o esterna)
Coreografia - attributi
 Coordinamento
 indica che tutti i partecipanti devono essere
d’accordo su come la coreografia è terminata
 Eventualmente con un coordination protocol
 Isolamento
 Indica che le variabili utilizzate dalla coreografia
sono visibili dalle altre solo quando termina
 Altrimenti c’è condivisione delle variabili
Linea di vita
father successfully completed
no more activity enabled
initiator interaction performed
waiting
enabled
exception
(catched)
Complete condition==true
succesfully
completed
no
finalizer
exception
(propagated)
unsuccesfully
completed exceptionBlock completed
finalizerBlock
completed
closed
Enclosing
choreographies
closed
Interaction
 Attività fondamentale
 Modella lo scambio di informazioni tra partecipanti
ed eventuale sincronizzazione del proprio stato
osservabile
 Consiste nell’invio di un messaggio
 Associata a




Coppia di ruoli coinvolti e canale
Operazione richiesta al ricevente
Informazione scambiata
Variabili utilizzate da sender e receiver per lo
scambio
 Eventuali variabili di stato che reagiscono
all’interazione
Allineamento
 Indica la necessità di avere concordanza sugli
effetti di un’interazione su sender e receiver
 Controllando la coerenza nella modifica delle variabili
di stato
 Verificando la consistenza delle variabili che
memorizzano l’info scambiata
 I partecipanti possono capire che il messaggio è
stato effettivamente consegnato
 Esempio: buyer e seller vogliono verificare che dopo
l’effettuazione di un ordine
 orderState(Buyer)=‘Sent’ e orderState(Seller)=‘Received’
 Le variabili order(Buyer) e order(Seller) hanno = contenuto
Interaction - exchange
 Exchange (scambio di informazioni)
 Specifica del fault (compatibilità con WSDL)
 Request o respond
 Info scambiate
 Send: cosa viene inviato
 Receive: cosa viene ricevuto
 Eventuale time-out
 Record riferiti dall’exchange e/o dal time-out
 Manipolazione di variabili dicendo quando e come
 Nota: se più di una respond scelta implicita
Esempio
<exchange name="request" informationType="tns:purchaseOrderType”
action="request">
<send variable="cdl:getVariable('tns:purchaseOrder','','')" />
<receive variable="cdl:getVariable('tns:purchaseOrder','','')"
recordReference="record-the-channel-info" />
</exchange>
<exchange name="response"
informationType="purchaseOrderAckType"
action="respond">
<send variable="cdl:getVariable('tns:purchaseOrderAck','','')" />
<receive variable="cdl:getVariable('tns:purchaseOrderAck','','')" />
</exchange>
<exchange name="badPurchaseOrderAckException”
faultName="badPurchaseOrderAckException”
informationType="badPOAckType”action="respond">
<send variable="cdl:getVariable('tns:badPurchaseOrderAck','','')"
causeException="tns:badPOAck" />
<receive variable="cdl:getVariable('tns:badPurchaseOrderAck','','')"
causeException="tns:badPOAck" />
</exchange>
Performance
 Indica che si passa a eseguire una nuova
coreografia (enclosed)
 Non devono esistere dipendenze cicliche
 Fase di bind in cui si legano variabili del
chiamante a quelle del chiamato
 Attributo block
 Truesi attende la fine della enclosed
choreography
 Falsel’enclosed choreography viene attivata in
parallelo col flusso del chiamante
 Se il chiamante termina con successo l’enclosed termina
automaticamente con successo
Altre attività semplici
 Assign (~BPEL)
 silentAction
 Il ruolo esegue un’operazione non
osservabile dall’esterno
 noAction (empty in BPEL)
 Nota: se il ruolo non viene specificato
vuol dire che riguarda tutti…
Workunit
 Unità di lavoro
 Attività preceduta da un vincolo
 condizione che deve essere verificata affinchè la
collaborazione possa continuare
 Solo se (o quando) il vincolo è soddisfatto l’attività
viene abilitata
 Attributo block
 Si testa la condizione o si attende finchè non
diventa vera
 Attributo repeat (modellazione di cicli)
 Indica che quando la workunit è terminata si
considera di nuovo la condizione
Funzioni specifiche
 Funzioni richiamabili nelle condizioni
 Data/ora corrente
 Si suppone che gli orologi siano più o meno
sincronizzati
 Test su deadline/timer
 Conoscenza dello stato della coreografia
 Gestione delle variabili
 Recupero valore o attesa disponibilità
 Test sull’allineamento
 Trigger globali
 Variabili di diversi ruoli
Esempi
<workunit name="WaitForAlignment"
guard="cdl:variablesAligned(
'PurchaseOrderAtBuyer',
'PurchaseOrderAtSeller',
'tns:Customer-Retailer-Relationship')"
block="true" >
<!--some activity -->
False se la
</workunit>
variabile non è
disponibile
<workunit name="StockCheck"
guard="cdl:getVariable(
'StockQuantity','','/Product/Qty','tns:Retailer')
>10"
block="false" >
<!--some activity -->
</workunit>
Ordering Structures
 Sequence
 Parallel
 Choice
 Mutua esclusione classica (deferred)
 Quando viene scelto un ramo gli altri sono disabilitati
 Se i rami contengono workunits con guardie
 Si possono realizzare punti decisionali
 La prima workunit che fa match (se più d’una non
determinismo) determina la scelta
Eccezioni
 Coreografia associata a una o più exception
workunit
 Non bloccanti e non cicliche
 Default: nessuna guardia
 Altrimenti si esprime l’interesse per una certa
eccezione (funzione apposita)
 Le workunit sono abilitate quando viene
abilitato l’exceptionBlock
 Meccanismo di match (se più di una non
determinsmo) o propagazione
 L’eccezione può leggere le variabili
Finalization
 Quando la coreografia termina con
successo
 Può essere invocato uno fra una serie di
finalizerBlocks
 Gestiscono la compensazione della coreografia
 commit, undo, cancel, rollback applicativi
 I finalizer si distinguono per nome e ne
viene scelto uno solo
Coordinamento 1/2
 Garantisce che tutti i ruoli siano
d’accordo su come la coreografia è
terminata
 Indica che un insieme di interazioni è
allineato (conoscenza condivisa)
 Tutti i ruoli sanno che la coreografia è
terminata con successo o meno
 L’accordo viene raggiunto con un
coordination protocol
Coordinamento 2/2
 Nel caso di enclosed choreography l’accordo
è anche sull’eventuale finalizer
 Se non c’è coordinamento viene sollevata
un’eccezione
 Se la coreografia termina con un eccezione e
alcuni ruoli non se ne accorgono, il protocollo
di coordinamento solleva un’eccezione su
questi
Esempio 1/3
Warehouse
Retailer
r4w
w4r
r4c
w4c
c4r
c4w
Consumer
Esempio 2/3
sequence
Interaction handlePO
POc
POackc
POreq
POr
POresp
POackr
Interaction handlePO
RWreq
POr
okR
RWresp
assign
okR
result
clientSatisfied
POw
okW
Esempio 3/3
NON NOTO A PRIORI
choice
workunit block=false repeat=false guard=boolean(customerSatisfied)
Interaction handlePOResponse
POResp
POResp
POposResp
perform CWchoreo
La warehouse invia una ricevuta al consumer
(estraendo il canale dal messaggio precedentemente ricevuto dal retailer)
workunit block=false repeat=false guard=not(boolean(customerSatisfied))
Interaction handlePOResponse
POResp
POResp
POnegResp
Qualche spunto…1/2
 Van der Aalst. Life After BPEL?
 Sostiene che BPEL astratto è una forzatura
 Serve un linguaggio dichiarativo
 Indica tre importanti topic
 Process mining
 Riscostruzione di un processo da un event log
 Conformance testing
 Verifica di compliance su un event log
 Mediation
 Adattamento di un servizio in modo da permettergli di
partecipare a una coreografia
 Conformance test ++
Qualche spunto…2/2
 Barros, Dumas, Oaks. A critical overview of WS-CDL
 Topic
 Separare il meta-modello di coreografia dall’XML
 Ricondurre WS-CDL a un linguaggio formale
 Per la verifica di proprietà
 Per la verifica di conformance
 Supporto di interazioni multi-party e multi-instance
 Rapporto con BPEL
 Come mappare le workunit sui costrutti BPEL?
 Necessità di definire un core unitario
 Notazione grafica per esprimere la coreografia a
livello alto