Orchestrazione e coreografia BPEL vs WS-CDL

Service Oriented Architecture Architettura basata su servizi Servizi Funzioni di business auto-contenute Eseguono unità di lavoro discrete non posso invocare un servizio “a metà” Indipendenti dalla tecnologia (interoperabilità) Invocabili utilizzando standard di comunicazione Disaccoppiati Si conoscono unicamente tramite un’interfaccia pubblica Devo poter modificare l’implementazione di un servizio senza toccare gli altri Trasparenti rispetto alla locazione Recuperabili interrogando un repository

Basic SOA Service Provider Publish Bind Service Registry Service Client Find

Web Services XML XSD Caso tipico HTTP Service Provider WSDL Messaggi SOAP Publish Bind UDDI Service Registry Service Client Find

Composition - Processes WS Stack Composition - Processes BPEL, BPELJ, WS-CDL Coordination - Context - Transactions - Security WS-Coordination, WS-AtomicTransactions, WS-Security, … Description WSDL, WS-Policy Advertisement UDDI Messaging SOAP, WS-Addressing, WS-ReliableMessaging Transport HTTP, SMTP, HTTPS Format XML

Simple Object Access Protocol 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 Document Messaggio, parametri, valori Fault

Modalità di interazione Determinate dall’encoding SOAP Tipo di interazione Tipo di codifica Due modalità fondamentali: RPC (sempre meno utilizzata) Document-based (message passing) Si tende a realizzare una invocazione con risultato con una coppia di messaggi ma non c’è più attesa del cliente

Web Services Description Language 1/3 Dialetto XML per la descrizione dell’interfaccia pubblica di un servizio Cosa fa il servizio (operazioni e relativi parametri) Dove si trova Come si invoca La descrizione si compone di una parte astratta (interfaccia) e di una concreta (realizzazione del servizio)

WSDL 2/3 Parte astratta Messaggio Operation informazione effettivamente scambiata tra requestor e provider (per input, output, fault) Associato a parametri Tipi XSD Operation descrizione astratta di un’attività supportata dal servizio si aggancia a messaggi Interface (o Port Type) = insieme di operazioni astratte

WSDL 3/3 Parte concreta Types Binding Port (Endpoint) Service definizione dei tipi (tramite XSD) Binding Specifica i protocolli di comunicazione e i formati dei dati per le operazioni e i messaggi definiti da un’interfaccia Port (Endpoint) Specifica l’indirizzo per legarsi al servizio Service aggregazione di un insieme di porte

Esempio 1/2 Tipo Messaggio <element name=“TradePrice”> <complexType> <all> <element name=“price” type=“float”/> </all> </complexType> </element> Messaggio <message name=“GetLastTradePriceOutput”> <part name=“body” element=“xsdl:TradePrice”/> </message>

Esempio 2/2 portType (request-response) <portType name=“StockQuotePortType”> <operation name=“GetLastTradePrice”> <input message=“tns:GetLastTradePriceInput”/> <output message=“tns:GetLastTradePriceOutput”/> </operation> </portType>

Modalità di interazione In base a come una operation viene legata ai messaggi otteniamo 4 diverse modalità di interazione One way Un solo messaggio in input all’endpoint Request response L’endpoint riceve un messaggio ed emette in output una risposta Solicit response (?) L’endpoint invia un messaggio al client (sollecitazione) e attende un messaggio di risposta Notification (?) L’endpoint invia un messaggio di notifica in output

Composizione di servizi Possiamo comporre servizi semplici per realizzare applicazioni più complesse Da servizi a processi di business Due approcci Orchestrazione Si definisce un servizio in termini di interazione con altri servizi + parti “private” Coreografia Si definisce, assumendo un punto di vista globale, come devono interagire differenti servizi al fine di raggiungere l’obiettivo della composizione L’interfaccia di comportamento di un servizio rappresenta la parte del servizio che interagisce con l’esterno

