0% found this document useful (0 votes)
128 views62 pages

Service Oriented Architecture: Lecture 7: BPEL

A needs to know B's interface, so B's WSDL needs to specify: - Port type with operations - Input and output message types - Binding that specifies the protocol (typically SOAP) This allows A to invoke B as a synchronous web service and know what messages to send, and that it will block and wait for a response.

Uploaded by

Rajesh
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
128 views62 pages

Service Oriented Architecture: Lecture 7: BPEL

A needs to know B's interface, so B's WSDL needs to specify: - Port type with operations - Input and output message types - Binding that specifies the protocol (typically SOAP) This allows A to invoke B as a synchronous web service and know what messages to send, and that it will block and wait for a response.

Uploaded by

Rajesh
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 62

Service Oriented Architecture

Lecture 7: BPEL
Some notes selected from Business Process Execution Language for Web Services by Matjaz Juric

95-843: Service Oriented Architecture

Master of Information System Management

We Are Here

From IBMs High Level Reference Architecture


95-843: Service Oriented Architecture

Master of Information System Management

BPEL
Business Process Execution Language Programming in the large Processing logic to handle synchronous and asynchronous messages Quite different from programming in the small - different issues to deal with Structured programming language using while, if else, sequence, flow, XPATH used for addressing message 95-843: Service Oriented Architecture parts 3
Master of Information System Management

Basics
Developing web services and exposing functionalities is not sufficient. 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. BPEL allows composition of web services. BPEL may be used for a long running process. Dehydration is the term used to refer to the saving of a process state. Successfully completed processes as well are saved in the dehydration store.
95-843: Service Oriented Architecture

Master of Information System Management

Web Service Composition Methods - 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. Only the central coordinator of the orchestration knows this. So orchestration is centralized with explicit definitions of operations and the order of invocation of web services.

95-843: Service Oriented Architecture

Master of Information System Management

Web Service Composition Methods - Choreography


Choreography does not rely on a central coordinator. 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. This is a peer-to-peer approach.
95-843: Service Oriented Architecture

Master of Information System Management

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 WSCDL (Web Services Choreography Description Language). Choreography has not gained support from the industry which would be comparable to BPEL.

95-843: Service Oriented Architecture

Master of Information System Management

Programming in the Large History


IBM WSFL (Web Service Flow Language) defined in May 2001. Microsoft XLANG defined around the same time. Joint submission to OASIS under the name BPEL4WS. OASIS (September 2004) WS-BPEL-2.0. Has no standard graphical language. The BPEL process itself is a web service. BPEL business processes are portable.
95-843: Service Oriented Architecture

Master of Information System Management

BPEL
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, WSCoordination and WS-Transaction.
95-843: Service Oriented Architecture

Master of Information System Management

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. Since 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.
95-843: Service Oriented Architecture

Master of Information System Management

10

Steps in a Process
Each step is called an activity. BPEL supports primitive and structure activities. Primitive activities represent basic constructs and are used for common tasks

95-843: Service Oriented Architecture

Master of Information System Management

11

Primitive Activities
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> Waiting for some time, using <wait> Terminating the entire process, using <terminate> etc.
95-843: Service Oriented Architecture

Master of Information System Management

12

Defining Processes
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

95-843: Service Oriented Architecture

Master of Information System Management

13

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>
95-843: Service Oriented Architecture

Master of Information System Management

14

Definitions and Declarations


BPEL processes will typically declare variables using <variable> BPEL processes will typically define partner links using <partnerLink> 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)
95-843: Service Oriented Architecture

Master of Information System Management

15

Example Process
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.
95-843: Service Oriented Architecture

Master of Information System Management

16

95-843: Service Oriented Architecture

Master of Information System Management

17

Typical Structure (1)


<process> <partnerLinks> <partnerLink> <partnerLink> </partnerLinks> <variables> <variable> <variable> </variable> <sequence> <receive> </receive>

the initial client request

95-843: Service Oriented Architecture

Master of Information System Management

18

Partner Links
BPEL calls the links to all parties it interacts with as 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.
95-843: Service Oriented Architecture

Master of Information System Management

19

Typical Structure (2)


<flow> <invoke> <invoke> </flow> make calls in parallel a web service </invoke> another web service </invoke>

95-843: Service Oriented Architecture

Master of Information System Management

20

Typical Structure (3)


