Orchestrazione e coreografia BPEL vs WS-CDL

1
Orchestrazione e coreografiaBPEL vs WS-CDL
2
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 uninterfaccia
  pubblica
• Devo poter modificare limplementazione di un
  servizio senza toccare gli altri
• Trasparenti rispetto alla locazione
• Recuperabili interrogando un repository

3
Basic SOA
Service Provider
Bind
Publish
Service Client
Service Registry
Find
4
Web Services
XML XSD
Caso tipico HTTP
Service Provider
WSDL
Messaggi SOAP
Bind
Publish
UDDI
Service Client
Service Registry
Find
5
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-ReliableMessagin
g
Transport HTTP, SMTP, HTTPS
Format XML
6
Simple Object Access Protocol

• Protocollo indipendente dal livello di trasporto
  per lo scambio di documenti XML-based
• Messaggio SOAP
• Header con informazioni aggiuntive -
  infrastrutturali (es gestione della sicurezza)
• Body con il messaggio da comunicare
• Fault per leventuale gestione di errori e
  eccezioni

Envelope
Header
Body
Document Messaggio, parametri, valori
Fault
7
Modalità di interazione

• Determinate dallencoding 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

8
Web Services Description Language 1/3

• Dialetto XML per la descrizione dellinterfaccia
  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)

9
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 unattività supportata
  dal servizio
• si aggancia a messaggi
• Interface (o Port Type) insieme di operazioni
  astratte

10
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 uninterfaccia
• Port (Endpoint)
• Specifica lindirizzo per legarsi al servizio
• Service
• aggregazione di un insieme di porte

11
Esempio 1/2

• Tipo
• ltelement nameTradePricegt
• ltcomplexTypegt
• ltallgt
• ltelement nameprice typefloat/gt
• lt/allgt
• lt/complexTypegt
• lt/elementgt
• Messaggio
• ltmessage nameGetLastTradePriceOutputgt
• ltpart namebody elementxsdlTradePrice/gt
• lt/messagegt

12
Esempio 2/2

• portType (request-response)
• ltportType nameStockQuotePortTypegt
• ltoperation nameGetLastTradePricegt
• ltinput messagetnsGetLastTradePriceInput/gt
  
• ltoutput messagetnsGetLastTradePriceOutput
  /gt
• lt/operationgt
• lt/portTypegt

13
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 allendpoint
• Request response
• Lendpoint riceve un messaggio ed emette in
  output una risposta
• Solicit response (?)
• Lendpoint invia un messaggio al client
  (sollecitazione) e attende un messaggio di
  risposta
• Notification (?)
• Lendpoint invia un messaggio di notifica in
  output

14
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 lobiettivo della
  composizione
• Linterfaccia di comportamento di un servizio
  rappresenta la parte del servizio che interagisce
  con lesterno

15
Business Process Execution Language (for Web
Services)

• Linguaggio XML-based per lorchestrazione 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 dallIBM
• A partire da una serie di servizi stateless
  costruisco un processo con stato
• che può eventualmente esporsi a sua volta come
  servizio

16
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

17
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

18
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 listanza con cui si
  interagirà

19
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
  linnestamento)
• Variabili o globali o valide allinterno 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)

20
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 alluso dei dati (che determinano lo
  stato) e dei protocolli di comunicazione
• Usiamo un business token, dichiarando la sua
  struttura e la sua posizione nellenvelope
• Dichiariamo che un gruppo di attività è correlato
  dicendo quali token di correlazione vengono
  condivisi dalle attività (correlation set)
• Allinizio il correlation set non ha valore
• viene assegnato allo scambio di un certo
  messaggio

21
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 createInstanceYES 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 ltterminategt (terminazione anomala,
  solo per processi concreti)

22
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

23
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 linput che loutput
• Si può eventualmente verificare (e gestire
  localmente o rilanciare) un fault
• Associabile ad un handler di compensazione
  (in-line)

24
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 è lunica 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 lattivazione simultanea di due
  receive esattamente identiche

25
Risposta

• Reply
• Utilizzata per rispondere ad una richiesta
  sincrona (rilevata con una precedente receive)
• In caso di richiesta asincrona, leventuale
  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

26
Altre attività semplici

• Assign
• Assegna il contenuto di una variabile ad unaltra
  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)

27
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 lelse)
• Si sceglie il primo ramo valutato vero (non
  deterministicamente)
• Se nessuna condizione è true e non cè lelse si
  suppone ci sia un implicito ltotherwisegtltempty/gtlt/o
  therwisegt

28
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 lallarme o arriva uno dei messaggi
• il processo si risveglia (se arrivano due
  messaggi simultanei scelta non deterministica)
• Il pick viene disattivato
• Può creare unistanza del processo
• Non ci devessere unallarme

29
Attività complesse 3/3

