bpel basics

7/30/2019 BPEL Basics

1/91

1

Business Process Execution

Language for Web Services

(BPEL4WS)


2/91

2

BPEL vs. WSDL

WSDL supports a stateless model which describes

operations supported by web servers

One or two messages needed for client/servercommunication

No mechanism for describing state between operations

A business process (BP) typically characterized by

long-running, statefull sequence of operations withone or more web services (business partners).


3/91

3

Simple Example: Ordering

Stationerycobegin

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

4

New Issues

Must be able to communicate with other WebServices

Must be able to access and modify data received inmessages

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

5

Example (BPEL)

.. Continued on next slide..


6/91

6

Example (BPEL)


7/91

7

Business Process (BP)

A BP consists of both internal computations andinvocations of operations exported by web service

partners

The operations it exports constitute its interface toits partners

The sequence of invocations it executes is referred

to as a protocol and is data dependent

responds to exceptional conditions


8/91

8

Abstract Vs. Executable BPs

Executable BPcomplete description of BP (including allcomputations)

Abstract BPcontains only externally visible(communication related) behavior of BP

Not executable

Internal decision making algorithm and datamanipulation not described

Languages for describing abstract and executable BPs

share a common core, but differ primarily in data handlingcapabilities

BPEL4WS is used to specify both abstract and executableBPs


9/91

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

Actual implementation, however, might not use BPEL, Abstract BP specifies external interface and can be

exported for use by business partners


10/91

10

Abstract BP

Unfolding of protocol related portion of BP

depends on properties - a subset of the data contained in

messages Ex. Message invokinggetQuoteRequestmight have parts

instrumentType (with value stock or bond) andsymbol

(which identifies a particular instrument of that type)

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

protocol

symbolwillnot if it does not affect the course of the protocol

Only properties are visible to abstract BP


11/91

11

Abstract Vs Executable BP

Internal computation of executable BP not included inabstract BP

If assignment is to a variable that is not a property, it iseliminated 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 ofbidPrice might affect protocol:

if (bidPrice>1000) invoke webService1 else invoke webService2

bidPrice will be a property, but its value is computed by aninternal algorithm

The computation that produces the new value is generallynot relevant to the protocol


12/91

12

Abstract BPNon-determinism

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

Abstract and executable BPs differ in data handling

abilityExecutable 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/91

13

Abstract BPNon-determinism

computation that

assigns a value

to partx

non-deterministic

assignment

to propertyx(alias of x)

switch(x) switch(x)

Executable BP Abstract BP


14/91

14

CommunicationClient Side

Invoking an operation of an interface(specified in WSDL) exported by server

Client assigns message to operations input

variableClient 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 operations outputvariable


15/91

15


Receiving an operation (e.g., an asynchronous

response to a prior invocation) on a (callback)

operation exported by clientClient executes receive on operation

Client waits for message

Client can access message in variable associated with

operation and resume execution


16/91

16


client server

invoke

invoke

invoke

receive

server exportsinterface

client exports

(callback) operation

(synchronous invoke)

(asynchronous invoke)

client

waits

client

continues

problem: how do

you associate

request with

response?


17/91

17

CommunicationServer 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 clients exported (callback) operation

Server executes invoke on operation


18/91

18

CommunicationServer Side

client server

invoke

server exports

interface

client exports

(callback) interface

(synchronous invoke)

(asynchronous invoke)

receive

reply

receive

receive

invoke

invoke

receive invoke


19/91

19

Example: Purchase Order (PO) Service

initiate

price

calculation

complete

price

calculation

arrange

logistics

invoice

processing,

reply

decide on

shipper

complete

production

scheduling

receive

purchaseorder

initiate

production

scheduling

concurrencysequencing

synchronization


20/91

20

PO Service

customer

receive

reply

Body of PO

Service

POMsg

InvMsg

operationsendPurchOr

on interface

purchOrIf

synchronous

invocation

PO Service


21/91

21

PO Service Interface (WSDL)

..

-- arguments supplied -- response

..

interface exportedby PO Service

prefix for target

namespace in

this document


22/91

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

Has an associated scope

lns is prefix in BPEL document for the WSDL document


23/91

23

Partner Link Type (WSDL)

describes the way two BPs interact:- names an interface that must be declared in each

- associates with each end of the interaction

Only one role since only

POService needs to

provide an interface

