+ All Categories
Home > Documents > Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su...

Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su...

Date post: 01-May-2015
Category:
Upload: franco-capasso
View: 216 times
Download: 3 times
Share this document with a friend
72
Orchestrazione e coreografia BPEL vs WS-CDL
Transcript
Page 1: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Orchestrazione e coreografiaBPEL vs WS-CDL

Orchestrazione e coreografiaBPEL vs WS-CDL

Page 2: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Service Oriented ArchitectureService 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

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

Page 3: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Basic SOABasic SOA

ServiceProvider

ServiceClient

ServiceRegistry

Bind

Find

Publish

Page 4: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Web ServicesWeb Services

ServiceProvider

ServiceClient

ServiceRegistry

Bind

Find

PublishWSDL

UDDI

MessaggiSOAP

XMLXSD Caso tipico

HTTP

Page 5: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

WS StackWS Stack

TransportHTTP, SMTP, HTTPS

FormatXML

DescriptionWSDL, WS-Policy

AdvertisementUDDI

MessagingSOAP, WS-Addressing, WS-ReliableMessaging

Coordination - Context - Transactions - SecurityWS-Coordination, WS-AtomicTransactions, WS-Security, …

Composition - ProcessesBPEL, BPELJ, WS-CDL

Page 6: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Simple Object Access Protocol

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 l’eventuale gestione di errori e eccezioni

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 l’eventuale gestione di errori e eccezioni

Envelope

Header

Body

DocumentMessaggio, parametri,

valori

Fault

Page 7: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Modalità di interazioneModalità 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

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

Page 8: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Web Services Description Language 1/3

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)

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)

Page 9: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

WSDL 2/3WSDL 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

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

Page 10: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

WSDL 3/3WSDL 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

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

Page 11: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Esempio 1/2Esempio 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>

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>

Page 12: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Esempio 2/2Esempio 2/2

portType (request-response)<portType name=“StockQuotePortType”>

<operation name=“GetLastTradePrice”>

<input message=“tns:GetLastTradePriceInput”/>

<output message=“tns:GetLastTradePriceOutput”/>

</operation>

</portType>

portType (request-response)<portType name=“StockQuotePortType”>

<operation name=“GetLastTradePrice”>

<input message=“tns:GetLastTradePriceInput”/>

<output message=“tns:GetLastTradePriceOutput”/>

</operation>

</portType>

Page 13: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Modalità di interazioneModalità 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

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

Page 14: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Composizione di serviziComposizione 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

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

Page 15: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Business Process Execution Language (for Web Services)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

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

Page 16: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Le due visioni di BPELLe 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

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

Page 17: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Parti fondamentaliParti 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

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

Page 18: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Partner del processoPartner 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à

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à

Page 19: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

DatiDati

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)

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)

Page 20: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

CorrelazioneCorrelazione 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

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

Page 21: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Inizio e fine di un processoInizio 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)

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)

Page 22: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Attività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

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

Page 23: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Invocazione di un servizioInvocazione 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 (in-

line)

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 (in-

line)

Page 24: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Ricezione di una richiestaRicezione 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

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

Page 25: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

RispostaRisposta

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

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

Page 26: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Altre attività sempliciAltre 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)

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)

Page 27: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Attività complesse 1/3Attività 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>

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>

Page 28: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Attività complesse 2/3Attività 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

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

Page 29: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Attività complesse 3/3Attività 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

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

B

A

E

C D F

A

C

B

sequenza

Page 30: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

LinksLinks

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

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

Page 31: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Dead Path EliminationDead 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)

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)

Page 32: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

EsempioEsempio I link possono scavalcare le attività

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

strutturate (entro certi limiti ben fissati)

A B C

X Y

C2C1

Join condition: C1 C2sequence

Page 33: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Compensation handlersCompensation 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

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

Page 34: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Event handlersEvent 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)

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)

Page 35: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Estensione: processi eseguibili

Estensione: processi eseguibili

Gestione più approfondita di Espressioni Variabili Assegnamenti

Possibilità di terminare esplicitamente il processo con <terminate>

Maggior numero di fault

Gestione più approfondita di Espressioni Variabili Assegnamenti

Possibilità di terminare esplicitamente il processo con <terminate>

Maggior numero di fault

Page 36: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Estensione: business protocols

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

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

Page 37: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

EsempioEsempio

client

agent

onMsgonTaskResult

Taskresponse

assignExtract status

Taskresponse

status

escalateclaim

evaluateclaim

receiverecTaskResult

Taskresponse

receiveinitiate

Initiatemessage

invokeevalClaim

Initiatemessage

invokeevalClaim

Initiatemessage

pick

endpick

Rejectionhandling

Acceptancehangling

throwillegalStatus

end

otherwise

status=‘accepted’

status=‘rejected’

onAlarm10 days

EventonMsg

kill

terminate

correlation

Page 38: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

ImplementazioniImplementazioni

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

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

Receive A

Receive B A

BB

B

AA

B

Page 39: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Qualche notaQualche 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

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

Page 40: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

WS-CDLWS-CDLThe 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.

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

WS4

WS3

Page 41: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Note generaliNote 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!

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!

Page 42: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Panoramica di WS-CDLPanoramica 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

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

