1

Business Process Execution Language for Web Services

(BPEL4WS)

2

BPEL vs. WSDL

• WSDL supports a stateless model which describes operations supported by web servers– One or two messages needed for client/server

communication

– No mechanism for describing state between operations

• A business process (BP) typically characterized by long-running, statefull sequence of operations with one or more web services (business partners).

3

Simple Example: Ordering Stationery

cobegin invoke Staples.StationeryQuote(staples-quote); invoke Office-Max.StationeryQuote Service(max-quote);coend; if staples-quote < max-quote {invoke Staples.StationeryPurchase} else {invoke Office-Max.StationeryPurchase}

state

4

New Issues

• Must be able to communicate with other Web Services

• Must be able to access and modify data received in messages– Use XPath to extract information from messages

• Must have control constructs– sequence, switch (if), flow (concurrency), while, link

(synchronize concurrent processes), invoke, etc

• Must be able to handle faults

5

Example (BPEL)

<sequence> <flow> <invoke partnerLink=“Staples” interface=“staplesPurchasePt” operation=“requestQuote” inputVariable=“stationeryReq” outputVariable=“staplesStationeryQuote”> </invoke> <invoke partnerLink=“OfficeMax” interface=“officeMQuotePT” operation=“requestQuote” inputVariable=“stationeryReq” outputvariable=“officeMStationeryQuote”> </invoke> </flow> ….. Continued on next slide …..

6

Example (BPEL) <switch>

<case condition=“bpws:getVariableProperty(staplesStationeryQuote, quote) < bpws:getVariableProperty(officeMStationeryQuote, quote)” /> <invoke partnerLink=“Staples” interface=“staplesQuotePt” operation=“purchStationery” inputVariable=“stationeryPurch” outputVariable=“stationeryResp”> </invoke> </case <otherwise> <invoke partnerLink=“Office Max” interface=“officeMQuotePT” operation=“purchStationery” inputVariable=“stationeryPurch” outputVariable=“stationeryResp”> </invoke> </otherwise> </switch></sequence>

7

Business Process (BP)

• A BP consists of both internal computations and invocations of operations exported by web service partners

• The operations it exports constitute its interface to its partners

• The sequence of invocations it executes is referred to as a protocol and – is data dependent– responds to exceptional conditions

8

Abstract Vs. Executable BPs

• Executable BP – complete description of BP (including all computations)

• Abstract BP – contains only externally visible (communication related) behavior of BP– Not executable– Internal decision making algorithm and data

manipulation not described• Languages for describing abstract and executable BPs

share a common core, but differ primarily in data handling capabilities

• BPEL4WS is used to specify both abstract and executable BPs

9

Executable BPs

• BPEL is sufficient for describing a complete (executable) BP that– Relies on web services and XML data– Is portable (platform independent)

• Executable BP is a complete specification of the Web Service– Actual implementation, however, might not use BPEL,

• Abstract BP specifies external interface and can be exported for use by business partners

10

Abstract BP

• Unfolding of protocol related portion of BP – depends on properties - a subset of the data contained in

messages

– Ex. Message invoking getQuoteRequest might have parts instrumentType (with value stock or bond) and symbol (which identifies a particular instrument of that type)

• instrumentType will be a property if it affects the course of the protocol

• symbol will not if it does not affect the course of the protocol

• Only properties are visible to abstract BP

11

Abstract Vs Executable BP• Internal computation of executable BP not included in

abstract BP– If assignment is to a variable that is not a property, it is

eliminated from abstract process• Ex. Address data might not affect the protocol

– If assignment is to a variable that is a property, it (generally) affects the protocol

• Ex. Value of bidPrice might affect protocol: – if (bidPrice>1000) invoke webService1 else invoke webService2– bidPrice will be a property, but its value is computed by an

internal algorithm

• The computation that produces the new value is generally not relevant to the protocol

12

Abstract BP – Non-determinism

• Description of abstract BP allows assignment of non-deterministic values to properties to model this

• Abstract and executable BPs differ in data handling ability– Executable can explicitly manipulate all data– Abstract can access only properties in limited

ways and can assign non-deterministic values to them

– Executable cannot assign non-deterministic values to anything

13

Abstract BP – Non-determinism

computation that assigns a value

to part x

non-deterministicassignment

to property x(alias of x)

switch(x) switch(x )

Executable BP Abstract BP

14

Communication – Client Side

• Invoking an operation of an interface (specified in WSDL) exported by server– Client assigns message to operation’s input

variable– Client executes invoke on operation

