bpel study material

Enterprise Computing:

Business Process Execution Language

(BPEL)

Stephen Gilmore

The University of Edinburgh

Lecture content copyright c©

O’Reilly and Associates, Inc.,

101 Morris Street, Sebastopol,

CA 95472, U.S.A.

All rights reserved.

Introduction

Within companies, business applications have

to interoperate and integrate — so they have

between companies.

Integrating different applications has always

been a difficult task for various functional and

technology related reasons.

The most recent answer to the integration

challenge is the Service Oriented Architecture

(SOA) and the web services technologies.

The most recent answer to the integration

challenge is the Service Oriented Architecture

(SOA) and the web services technologies.

The bottom-up view of the SOA sees different

business applications exposing their

functionalities through web services. Thus we

can now access different functionalities of

different legacy and new developed applications

in a standard way (through web services).

Developing the web services and exposing the

functionalities is not sufficient. We also need a

way to compose these functionalities in the

right order — a way to define business

processes which will make use of the exposed

functionalities.

Developing the web services and exposing the

functionalities is not sufficient. We also need a

way to compose these functionalities in the

right order — a way to define business

processes which will make use of the exposed

functionalities.

We would obviously prefer a relatively simple

and straightforward way to define such

processes, particularly because we know that

business processes change often, therefore we

would like to modify them easily.

This is where the BPEL (Business Process

Execution Language for Web Services, also

WS-BPEL or BPEL4WS) becomes important.

BPEL allows composition of web services and

is thus the top-down approach to SOA — the

process-oriented approach to SOA.

Role of BPEL

The process-oriented approach to SOA

requires a language for relatively simple

description of how web services should be

composed into business processes.

Role of BPEL

The process-oriented approach to SOA

requires a language for relatively simple

description of how web services should be

composed into business processes.

Of course it would be great if such

descriptions could also be executed, which

would allow us not only to define abstract

process definitions, but to write exact

executable specifications of processes.

Role of BPEL

The process-oriented approach to SOA

requires a language for relatively simple

description of how web services should be

composed into business processes.

Of course it would be great if such

descriptions could also be executed, which

would allow us not only to define abstract

process definitions, but to write exact

executable specifications of processes.

BPEL is such a language.

BPEL is the first language which:

1. Allows us to define abstract and

executable processes

2. Is supported by the majority of major

companies

3. Software exists (from several vendors) on

which such processes can be executed

(BPEL servers) and developed (BPEL

designers).

Web Service composition

There are two primary ways in which web

services can be composed: orchestration and

choreography.

Web Service composition

There are two primary ways in which web

services can be composed: orchestration and

choreography.

Orchestration

In orchestration, a central process takes

control over the involved web services and

coordinates the execution of different

operations on the web services involved in the

operation. This is done as per the

requirements of the orchestration.

The involved web services do not know (and

do not need to know) that they are involved

into a composition and that they are a part of

a higher business process.

The involved web services do not know (and

do not need to know) that they are involved

into a composition and that they are a part of

a higher business process.

Only the central coordinator of the

orchestration knows this, so the orchestration

is centralized with explicit definitions of

operations and the order of invocation of web

services.

Choreography

Choreography on the other hand does not rely

on a central coordinator. Rather, each web

service involved in the choreography knows

exactly when to execute its operations and

whom to interact with.

Choreography

Choreography on the other hand does not rely

on a central coordinator. Rather, each web

service involved in the choreography knows

exactly when to execute its operations and

whom to interact with.

Choreography is a collaborative effort focused

on exchange of messages. All participants of

the choreography need to be aware of the

business process, operations to execute,

messages to exchange, and the timing of

message exchanges.

From the perspective of composing web

services to execute business processes,

orchestration is the more flexible approach

compared to choreography:

• We know exactly who is responsible for the

execution of the whole business process.

• We can incorporate web services, even

those that are not aware that they are a

part of a business process.

• We can also provide alternative scenarios

when faults occur.