Unit ofcollaboration

Not a process(allows actual

partner to be

specified

dynamically)

Identifies a BPEL schema


24/91

24

Partner Link Type (WSDL)

BP playing role

of invoice

requester

BP playing role

of invoice service

invoiceCallbackIf computePriceIf

description of a

possible relationship

between two BPs


25/91

25

Partner Link (BPEL)

hence PO service

must provide

purchOrIf

Connection to another BP described by a partner link 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/91

26

Partner (BPEL)

A BP might interact with another BPcalled a

partner - through several partnerLinks

Need a mechanism that asserts that thesame BP is at

the other end of a set of partnerLinks

Ex: BPs might supportgetFareIfandpurchaseTicketIf;

an acceptable partner is one that supports both


27/91

27

Process Name

Each BP is assigned a name in the tag

declarations and process body

declarations and body of PO service


28/91

28

Linkage: Customer

to PO Service

WSDL inter-

face exportedby PO Service

partner

specification

in customerprocess

partner

specification

in PO Service

plnkprefix in WSDL doc refers

to WSDL extension

postarget ns of WSDL doc

lnsprefix in PO Service refers

to WSDL doc

cnsprefix in customer refers

to WSDL doc


29/91

29

Partners

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 thelocal BP interacts with other BPs through a

partnerLinktype.


30/91

30

PO Service (BPEL)

. concurrent body.

Both necessary since PO Service might communicate

with several BPs through the same interface


31/91

31

Interaction with Shipping Provider

decide on

shipper

(invoke)

arrange

logisitics

(receive)

shippingProvider

shipReqMsg

shipInfoMsg

operation requestShipping

on interfaceshippingIf

operationsendSchedule on

portshippingCallbackIf

role = shippingService

role = shippingRequester

scheduleMsg


32/91

32

Handling Shipping (WSDL)

interface exported

by PO Service

interface imported

from shipping

service


33/91

33

Handling Shipping

WSDL

BPEL


34/91

34

Handling Shipping (BPEL)

contains

inputmessage

Li k (BPEL) S h i i


35/91

35

Links (BPEL)Synchronizing

Concurrent Activities w/I a BP

Production scheduling cannot be completed untillogistics have been arranged

decide on

shipper

arrange

logistics

complete

production

scheduling

initiate

production

scheduling

source target

link

Concurrent sequence activities in flow data produced by

arrange logistics is

needed by complete

production scheduling

data communicated

through globally sharedvariable

fl


36/91

36

Links

.

.

shipping

scheduling

arrange

logistics

complete

production

scheduling

decide on

shipper


37/91

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

Aproperty declares a global name that can be assigned

to data items that may be parts of several differentmessage types and carry the same meaning

taxpayerID might be a part of one message type in onenamespace (e.g., Internal Revenue),ssn might be a part ofanother in a different namespace (e.g., Social Sec. Admin)

Both might represent the same information of type txtyp:SSN


38/91

38

Property Alias (WSDL)

Used to associate a property name with a field inmessage part

A particular property can be associated with differentfields in different messages

query stringspecified in

XPath - to locate the field in

the part


39/91

39

Correlation Sets (BPEL)

A web service might be configured with multipleinstances 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 particularconversation to the correct BP instance

Messages of a particular conversation can be recognized by thefact that they will generally all carry some identifying value(s)(e.g., customerID and orderNum)


40/91

40

Correlation Sets

A correlation setis a set of properties whosevalue is shared by all messages in a particular

conversation.

Hence, an address is really:(host address, port, correlation set)

A correlation setidentifies the BP instance

aliased to items of

information contained

in the messages of a

conversation


41/91

41

Using Correlation Sets

A particularreceive operation can be used in a BPto accept the start of a new conversation

All subsequently arriving messages with same

value of PurchaseOrder will be directed to this BP

create a new correlationset value for BP instance

asynchronous

purchase requst


42/91

42

Using Correlation Sets

Response returns the correlation set value

Asynchronous (callback) response to previousinvocation

A reply to a synchronous invocation would be similar

use the set to

address the

message


43/91

43

Multiple Correlation Sets

buyer server

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

messsage

contains bothcorrelation sets

messages of asingle conversation


44/91

44

Multiple Correlation Sets

With synchronous invocation two messagesare involved; the pattern attribute associates

a correlation set with a message.