• Flow
• Concorrenza/sincronizzazione di attività
• Si può imporre lordinamento 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

30
Links

• Unattività è 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

31
Dead Path Elimination

• Attributo (a livello di scope) per dire che non
  vogliamo questo tipo di fault
• In caso di condizione di join negativa
• Lattività 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)

32
Esempio

• I link possono scavalcare le attività strutturate
  (entro certi limiti ben fissati)

Join condition C1 ? C2
sequence
A
B
C
C1
C2
X
Y
33
Compensation handlers

• Gestione a livello applicativo della
  compensazione
• Lhandler di compensazione non può modificare lo
  stato del processo (agisce solo sullesterno)
• In futuro ci sarà interazione
• Lhandler viene installato quando la parte di
  processo a cui si riferisce è completata
• È può in seguito essere invocato con ltcompensategt
  da
• Un fault handler
• Lhandler di compensazione dello scope che lo
  contiene

34
Event handlers

• Possiamo associare a uno scope degli eventi che
• scattano in maniera asincrona rispetto al
  processo
• Attivano unattività (complessa)
• La regola di triggering è larrivo di un
  messaggio o un timer
• Levento rimane sempre abilitato (può riscattare
  arbitrariamente)

35
Estensione processi eseguibili

• Gestione più approfondita di
• Espressioni
• Variabili
• Assegnamenti
• Possibilità di terminare esplicitamente il
  processo con ltterminategt
• Maggior numero di fault

36
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

37
Esempio
correlation
client
pick
end pick
evaluate claim
agent
escalate claim
38
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
B
A
A
Receive A
B
A
Receive B
B
39
Qualche nota

• Problematiche
• Nessuna interazione con lutente
• Nessuna possibilità di invocare attività private
• BPELJ rende possibile inserire sezioni di codice
  JAVA allinterno del processo BPEL
• Descrive davvero un processo di business?
• Composizione di servizi con un approccio
  fortemente centralizzato
• Ogni interazione deve per forza riguardare
  lorchestratore
• Non cè la possibilità di invocare un
  (sotto)processo BPEL

40
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
41
Note generali

• WS-CDL contratto collaborativo che specifica
  come i partecipanti devono interagire
• Interazione non più legata ad un centro di
  controllo
• Si separa linterazione dai partecipanti
• I partecipanti devono esibire uninterfaccia di
  comportamento conforme alla coreografia
• Interoperabilità garantita dallinterfaccia
• 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!

42
Panoramica di WS-CDL

• Principalmente abbiamo
• Una parte dichiarativa
• Ruoli partecipanti
• Relazioni fra ruoli (commitments)
• Canali di comunicazione fra partecipanti
• Una parte conversazionale
• Descrizione dellinterazione
• Contempla anche la possibilità di specificare
  lavanzamento della collaborazione in termini di
  informazioni e stato dei partecipanti
• Che possono eventualmente sincronizzarsi

43
Semantica degli elementi

• WS-CDL permette di agganciare agli elementi una
  descrizione
• Opzionale
• In maniera
• Testuale
• Specificando un URI
• Agganciandosi ad OWL oppure RDF

44
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 uninterfaccia WSDL
• participantType
• Collezione dei ruoli assunti da un partecipante

45
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

46
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)

47
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

48
Esempio

• ltchannelType nameOrderChannel
• actionrequest
• usagedistinctgt
• ltroleType typeRefSupplier/gt
• ltidentity usage"primary"gt
• lttoken name"OrderId" /gt
• lt/identitygt
• ltidentity usage"alternate"gt
• lttoken name"TxnId" /gt
• lt/identitygt
• lt/channelTypegt

• Messaggi accettati dal canale
• Allinizio solo messaggi contenenti OrderID
• Poi messaggi contenenti OrderID o TxnId

49
Variabili

• Utilizzate per più scopi
• Memorizzare le informazioni scambiate via
  messaggi
• Catturare lo stato di un partecipante
• Es quando il cliente spedisce lordine 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)

50
Coreografie

• Definiscono i contratti di interazione
• Attività, eccezioni, finalizers
• Nel documento si inseriscono una o più top-level
  choreographies
• Una può essere dichiarata root (abilitata per
  default)
• Le altre vengono abilitate quando eseguite
• Una coreografia può richiamarne unaltra
  (riusabilità)
• O definita localmente
• O richiamandone una di top-level (o esterna)

51
Coreografia - attributi

• Coordinamento
• indica che tutti i partecipanti devono essere
  daccordo 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

52
Linea di vita
father successfully completed
no more activity enabled
waiting
enabled
succesfully completed
initiator interaction performed
Complete conditiontrue
no finalizer
exception (catched)
exception (propagated)
finalizerBlock completed
unsuccesfully completed
closed
exceptionBlock completed
Enclosing choreographies closed
53
Interaction

