Orchestrazione e coreografia BPEL vs WS-CDL - PowerPoint PPT Presentation

About This Presentation
Title:

Orchestrazione e coreografia BPEL vs WS-CDL

Description:

BPEL vs WS-CDL Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute Eseguono unit di lavoro discrete non posso ... – PowerPoint PPT presentation

Number of Views:19
Avg rating:3.0/5.0
Slides: 73
Provided by: MarcoM78
Category:

less

Transcript and Presenter's Notes

Title: 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)
Write a Comment
User Comments (0)
About PowerShow.com