invoke (partnerLink=Buyer interface=SP:BuyerIfoperation=synchPurchaseResp

inputVariable=PO outputVariable=invoice>

(initiated in outbound msg) (initiated in inbound msg,

which contains both sets)


45/91

45

Data Manipulation

Data (state) stored in variables (used for messages andlocal storage)

Expressions use expression language (XPath default) toaccess data in variables

Executable processes can use:

All processes can use:

Returns the part (or, if the locationPath is specified thefield 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/91

46

Assignment

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

query is an absolute expression (if XPath is the querylanguage) that identifies a single node w/i the documentfragment specified bypart

from child can also contain a literal value or a simplearithmetic expression (for data transformation)


47/91

47

Assignment in Abstract Process

A non-deterministic value from a propertysdomain can be assigned to the property by an

abstract process using opaque assignment Allows simulation of execution traces


48/91

48

Invoking Web Service Operations

invoke might have child elements related to faults andcompensation (discussed subsequently), and links and

correlation (discussed previously)

invoke specifies apartnerLinksince an interface can beassociated with severalpartnerLinkTypes connected to

different BPs


49/91

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


50/91

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 cant be handled instantly even

with low loads. Asynchronous invocation will play an

increasingly important role.


51/91

51

Providing Web Service Operations

receive waits for an invocation to arrive

specifies apartnerLinksince an interface can

be associated with severalpartnerLinkTypesconnected to different BPs


52/91

52


Initiating a new instance of a BP:

createInstance=yes => a new instance of the BP iscreated 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 acorrelation child element should be specified:


53/91

53


reply is used to respond to a synchronous invocation.

connection between receive and reply based onconstraint 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 madeusing an invoke on a callback operation

partnerLinkbetween requestor and requestee must havetwo roles


54/91

54

Other Basic Activities

or


55/91

55

Structured Activities

at least one case

element; conditions

evaluated in order

if present, executed

if all conditions

fail, else an empty

otherwise is assumed

Involves only

properties if

process is abstract


56/91

56


-- waits for the occurrence of first event

at least one,

acts like

receive

zero or

more


57/91

57


concurrently executes nested (child)

activities

Terminates when all children terminate


58/91

58

WSDL Review

WHAT: interface describes abstract functionality(operations, messages)

HOW: bindingdescribes how elements of aninterface (operations, messages) are mapped to a

particular transport protocol (e.g., SOAP over HTTP,data encoding)

WHERE: endpointmaps a bindingto an address(particular server at a URL)

service is a collection of related endpoints


59/91

59

Endpoint References

A BP isstatically dependent on the interfaces with

which it communicates

However, the endpoints associated with thoseinterfaces (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/91

60

Endpoint References

A message part ofEndpointReferenceType canhold addressing information

Every role in apartnerLinkhas an associatedEndpointReference (of that type) thatidentifies an endpoint (address) and anassociated process instance

AnEndpointReference element is analternative to aservice element

WS Addressing Specification for


61/91

61

WS-Addressing Specification for

Endpoint Reference

a URI -- required

properties (child elements) are inserted here .

wsa identifies WSDL extension namespace forendpoint references

Information to identify a particular instance of a BP can

also be supplied


62/91

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

Endpoint Reference Example


63/91

63


.


64/91

64


..


65/91

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

Receiving an address: to child must be associated with

partnerRole (cant change your own address)

Links Synchronizing Flow


66/91

66

Links Synchronizing Flow

Activities

- any activity can have asource

ortargetchild element

- every link must have exactly

one activity w/i the flow as

its source and one as its target- sequence Ycant start until

sequenceXcompletes

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

67

Link Semantics at the Source

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

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

variable nameproperty name

Link Semantics at the Target


68/91

68


Without considering links, an activity is ready to execute inaccordance with normal flow-of-control rules (sequence, switch,etc.)

In addition, an activity might be the targetof several links.

- Every such activity has ajoinCondition 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.

DefaultjoinCondition: status of at least one incoming link is true

.


69/91

69


joinCondition can be explicitly provided as

an attribute using getLinkStatus() function.

.

must specify an incoming

link for activity X


70/91

70


If thejoinCondition 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 aswitch, an activitythat does not

complete due to a fault) then the status of all

outgoing links fromXis set to negative.

Link


71/91

71

Link

Semantics

.

.

.

- only one case is executed

- joinCondition at C cannotbe 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 notdone C would never start)

- default joinCondition at C is

true when either C1 or C2

completes - since their (default)

transitionCondition is true


72/91

72

Link Semantics

Problemin some cases a falsejoinConditionis not a fault; it is an indication that the activityshould not be performed in at a particular point

in the executionIn that case the status of all outgoing links should

be set to false so that thejoinCondition of otheractivities can be evaluated

Solutionuse activity attributesuppressJoinFailure


73/91

73

Link Semantics

If value of thesuppressJoinFailure attribute of

an activity,A, isyes, then if thejoinCondition

ofA or any nested activity has valuefalsewhen it is ready to execute

status of all of its outgoing links is set to negative

itis skipped and execution continues (as if it hadterminated without raising a fault)

referred to as dead-path-elimination

Link


74/91

74

Link

Semantics

.

.

.

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

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

76

Faults

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

Sources of faults:Explicit raising of a fault

Standard BPEL faults

bpws:joinFailure - joinCondition has value falsebpws:conflictingReceivetwo receives for same

partnerLink, interface and operationpendingwithin aflow at the same time

F l


77/91

77

Faults Source of faults (cont):

Fault response to an invoke. The reply:

raises the fault unableToHandleRequestin customerthat has synchronously invoked requeston interface:


78/91

78

Faults

The reply raises theunableToHandleRequestfault incustomerwhich is handled by

. handle the fault .

Re-throw the same fault

and/or clean-up and/or

invoke a compensation

handler

Handlers


79/91

79

Handlers Handler is associated with an implicit or explicit

scope; catches faults that occur in that scope

. handle the fault.

. handle the fault

other handlers

activities

activities

or

F l Fl f C l


80/91

80

Fault Flow of Control

When a faultfoccurs in some scope,B Execution of activities within are terminated

If a fault handler forfor a catchAllhandler has been

declared local toB, itis executed and execution resumes

in the next enclosing scope at the activity followingB Else fis thrown in the next enclosing scope

In both casesB is said to have exited abnormally

The handler might reverse changes it has made to

variables global toB and invoke compensationhandlers for scopes nested inB that have

completed normally.

F lt Fl f C t l


81/91

81

Fault Flow of ControlA

B catch fthrow g

or

exit

throw f

abnormal exit


82/91

82

Atomicity

A BP is a long running process involving invocationsof 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

Long-Running Business


83/91

83

Long Running Business

Transactions (LRT) Reversing the effect of a BP relies on compensation

a web service might offer a compensating operation for asynchronous operation

Ex. CancelPurchase compensates forPurchase

BPEL supports an LRT by providing compensationhandlers

Allows application to specify a recovery strategy usingcompensating operations

No guarantee of atomicity or isolation

Future work in this direction is being carried out in thecontext of the WS-Transaction specification

Compensation Handler


84/91

84

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

local toscope

Undoes the effect of the scoped activities

--pattern=out indicates set applies to request msg

-- invSeller is

name of scope

I ki C i


85/91

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

86

Invoking Compensation

At most one compensation handler can beexplicitly declared local to a scope (incontrast to fault handlers)

Scope has a name; handler is invoked using

Handler is installed when scope is exitednormally (at that point compensation ismeaningful)

H dl I ti


87/91

87

Handler Invocation

A

B

C

throw f

catch f

compensate B

compensate C

compensate D

fault handler

for f

compensation

handler for B

compensation

handler for C

Although B, C and

D may have exited

normally, A will

exit abnormally

in this case

Dcompensation

handler for D

Compensation


88/91

88

Compensation

fault

compensate

normal

exit

abnormal exit

Default Handlers


89/91

89

Default Handlers

Problem: Suppose a fault handleris not declared

Compensation handler for Ccannot be called from within A

Solution: default fault handlersautomatically invoke declaredcompensation handlers ofimmediately enclosed scopes andthen rethrow the fault

A

B

C

default

handler

for f

throw f

compensation

handler for C

Default Handlers


90/91

90

Default Handlers

Problem: Suppose acompensation handleris not declared

Compensation handler for Ccannot be called from within A

Solution: default compensationhandler automatically invokesdeclared compensation handlersof immediately enclosed scopes

A

B

C

default

compensation

handler

throw f

compensation

handler for C

fault handler

for f

catch f

compensate B


91/91

Structure of a BP

activity

bpel basics

Documents