Business Process Execution Language (for Web Services) Linguaggio XML-based per l’orchestrazione di una serie di servizi al fine di realizzare un processo di business Il coordinatore è, in fase di esecuzione, il BPEL-engine che esegue la specifica Standard de-facto proposto dall’IBM A partire da una serie di servizi stateless costruisco un processo con stato… …che può eventualmente esporsi a sua volta come servizio

Le due visioni di BPEL Linguaggio core per definire i ruoli (abstract WSDL) che interagiscono con il processo e specificare i pattern di interazione con tali ruoli Questo core si può poi istanziare su due differenti realtà La specifica di un protocollo di business o processo astratto (interfaccia di comportamento) La specifica di un processo eseguibile (processo astratto + attività private, interne al processo stesso) Idea fondamentale: finchè un processo espone la stessa interfaccia di comportamento, possiamo aggiornarlo senza toccare il mondo esterno

Parti fondamentali Variables partnerLinks Definizione del processo Dati utilizzati dal processo WSDL message types Tipi semplici o elementi XSD partnerLinks Identificazione di chi interagisce con il processo Definizione del processo Definizione dei fault handlers Sia per cause interne che per cause esterne (vedi WSDL) Definizione degli handler di compensazione

Partner del processo Un partner è un insieme di partnerLink Deve fornire le funzionalità richieste Un partnerLink rappresenta un servizio con cui il processo interagisce È identificato da un partnerLinkType Un partnerLinkType è associato ad un ruolo e ad un portType (vedi WSDL) Nota: una port implementa un portType A livello di definizione, rimaniamo in astratto In fase di esecuzione è possibile definire staticamente o dinamicamente l’istanza con cui si interagirà

Dati I dati costituiscono lo stato del processo Sono i messaggi scambiati, i valori intermedi delle variabili, i valori dei time-out… Lo scoping è quello classico (vale l’innestamento) Variabili o globali o valide all’interno di uno scope Problemi nel caso di uso di variabili ancora non inizializzate Ci sono anche delle “proprietà” definite globalmente (tipi XSD semplici che rappresentano le informazioni principali del processo)

Correlazione In alcuni casi il processo vuole dialogare sempre con la stessa istanza di un partner In OO si usa un object reference Paradigma inutilizzabile nel contesto WS Si ricorre all’uso dei dati (che determinano lo stato) e dei protocolli di comunicazione Usiamo un business token, dichiarando la sua struttura e la sua posizione nell’envelope Dichiariamo che un gruppo di attività è correlato dicendo quali token di correlazione vengono condivisi dalle attività (correlation set) All’inizio il correlation set non ha valore viene assegnato allo scambio di un certo messaggio

Inizio e fine di un processo BPEL descrive un processo con stato E che quindi ha un ciclo di vita Un processo viene istanziato implicitamente Attributo createInstance=YES sulla ricezione di un messaggio (receive o pick) Il processo viene istanziato sempre su stimolo esterno Terminazione… Quando non c’è più nulla da fare (terminazione implicita) Quando viene sollevato un fault Utilizzando <terminate> (terminazione anomala, solo per processi concreti)

Attività Utilizzate per modellare il comportamento del processo e degli handlers Attività semplici e costrutti complessi (diramazione del flusso, sincronizzazione, cicli) BPEL eredita da XLANG (Microsoft) Linguaggio strutturato WSFL(IBM) Basato su grafi

Invocazione di un servizio Invoke Invocazione di un servizio su un partner Invocazione asincrona Si specifica la variabile di input Invocazione sincrona Si specifica sia l’input che l’output Si può eventualmente verificare (e gestire localmente o rilanciare) un fault Associabile ad un handler di compensazione (in-line)