• Asynchronous (in-only WSDL pattern): – Client resumes execution immediately

• Synchronous (in-out WSDL pattern):– Client waits for response and then resumes execution– Client can access response message in operation’s output

variable

15

Communication – Client Side

• Receiving an operation (e.g., an asynchronous response to a prior invocation) on a (callback) operation exported by client– Client executes receive on operation

– Client waits for message

– Client can access message in variable associated with operation and resume execution

16

Communication – Client Side

client server

invoke

invoke

invoke

receive

• • •

• •

• •

•

• •

• •

• •

• •

• server exportsinterface

client exports (callback) operation

(synchronous invoke)

(asynchronous invoke)

clientwaits

clientcontinues

problem: how doyou associaterequest withresponse?

• • •

17

Communication – Server Side

• Accepting an operation invocation on an (exported) interface (specified in WSDL)– Server executes receive on operation and waits

• Responding to a synchronous operation invocation– Server executes reply on operation (rpc)

• Invoking a client’s exported (callback) operation– Server executes invoke on operation

18

Communication – Server Side

client server

invoke• •

• • •

• •

• •

• •

• •

• server exportsinterface

client exports (callback) interface

(synchronous invoke)

(asynchronous invoke)

receive

reply

receive

receive

invoke

invoke

receive invoke

19

Example: Purchase Order (PO) Service

initiateprice

calculation

completeprice

calculation

arrangelogistics

invoiceprocessing,

reply

decide on shipper

completeproductionscheduling

receivepurchase

order

initiateproduction scheduling

concurrencysequencing

synchronization

20

PO Service

customer

receive

reply

Body of PO Service

Body of PO Service

POMsg

InvMsg

operationsendPurchOron interfacepurchOrIf

synchronous invocation

PO Service

21

PO Service Interface (WSDL)

<message name=“POMsg”> <part name=“custInfo” type=“sns:custInfo”/> <part name=“purchOr” type=“sns:purchOr”/></message><message name=“InvMsg”> <part name=“IVC” type=“sns:Invoice”/></message>…..<interface name=“purchOrIf”> <operation name=“sendPurchOr> <input message=“pos:POMsg/> -- arguments supplied <ouput message=“pos:InvMsg”/> -- response </operation></interface>…..

interface exportedby PO Service

<definitions targetNamespace=“….” xmlns=“http://schemas.smlsoap.org/wsdl/” …>

</definitions>

prefix for targetnamespace in this document

22

Variables (BPEL)

• Variables maintain the state of a BP– Used to store messages that have been sent or received or

for local storage (no message involved)– Has an associated type:

• Can be a message type

• Can be an XML simple type• Can be an XML schema element (which might have a complex

type)

– Has an associated scope

<variable name=“PO” messageType=“lns:POMsg”/>

lns is prefix in BPEL document for the WSDL document

23

Partner Link Type (WSDL)

<plnk:partnerLinkType name=“purchLT”> <plnk:role name=“purchService”> <plnk:interface name=“pos:purchOrIf”/> </plnk:role></plnk:partnerLinkType>

• <partnerLinkType> describes the way two BPs interact: - names an interface that must be declared in each - associates <role> with each end of the interaction

Only one role since only POService needs to provide an interface

Unit of collaboration

Not a process (allows actual partner to be

specified dynamically)

Identifies a BPEL schema

24

Partner Link Type (WSDL)<plnk:partnerLinkType name=“invoicingLT”> <plnk:role name=“invoiceService”> <plnk:interface name=“pos:computePriceIf”/> </plnk:role> <plnk:role name=“invoiceRequester”> <plnk:interface name=“pos:invoiceCallbackIf”/></plnk:partnerLinkType>

BP playing roleof invoicerequester

BP playing roleof invoice service

invoiceCallbackIf computePriceIf

description of apossible relationship between two BPs

25

Partner Link (BPEL)

<partnerLinks> <partnerLink name=“purchLink” partnerLinkType=“lns:purchLT” myRole=“purchService”/> <!-- other partnerLink’s go here --></partnerLinks>

hence PO service must provide

purchOrIf

• Connection to another BP described by a partner link • <partnerLink> construct in BPEL names a process and associates it with a role in that link.

prefix lns refers to WSDL document

name of partnerLink

partner specification in

PO service

26

Partner (BPEL)

• A BP might interact with another BP – called a partner - through several partnerLinks– Need a mechanism that asserts that the same BP is at

the other end of a set of partnerLinks– Ex: BPs might support getFareIf and purchaseTicketIf;

an acceptable partner is one that supports both