<switch> make decisions <case condition => <assign> <copy> <from><to> </case> <otherwise> <assign> <copy> <from><to> </otherwise> </switch> <reply> reply to synchronous caller </sequence> </process>
95-843: Service Oriented Architecture

Master of Information System Management

21

Sequential Order of Activities


<process> . <sequence> Do activities in sequential order. <receive> <invoke> <assign> <invoke> <receive> <invoke> </sequence> </process>

95-843: Service Oriented Architecture

Master of Information System Management

22

Parallel Activities
<process> . <sequence> <receive> Wait to start process <flow> <invoke> <invoke> <invoke> </flow> </sequence> </process>

The three invokes are carried out in parallel.

95-843: Service Oriented Architecture

Master of Information System Management

23

Parallel Sequences
<process> . <sequence> <receive> <flow> <sequence> <invoke> <invoke> </sequence> <sequence> <invoke> <invoke> </sequence> </flow> </sequence> </process> Wait to start process. Both sequences may run in parallel. These two invokes go in order.

These two invokes go in order

95-843: Service Oriented Architecture

Master of Information System Management

24

Synchronous Web Services


The sender blocks and waits for a reply. The service should run fast. The <receive> and <reply> form a pair on B.
<receive> <invoke> No <receive> needed <reply> B is a synchronous web service and uses a BPEL reply. <invoke>..<invoke>

A
95-843: Service Oriented Architecture

B
Master of Information System Management

25

Quiz on Synchronous Web Services


What does A need to know about B? In other words, what is required in Bs WSDL?

<receive> <invoke> <invoke>..<invoke>

No <receive> needed.
<reply>

A
95-843: Service Oriented Architecture

B
Master of Information System Management

B is a synchronous web service and uses a BPEL reply.

26

Quiz on Synchronous Web Services


What does A need to know about B? In other words, what is required in Bs WSDL? A needs to know the message types and the available operations as well as Bs location.
<receive> <invoke> <invoke>..<invoke>

No <receive> needed.
<reply>

A
95-843: Service Oriented Architecture

B
Master of Information System Management

B is a synchronous web service and uses a BPEL reply.

27

Asynchronous Web Services (1)


Most real-world processes are long running and if callbacks are needed, message correlation may be used. If callbacks are not needed, B need not perform an <invoke>.

<receive> <invoke> Do other things <receive> <invoke> B is an asynchronous web service and replies with an optional invoke not a reply. 28 <invoke>..<invoke>

A
95-843: Service Oriented Architecture

B
Master of Information System Management

Quiz on Asynchronous Web Services


What does A need to know in order to use B? In other words, what information must be available in Bs WSDL?

<receive> <invoke> Do other things <receive> <invoke> B is an asynchronous web service and replies with an optional invoke not a reply. 29 <invoke>..<invoke>

A
95-843: Service Oriented Architecture

B
Master of Information System Management

Quiz on Asynchronous Web Services


What does A need to know in order to use B? In other words, what information must be available in Bs WSDL? A needs

to know the message types and the available operations as well as Bs location. In order to use B, A must also know exactly what operations it needs to provide and what messages will be received.
<receive> <invoke> Do other things <receive> <invoke>

<invoke>..<invoke>

A
95-843: Service Oriented Architecture

B
Master of Information System Management

B is an asynchronous web service and replies with an optional invoke not a reply. 30

Example Business Process


Collect employee information (name, id, travel plans, etc.). Determine an employees flying status (first class or coach) and then determine the cheaper of two airlines. Return suggested flight to the employee.

95-843: Service Oriented Architecture

Master of Information System Management

31

Modified Example from Juric Text


<receive>
<invoke>

<invoke> <invoke> : <receive> <invoke> : <receive> <invoke>

Employee Travel Status WS synchronous

Coach or first class

<receive>

price

American Airlines WS asynchronou

price

Asynch Process for Business Travels

Delta Airlines WS asynchronou

95-843: Service Oriented Architecture

Asynchronous web service

Master of Information System Management

32

Partner Links
Partner links describe links to partners.

Partners might be:


(1) Services that invoke the BPEL process. (2) Services invoked by the BPEL process. (3) Services that play both roles - the BPEL process invokes the service and the service invokes a callback on the BPEL process.

95-843: Service Oriented Architecture

Master of Information System Management

33