Page 43: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Semantica degli elementiSemantica degli elementi

WS-CDL permette di agganciare agli elementi una descrizione Opzionale In maniera

Testuale Specificando un URI Agganciandosi ad OWL oppure RDF

WS-CDL permette di agganciare agli elementi una descrizione Opzionale In maniera

Testuale Specificando un URI Agganciandosi ad OWL oppure RDF

Page 44: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Parte dichiarativaParte 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

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

Page 45: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

RelazioniRelazioni

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

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

Page 46: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Canali 1/2Canali 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)

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)

Page 47: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Canali 2/2Canali 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

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

Page 48: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

EsempioEsempio

<channelType name=“OrderChannel” action=“request”

usage=“distinct”><roleType typeRef=“Supplier”/>

<identity usage="primary"> <token name="OrderId" />

</identity><identity usage="alternate">

<token name="TxnId" /></identity>

</channelType>

<channelType name=“OrderChannel” action=“request”

usage=“distinct”><roleType typeRef=“Supplier”/>

<identity usage="primary"> <token name="OrderId" />

</identity><identity usage="alternate">

<token name="TxnId" /></identity>

</channelType>

Messaggi accettati dal canale:•All’inizio solo messaggi contenenti OrderID•Poi messaggi contenenti OrderID o TxnId

Page 49: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

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

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)

Page 50: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

CoreografieCoreografie

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 un’altra (riusabilità) O definita localmente O richiamandone una di top-level (o esterna)

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 un’altra (riusabilità) O definita localmente O richiamandone una di top-level (o esterna)

Page 51: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Coreografia - attributiCoreografia - 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

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

Page 52: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Linea di vitaLinea di vita

waiting enabled

exception(catched)

unsuccesfullycompleted closed

initiator interaction performed

exceptionBlock completed

nofinalizer

succesfullycompleted

finalizerBlockcompleted

Complete condition==true

exception(propagated)

father successfully completed

no more activity enabled

Enclosingchoreographies

closed

Page 53: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

InteractionInteraction 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

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

Page 54: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

AllineamentoAllineamento

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

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

Page 55: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Interaction - exchangeInteraction - 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

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

Page 56: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

EsempioEsempio<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>

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

Page 57: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

PerformancePerformance

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 Truesi attende la fine della enclosed choreography Falsel’enclosed choreography viene attivata in

parallelo col flusso del chiamante Se il chiamante termina con successo l’enclosed termina

automaticamente con successo

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 Truesi attende la fine della enclosed choreography Falsel’enclosed choreography viene attivata in

parallelo col flusso del chiamante Se il chiamante termina con successo l’enclosed termina

automaticamente con successo

Page 58: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Altre attività sempliciAltre 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…

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…

Page 59: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

WorkunitWorkunit

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

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

Page 60: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Funzioni specificheFunzioni 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

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

Page 61: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

EsempiEsempi

<workunit name="WaitForAlignment" guard="cdl:variablesAligned(

'PurchaseOrderAtBuyer','PurchaseOrderAtSeller',

'tns:Customer-Retailer-Relationship')" block="true" >

<!--some activity --></workunit>

<workunit name="StockCheck" guard="cdl:getVariable('StockQuantity','','/Product/Qty','tns:Retailer')

>10"block="false" >

<!--some activity --></workunit>

<workunit name="WaitForAlignment" guard="cdl:variablesAligned(

'PurchaseOrderAtBuyer','PurchaseOrderAtSeller',

'tns:Customer-Retailer-Relationship')" block="true" >

<!--some activity --></workunit>

<workunit name="StockCheck" guard="cdl:getVariable('StockQuantity','','/Product/Qty','tns:Retailer')

>10"block="false" >

<!--some activity --></workunit>

False se la variabile non è

disponibile

Page 62: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Ordering StructuresOrdering 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

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

Page 63: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

EccezioniEccezioni

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

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

Page 64: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

FinalizationFinalization

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

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

Page 65: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Coordinamento 1/2Coordinamento 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

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

Page 66: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Coordinamento 2/2Coordinamento 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

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

Page 67: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Retailer

Consumer

Warehouse

Esempio 1/3Esempio 1/3

r4w

r4c

c4r c4w

w4r

w4c

Page 68: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

assign

okR

resultclientSatisfied

Esempio 2/3Esempio 2/3

Interaction handlePO

POc POrPOreq

POackrPOackcPOresp

POr POwRWreq

okWokRRWresp

Interaction handlePO

sequence

Page 69: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

choice

Esempio 3/3Esempio 3/3

workunit block=false repeat=false guard=boolean(customerSatisfied)

workunit block=false repeat=false guard=not(boolean(customerSatisfied))

Interaction handlePOResponse

POnegRespPORespPOResp

Interaction handlePOResponse

POposRespPORespPOResp

La warehouse invia una ricevuta al consumer(estraendo il canale dal messaggio precedentemente ricevuto dal retailer)

perform CWchoreo

NON NOTO A PRIORI

Page 70: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Qualche spunto…1/2Qualche 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 ++

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 ++

Page 71: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Qualche spunto…2/2Qualche 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

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

Page 72: Orchestrazione e coreografia BPEL vs WS-CDL. Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute.

Recommended