<partners> <partner name=“ticketVendor”> <partnerLink name=“xxxx”/> <!-- supports getFareIf --> <partnerLink name=“yyyy”/> <!-- supports purchaseTicketIf --> </partner></partners>

27

Process Name

• Each BP is assigned a name in the <process> tag

<process name=“customer” … namespace declarations … … query language (default XPath) … … expression language (default XPath)… > … declarations and process body …</process>

<process name=“purchOrProcess” … similarly … > … declarations and body of PO service …</process>

28

Linkage: Customerto PO Service

<plnk:partnerLinkType name=“purchLT> <plnk:role name=“purchService”> <plnk:interface name=“pos:purchOrIf”/> </plnk:role></plnk:partnerLinkType>

<partnerLink name=“linkToPurch” partnerLinkType=“cns:purchLT” partnerRole=“purchService”/>

<partnerLink name=“purchLink” partnerLinkType=“lns:purchLT” myRole=“purchService”/>

WSDL inter-face exportedby PO Service

partner specificationin customer process

partnerspecificationin PO Service

plnk – prefix in WSDL doc refers to WSDL extensionpos – target ns of WSDL doclns – prefix in PO Service refers to WSDL doccns – prefix in customer refers to WSDL doc

29

Partners

<partnerLinks> <partnerLink name=“invoiceProvider” partnerLinkType=“lns:invoiceLT” myRole=“invoiceRequester” partnerRole=“invoiceServices”/></partnerLinks>

• In general: - A partnerLinktype is not specific to a particular BP; it is a global, bilateral (WSDL) description of the interaction between two BPs. - A partnerLink declaration (BPEL) describes how the local BP interacts with other BPs through a partnerLinktype.

30

PO Service (BPEL)<variables> <variable name=“PO” messageType=“lns:POMsg”/> <variable name=“Invoice” messageType=“lns:InvMsg”/></variables>

<sequence> <receive partnerLink=“purchLink” interface=“lns:purchOrIf” operation=“sendPurchOr” variable=“PO”/> </receive>

<flow> …. concurrent body…. </flow>

<reply partnerLink=“purchLink” interface=“lns:purchOrIf” operation=“sendPurchOr” variable=“Invoice”/></sequence>

Both necessary since PO Service might communicate with several BPs through the same interface

31

Interaction with Shipping Provider

decide onshipper(invoke)

arrangelogisitics(receive)

shippingProvider

shipReqMsg

shipInfoMsg

operation requestShippingon interface shippingIf

operation sendSchedule onport shippingCallbackIf

role = shippingService

role = shippingRequester

scheduleMsg

32

Handling Shipping (WSDL)

<interface name=“shippingCallbackIf”> <operation name=“sendSchedule”> <input message=“…”/> </operation></interface>

<interface name=“shippingIf”> <operation name=“requestShipping”> <input message=“…”/> <output message=“…”/> </operation></interface>

interface exportedby PO Service

interface importedfrom shippingservice

33

Handling Shipping

<plnk:partnerLinkType name=“shippingLT”> <plnk:role name=“shippingService”> <plnk:interface name=“pos:shippingIf”/> </plnk:role> <plnk:role name=“shippingRequester”> <plnk:interface name=“pos:shippingCallBackIf/> </plnk:role></plnk:partnerLinkType>

<partnerLink name=“shippingProvider” partnerLinkType=“lns:shippingLT” myRole=“shippingRequester” partnerRole=“shippingService”/>

WSDL

BPEL

34

Handling Shipping (BPEL)

<sequence> <assign> <copy> <from variable=“PO” part=“custInfo” /> <to variable=“shippingReq” part=“custInfo” /> </copy> </assign> <invoke partnerLink=“shippingProvider” interface=“lns:shippingIf” operation=“requestShipping” inputVariable=“shippingReq” outputVariable=“shippingInfo” > </invoke> <receive partnerLink=“shippingProvider” interface=“lns:shippingCallbackPT” operation=“sendSchedule” variable=“shippingSchedule”/> </sequence>

contains input

message

35

Links (BPEL)– Synchronizing Concurrent Activities w/I a BP

• Production scheduling cannot be completed until logistics have been arranged

decide onshipper

arrangelogistics

completeproductionscheduling

initiateproductionscheduling

source target

link

Concurrent sequence activities in flow• data produced byarrange logistics isneeded by completeproduction scheduling• data communicatedthrough globally sharedvariable

36

