Introduction to Business Process Execution Language for Web
Introduction to Business Process Execution Language for Web Services (BPEL 4 WS) Joseph M. Chiusano Booz | Allen | Hamilton XML. gov Working Group Washington, DC February 18, 2004
Overview 4 Introduction 4 Partner Links 4 Main BPEL 4 WS Process Flow Constructs 4 Message Correlation 4 Process Compensation 4 Questions 1
Introduction 2
BPEL 4 WS (Business Process Execution Language For Web Services) provides a language for the formal specification of business process behavior based exclusively on Web Services 4 BPEL 4 WS extends the Web Services interaction model and enables it to support business transactions § It defines a model and grammar for describing the behavior of a business process based on interactions between the process and its partners 4 The BPEL 4 WS specification was originally authored by IBM, Microsoft, BEA Systems, SAP, and Siebel Systems § The most current public version is Version 1. 1 (May 2003) http: //www-106. ibm. com/developerworks/webservices/library/ws-bpel/ 4 The OASIS WS BPEL Technical Committee is advancing the BPEL 4 WS Specification § Updated version planned for release in February/March 2004 3
BPEL 4 WS sits at the top of the emerging Web Services stack, at the “process/collaboration modeling” layer 4 BPEL 4 WS sits above Web Services Choreography definitions Process/Collaboration Modeling Definitions Web Services Choreography Definitions Current Web Services Stack BPEL 4 WS WSCI, W 3 C Web Services Choreography WSDL, SOAP, Messaging, Discovery, etc. 4
The BPEL 4 WS process model is layered on top of the service model defined by WSDL 1. 1 4 WSDL specifies a hierarchy for describing Web Services characteristics in an abstract form: Port Type (“Interface” in 2. 0) Ex: Purchase Order Interface Operations Ex: Purchase Order Status Query Messages Ex: Submit Purchase Order Number, Receive Status Parts Ex: Purchase Order Number, Status 5
BPEL 4 WS is capable of modeling complex business processes, and the dependencies between activities 4 The following is a BPEL 4 WS process for handling a purchase order: “Purchase Order” port. Type “Invoice Services” port. Type “Production Scheduling” port. Type operation message <port. Type name=“scheduling. PT” <operation name=“request. Production. Scheduling”> <input message=“pos: POMessage”/> </operation> “Shipping <operation name=“send. Shipping. Schedule”> Services” <input message=“pos: schedule. Message”/> port. Type </operation> </port. Type> operation “Initiate Production Scheduling” operation “Complete Production Scheduling” operation Source: BPEL 4 WS Version 1. 1 Specification 6
Partner Links 7
Partner links are used to represent interactions between a service and each of the parties with which it interacts 4 Partner links define the messages and port types used in the interactions in both directions, along with role names “Purchasing” partner link “Invoicing” partner link “Scheduling” partner link <partner. Link name="scheduling" partner. Link. Type="lns: scheduling. LT" partner. Role="scheduling. Service"/> <plnk: partner. Link. Type name="scheduling. LT"> “Shipping” <plnk: role name="scheduling. Service"> partner link <plnk: port. Type name="pos: scheduling. PT"/> </plnk: role> </plnk: partner. Link. Type> The port. Type used in the partner link 8
Main BPEL 4 WS Process Flow Constructs 9
The “receive”, “flow” and “reply” constructs are the main BPEL 4 WS constructs used to represent process flows 4 The purchase order example uses all three constructs “Receive” construct “Flow” construct “Reply” construct 10
The “receive”, “flow” and “reply” constructs are the main BPEL 4 WS constructs used to represent process flows (cont’d) 4 The receive construct allows a process to do a blocking wait for a matching message to arrive <receive partner. Link="purchasing" port. Type="lns: purchase. Order. PT" operation="send. Purchase. Order" variable="PO"> </receive> Wait to receive a purchase order on the “Purchasing” partner link Represents the purchase order message 4 The flow construct allows one or more activities to be performed concurrently Source: SOAP 1. 1 Recommendation 11
The “receive”, “flow” and “reply” constructs are the main BPEL 4 WS constructs used to represent process flows (cont’d) 4 The reply construct allows a process to send a message in reply to a message that was received through a <receive> Send invoice on the “Purchasing” partner link <reply partner. Link="purchasing" port. Type="lns: purchase. Order. PT" operation="send. Purchase. Order" variable=“Invoice"> </reply> Represents the invoice message Source: SOAP 1. 1 Recommendation 12
BPEL 4 WS is also capable of modeling dependencies between activities 4 There are several dependencies in the purchase order example Cannot complete price calculation until shipper is determined Cannot complete production scheduling until shipping logistics are arranged Source: BPEL 4 WS Version 1. 1 Specification 13
The synchronization dependencies between concurrent tasks are expressed by using “links” to connect them 4 The following represents the dependency of the price calculation on the shipper selected: <invoke partner. Link=“shipping" port. Type="lns: shipping. PT" operation=“request. Shipping" input. Variable="shipping. Request"> output. Variable="shipping. Info"> <source link. Name="ship-to-invoice"/> </invoke> <invoke partner. Link=“invoicing" port. Type="lns: compute. Price. PT" operation=“send. Shipping. Price" input. Variable="shipping. Info"> <target link. Name="ship-to-invoice"/> </invoke> This represents the “Decide on Shipper” activity The common link name represents aa dependency between the two activities This represents the “Complete Price Calculation” activity 14
Message Correlation 15
Message correlation involves the association of two or more messages with each other in an asynchronous environment 4 This may be done by associating contents in a given message with its correlating message § For example, in a purchase order/invoice scenario, the invoice may contain the corresponding purchase order number Purchase Order: Invoice: <Purchase. Order> <Purchase. Order. Number> <Purchase. Order. Date>. . . . </Purchase. Order> <Invoice. Number> <Invoice. Date> <Purchase. Order. Number>. . . . </Invoice> Purchase order number is common in both messages Source: SOAP 1. 1 Recommendation 16
BPEL 4 WS represents message correlations using “correlation sets” 4 A correlation set contains a set of properties shared Declares correlated group correlation between purchase <invoke order and invoice partner. Link="Buyer" port. Type="SP: Buyer. PT" by all messages in a operation="Async. Purchase. Response" input. Variable="POResponse"> <correlations> <correlation set="Purchase. Order" initiate="no" pattern="out"> <correlation set="Invoice" initiate="yes" pattern="out"> </correlations> A customer ID </invoke> and order number <correlation. Set name="Purchase. Order" properties="cor: customer. ID cor: order. Number"/> represent a unique purchase order <correlation. Set name="Invoice" properties="cor: vendor. ID cor: invoice. Number"/> A vendor ID and invoice number represent a unique invoice 17
Endpoint References 18
BPEL 4 WS uses “endpoint references” for dynamic selection of service providers and invocation of their operations 4 The relevant information about a partner service can be set up as part of business process deployment § This is a more “static” approach 4 However, it is also possible to select and assign partner services dynamically 4 BPEL 4 WS leverages the WS-Addressing specification for this capability § WS-Addressing defines a standard representation for endpoint references that incorporates information from a WSDL description as well as policy information: <wsa: Endpoint. Reference xmlns: wsa=". . . "> <wsa: Address>http: //www. someendpoint. com</wsa: Address> <wsa: Port. Type>Purchase. Order. Port. Type</wsa: Port. Type> </wsa: Endpoint. Reference> § URL: http: //msdn. microsoft. com/ws/2003/03/ws-addressing The port. Type associated with the address 19
Process Compensation 20
Business processes are often of long duration, which means that a business process may need to be cancelled after many transactions have been committed during its progress 4 Consider a situation in which a user cancels a purchase order: Revert back to original state Sub mit Pur cha se Ord er Pro ces s Pur cha se Ord er Che ck Inve ntor y Ord er Fro m Sup plier User Cancels! 4 In this situation, it is not possible to lock system resources (ex: database records) for extended periods of time § Therefore, the partial work must be undone as best as possible 21
BPEL 4 WS defines “compensation handlers” that are invoked to perform compensation activities 4 A compensation handler is essentially a “wrapper” for compensation activities § Specifies a compensating operation on a given port. Type for a given partner link: The <compensation. Handler> “Cancel. Purchase” <invoke partner. Link="Seller" operation invokes port. Type="SP: Purchasing" a cancellation operation="Cancel. Purchase" input. Variable="get. Response" output. Variable="get. Confirmation"> The response to the purchase <correlations> request is used <correlation set="Purchase. Order" as input pattern="out"/> </correlations> </invoke> </compensation. Handler> 22
Questions? 23
Contact Information Joseph M. Chiusano Booz | Allen | Hamilton Mc. Lean, VA (703) 902 -6923 chiusano_joseph@bah. com 24
- Slides: 25