BPEL follows the orchestration paradigm.

Choreography is covered by other standards,

such as WSCI (Web Services choreography

Interface) and WS-CDL (Web Services

Choreography Description Language).

BPEL follows the orchestration paradigm.

Choreography is covered by other standards,

such as WSCI (Web Services choreography

Interface) and WS-CDL (Web Services

Choreography Description Language).

Choreography has not gained support from the

industry which would be comparable to BPEL.

BPEL can be used within and between

companies. Within companies the role of

BPEL is to standardize enterprise application

integration and extend the integration to

previously isolated systems.

BPEL can be used within and between

companies. Within companies the role of

BPEL is to standardize enterprise application

integration and extend the integration to

previously isolated systems.

Between enterprises, BPEL will enable easier

and more effective integration with business

partners.

Definitions of business processes described in

BPEL do not impact existing systems thus

stimulating upgrades.

Definitions of business processes described in

BPEL do not impact existing systems thus

stimulating upgrades.

BPEL is the key technology in environments

where functionalities already are or will be

exposed via web services. With increases in the

use of web service technology the importance

of BPEL will rise further.

BPEL Language

BPEL supports two types of business process:

• Executable processes allow us to specify

the exact details of business processes.

They can be executed by an orchestration

engine. In most cases BPEL is used for

executable processes.

BPEL Language

BPEL supports two types of business process:

• Executable processes allow us to specify

the exact details of business processes.

They can be executed by an orchestration

engine. In most cases BPEL is used for

executable processes.

• Abstract business protocols allow us to

specify the public message exchange

between parties only. They do not include

the internal details of process flows and

are not executable.

BPEL builds on top of XML and web services.

It is an XML-based language which supports

the web services technology stack, including

SOAP, WSDL, UDDI, WS-Reliable Messaging,

WS-Addressing, WS-Coordination and

WS-Transaction.

BPEL represents a convergence of two early

workflow languages, WSFL (Web Services

Flow Language) and XLANG.

WSFL was designed by IBM and is based on

the concept of directed graphs. XLANG was

designed by Microsoft and is a block-structured

language. BPEL combines both approaches

and provides a rich vocabulary for description

of business processes.

Service invocation

A BPEL process specifies the exact order in

which participating web services should be

invoked. This can be done sequentially or in

parallel.

With BPEL, we can express conditional

behaviour, for example, a web service

invocation can depend on the value of a

previous invocation. We can also construct

loops, declare variables, copy and assign

values, define fault handlers, and so on.

With BPEL, we can express conditional

behaviour, for example, a web service

invocation can depend on the value of a

previous invocation. We can also construct

loops, declare variables, copy and assign

values, define fault handlers, and so on.

By combining all these constructs, we can

define complex business processes in an

algorithmic manner.

BPEL is thus comparable to general purpose

programming language such as Java, but it is

not as powerful as Java.

On the other hand it is simpler and better

suited for business process definition.

Therefore BPEL is not a replacement but

rather a supplement to modern languages such

as Java.

A typical BPEL process

First, the BPEL business process receives a

request. To fulfill it, the process then invokes

the involved web services and finally responds

to the original caller.

A typical BPEL process

First, the BPEL business process receives a

request. To fulfill it, the process then invokes

the involved web services and finally responds

to the original caller.

Because the BPEL process communicates with

other web services, it relies heavily on the

WSDL description of the web services invoked

by the composite web service.

A typical BPEL process

First, the BPEL business process receives a

request. To fulfill it, the process then invokes

the involved web services and finally responds

to the original caller.

Because the BPEL process communicates with

other web services, it relies heavily on the

WSDL description of the web services invoked

by the composite web service.

A BPEL process consists of steps. Each step

is called an activity. BPEL supports primitive

and structured activities.

Primitive activities represent basic constructs

and are used for common tasks, such as those

listed below:

Primitive activities represent basic constructs

and are used for common tasks, such as those

listed below:

• Invoking other web services, using <invoke>

