1 business process execution language for web services (bpel4ws)
TRANSCRIPT
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>