Links<flow> <links> <link name=“ship-sched”/> </links> <sequence> <assign> …. </assign> <invoke partnerLink= ….> </invoke> <receive partnerLink= …. variable=“shippingSched”> <source linkName=“ship-sched”/> </receive> </sequence> <sequence> <invoke partnerLink=….> </invoke> <invoke partnerLink=…. inputVariable=“shippingSched”> <target linkName=“ship-sched”/> </invoke> </sequence> ….</flow>

shipping

scheduling

arrangelogistics

completeproductionscheduling

decide on shipper

37

Properties (WSDL)

• Some message data is protocol-relevant.– Used in conditional behavior of BP– Used to relate messages sent to a particular instance of a BP

• A property declares a global name that can be assigned to data items that may be parts of several different message types and carry the same meaning– taxpayerID might be a part of one message type in one

namespace (e.g., Internal Revenue), ssn might be a part of another in a different namespace (e.g., Social Sec. Admin)

– Both might represent the same information of type txtyp:SSN

<bpws:property name=“customerID” type=“txtyp:SSN’/>

38

Property Alias (WSDL)• Used to associate a property name with a field in

message part– A particular property can be associated with different

fields in different messages

<bpws:property name=“customerID” type=“txtyp:SSN’/><bpws:propertyAlias propertyName=“customerID” messageType=“txmsg:taxpayerInfo” part=“taxpayerID” query=“/socialSecNum” /></bpws:propertyAlias>

query string – specified in XPath - to locate the field in

the part

39

Correlation Sets (BPEL)

• A web service might be configured with multiple instances of a BP to concurrently handle (stateful) conversations with multiple clients.– All receive requests over the same port

• With SOAP over HTTP, messages arrive on port 80

• A mechanism is needed to:– Route an arriving message that is part of a particular

conversation to the correct BP instance• Messages of a particular conversation can be recognized by the

fact that they will generally all carry some identifying value(s) (e.g., customerID and orderNum)

40

Correlation Sets

• A correlation set is a set of properties whose value is shared by all messages in a particular conversation.– Hence, an address is really:

(host address, port, correlation set)– A correlation set identifies the BP instance

<correlationSet name=“PurchaseOrder” properties=“cor:customerID cor:orderNum”/>

aliased to items of information contained in the messages of aconversation

41

Using Correlation Sets

• A particular receive operation can be used in a BP to accept the start of a new conversation

• All subsequently arriving messages with same value of PurchaseOrder will be directed to this BP

<receive partnerLink =“Buyer” interface=“SP:PurchasingIf” operation=“asynchPurchase” variable=“PO”> <correlations> <correlation set=“PurchaseOrder” initiate=“yes”/> </correlations></receive>

create a new correlation set value for BP instance

asynchronouspurchase requst

42

Using Correlation Sets• Response returns the correlation set value

– Asynchronous (callback) response to previous invocation

– A reply to a synchronous invocation would be similar

<invoke partnerLink “Buyer” interface=“SP:BuyerIf” operation=“asynchPurchaseResp” variable=“PO”> <correlations> <correlation set=“PurchaseOrder” initiate=“no”/> </correlations></invoke>

use the set toaddress the message

43

Multiple Correlation Sets

buyer serverinvoke(corrSet=“PO” init=“yes”) receive(corrSet=“PO” init=“yes”)

receive(corrSet=“PO” init=“no” invoke(corrSet=“PO” init=“no” corrSet=“inv” init=“yes”) corrSet=“inv” init=“yes”)

subsequent messages sent and received use correlation set inv

messsagecontains bothcorrelation sets

messages of asingle conversation

44

Multiple Correlation Sets

• With synchronous invocation two messages are involved; the pattern attribute associates a correlation set with a message.