Primitive activities represent basic constructs

and are used for common tasks, such as those

listed below:

• Invoking other web services, using <invoke>

• Waiting for the client to invoke the

business process through sending a

message, using <receive> (receiving a

request)

Primitive activities represent basic constructs

and are used for common tasks, such as those

listed below:

• Invoking other web services, using <invoke>

• Waiting for the client to invoke the

business process through sending a

message, using <receive> (receiving a

request)

• Generating a response for synchronous

operations, using <reply>

Primitive activities represent basic constructs

and are used for common tasks, such as those

listed below:

• Invoking other web services, using <invoke>

• Waiting for the client to invoke the

business process through sending a

message, using <receive> (receiving a

request)

• Generating a response for synchronous

operations, using <reply>

• Manipulating data variables, using <assign>

• Indicating faults and exceptions, using

<throw>

• Indicating faults and exceptions, using

<throw>

• Waiting for some time, using <wait>

• Indicating faults and exceptions, using

<throw>

• Waiting for some time, using <wait>

• Terminating the entire process, using

<terminate>, etc.

• Indicating faults and exceptions, using

<throw>

• Waiting for some time, using <wait>

• Terminating the entire process, using

<terminate>, etc.

We can then combine these and other primitive

activities and define complex algorithms, which

exactly specify the steps of business processes.

To combine primitive activities BPEL supports

several structured activities.

To combine primitive activities BPEL supports

several structured activities.

• Sequence (<sequence>), which allows us to

define a set of activities that will be

invoked in an ordered sequence

To combine primitive activities BPEL supports

several structured activities.

• Sequence (<sequence>), which allows us to

define a set of activities that will be

invoked in an ordered sequence

• Flow (<flow>) for defining a set of

activities that will be invoked in parallel

To combine primitive activities BPEL supports

several structured activities.

• Sequence (<sequence>), which allows us to

define a set of activities that will be

invoked in an ordered sequence

• Flow (<flow>) for defining a set of

activities that will be invoked in parallel

• Case-switch construct (<switch>) for

implementing branches

To combine primitive activities BPEL supports

several structured activities.

• Sequence (<sequence>), which allows us to

define a set of activities that will be

invoked in an ordered sequence

• Flow (<flow>) for defining a set of

activities that will be invoked in parallel

• Case-switch construct (<switch>) for

implementing branches

• While (<while>) for defining loops

To combine primitive activities BPEL supports

several structured activities.

• Sequence (<sequence>), which allows us to

define a set of activities that will be

invoked in an ordered sequence

• Flow (<flow>) for defining a set of

activities that will be invoked in parallel

• Case-switch construct (<switch>) for

implementing branches

• While (<while>) for defining loops

• The ability to select one of a number of

alternative paths, using <pick>

Each BPEL process will also declare variables,

using <variable>, and define partner links,

using <partnerLink>.

A BPEL process can be synchronous or

asynchronous.

A BPEL process can be synchronous or

asynchronous.

A synchronous BPEL process blocks the client

(the one which is using the process) until the

process finishes and returns a result to the

client.

A BPEL process can be synchronous or

asynchronous.

A synchronous BPEL process blocks the client

(the one which is using the process) until the

process finishes and returns a result to the

client.

An asynchronous process does not block the

client. Rather it uses a callback to return the

result (if any).

Usually we use asynchronous processes for

longer-lasting processes and synchronous for

processes that return a result in a relatively

short time.

If a BPEL process uses asynchronous web

services, the process itself is usually also

asynchronous (although this is not necessary).

For its clients a BPEL process looks like any

other web service. When we define a BPEL

process, we actually define a new web service

that is a composition of existing services.

For its clients a BPEL process looks like any

other web service. When we define a BPEL

process, we actually define a new web service

that is a composition of existing services.

The interface of the new BPEL composite web

service uses a set of port types, through which

it provides operations like any other web

service.

For its clients a BPEL process looks like any

other web service. When we define a BPEL

