XML Working Group Washington, DC February 18, 2004

1. Introduction to Business Process Execution Language for Web Services (BPEL4WS) Joseph M. Chiusano Booz | Allen | Hamilton XML.gov Working Group Washington, DC February 18, 2004

2. Overview • Introduction • Partner Links • Main BPEL4WS Process Flow Constructs • Message Correlation • Process Compensation • Questions

3. Introduction

4. BPEL4WS (Business Process Execution Language For Web Services) provides a language for the formal specification of business process behavior based exclusively on Web Services • BPEL4WS 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 • The BPEL4WS 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/ • The OASIS WS BPEL Technical Committee is advancing the BPEL4WS Specification • Updated version planned for release in February/March 2004

5. BPEL4WS WSCI, W3C Web Services Choreography WSDL, SOAP, Messaging, Discovery, etc. BPEL4WS sits at the top of the emerging Web Services stack, at the “process/collaboration modeling” layer • BPEL4WS sits above Web Services Choreography definitions Process/Collaboration Modeling Definitions Web Services Choreography Definitions Current Web Services Stack

6. 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 The BPEL4WS process model is layered on top of the service model defined by WSDL 1.1 • WSDL specifies a hierarchy for describing Web Services characteristics in an abstract form:

7. “Production Scheduling” portType “Invoice Services” portType “Purchase Order” portType operation <portType name=“schedulingPT” <operation name=“requestProductionScheduling”> <input message=“pos:POMessage”/> </operation> <operation name=“sendShippingSchedule”> <input message=“pos:scheduleMessage”/> </operation> </portType> operation “Initiate Production Scheduling” operation “Shipping Services” portType “Complete Production Scheduling” operation BPEL4WS is capable of modeling complex business processes, and the dependencies between activities • The following is a BPEL4WS process for handling a purchase order: message Source: BPEL4WS Version 1.1 Specification

8. Partner Links

9. “Invoicing” partner link “Scheduling” partner link “Purchasing” partner link <partnerLink name="scheduling" partnerLinkType="lns:schedulingLT" partnerRole="schedulingService"/> <plnk:partnerLinkType name="schedulingLT"> <plnk:role name="schedulingService"> <plnk:portType name="pos:schedulingPT"/> </plnk:role> </plnk:partnerLinkType> The portType used in the partner link “Shipping” partner link Partner links are used to represent interactions between a service and each of the parties with which it interacts • Partner links define the messages and port types used in the interactions in both directions, along with role names

10. Main BPEL4WS Process Flow Constructs

11. “Receive” construct “Flow” construct “Reply” construct The “receive”, “flow” and “reply” constructs are the main BPEL4WS constructs used to represent process flows • The purchase order example uses allthree constructs

12. The “receive”, “flow” and “reply” constructs are the main BPEL4WS constructs used to represent process flows (cont’d) • The receive construct allows a process to do a blocking wait for a matching message to arrive <receive partnerLink="purchasing" portType="lns:purchaseOrderPT" operation="sendPurchaseOrder" variable="PO"> </receive> • The flow construct allows one or more activities to be performed concurrently Wait to receive a purchase order on the “Purchasing” partner link Represents the purchase order message Source: SOAP 1.1 Recommendation

13. The “receive”, “flow” and “reply” constructs are the main BPEL4WS constructs used to represent process flows (cont’d) • The reply construct allows a process to send a message in reply to a message that was received through a <receive> <reply partnerLink="purchasing" portType="lns:purchaseOrderPT" operation="sendPurchaseOrder" variable=“Invoice"> </reply> Send invoice on the “Purchasing” partner link Represents the invoice message Source: SOAP 1.1 Recommendation

14. BPEL4WS is also capable of modeling dependencies between activities • There are several dependencies in the purchase order example Cannot complete production scheduling until shipping logistics are arranged Cannot complete price calculation until shipper is determined Source: BPEL4WS Version 1.1 Specification

15. The common link name represents a dependency between the two activities The common link name represents a dependency between the two activities The synchronization dependencies between concurrent tasks are expressed by using “links” to connect them • The following represents the dependency of the price calculation on the shipper selected: <invoke partnerLink=“shipping" portType="lns:shippingPT" operation=“requestShipping" inputVariable="shippingRequest"> outputVariable="shippingInfo"> <source linkName="ship-to-invoice"/> </invoke> <invoke partnerLink=“invoicing" portType="lns:computePricePT" operation=“sendShippingPrice" inputVariable="shippingInfo"> <target linkName="ship-to-invoice"/> </invoke> This represents the “Decide on Shipper” activity This represents the “Complete Price Calculation” activity

16. Message Correlation

17. Purchase Order: Invoice: <PurchaseOrder> <PurchaseOrderNumber> <PurchaseOrderDate> ........ </PurchaseOrder> <Invoice> <InvoiceNumber> <InvoiceDate> <PurchaseOrderNumber> ........ </Invoice> Purchase order number is common in both messages Message correlation involves the association of two or more messages with each other in an asynchronous environment • 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 Source: SOAP 1.1 Recommendation

18. Declares correlation between purchase order and invoice A customer ID and order number represent a unique purchase order A vendor ID and invoice number represent a unique invoice BPEL4WS represents message correlations using “correlation sets” • A correlation set contains a set of properties shared by all messages in a correlated group <invoke partnerLink="Buyer" portType="SP:BuyerPT" operation="AsyncPurchaseResponse" inputVariable="POResponse"> <correlations> <correlation set="PurchaseOrder" initiate="no" pattern="out"> <correlation set="Invoice" initiate="yes" pattern="out"> </correlations> </invoke> <correlationSet name="PurchaseOrder" properties="cor:customerID cor:orderNumber"/> <correlationSet name="Invoice" properties="cor:vendorID cor:invoiceNumber"/>

19. Endpoint References

20. BPEL4WS uses “endpoint references” for dynamic selection of service providers and invocation of their operations • The relevant information about a partner service can be set up as part of business process deployment • This is a more “static” approach • However, it is also possible to select and assign partner services dynamically • BPEL4WS 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:EndpointReference xmlns:wsa="..."> <wsa:Address>http://www.someendpoint.com</wsa:Address> <wsa:PortType>PurchaseOrderPortType</wsa:PortType> </wsa:EndpointReference> • URL: http://msdn.microsoft.com/ws/2003/03/ws-addressing The portType associated with the address

21. Process Compensation

22. Revert back to original state Submit Purchase Order Process Purchase Order Check Inventory Order From Supplier 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 • Consider a situation in which a user cancels a purchase order: • 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 User Cancels!

23. BPEL4WS defines “compensation handlers” that are invoked to perform compensation activities • A compensation handler is essentially a “wrapper” for compensation activities • Specifies a compensating operation on a given portType for a given partner link: <compensationHandler> <invoke partnerLink="Seller" portType="SP:Purchasing" operation="CancelPurchase" inputVariable="getResponse" outputVariable="getConfirmation"> <correlations> <correlation set="PurchaseOrder" pattern="out"/> </correlations> </invoke> </compensationHandler> The “CancelPurchase” operation invokes a cancellation The response to the purchase request is used as input

24. Questions?

25. Contact Information • Joseph M. Chiusano • Booz | Allen | Hamilton • McLean, VA • (703) 902-6923 • chiusano_joseph@bah.com