PartnerLinkTypes
PartnerLinkTypes represent interactions between the parties.

We have three types of interactions in the airline example: (1) The client interacts with the BPEL process. (2) The BPEL process calls the employee status web service. (3) The BPEL process calls the two airline web services and expects callbacks from both.

95-843: Service Oriented Architecture

Master of Information System Management

34

PartnerLinkTypes
Within the BPEL process WSDL, we have two roles defined for one of the links:

<partnerLinkType name="travelLT"> <role name="travelService"> <portType name="tns:TravelApprovalPT" /> </role> <role name="travelServiceCustomer"> <portType name="tns:ClientCallbackPT" /> </role> The interface of the BPEL service is implemented at the service. The interface of the client callback is implemented on the client.

Client callback BPEL Process interface </partnerLinkType> interface travelLT 95-843: Service Oriented Architecture Travel Link Type 35 Master of Information System
Management

PartnerLinkTypes
The employee status WS is synchronous so within the employee status WS WSDL we have one role defined:

<partnerLinkType name="employeeLT"> <role name="employeeTravelStatusService"> <portType name="tns:EmployeeTravelStatusPT" /> </role> </partnerLinkType>


employeeLT Employee Link Type
95-843: Service Oriented Architecture

Interface of employee status web service.

Master of Information System Management

36

PartnerLinkTypes
The airline web services are asynchronous and so within the airline WS WSDLs we have two roles defined:

<partnerLinkType name="flightLT"> <role name="airlineService"> <portType name="tns:FlightAvailabilityPT" /> </role> <role name="airlineCustomer"> <portType name="tns:FlightCallbackPT" /> </role> Callees </partnerLinkType>
95-843: Service Oriented Architecture

callback interface

flightLT Flight Link Type

Airline interface

Master of Information System Management

37

<partnerLinks> <partnerLink name="client" partnerLinkType="trv:travelLT" myRole="travelService" partnerRole="travelServiceCustomer"/>

PartnerLinks Are in the BPEL (1)

<partnerLink name="employeeTravelStatus" partnerLinkType="emp:employeeLT" partnerRole="employeeTravelStatusService"/> <partnerLink name="AmericanAirlines" partnerLinkType="aln:flightLT" myRole="airlineCustomer" partnerRole="airlineService"/> <partnerLink name="DeltaAirlines" partnerLinkType="aln:flightLT" myRole="airlineCustomer" partnerRole="airlineService"/> </partnerLinks>
95-843: Service Oriented Architecture

Master of Information System Management

38

PartnerLinks Are in the BPEL(2)


<partnerLinks> <partnerLink name="client" partnerLinkType="trv:travelLT" myRole="travelService" partnerRole="travelServiceCustomer"/> : :

This partner link is of type travelLT. So, two interfaces are involved. This process is the travel service part. The partner implements the client callback interface.

These names are defined in the partner link type section.

</partnerLinks>
95-843: Service Oriented Architecture

Master of Information System Management

39

PartnerLinks Are in the BPEL(3)


<partnerLinks> : : <partnerLink name="employeeTravelStatus" partnerLinkType="emp:employeeLT" partnerRole="employeeTravelStatusService"/> : : </partnerLinks>

This partner link is of type employeeLT. So, one interface is involved, that is, the interface of the employee status web service.

95-843: Service Oriented Architecture

Master of Information System Management

40

PartnerLinks Are in the BPEL(4)


<partnerLinks>

: : <partnerLink name="AmericanAirlines" partnerLinkType="aln:flightLT" myRole="airlineCustomer" partnerRole="airlineService"/> <partnerLink name="DeltaAirlines" partnerLinkType="aln:flightLT" myRole="airlineCustomer" partnerRole="airlineService"/> </partnerLinks>
95-843: Service Oriented Architecture

Both of these partner links are of type flightLT. As such, two interfaces are mentioned. The role of this process is to provide the callback (FlightCallbackPT) and the role the partner is to provide the

FlightAvailabilityPT.

Master of Information System Management

41

PartnerLinks Are in the BPEL(5)


<partnerLinks> <partnerLink name="client" partnerLinkType="trv:travelLT" myRole="travelService" partnerRole="travelServiceCustomer"/>
<partnerLinkType name="travelLT"> <role name="travelService"> <portType name="tns:TravelApprovalPT" /> </role> <role name="travelServiceCustomer"> <portType name="tns:ClientCallbackPT" /> </role> </partnerLinkType> The interface of the BPEL service is implemented at the service. The interface of the client callback is implemented on the client.