process, we actually define a new web service

that is a composition of existing services.

The interface of the new BPEL composite web

service uses a set of port types, through which

it provides operations like any other web

service.

To invoke a business process described in

BPEL, we have to invoke the resulting

composite web service.

Partner Links

BPEL processes interact with external web

services in two ways:

Partner Links

BPEL processes interact with external web

services in two ways:

• The BPEL process invokes operations on

other web services.

Partner Links

BPEL processes interact with external web

services in two ways:

• The BPEL process invokes operations on

other web services.

• The BPEL process receives invocations

from clients. One of the clients is the user

of the BPEL process, which makes the

initial invocation. Other clients are web

services, for example, those that have

been invoked by the BPEL process, but

make callbacks to return replies.

BPEL calls the links to all parties it interacts

with partner links.

Partner links can be links to web services that

are invoked by the BPEL process. Partner

links can also be links to clients which invoke

the BPEL process.

BPEL calls the links to all parties it interacts

with partner links.

Partner links can be links to web services that

are invoked by the BPEL process. Partner

links can also be links to clients which invoke

the BPEL process.

Each BPEL process has at least one client

partner link, because there has to be a client

that invokes the BPEL process.

Usually a BPEL process will also have at least

one invoked partner link, because it will most

likely invoke at least one web service (usually

more than one).

Usually a BPEL process will also have at least

one invoked partner link, because it will most

likely invoke at least one web service (usually

more than one).

Invoked partner links may, however, become

client partner links—this is usually the case

with asynchronous services, where the process

invokes an operation.

Usually a BPEL process will also have at least

one invoked partner link, because it will most

likely invoke at least one web service (usually

more than one).

Invoked partner links may, however, become

client partner links—this is usually the case

with asynchronous services, where the process

invokes an operation.

Later the service (partner) invokes the

call-back operation on the process to return

the requested data.

BPEL treats clients as partner links for two

reasons. The most obvious reason is support

for asynchronous interactions. The second

reason is based on the fact that the BPEL

process can offer services.

BPEL treats clients as partner links for two

reasons. The most obvious reason is support

for asynchronous interactions. The second

reason is based on the fact that the BPEL

process can offer services.

These services, offered through port types, can

be used by more than one client. The process

may wish to distinguish between different

clients and offer them only the functionality

they are authorized to use.

To sum up, we can see that the partner links

describe links to partners, where partners

might be:

To sum up, we can see that the partner links

describe links to partners, where partners

might be:

• Services invoked by the process

To sum up, we can see that the partner links

describe links to partners, where partners

might be:

• Services invoked by the process

• Services that invoke the process

To sum up, we can see that the partner links

describe links to partners, where partners

might be:

• Services invoked by the process

• Services that invoke the process

• Services that have both roles—they are

invoked by the process and they invoke the

process

BPEL Example

To get an idea how a BPEL process looks we

show below a very simple BPEL process, which

selects the best insurance offer. We first

declare the partner links to the BPEL process

client (called client) and two insurance web

services (called insuranceA and insuranceB):

1 <?xml version=”1.0” encoding=”utf−8”?>

2

3 <process name=”insuranceSelectionProcess”

4 targetNamespace=”http://packtpub.com/bpel/example/”

5 xmlns=”http://schemas.xmlsoap.org/ws/2003/03/business−process/”

6 xmlns:ins=”http://packtpub.com/bpel/insurance/”

7 xmlns:com=”http://packtpub.com/bpel/company/” >

8

9 <partnerLinks>

10 <partnerLink name=”client”

11 partnerLinkType=”com:selectionLT”

12 myRole=”insuranceSelectionService”/>

13

14 <partnerLink name=”insuranceA”

15 partnerLinkType=”ins:insuranceLT”

16 myRole=”insuranceRequester”

17 partnerRole=”insuranceService”/>

18

19 <partnerLink name=”insuranceB”

20 partnerLinkType=”ins:insuranceLT”