invoke (partnerLink=“Buyer” interface=“SP:BuyerIf” operation=“synchPurchaseResp” inputVariable=“PO” outputVariable=“invoice”> <correlations> <correlation set=“PurchaseOrder” initiate=“yes” pattern=“out”/> (initiated in outbound msg) <correlation set=“InvoiceResp” initiate=“yes” pattern=“in”/> (initiated in inbound msg, which contains both sets) </correlations></invoke>

45

Data Manipulation• Data (state) stored in variables (used for messages and local storage)• Expressions use expression language (XPath default) to access data

in variables– Executable processes can use:

– All processes can use:

– Returns the part (or, if the locationPath is specified the field within the part) in the named variable.

• If a single node is not specified, a fault is returned.

bpws:getVariableData (‘variableName’, ‘partName’, ‘locationPath’?)

bpws:getVariableProperty(‘variableName’, ‘propertyName’)

query string

property alias contains query string

46

Assignment• Allows copying of data • One form (for executable processes):

– query is an absolute expression (if XPath is the query language) that identifies a single node w/i the document fragment specified by part

– from child can also contain a literal value or a simple arithmetic expression (for data transformation)

<assign> <copy> <from variable=“v1” part=“p1” query=“q1”/> <to variable=“v2” part=“p2” query=“q2”/> </copy></assign>

47

Assignment in Abstract Process

• A non-deterministic value from a property’s domain can be assigned to the property by an abstract process using opaque assignment– Allows simulation of execution traces

<assign> <copy> <from opaque=“yes”/> <to variable=“v2” property=“p2”/> </copy></assign>

48

Invoking Web Service Operations

• invoke might have child elements related to faults and compensation (discussed subsequently), and links and correlation (discussed previously)

• invoke specifies a partnerLink since an interface can be associated with several partnerLinkTypes connected to different BPs

<invoke partnerLink=“shippingProvider” interface=“lns:shippingIf” operation=“requestShipping” inputVariable=“shippingRequest” ouputVariable=“shippingInfo”></invoke>

49

Invoking Web Service Operations• invoke can be

– Synchronous• input and output variables specified• waits for a response

– Asynchronous • no output variable specified• no waiting

<invoke partnerLink=“invoiceProvider” interface=“lns:computePriceIf” operation=“initiatePriceCalc” inputVariable=“PO”></invoke>

50

Synchronous Vs. Asynchronous Invocation

• Web service communication characterized by:– Services are not always available.– Loads tend to be unpredictable.

• Attempts to handle too many requests in real time can lead to thrashing and failure.

– Many requests can’t be handled instantly even with low loads.

• Asynchronous invocation will play an increasingly important role.

51

Providing Web Service Operations

• receive waits for an invocation to arrive

– specifies a partnerLink since an interface can be associated with several partnerLinkTypes connected to different BPs

<receive partnerLink=“customer” interface=“lns:purchOrIf” operation=“sendPurchOr” variable=“POmsg”/> </receive>

52

Providing Web Service Operations• Initiating a new instance of a BP:

– createInstance=“yes” => a new instance of the BP is created and this is its initial activity.

• The receive should be the first activity in the BP (since prior activities will not be executed within the new instance)

• If the message is the start of a conversation then a correlation child element should be specified:

<receive partnerLink=“customer” interface=“lns:purchOrIf” operation=“sendPurchOr” variable=“POmsg” createInstance=“yes”/> </receive>

<correlation set=“PurchaseOrder” initiation=“yes”/>

53

Providing Web Service Operations

• reply is used to respond to a synchronous invocation.– connection between receive and reply based on

constraint that not more than one synchronous request from a particular (partnerLink, interface, operation) can be outstanding at a time

• Response to an asynchronous invocation is made using an invoke on a callback operation– partnerLink between requestor and requestee must have

two roles

<reply partnerLink=“customer” interface=“lns:purchOrIf” operation=“sendPurchOr” variable=“Invoice”/>

54

Other Basic Activities

• <terminate>

• <wait until=“deadline”>

or

<wait for=“duration”>

• <empty>

55

Structured Activities

• <sequence> <!-- list of activities --> </sequence>• <switch> <case condition=“bool-expr”>

<!-- activity --> </case> <otherwise> <!-- activity --> </otherwise> </switch>

at least one case element; conditionsevaluated in order

if present, executedif all conditionsfail, else an emptyotherwise is assumed

Involves only properties if

process is abstract

56

Structured Activities

• <while condition=“bool-exp”> <!-- iteratively executed activity --> </while>• <pick> -- waits for the occurrence of first event <onMessage partnerLink=“..” interface=“..” operation=“..” variable=“..”> <!-- activity to process message --> </onMessage> <onAlarm for=“durationExp” | until=“deadlineExp”> <!-- timeout activity --> </onAlarm> </pick>

at least one,acts likereceive

zero or more

57

Structured Activities

• <flow> concurrently executes nested (child) activities

• Terminates when all children terminate

<sequence> <flow> <invoke partnerLink=… /> <invoke partnerLink=… /> </flow> <invoke partnerLink=../> </sequence>

58

WSDL Review

• WHAT: interface describes abstract functionality (operations, messages)

• HOW: binding describes how elements of an interface (operations, messages) are mapped to a particular transport protocol (e.g., SOAP over HTTP, data encoding)

• WHERE: endpoint maps a binding to an address (particular server at a URL)– service is a collection of related endpoints

59

Endpoint References

• A BP is statically dependent on the interfaces with which it communicates

• However, the endpoints associated with those interfaces (and hence the identity of the BP instances with which it communicates) can change dynamically– Endpoints can be sent in messages

– A BP can dynamically select a provider

– Example: client can send a callback interface to which server can send response

60

Endpoint References

• A message part of EndpointReferenceType can hold addressing information

• Every role in a partnerLink has an associated EndpointReference (of that type) that identifies an endpoint (address) and an associated process instance

• An EndpointReference element is an alternative to a service element

61

WS-Addressing Specification for Endpoint Reference

<wsa:EndpointReference …namespace declarations… > <wsa:Address> … a URI … </wsa:Address> -- required <wsa:ReferenceProperties> … properties (child elements) are inserted here …. </wsa:ReferenceProperties> <wsa:Interface> …</wsa:Interface> <wsa:ServiceName> … </wsa:ServiceName> <wsa:Policy> … </wsa:Policy></wsa:EndpointReference>

• wsa identifies WSDL extension namespace for endpoint references• Information to identify a particular instance of a BP can also be supplied

62

Endpoint Reference

• Properties: mapped literally to SOAP headers– MessageId– Action: action to be taken by destination– ReplyTo: …

• Interface: identifies the associated interface

• ServiceName: identifies the associated service

63

Endpoint Reference Example<message name=“buyerData”> …. <part name=“serviceReference” type=“wsa:EndpointReferenceType”/> <part …. /></message>

<interface name=“buyerIf”> <operation name=“submit”> <input message=“tns:buyerData”/> </operation></interface><interface name=“buyerCallbackIf”> <operation name=“answer” …. </interface>

<plnk:partnerLinkType name=“buyerStoreLT”> <plnk:role name=“store”> <plnk:interface name=“tns:buyerIf”/> </plnk:role> <plnk:role name=“buyer”/> <plnk:interface name=“buyerCallbackIf”/> </plnk:role></plnk:partnerLinkType>

64

Endpoint Reference Example<partnerLink name=“buyer” partnerLinkType=“as:buyerStoreLT” myRole=“store” partnerRole=“buyer”/><variable name=“buyerData” messageType=“as:buyerData”/>……<sequence> <receive name=“acceptFromBuyer” partnerLink=“buyer” interface=“as:buyerIf” operation=“submit” variable=“buyerData”/> ….. <assign> <copy> <from variable=“buyerData” part=“endpointReference”/> <to partnerLink=“buyer”/> </copy> </assign> <invoke name=“respondToBuyer” partnerLink=“buyer” interface=“as:buyerCallbackIf” operation=“answer” inputVariable=“…” /></sequence>

65

Assignment and Endpoint References

• Sending an address: from child can have the form

– A BP might want to send its own address (e.g., for a callback) or its partner’s address

• Receiving an address: to child must be associated with partnerRole (can’t change your own address)

<from partnerLink=“ … ” endpointReference=“myRole|partnerRole ”/>

<to partnerLink=“ … ” />

66

Links – Synchronizing Flow Activities<flow>

<links> <link name=“XtoY” /> <link name=“CtoD”/> </links> <sequence name=“X”> <source linkName=“XtoY”/> <invoke name=“A”…/> … </sequence> <sequence name=“Y”> <target linkName=“XtoY”/> <receive name=“C”…> <source linkName=“CtoD”/> </receive> … </sequence> <invoke name=“D”…> <target linkName=“CtoD”/> </invoke></flow>

- any activity can have a source or target child element- every link must have exactly one activity w/i the flow as its source and one as its target- sequence Y can’t start until sequence X completes- source and target need not be nested at same level (CtoD)- link must not cross a while boundary- links must not create a loop

67

Link Semantics at the Source

• Each source child of an activity has an implicit or explicit transitionCondition whose value is:

- Implicit: true when activity terminates

- Explicit: the value of the transitionCondition when the activity terminates

<source linkName=“AtoB”

transitionCondition=“getVariableProperty(‘eval’, ‘risk’) = ‘low’ ”/>

- The transitionCondition determines the link status (positive or negative) when the activity terminates

variable nameproperty name

68

Link Semantics at the Target• Without considering links, an activity is ready to execute in

accordance with normal flow-of-control rules (sequence, switch, etc.)• In addition, an activity might be the target of several links.

- Every such activity has a joinCondition which can be evaluated when the status of all incoming links has been determined. Execution starts when the activity is ready and its joinCondition is true. • Default joinCondition: status of at least one incoming link is true

<sequence name=“X” > <target linkName=“AtoX”/> <target linkName=“BtoX”/> …….</sequence>

69

Link Semantics at the Target

• joinCondition can be explicitly provided as an attribute using getLinkStatus() function.

<sequence name=“X” joinCondition=“bpws:getLinkStatus(AtoX) AND bpws:getLinkStatus(BtoX)”> <target linkName=“AtoX”/> <target linkName=“BtoX”/> …….</sequence>

must specify an incominglink for activity X

70

Link Semantics at the Target

• If the joinCondition evaluates to false a joinFailure fault is thrown, else the activity is started

• If an activity, X, will not be executed (e.g. a case in a switch, an activity that does not complete due to a fault) then the status of all outgoing links from X is set to negative.

71

Link Semantics

<flow> <link name=“AtoC”/> <link name=“BtoC”/><sequence><switch> <sequence name=“C”> <case condition=“C1”> <target name=“AtoC”/> <sequence name=“A”> <target name=“BtoC”/> <source linkName=“AtoC”/> ……… …. </sequence> </case> <case condition=“C2”> <sequence name=“B”> <source linkName=“BtoC”/> …. </sequence> </case></switch>……. </flow>

- only one case is executed- joinCondition at C cannot be evaluated until status of both links are determined- if C1 is chosen for execution the status of BtoC is set to negative (if that were not done C would never start)- default joinCondition at C is true when either C1 or C2 completes - since their (default) transitionCondition is “true”

72

Link Semantics

• Problem – in some cases a false joinCondition is not a fault; it is an indication that the activity should not be performed in at a particular point in the execution– In that case the status of all outgoing links should

be set to false so that the joinCondition of other activities can be evaluated

• Solution – use activity attribute suppressJoinFailure

73

Link Semantics

• If value of the suppressJoinFailure attribute of an activity, A, is yes, then if the joinCondition of A or any nested activity has value false when it is ready to execute – status of all of it’s outgoing links is set to negative– it is skipped and execution continues (as if it had

terminated without raising a fault)– referred to as dead-path-elimination

74

Link Semantics <flow suppressJoinFailure=“yes”>

<link name=“AtoC”/><sequence><switch> <sequence name=“C”> <case condition=“C1”> <target name=“AtoC”/> <sequence name=“A”> ……… <source linkName=“AtoC”/> …. </sequence> </case> <case condition=“C2”> <sequence name=“B”> …. </sequence> </case></switch>……. </flow>

- C is executed if C1 is chosen- if C1 is not chosen the status of AtoC is set to negative and a joinFailure would occur- suppressing joinFailure allows C to be silently skipped

75

Scope

• Nested scoping is provided through the scope activity in the conventional way.

• Variables, fault and compensation handlers, and correlation sets can be declared.

• Properties are global since they are mapped to data in messages.

76

Faults

• Fault has a unique name and an (optional) fault variable describing the event

• Sources of faults:– Explicit raising of a fault <throw faultName=“trouble” faultVariable=“descr”/>

– Standard BPEL faults bpws:joinFailure - joinCondition has value false bpws:conflictingReceive – two receive’s for same

partnerLink, interface and operation pending within a flow at the same time

77

Faults• Source of faults (con’t):

– Fault response to an invoke. The reply:

raises the fault unableToHandleRequest in customer

that has synchronously invoked request on interface:

<reply partnerLink=“customer” interface=“lns:loanServiceIf” operation=“request” variable=“error” faultName=“unableToHandleRequest”/>

<interface name=“loanServiceIf”> <operation name=“request” pattern=“http://www.w3.org/2003/06/wsdl/in-out”> <input message=“lns:creditInfoMsg”/> <output message=“lns:approvalMsg”/> <fault name=“unableToHandleRequest” message=“errorMsg”/> </operation></interface>

78

Faults

The reply raises the unableToHandleRequest fault in customer which is handled by

<faultHandlers> <catch faultName=“unableToHandleRequest” faultVariable=“error”> …. handle the fault …. </catch></faultHandlers>

Re-throw the same fault and/or clean-up and/or invoke a compensationhandler

79

Handlers• Handler is associated with an implicit or explicit

scope; catches faults that occur in that scope

<invoke partnerLink=“loanApprovProc” interface=“lns:loanserviceIf” operation=“request” ….. > <catch faultName=“unable…” faultVariable=“error”> …. handle the fault…. </catch></invoke>

<scope> <faultHandlers> <catch faultName=“unable…” faultVariable=“error”> …. handle the fault … </catch> …other handlers … </faultHandlers> …activities … <invoke partnerLink=“loanApprovProc” interface=“lns:loanserviceIf” operation=“request” … > </invoke> …activities…</scope>

or

80

Fault Flow of Control• When a fault f occurs in some scope, B

– Execution of activities within are terminated

– If a fault handler for f or a catchAll handler has been declared local to B, it is executed and execution resumes in the next enclosing scope at the activity following B

– Else f is thrown in the next enclosing scope

– In both cases B is said to have exited abnormally

• The handler might reverse changes it has made to variables global to B and invoke compensation handlers for scopes nested in B that have completed normally.

81

Fault Flow of ControlA

B catch f throw g or exit

throw f

abnormal exit

82

Atomicity• A BP is a long running process involving invocations

of operations at a number of web services.• It is unrealistic to treat a BP as a single transaction,

since a particular service will not hold locks for the duration of the BP

• Instead, a single operation at a service might be treated as a transaction that commits when it sends reply

• BPEL does not support global atomicity (e.g., two-phase commit) over multiple invocations by a BP

83

Long-Running Business Transactions (LRT)

• Reversing the effect of a BP relies on compensation– a web service might offer a compensating operation for a

synchronous operation– Ex. CancelPurchase compensates for Purchase

• BPEL supports an LRT by providing compensation handlers – Allows application to specify a recovery strategy using

compensating operations– No guarantee of atomicity or isolation– Future work in this direction is being carried out in the

context of the WS-Transaction specification

84

Compensation Handler• Handler can be in the immediate scope of invoke or declared

local to scope– Undoes the effect of the scoped activities

<invoke name=“invSeller” partnerLink=“seller” interface=“SP:Purch” operation=“syncPurch” inputVariable=“sendPO” outputVariable=“getResponse”> <correlations> <correlation set=“PurchOr” initiate=“yes” pattern=“out”/> </correlations> -- pattern=“out” indicates set applies to request msg <compensationHandler> <invoke partnerLink=“seller” interface=“SP:Purch” operation=“cancelPurch” inputVariable=“getResponse” outputVariable=“getConfirm”> <correlations> <correlation set=“PurchOr” pattern=“out”/> </correlations> </invoke> </compensationHandler></invoke>

-- invSeller isname of scope

85

Invoking Compensation

• Compensation can only be performed for scope (e.g., invoke, scope) that has completed normally– A compensation handler is not “installed” until the

associated scope has completed normally.• Hence handler must be invoked from outside the scope

– Compensation occurs when a failure is detected• Hence handler is invoked from a global fault or

compensation handler

86

Invoking Compensation

• At most one compensation handler can be explicitly declared local to a scope (in contrast to fault handlers)

• Scope has a name; handler is invoked using <compensate name=“scopeName”/>

• Handler is installed when scope is exited normally (at that point compensation is meaningful)

87

Handler InvocationA

B

C

throw f

catch f compensate B

compensate Ccompensate D

fault handlerfor f

compensationhandler for B

compensationhandler for C

Although B, C andD may have exitednormally, A willexit abnormallyin this case

D compensationhandler for D

88

Compensation<scope> <faultHandlers> <catch faultName=“unable…” faultVariable=“error”> <compensate scope=“invBank”/> </catch> </faultHandlers> <sequence> <invoke name=“invBank” partnerLink=“myBank” interface=“bankIf” operation=“Op” ….> <compensationHandler> <invoke partnerLink=“myBank” interface=“bankIf” operation=“cancelOP” …..> </invoke> </compensationHandler> </invoke> <invoke partnerLink=“loanApprovProc” interface=“lns:loanserviceIf” operation=“request” ….. > </invoke> …………

fault

compensate

normalexit

abnormal exit

89

Default Handlers

• Problem: Suppose a fault handler is not declared

• Compensation handler for C cannot be called from within A

• Solution: default fault handlers automatically invoke declared compensation handlers of immediately enclosed scopes and then rethrow the fault

A

B

C

default handlerfor f

throw f

compensationhandler for C

90

Default Handlers

• Problem: Suppose a compensation handler is not declared

• Compensation handler for C cannot be called from within A

• Solution: default compensation handler automatically invokes declared compensation handlers of immediately enclosed scopes

A

B

C

defaultcompensation handler

throw f

compensationhandler for C

fault handlerfor f

catch f compensate B

91

Structure of a BP

<process name=“…” abstractProcess=“yes|no” … />

<partnerLinks> … </partnerLinks> <variables> … </variables> <correlationSets> … </correlationSets> <faultHandlers> … </faultHandlers> <compensationHandlers> … </compensationHandlers> activity</process>