Ricezione di una richiesta Receive Ricezione di un messaggio da parte di un partnerLink, il quale indica portType e operation che vuole invocare Eventualmente si utilizza una variabile per accogliere i dati spediti (fondamentale per un processo concreto) Può istanziare il processo Se è l’unica attività iniziale (non preceduta da nessuno) Nel caso sia in parallelo con altre receive di questo tipo, tutte devono appartenere allo stesso correlation set Non è possibile l’attivazione simultanea di due receive esattamente identiche

Risposta Reply Utilizzata per rispondere ad una richiesta sincrona (rilevata con una precedente receive) In caso di richiesta asincrona, l’eventuale risposta si spedisce con una invoke Eventualmente associabile alla variabile contenente la risposta Semantica indefinita nel caso di una reply “isolata” Si può specificare se si tratta di una risposta normale o di un fault

Altre attività semplici Assign Assegna il contenuto di una variabile ad un’altra variabile (anche tra parti di messaggi) Throw Genera un fault interno Wait Sospende il processo per un certo tempo o fino ad una certa deadline (es. attiva una attività il tal giorno) Empty No-op (utilizzato ad es. per catturare un fault e non fare nulla)

Attività complesse 1/3 Specificano il flusso di esecuzione Sequence Ordinamento sequenziale delle attività innestate Switch Scelta di uno e un solo percorso fra una serie, in base a una condizione logica (ramo otherwise per indicare l’else) Si sceglie il primo ramo valutato vero (non deterministicamente) Se nessuna condizione è true e non c’è l’else si suppone ci sia un implicito <otherwise><empty/></otherwise>

Attività complesse 2/3 While Pick Ripetizione finchè una condizione non diventa vera Pick Mette il processo in attesa di una serie di messaggi o di un allarme Attesa di un messaggio: tag onMessage (= a receive) Allarme: tag onAlarm (stessi attributi della wait) Appena scatta l’allarme o arriva uno dei messaggi il processo si risveglia (se arrivano due messaggi “simultanei” scelta non deterministica) Il pick viene disattivato Può creare un’istanza del processo Non ci dev’essere un’allarme

Attività complesse 3/3 Flow Concorrenza/sincronizzazione di attività Si può imporre l’ordinamento fra attività concorrenti utilizzando dei link (reminiscenza di WSFL) Posso realizzare sincronizzazioni intermedie Ad una attività qualsiasi possiamo associare uno o più link sia in ingresso che in uscita Ogni link può essere associato ad una condizione logica B A E C D F sequenza

Links Un’attività è associata ad una condizione di join sullo stato dei link entranti Default: true se almeno uno dei link dà valutazione positiva Valutazione dei link: A termina tutti i suoi link uscenti sono valutati  B dipendente da A tramite link valuta Se B è “strutturalmente” pronto a partire Se lo stato di tutti i suoi link entranti è stato valutato Se sì viene valutata la condizione di join Se vera B viene attivata Altrimenti viene sollevato un fault speciale

Dead Path Elimination Attributo (a livello di scope) per dire che non vogliamo questo tipo di fault In caso di condizione di join negativa: L’attività B viene saltata Tutti i link uscenti da B vengono valutati negativamente La valutazione negativa si propaga finchè non si trova un punto in cui la condizione di join dà riscontro positivo (DPE)

Esempio I link possono scavalcare le attività strutturate (entro certi limiti ben fissati) Join condition: C1  C2 sequence A B C C1 C2 X Y

Compensation handlers Gestione a livello applicativo della compensazione L’handler di compensazione non può modificare lo stato del processo (agisce solo sull’esterno) In futuro ci sarà interazione L’handler viene installato quando la parte di processo a cui si riferisce è completata È può in seguito essere invocato con <compensate> da Un fault handler L’handler di compensazione dello scope che lo contiene

Event handlers Possiamo associare a uno scope degli eventi che scattano in maniera asincrona rispetto al processo Attivano un’attività (complessa) La regola di triggering è l’arrivo di un messaggio o un timer L’evento rimane sempre abilitato (può riscattare arbitrariamente)