• Attività fondamentale
• Modella lo scambio di informazioni tra
  partecipanti ed eventuale sincronizzazione del
  proprio stato osservabile
• Consiste nellinvio 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
  allinterazione

54
Allineamento

• Indica la necessità di avere concordanza sugli
  effetti di uninterazione su sender e receiver
• Controllando la coerenza nella modifica delle
  variabili di stato
• Verificando la consistenza delle variabili che
  memorizzano linfo scambiata
• I partecipanti possono capire che il messaggio è
  stato effettivamente consegnato
• Esempio buyer e seller vogliono verificare che
  dopo leffettuazione di un ordine
• orderState(Buyer)Sent e orderState(Seller)Rec
  eived
• Le variabili order(Buyer) e order(Seller) hanno
  contenuto

55
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 dallexchange e/o dal time-out
• Manipolazione di variabili dicendo quando e come
• Nota se più di una respond scelta implicita

56
Esempio

• ltexchange name"request" informationType"tnspurc
  haseOrderType
• action"request"gt
• ltsend variable"cdlgetVariable('tnspurchaseOrd
  er','','')" /gt ltreceive
  variable"cdlgetVariable('tnspurchaseOrder','','
  ')" recordReference"record-the
  -channel-info" /gt
• lt/exchangegt
• ltexchange name"response"
  informationType"purchaseOrderAckType"
  action"respond"gt
• ltsend variable"cdlgetVariable('tnspurchaseOrd
  erAck','','')" /gt
• ltreceive variable"cdlgetVariable('tnspurchase
  OrderAck','','')" /gt
• lt/exchangegt
• ltexchange name"badPurchaseOrderAckException
• faultName"badPurchaseOrderAckException
• informationType"badPOAckTypeaction"respond"gt
  
• ltsend variable"cdlgetVariable('tnsbadPurchase
  OrderAck','','')"
  causeException"tnsbadPOAck" /gt
• ltreceive variable"cdlgetVariable('tnsbadPurch
  aseOrderAck','','')"
  causeException"tnsbadPOAck" /gt
• lt/exchangegt

57
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?lenclosed choreography viene attivata in
  parallelo col flusso del chiamante
• Se il chiamante termina con successo lenclosed
  termina automaticamente con successo

58
Altre attività semplici

• Assign (BPEL)
• silentAction
• Il ruolo esegue unoperazione non osservabile
  dallesterno
• noAction (empty in BPEL)
• Nota se il ruolo non viene specificato vuol dire
  che riguarda tutti

59
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
  lattività 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

60
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 sullallineamento
• Trigger globali
• Variabili di diversi ruoli

61
Esempi

• ltworkunit name"WaitForAlignment"
  guard"cdlvariablesAligned(
  'PurchaseOrderAtBuyer',
• 'PurchaseOrderAtSeller',
• 'tnsCustomer-Retailer-Relationship
  ')"
• block"true" gt
• lt!--some activity --gt
• lt/workunitgt
• ltworkunit name"StockCheck"
  guard"cdlgetVariable(
• 'StockQuantity','','/Product/Qty','tnsRetailer')
  
• gt10"
• block"false" gt
• lt!--some activity --gt
• lt/workunitgt

False se la variabile non è disponibile
62
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ù duna non
  determinismo) determina la scelta

63
Eccezioni

• Coreografia associata a una o più exception
  workunit
• Non bloccanti e non cicliche
• Default nessuna guardia
• Altrimenti si esprime linteresse per una certa
  eccezione (funzione apposita)
• Le workunit sono abilitate quando viene abilitato
  lexceptionBlock
• Meccanismo di match (se più di una non
  determinsmo) o propagazione
• Leccezione può leggere le variabili

64
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

65
Coordinamento 1/2

• Garantisce che tutti i ruoli siano daccordo 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
• Laccordo viene raggiunto con un coordination
  protocol

66
Coordinamento 2/2

• Nel caso di enclosed choreography laccordo è
  anche sulleventuale finalizer
• Se non cè coordinamento viene sollevata
  uneccezione
• Se la coreografia termina con un eccezione e
  alcuni ruoli non se ne accorgono, il protocollo
  di coordinamento solleva uneccezione su questi

67
Esempio 1/3
Warehouse
Retailer
r4w
w4r
r4c
w4c
Consumer
c4r
c4w
68
Esempio 2/3
sequence
69
Esempio 3/3
NON NOTO A PRIORI
choice
workunit blockfalse repeatfalse
guardboolean(customerSatisfied)
workunit blockfalse repeatfalse
guardnot(boolean(customerSatisfied))
70
Qualche spunto1/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

71
Qualche spunto2/2

• Barros, Dumas, Oaks. A critical overview of
  WS-CDL
• Topic
• Separare il meta-modello di coreografia dallXML
• 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

72
(No Transcript)