95-843: Service Oriented Architecture

Master of Information System Management

42

PartnerLinks Are in the BPEL(6)


<partnerLink name="employeeTravelStatus" partnerLinkType="emp:employeeLT" partnerRole="employeeTravelStatusService"/>

<partnerLinkType name="employeeLT"> <role name="employeeTravelStatusService"> <portType name="tns:EmployeeTravelStatusPT" /> </role>

95-843: Service Oriented Architecture

Master of Information System Management

43

PartnerLinks Are in the BPEL(7)


<partnerLink name="AmericanAirlines" partnerLinkType="aln:flightLT" myRole="airlineCustomer" partnerRole="airlineService"/> <partnerLink name="DeltaAirlines" partnerLinkType="aln:flightLT" myRole="airlineCustomer" partnerRole="airlineService"/>

<partnerLinkType name="flightLT"> <role name="airlineService"> <portType name="tns:FlightAvailabilityPT" /> </role> <role name="airlineCustomer"> <portType name="tns:FlightCallbackPT" /> </role> </partnerLinkType>

95-843: Service Oriented Architecture

Master of Information System Management

44

Variables in BPEL
<variables> <!-- input for this process --> <variable name="TravelRequest" messageType="trv:TravelRequestMessage"/>

<!-- input for the Employee Travel Status Web service --> <variable name="EmployeeTravelStatusRequest" messageType="emp:EmployeeTravelStatusRequestMessage"/>
<!-- output from the Employee Travel Status Web service --> <variable name="EmployeeTravelStatusResponse" messageType="emp:EmployeeTravelStatusResponseMessage"/>

95-843: Service Oriented Architecture

Master of Information System Management

45

Variables (2)
<!-- input for American and Delta Web services --> <variable name="FlightDetails" messageType="aln:FlightTicketRequestMessage"/> <!-- output from American Airlines --> <variable name="FlightResponseAA" messageType="aln:TravelResponseMessage"/> <!-- output from Delta Airlines --> <variable name="FlightResponseDA" messageType="aln:TravelResponseMessage"/>

<!-- output from BPEL process --> <variable name="TravelResponse" messageType="aln:TravelResponseMessage"/>


</variables>
95-843: Service Oriented Architecture

Master of Information System Management

46

BPEL Main Process (1)


<sequence> <!-- Receive the initial request for business travel from client --> <receive partnerLink="client" portType="trv:TravelApprovalPT" operation="TravelApproval" variable="TravelRequest" createInstance="yes" />

95-843: Service Oriented Architecture

Master of Information System Management

47

BPEL Main Process (2)


<!-- Prepare the input for the Employee Travel Status Web Service --> <assign> <copy> <from variable="TravelRequest" part="employee"/> <to variable="EmployeeTravelStatusRequest" part="employee"/> </copy> </assign>

95-843: Service Oriented Architecture

Master of Information System Management

48

BPEL Main Process (3)


<!-- Synchronously invoke the Employee Travel Status Web Service --> <invoke partnerLink="employeeTravelStatus" portType="emp:EmployeeTravelStatusPT" operation="EmployeeTravelStatus" inputVariable="EmployeeTravelStatusRequest" outputVariable="EmployeeTravelStatusResponse" />

95-843: Service Oriented Architecture

Master of Information System Management

49

BPEL Main Process (4)


<!-- Prepare the input for the airlines. The input comes from two variables. --> <assign> <copy> <from variable="TravelRequest" part="flightData"/> <to variable="FlightDetails" part="flightData"/> </copy> <copy> <from variable="EmployeeTravelStatusResponse" part="travelClass"/> <to variable="FlightDetails" part="travelClass"/> </copy> </assign>

95-843: Service Oriented Architecture

Master of Information System Management

50

BPEL Main Process (5)


<!-- Make a concurrent invocation on both airlines. --> <flow> <sequence> <!-- Async invoke of the AA Web service and wait for the callback--> <invoke partnerLink="AmericanAirlines" portType="aln:FlightAvailabilityPT" operation="FlightAvailability" inputVariable="FlightDetails" /> <receive partnerLink="AmericanAirlines" portType="aln:FlightCallbackPT" operation="FlightTicketCallback" variable="FlightResponseAA" /> </sequence>
95-843: Service Oriented Architecture