Estensione: processi eseguibili Gestione più approfondita di Espressioni Variabili Assegnamenti Possibilità di terminare esplicitamente il processo con <terminate> Maggior numero di fault

Estensione: business protocols Le variabili possono essere utilizzate anche se non inizializzate Potrebbero essere state manipolate da attività private Si possono omettere parametri nei messaggi Output: suppongo che siano gestiti implicitamente Input: il dato non mi interessa a livello pubblico Ipotesi sulle correlazioni… Assegnamento con copia da una variabile opaca Non sappiamo qual è il suo valore Ne viene preso uno non deterministicamente dal suo spazio dei valori

Esempio client agent pick Event onMsg initiate correlation evalClaim kill terminate receive initiate Initiate message correlation client invoke evalClaim Initiate message pick onAlarm 10 days onMsg onTaskResult Task response invoke evalClaim Initiate message end pick evaluate claim receive recTaskResult Task response agent assign Extract status Task response status Rejection handling Acceptance hangling throw illegalStatus end otherwise status=‘accepted’ status=‘rejected’ escalate claim

Implementazioni Lo standard lascia alcuni punti non specificati Es: al processo viene consegnato un messaggio quando non se lo aspetta Lo butta via? Segnala un errore? Lo tiene in sospeso? Solitamente il BPEL-engine mantiene una coda in cui inserisce i messaggi in arrivo per consumarli quando possibile B A B A Receive A B A Receive B B

Qualche nota Problematiche Nessuna interazione con l’utente Nessuna possibilità di invocare attività private BPELJ rende possibile inserire sezioni di codice JAVA all’interno del processo BPEL Descrive davvero un processo di business? Composizione di servizi con un approccio fortemente centralizzato Ogni interazione deve per forza riguardare l’orchestratore Non c’è la possibilità di invocare un (sotto)processo BPEL

WS-CDL The Web Services Choreography Description Language (WS-CDL) is a declarative XML-based language that describes peer-to-peer collaborations of participants by defining, from a global viewpoint, their common and complementary observable behavior; where ordered message exchanges result in accomplishing a common business goal. WS1 WS2 WS3 WS4

Note generali WS-CDL: contratto collaborativo che specifica come i partecipanti devono interagire Interazione non più legata ad un centro di controllo Si separa l’interazione dai partecipanti I partecipanti devono esibire un’interfaccia di comportamento conforme alla coreografia Interoperabilità garantita dall’interfaccia Fornisce uno strumento per superare le resistenze ad integrare servizi propri con quelli di altre parti La coreografia è a tutti gli effetti un contratto È un linguaggio descrittivo, non eseguibile Non per forza i partecipanti devono essere servizi!

Panoramica di WS-CDL Principalmente abbiamo Una parte dichiarativa Ruoli partecipanti Relazioni fra ruoli (commitments) Canali di comunicazione fra partecipanti Una parte conversazionale Descrizione dell’interazione Contempla anche la possibilità di specificare l’avanzamento della collaborazione in termini di informazioni e stato dei partecipanti Che possono eventualmente sincronizzarsi

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

Parte dichiarativa Descrizione delle funzionalità e dei legami che i peer devono esibire per poter collaborare roleType Ruolo che un peer può giocare Enumera una serie di comportamenti che il ruolo esibisce Ogni comportamento può essere opzionalmente agganciato a un’interfaccia WSDL participantType Collezione dei ruoli assunti da un partecipante

Relazioni relationshipType Relazione tra due ruoli che interagiranno (mutual commitments) Si possono anche inserire esplicitamente quali comportamenti sono richiesti dalla relazione (default: tutti quelli del ruolo) Ovviamente un partecipante può partecipare alla relazione se realizza il ruolo richiesto