21 myRole=”insuranceRequester”

22 partnerRole=”insuranceService”/>

23

24 </partnerLinks>

25 ...

Next, we declare variables for the insurance

request (InsuranceRequest), insurance A and B

responses (InsuranceAResponse,

InsuranceBResponse), and for final selection

(InsuranceSelectionResponse):

1 ...

2 <variables>

3 <!−− input for BPEL process −−>

4 <variable name=”InsuranceRequest”

5 messageType=”ins:InsuranceRequestMessage”/>

6 <!−− output from insurance A −−>

7 <variable name=”InsuranceAResponse”

8 messageType=”ins:InsuranceResponseMessage”/>

9 <!−− output from insurance B −−>

10 <variable name=”InsuranceBResponse”

11 messageType=”ins:InsuranceResponseMessage”/>

12 <!−− output from BPEL process −−>

13 <variable name=”InsuranceSelectionResponse”

14 messageType=”ins:InsuranceResponseMessage”/>

15 </variables>

16 ...

Finally, we specify the process steps.

Finally, we specify the process steps.

First we wait for the initial request message

from the client (<receive>).

Finally, we specify the process steps.

First we wait for the initial request message

from the client (<receive>).

Then we invoke both insurance web services

(<invoke>) in parallel using the <flow> activity.

The insurance web services return the

insurance premium.

Finally, we specify the process steps.

First we wait for the initial request message

from the client (<receive>).

Then we invoke both insurance web services

(<invoke>) in parallel using the <flow> activity.

The insurance web services return the

insurance premium.

Then we select the lower amount

(<switch>/<case>) and return the result to the

client (the caller of the BPEL process) using

<reply> activity:

1 ...

2 <sequence>

3

4 <!−− Receive the initial request from client −−>

5 <receive partnerLink=”client”

6 portType=”com:InsuranceSelectionPT”

7 operation=”SelectInsurance”

8 variable=”InsuranceRequest”

9 createInstance=”yes” />

10

11 <!−− Make concurrent invocations to Insurance A and B −−>

12 <flow>

13

14 <!−− Invoke Insurance A web service −−>

15 <invoke partnerLink=”insuranceA”

16 portType=”ins:ComputeInsurancePremiumPT”

17 operation=”ComputeInsurancePremium”

18 inputVariable=”InsuranceRequest”

19 outputVariable=”InsuranceAResponse” />

20

21 <!−− Invoke Insurance B web service −−>

22 <invoke partnerLink=”insuranceB”

23 portType=”ins:ComputeInsurancePremiumPT”

24 operation=”ComputeInsurancePremium”

25 inputVariable=”InsuranceRequest”

26 outputVariable=”InsuranceBResponse” />

27

28 </flow>

29

30 <!−− Select the best offer and construct the response −−>

31 <switch>

32

33 <case condition=”bpws:getVariableData(’InsuranceAResponse’,

34 ’confirmationData’,’/confirmationData/Amount’)

35 <= bpws:getVariableData(’InsuranceBResponse’,

36 ’confirmationData’,’/confirmationData/Amount’)”>

37

38 <!−− Select Insurance A −−>

39 <assign>

40 <copy>

41 <from variable=”InsuranceAResponse” />

42 <to variable=”InsuranceSelectionResponse” />

43 </copy>

44 </assign>

45 </case>

46

47 <otherwise>

48 <!−− Select Insurance B −−>

49 <assign>

50 <copy>

51 <from variable=”InsuranceBResponse” />

52 <to variable=”InsuranceSelectionResponse” />

53 </copy>

54 </assign>

55 </otherwise>

56 </switch>

57

58 <!−− Send a response to the client −−>

59 <reply partnerLink=”client”

60 portType=”com:InsuranceSelectionPT”

61 operation=”SelectInsurance”

62 variable=”InsuranceSelectionResponse”/>

63

64 </sequence>

65

66 </process>

Because each BPEL process is a web service

each BPEL process needs a WSDL document

too.