The receive operation must occur after the invoke. Hence, the sequence tag is used.

Master of Information System Management

51

BPEL Main Process (6)


<sequence> <!-- Async invoke of the DA Web service and wait for the callback--> <invoke partnerLink="DeltaAirlines" portType="aln:FlightAvailabilityPT" operation="FlightAvailability" inputVariable="FlightDetails" /> <receive partnerLink="DeltaAirlines" portType="aln:FlightCallbackPT" operation="FlightTicketCallback" variable="FlightResponseDA" /> </sequence> </flow>
95-843: Service Oriented Architecture

Only the flow is done in parallel. For the sequence to complete, the airline must respond.

Master of Information System Management

52

BPEL Main Process (7)


<!-- The airlines have responded. Select the best offer and construct the TravelResponse --> <switch> <case condition="bpws:getVariableData('FlightResponseAA', 'confirmationData','/confirmationData/Price') <= bpws:getVariableData('FlightResponseDA', 'confirmationData','/confirmationData/Price')"> <!-- Select American Airlines --> <assign> <copy> <from variable="FlightResponseAA" /> <to variable="TravelResponse" /> </copy> </assign> </case> 95-843: Service Oriented Architecture
Master of Information System Management

53

BPEL Main Process (8)


<otherwise> <!-- Select Delta Airlines --> <assign> <copy> <from variable="FlightResponseDA" /> <to variable="TravelResponse" /> </copy> </assign> </otherwise> </switch>
95-843: Service Oriented Architecture

Master of Information System Management

54

BPEL Main Process (9)


<!-- Make a callback to the client --> <invoke partnerLink="client" portType="trv:ClientCallbackPT" operation="ClientCallback" inputVariable="TravelResponse" /> </sequence>

</process>

95-843: Service Oriented Architecture

Master of Information System Management

55

Sketch of Working Process


sequence receive assign invoke assign flow sequence invoke receive sequence invoke receive switch invoke

information from employee assign to variable invoke service to determine flying status assign result to variable Do sequences in parallel
call airline A get price for ticket call airline B get price for ticket select cheaper flight inform the employee

95-843: Service Oriented Architecture

Master of Information System Management

56

Would this work?


sequence receive flow assign invoke assign invoke receive invoke receive switch invoke No. The previous slide had it right. Here, we have not expressed the synchronization dependencies between activities.

However, BPEL provides for more complex concurrency scenarios using links. A single link is specified with a source and a target.

95-843: Service Oriented Architecture

Master of Information System Management

57

We Need To Add Links


sequence receive flow assign invoke assign invoke receive invoke receive switch invoke

assign before the invoke invoke before the assign assign before the two invokes invoke before receive receive before the switch invoke before receive receive before the switch

95-843: Service Oriented Architecture

Master of Information System Management

58

Sources and Targets In BPEL


<sequence> <receive> <flow> <assign> <source linkName = A/> </assign> <invoke>. <target linkName = A /> <source linkName = B /> </invoke> <assign> <target linkName = B /> <source linkName = C /> <source linkName = D /> </assign>
95-843: Service Oriented Architecture

Assign before invoke.

Invoke before assign

Assign before the two invokes. Link names are user defined and should be well chosen. 59

Master of Information System Management

Sources and Targets


<invoke> <target linkName = C/> <source linkName = E/> </invoke> <receive> <target linkName = E/> <source linkName = G/> </receive> <invoke> <target linkName = D/> <source linkName =F /> </invoke>

95-843: Service Oriented Architecture

Master of Information System Management

60

Sources and Targets


<receive> <target linkName = F/> <source linkName = H/> </receive> <switch> <target linkName = G/> <target linkName = H/> </switch> </flow> <invoke>

95-843: Service Oriented Architecture

Master of Information System Management

61

Concurrency and Links


The flow tag provides the ability to express synchronization dependencies between activities. In other words, we can specify what happens and when. Link definitions are placed within the flow activity. For example, <flow> <links> <link name = A/> <link name = B /> </links> : Every link must be associated with exactly one source and target. A links target activity may only be performed after the source activity has completed. Transition conditions may be added for additional confusion.
95-843: Service Oriented Architecture

Master of Information System Management

62

You might also like