Canali 1/2 Identificano come e dove scambiarsi informazioni per realizzare la collaborazione I canali possono essere passati come argomenti di un messaggio (PI calcolo…) Comunicazione dinamica Esempio il cliente spedisce il “canale di consegna” al provider Il provider effettua il forward al fornitore Il fornitore utilizza questo canale per spedire il bene al cliente (che prima non conosceva) Il canale può vincolare il suo uso Numero massimo di messaggi supportati Restrizione delle informazioni trasportabili (canali compresi)

Canali 2/2 Utilizzo possibile di un canale Azioni: Once: una volta da un partecipante Distinct: più volte da un partecipante Shared: più volte da più partecipanti Azioni: Receive, Respond o Receive/Respond Associato al ruolo (comportamento) che chi lo utilizza deve esibire Specifica vincoli sui messaggi che possono transire Eventualmente agganciandosi ad altri canali

Esempio <channelType name=“OrderChannel” action=“request” usage=“distinct”> <roleType typeRef=“Supplier”/> <identity usage="primary"> <token name="OrderId" /> </identity> <identity usage="alternate"> <token name="TxnId" /> </channelType> Messaggi accettati dal canale: All’inizio solo messaggi contenenti OrderID Poi messaggi contenenti OrderID o TxnId

Variabili Utilizzate per più scopi Memorizzare le informazioni scambiate via messaggi Catturare lo stato di un partecipante Es: quando il cliente spedisce l’ordine salva in una variabile di stato ORDER_SENT Descrivere i canali (politiche, URL, …) Variabili globali o relative a un ruolo Se due ruoli di un partecipante def. la stessa c’è condivisione Attributi per specificare Politiche di lettura/scrittura della variabile Passaggio di variabili da una sotto-coreografia Token referenziano parti di variabili (via Xpath)

Coreografie Definiscono i contratti di interazione Attività, eccezioni, finalizers Nel documento si inseriscono una o più 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)

Coreografia - attributi Coordinamento indica che tutti i partecipanti devono essere d’accordo su come la coreografia è terminata Eventualmente con un coordination protocol Isolamento Indica che le variabili utilizzate dalla coreografia sono visibili dalle altre solo quando termina Altrimenti c’è condivisione delle variabili

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

Interaction Attività fondamentale Associata a Modella lo scambio di informazioni tra partecipanti ed eventuale sincronizzazione del proprio stato osservabile Consiste nell’invio di un messaggio Associata a Coppia di ruoli coinvolti e canale Operazione richiesta al ricevente Informazione scambiata Variabili utilizzate da sender e receiver per lo scambio Eventuali variabili di stato che reagiscono all’interazione

Allineamento Indica la necessità di avere concordanza sugli effetti di un’interazione su sender e receiver Controllando la coerenza nella modifica delle variabili di stato Verificando la consistenza delle variabili che memorizzano l’info scambiata I partecipanti possono capire che il messaggio è stato effettivamente consegnato Esempio: buyer e seller vogliono verificare che dopo l’effettuazione di un ordine orderState(Buyer)=‘Sent’ e orderState(Seller)=‘Received’ Le variabili order(Buyer) e order(Seller) hanno = contenuto

Interaction - exchange Exchange (scambio di informazioni) Specifica del fault (compatibilità con WSDL) Request o respond Info scambiate Send: cosa viene inviato Receive: cosa viene ricevuto Eventuale time-out Record riferiti dall’exchange e/o dal time-out Manipolazione di variabili dicendo quando e come Nota: se più di una respond scelta implicita

Esempio <exchange name="request" informationType="tns:purchaseOrderType” action="request"> <send variable="cdl:getVariable('tns:purchaseOrder','','')" /> <receive variable="cdl:getVariable('tns:purchaseOrder','','')" recordReference="record-the-channel-info" /> </exchange> <exchange name="response" informationType="purchaseOrderAckType" action="respond"> <send variable="cdl:getVariable('tns:purchaseOrderAck','','')" /> <receive variable="cdl:getVariable('tns:purchaseOrderAck','','')" /> <exchange 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" />

Performance Indica che si passa a eseguire una nuova coreografia (enclosed) Non devono esistere dipendenze cicliche Fase di bind in cui si legano variabili del chiamante a quelle del chiamato Attributo block Truesi attende la fine della enclosed choreography Falsel’enclosed choreography viene attivata in parallelo col flusso del chiamante Se il chiamante termina con successo l’enclosed termina automaticamente con successo

Altre attività semplici Assign (~BPEL) silentAction Il ruolo esegue un’operazione non osservabile dall’esterno noAction (empty in BPEL) Nota: se il ruolo non viene specificato vuol dire che riguarda tutti…

Workunit Unità di lavoro Attributo block Attività preceduta da un vincolo condizione che deve essere verificata affinchè la collaborazione possa continuare Solo se (o quando) il vincolo è soddisfatto l’attività viene abilitata Attributo block Si testa la condizione o si attende finchè non diventa vera Attributo repeat (modellazione di cicli) Indica che quando la workunit è terminata si considera di nuovo la condizione

Funzioni specifiche Funzioni richiamabili nelle condizioni Data/ora corrente Si suppone che gli orologi siano più o meno sincronizzati Test su deadline/timer Conoscenza dello stato della coreografia Gestione delle variabili Recupero valore o attesa disponibilità Test sull’allineamento Trigger globali Variabili di diversi ruoli

False se la variabile non è disponibile Esempi <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" > False se la variabile non è disponibile

Ordering Structures Sequence Parallel Choice Mutua esclusione classica (deferred) Quando viene scelto un ramo gli altri sono disabilitati Se i rami contengono workunits con guardie Si possono realizzare punti decisionali La prima workunit che fa match (se più d’una non determinismo) determina la scelta

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

Finalization Quando la coreografia termina con successo Può essere invocato uno fra una serie di finalizerBlocks Gestiscono la compensazione della coreografia commit, undo, cancel, rollback applicativi I finalizer si distinguono per nome e ne viene scelto uno solo

Coordinamento 1/2 Garantisce che tutti i ruoli siano d’accordo su come la coreografia è terminata Indica che un insieme di interazioni è allineato (conoscenza condivisa) Tutti i ruoli sanno che la coreografia è terminata con successo o meno L’accordo viene raggiunto con un coordination protocol

Coordinamento 2/2 Nel caso di enclosed choreography l’accordo è anche sull’eventuale finalizer Se non c’è coordinamento viene sollevata un’eccezione Se la coreografia termina con un eccezione e alcuni ruoli non se ne accorgono, il protocollo di coordinamento solleva un’eccezione su questi

Esempio 1/3 Warehouse Retailer r4w w4r r4c w4c Consumer c4r c4w

Esempio 2/3 result sequence Interaction handlePO POc POr POreq POackr POackc POresp POr POw RWreq okW okR RWresp Interaction handlePO assign okR result clientSatisfied

La warehouse invia una ricevuta al consumer Esempio 3/3 NON NOTO A PRIORI choice workunit block=false repeat=false guard=boolean(customerSatisfied) Interaction handlePOResponse POposResp POResp La warehouse invia una ricevuta al consumer (estraendo il canale dal messaggio precedentemente ricevuto dal retailer) perform CWchoreo workunit block=false repeat=false guard=not(boolean(customerSatisfied)) Interaction handlePOResponse POnegResp POResp

Qualche spunto…1/2 Sostiene che BPEL astratto è una forzatura Van der Aalst. Life After BPEL? Sostiene che BPEL astratto è una forzatura Serve un linguaggio dichiarativo Indica tre importanti topic Process mining Riscostruzione di un processo da un event log Conformance testing Verifica di compliance su un event log Mediation Adattamento di un servizio in modo da permettergli di partecipare a una coreografia Conformance test ++

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