Web Services Business Process Execution Language s1

Web Services Business Process Execution Language Version 2.0 Primer Initial Draft, 12th September, 2006

Document identifier:

wsbpel-primer-draft-06

Location:

Editors and Contributors:

Charleton Baretto, Adobe < [email protected]> Vaughn Bullard, Amberpoint Thomas Erl, SOA Systems John Evdemon, Microsoft Diane Jordan, IBM Dieter Koenig, IBM Simon Moser, IBM Ralph Stout, iWay Software Ron Ten-Hove, Sun Ivana Trickovic, SAP < [email protected]> Danny van der Rijn, Tibco Alex Yiu, Oracle

Abstract:

The WS-BPEL 2.0 specification provides a language for formally describing business processes and business interaction protocols. WS-BPEL was designed to extend the Web Services interaction model to support business transactions. wsbpel-primer-draft-06 8 September 2006

Copyright © OASIS Open 2006. All Rights Reserved. Page 1 of 33 The WS-BPEL Primer is a non-normative document intended to provide an easy to read explanation of the WS-BPEL 2.0 specification. The goal of this document is to help readers understand the concepts and major components of the WS-BPEL language. This document will also assist readers in recognizing appropriate scenarios for using WS- BPEL. This document describes several features of WS-BPEL using examples and extensive references to the normative specification.

Status:

This is the initial draft version of the WS-BPEL Primer.

wsbpel-primer-draft-06 12 September 2006

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director.

OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

1. Introduction...... 6 1.1. Terminology...... 6 1.2. Objective...... 6 1.3. Non-Normative Status...... 6 1.4. Relationship to the WS-BPEL Specification...... 6 1.5. Outline of this Document...... 6 2. History of WS-BPEL...... 7 2.1. Design Goals...... 7 2.2. XLANG and WSFL...... 8 3. Scenario...... 9 3.1. Description...... 9 4. Getting Started...... 10 4.1. The Structure of BPEL Processes...... 10 4.2. Relationship to Business Partners...... 10 4.3. State of a BPEL Process...... 11 4.4. Behavior of a BPEL Process...... 11 4.4.1. Providing and Consuming Web Services...... 11 4.4.2. Structuring the Process Logic...... 13 4.4.3. Repetitive Activities...... 14 4.4.4. Parallel Processing...... 15 4.4.5. Data Manipulation...... 15 4.4.6. Exception Handling...... 15 5. Advanced Concepts...... 16 5.1. Advanced Web Service Interactions...... 16 5.2. Advanced Control Flow...... 16 5.3. Concurrent Data Manipulation...... 16 5.4. Undoing Completed Work...... 16 5.5. Terminating Running Work...... 16 5.6. Dynamic Business Partner Resolution...... 16 6. More Advanced Concepts...... 17 6.1. Language Extensibility...... 17 6.2. Abstract Processes...... 17 7. Using WS-BPEL...... 18 7.1. Applying WS-BPEL to our scenario...... 18 7.2. Considerations...... 18 8. Summary...... 19 8.1. Benefits of WS-BPEL...... 19 8.2. Next Steps...... 19 A. WS-BPEL FAQ...... 20 B. References...... 21 C. Acknowledgements...... 23 wsbpel-primer-draft-06 12 September 2006

WS-BPEL is an acronym for Web Services Business Process Execution Language. WS-BPEL is a revision of the original acronym BPEL4WS (Business Process Execution Language for Web Services).

The preferred acronym is WS-BPEL for the following reasons:

 BPEL4WS refers to the 1.1 and 1.0 versions of the specification  BPEL may cause confusion because it does not refer to either version of the specification 1.2. Objective

Blah blah blah 1.3. Non-Normative Status

Blah blah blah 1.4. Relationship to the WS-BPEL Specification

Blah blah blah 1.5. Outline of this Document

Section 2 explains …

Goal 1: Define business processes that interact with external entities through Web service operations defined using WSDL 1.1 and that manifest themselves as Web services defined using WSDL 1.1. The interactions are “abstract” in the sense that the dependence is on portType definitions, not on port definitions.

Goal 2: Define business processes using an XML based language. Do not define a graphical representation of processes or provide any particular design methodology for processes.

Goal 3: Define a set of Web service orchestration concepts that are meant to be used in common by both the external (abstract) and internal (executable) views of a business process. Such a business process defines the behavior of a single autonomous entity, typically operating in interaction with other similar peer entities. It is recognized that each usage pattern (i.e. abstract view and executable view) will require a few specialized extensions, but these extensions are to be kept to a minimum and tested against requirements such as import/export and conformance checking that link the two usage patterns.

Goal 4: Provide both hierarchical and graph-like control regimes, and allow their usage to be blended as seamlessly as possible. This should reduce the fragmentation of the process modeling space.

Goal 5 : Provide limited data manipulation functions that are sufficient for the simple manipulation of data that is needed to define process relevant data and control flow.

Goal 6: Support an identification mechanism for process instances that allows the definition of instance identifiers at the application message level. Instance identifiers should be partner defined and may change over time.

Goal 7: Support the implicit creation and termination of process instances as the basic lifecycle mechanism. Advanced lifecycle operations like suspend, resume may be added in future releases for enhanced lifecycle management.

Goal 8: Define a long-running transaction model that is based on practically proven techniques like compensation actions and scoping to support failure recovery for parts of long-running business processes.

Goal 9: Use Web services as the model for process decomposition and assembly. wsbpel-primer-draft-06 12 September 2006

Copyright © OASIS Open 2006. All Rights Reserved. Page 7 of 33 Goal 10: Build on compatible Web services standards and standards proposals as much as possible in a composable and modular manner. 2.2. XLANG and WSFL

The Business Process Execution Language for Web Services (BPEL4WS) was first conceived in July, 2002 with the release of the BPEL4WS 1.0 specification, a joint effort by IBM, Microsoft, and BEA. This document proposed an orchestration language inspired by previous variations, such as IBM’s Web Services Flow Language (WSFL) and Microsoft’s XLANG specification.

Joined by other contributors from SAP and Siebel Systems, version 1.1 of the BPEL4WS specification was released less than a year later, in May of 2003. This version received more attention and vendor support, leading to a number of commercially available BPEL4WS- compliant orchestration engines. Just prior to this release, the BPEL4WS specification was submitted to an OASIS technical committee so that the specification could be developed into an official, open standard.

The case study in this primer follows the step-by-step process which a consulting firm named Perspective Technology Corp. (hereafter referred to as “PTC”) uses to build a WS-BPEL process definition for their new Timesheet Submission Process.

Add overview diagram for the PTC process … (avoid XML syntax in this chapter) …

First of all, a BPEL Process is a container where you can declare relationships to external partners, declarations for process data, handlers for various purposes and, most importantly, the activities to be executed. On top, the process container has a couple of attributes, i.e. a (mandatory) name and a (also mandatory) declaration of a namespace – as shown in the example below. You should note that not all possible attributes of the process element are shown in this example.

As you’ve already noticed, there is another attribute abstractProcess shown in the example. The reason it is listed here is that the BPEL specification distinguishes between two usage patterns of BPEL processes: One for describing business protocols (abstractProcess="yes"), one for describing executable processes (abstractProcess="no").

Business protocols describe the externally visible behavior of the process towards business partners without exposing the internal business logic. Executable processes, by contrast, define the internal business logic behind the external protocol. 4.2. Relationship to Business Partners

BPEL Business Processes offer the possibility to aggregate web services and define the business logic between each of these service interactions. It is also said that BPEL choreographs sich web service interaction. Each service interaction can be regarded as a communication with a business partner. In BPEL terms, each party that a process interacts with is called partner. The interaction takes place with the help of so-called Partner Links. Partner links are instances of typed connectors which specify the WSDL Port Types the process offers to and requires from a partner at the other end of the Partner Link.

TODO: picture

Note that for one partner, there can be a set of Partner Links. You can regard one Partner Link as one particular communication channel. Such an interaction is potentially two sided: the process invokes the partner and the partner invokes the process. Therefore, each partnerLink is wsbpel-primer-draft-06 12 September 2006

Copyright © OASIS Open 2006. All Rights Reserved. Page 10 of 33 characterized by a Partner Link Type and a role name. This information identifies the functionality that must be provided by the business process and by the partner service.

4.3. State of a BPEL Process

Variables hold the data that constitute the state of a BPEL business process during runtime. Data in BPEL is written to and read from typed variables. The values contained in such variables can be of two sources: either they come from messages exchanged with a partner, or it is intermediate data that is private to the process. In order to fulfill type-contracts with the partner, all variables in BPEL must either be WSDL message types, XML schema simple types or XML schema elements. In order to change the state of a process by changing the content of its variables, an expression language for manipulating and querying variables is required. In BPEL, the default language for that is XPath.

You can declare a variable by specifying a name and one of the three types mentioned above.

Variable declarations can take place directly under the process element, which means that they are visible to all BPEL constructs within the BPEL process. 4.4. Behavior of a BPEL Process

The major building blocks of BPEL processes are activities. There are two types: structured activities can contain other activities and define the business logic between them. In contrast, simple activities only perform their intended purpose (like calling a service, or manipulating data) and have no means to define any kind of activity internal logic.

4.4.1. Providing and Consuming Web Services

In BPEL, there exist a couple of simple activities with the purpose of consuming messages from and providing messages to web service partners. These activities are the receive activity, the reply activity and the invoke activity. All these activities allow exchanging messages with external partners (services). wsbpel-primer-draft-06 12 September 2006

Copyright © OASIS Open 2006. All Rights Reserved. Page 11 of 33 The purpose of the receive activity is receiving messages from an external partner. Therefore, a receive activity always specifies the partner link and the WSDL port type and operation of the partners the web service. You need also to specify a variable that holds the requested data that will be received from the partner. A receive activity has one or more associated reply activities if it is used to provide a WSDL request-response operation.

The attribute called createInstance on the receive activity means that you can use a receive activity with createInstace="yes" to create a new process instance, whereas createInstace="no" means that the incoming message will be consumed by the (already running) process instance.

As already mentioned, one receive activity can have an associated reply activity. You might think of a client that wants to order a book from a book selling process. The client would send a request to the receive activity of the book selling process, the process then would do some internal logic (like determining whether the book is available, checking if the delivery address and the provided credit card number are correct etc.). After that logic is done, it would be natural for the process to respond to the client to let him know whether the order was successful or not.

You should be aware that a reply activity can come in two flavors: It can reply normal data (which would yield to a normal reply), or it can reply faulted data (like a “the book is out of Stock” exception in the example above), which would then yield to a “faulted reply”. If so, you should specify an additional faultName attribute on the reply activity.

As you see, the reply activity is typically used in conjunction with the receive activity to implement a WSDL request-response operation on a particular communication channel (Partner Link). It provides means to return data to the caller by specifying a partnerLink and the WSDL portType and operation for the Web service. The specified variable holds the response data or fault data returned to the caller of the Web service. If fault data is returned, the faultName identifies the corresponding WSDL fault.

The third web-service related activity is the Invoke activity. The Invoke activity is used to call a

Copyright © OASIS Open 2006. All Rights Reserved. Page 12 of 33 web service provided by a partner. A Partner link as well as a WSDL port Type and operation of the web service to be called must be specified.

In WSDL 1.1 there exist multiple types of operations. Two of them are supported by BPEL: one- way operations and request-response operations. An Invoke activity can therefore either call a one-way operation (and would then continue with the process logic without waiting for the partner to reply), or a request-response operation (which would block the process (or a part of it) until it receives a response from the partner service. If the operation that is invoked is of type request-response operation, you must provide both an input and output variable. In case it is a one-way operation, you only have to specify an input variable.

//TODO: @DK - example w/ in- and output

//TODO2: I think we should remove this here, since a.) handlers are not yet introduced and b.) scopes are not know yet – however: where to move this ?

Besides, you can specify various handlers on an Invoke activity. This is because an invoke Activity can be regarded as a shorthand notation of a scope activity that contains the handlers allowed as well as the invoke activity itself. The handlers allowed are fault handlers, compensation handlers and termination handlers.

For more information on scopes see section XXX, the various types of handlers will be explained in greater detail in section XXX

For the sake of completeness it should be mentioned that there are more web-service related constructs like the Pick Activity and a handler called Event Handler which will be described in sections XXX and XXX, respectively.

4.4.2. Structuring the Process Logic

BPEL provides means to structure the business logic according to your needs. If you need a number or activities executed in a sequential order (e.g. first receive the order, then check the payment, then ship the goods, then send a confirmation) you can do so by using BPELs Sequence Activity. In other words, the Sequence activity is used to define a collection of activities which are executed sequentially in lexical order.

Another activity used for structuring the business logic is the if-else activity. The construct might be known from traditional programming languages. The if-else activity allows you to select exactly one branch of the activity from a given set of choices. For each choice, the behaviour is to check a condition and if that condition evaluates to true, the associated branch is executed, otherwise an alternative path is taken. As with all expressions in BPEL, you can use XPath expressions to formulate your condition. Note that only the first branch with a true condition is executed. If no condition evaluates to true, then a default choice can be specified using the else branch.

bool-expr: if order > 5000 $ bool-expr: if order > 2500 $

4.4.3. Repetitive Activities

BPEL offers three activites that allow the repeated execution of a piece of business logic. One of these activities is the While activity. The While activity is a structured activity, i.e. it has a child nested within. The While activity allows you to repeatedly execute the child activities as long as a given condition evaluates to true. The condition is specified on the while activity and gets evaluated at the beginning of each iteration, which means consequently that the body of the while activity might not be executed at all (if the condition does not evaulate to true at all).

bool-expr: if iterations > 3 $

In contrast, the repeat until Activity has the difference that the body of the activity is performed at least once, since the condition is evaulated at the end of each iteration.

bool-expr: if iterations > 3 $ wsbpel-primer-draft-06 12 September 2006

The third activity in the group of repetitive activities is the forEach Activity (in the serial version).

Explain loops (serial forEach) …

4.4.4. Parallel Processing

Explain flows and links …

4.4.5. Data Manipulation

Explain assignment …

4.4.6. Exception Handling

Explain fault handler (on process level)

Explain pick, processes with multiple receive activities, event handlers …

Explain properties and correlation sets …

Explain Message Exchange Patterns … 5.2. Advanced Control Flow

Explain parallel forEach …

Explain DPE …

Explain other activities (wait, exit, empty, validate) … 5.3. Concurrent Data Manipulation

Explain isolation concepts … 5.4. Undoing Completed Work

Explain long-running business transactions and compensation handling … 5.5. Terminating Running Work

Explain termination processing and termination handlers … 5.6. Dynamic Business Partner Resolution

Explain dynamic EPR assignment …

Explain ExtensionActivity, ExpressionLanguage/QueryLanguage, and general extension points … 6.2. Abstract Processes

Explain templating, externally observable behavior, business protocols …

7.2. Considerations

8.2. Next Steps

What is the difference between orchestration and choreography?

WS-BPEL is an orchestration language, not a choreography langauge. The primary difference between orchestration and choreography is scope. A choreography model provides a larger scope, encompassing all parties and their associated interactions (e.g. a peer to peer model). An orchestration model is between two participants (specifically focusing on the view of one participant).

Why isn’t there a standard notation for WS-BPEL?

This was considered out of scope. See the original design goals in section 3.1 of this document.

Who is implementing WS-BPEL?

At the time thjs primer was prepared the following organizations had committed to supporting WS-BPEL (this is by no means an exhaustive list):

 Active Endpoints ActiveWebflow Server  ActiveBPEL Engine (open source).  BEA WebLogic Workshop  bexee BPEL Execution Engine (open source)  Cape Clear Orchestrator  FiveSight PXE  IBM WebSphere Business Integration – Server Foundation V5.1  IBM WebSphere Process Server V6.0  Microsoft BizTalk Server  Microsoft Windows Workflow Foundation  OpenLink Virtuoso Universal Server  OpenStorm ChoreoServer  Oracle BPEL Process Manager  Parasoft BPEL Maestro  SeeBeyond eInsight BPM  Sun Java Studio Enterprise  Twister (open source)

What are the differences between BPEL4WS 1.1 and OASIS WS-BPEL 2.0? wsbpel-primer-draft-06 12 September 2006

What is WS-BPEL’s relationship to WS-CAF, BPSS, BPMN, WSCDL and BPEL-J?

 WS-CAF: WS-CAF is a Choreography initiative, unlike WS-BPEL which is an Orchestration language. Simply put, WS-CAF defines a “global” process model which includes all participants in the process and each of their responsibilities. WS-BPEL defines a single participant’s view into a process.  BPSS: BPSS is a Choreography language, unlike WS-BPEL which is an Orchestration language. BPSS defines a “global” process model which includes all participants in the process and each of their responsibilities. WS-BPEL defines a single participant’s view into a process.  BPMN: Business Process Modeling Notation (BPMN) is OMG’s graphical notation that for documenting a business process. A paper is available that illustrates how BPMN can be mapped to BPEL. Note that this paper may not be aligned with the latest version of the WS-BPEL 2.0 specification.  BPEL-J:  BPXL: BPXL is an intiative launched by BPMI (now part of OMG). The gosl of BPXL is to define a standardized way for extending the base WS-BPEL specification. B. References Normative References

[BPEL4WS 1.1] BEA, IBM, Microsoft, SAP and Siebel, “Business Process Execution Language for Web Services Version 1.1”, S. Thatte, et al., May 2003. ftp://www6.software.ibm.com/software/developer/library/ws-bpel.pdf

[Infoset] W3C Recommendation, “XML Information Set (Second Edition)”, J. Cowan, R. Tobin, February 4, 2004. http://www.w3.org/TR/2004/REC-xml-infoset-20040204

[RFC 2119] IETF, “Key words for use in RFCs to Indicate Requirement Levels”, RFC 2119, S. Bradner, March 1997. http://www.ietf.org/rfc/rfc2119.txt

[RFC 2396] IETF, “Uniform Resource Identifiers (URI): Generic Syntax”, RFC 2396, T. Berners-Lee, R. Fielding, L. Masinter, August 1998. http://www.ietf.org/rfc/rfc2396.txt

Copyright © OASIS Open 2006. All Rights Reserved. Page 21 of 33 [WSDL 1.1] W3C Note, “Web Services Definition Language (WSDL) 1.1”, E. Christensen, F. Curbera, G. Meredith, S. Weerawarana, March 15, 2001. http://www.w3.org/TR/2001/NOTE-wsdl-20010315

[WS-I Basic Profile 1.1 Errata] Web Services Interoperability Organization, “Basic Profile Version 1.1 Errata”, Revison 1.8, A. Karmarkar , October 25, 2005. http://www.ws-i.org/Profiles/BasicProfile-1.1-errata-2005-10-25.html

[WS-I Basic Profile] Web Services Interoperability Organization, “Basic Profile Version 1.1", K. Ballinger, D. Ehnebuske, M. Gudgin, M. Nottingham, P. Yendluri, April 16, 2004. http://www.ws-i.org/Profiles/BasicProfile-1.1.html

[XML Namespace] W3C Recommendation , “Namespaces in XML”, T. Bray, D. Hollander, A. Layman, January 14, 1999. http://www.w3.org/TR/1999/REC-xml-names-19990114

[XML Schema Part 1] W3C Recommendation, “XML Schema Part 1: Structures Second Edition”, H. S. Thompson, D. Beech, M. Maloney, N. Mendelsohn, October 28, 2004. http://www.w3.org/TR/2004/REC-xmlschema-1- 20041028/

[XML Schema Part 2] W3C Recommendation, “XML Schema Part 2: Datatypes Second Edition”, P. V. Biron, A. Malhotra, October 28, 2004. http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/

[XMLSpec] W3C Recommendation, “Extensible Markup Language (XML) 1.0 (Third Edition)", T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, F. Yergeau, February 4, 2004. http://www.w3.org/TR/2004/REC-xml-20040204

[XPATH 1.0] W3C Recommendation, “XML Path Language (XPath) Version 1.0”, J. Clark, S. DeRose, November 1999. http://www.w3.org/TR/1999/REC-xpath-19991116

[XSLT 1.0] W3C Recommendation, “XSL Transformations (XSLT) Version 1.0”, J. Clark, November 16, 1999. http://www.w3.org/TR/1999/REC-xslt- 19991116 Non-Normative References

[Sagas] Garcia-Molina H. and Kenneth Salem, "SAGAS", Proceedings of the ACM SIGMOD International Conference on Management of Data, pages 249--259, May 1987. wsbpel-primer-draft-06 12 September 2006

Copyright © OASIS Open 2006. All Rights Reserved. Page 22 of 33 [SOAP 1.1] W3C Note, “Simple Object Access Protocol (SOAP) 1.1”, D. Box, D. Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. F. Nielsen, S. Thatte, D. Winer, May 8, 2000. http://www.w3.org/TR/2000/NOTE-SOAP-20000508

[Trends] Traiger I. L., "Trends in System Aspects of Database Management", Proceeding of the 2nd International Conference on Database (ICOD- 2), pages 1-21, Wiley & Sons, 1983.

[UDDI] OASIS, “UDDI Version 3.0.2”, L. Clement, A. Hately, C. V. Riegen, T. Rogers, October 19, 2004. http://uddi.org/pubs/uddi-v3.0.2- 20041019.htm

[WSFL] IBM, “Web Service Flow Language (WSFL 1.0)”, F. Leymann, May 2001. http://www- 306.ibm.com/software/solutions/webservices/pdf/WSFL.pdf

[XLANG] Microsoft, “XLANG Web Services for Business Process Design”, S. Thatte, 2001. http://www.gotdotnet.com/team/xml_wsspecs/xlang- c/default.htm C. Acknowledgements

The authors of this Primer would like to extend their thanks and appreciation to Thomas Erl for contributing sections of his book "Service-Oriented Architecture: Concepts, Technology, and Design" to this effort.

Let’s begin with the root element of a WS-BPEL process definition. It is assigned a name value using the name attribute and is used to establish the process definition-related namespaces.

... ... ... ...

Example: A skeleton process definition.

The process construct contains a series of common child elements explained in the following sections. The partnerLinks and partnerLink elements

A partnerLink element establishes the port type of the service (partner) that will be participating during the execution of the business process. Partner services can act as a client to the process, responsible for invoking the process service. Alternatively, partner services can be invoked by the process service itself.

The contents of a partnerLink element represent the communication exchange between two partners – the process service being one partner and another service being the other. Depending on the nature of the communication, the role of the process service will vary. For instance, a process service that is invoked by an external service may act in the role of “TimesheetSubmissionProcess.” However, when this same process service invokes a different wsbpel-primer-draft-06 12 September 2006

Copyright © OASIS Open 2006. All Rights Reserved. Page 24 of 33 service to have an invoice verified, it acts within a different role, perhaps “InvoiceClient.” The partnerLink element therefore contains the myRole and partnerRole attributes that establish the service provider role of the process service and the partner service respectively.

Put simply, the myRole attribute is used when the process service is invoked by a partner client service, because in this situation the process service acts as the service provider. The partnerRole attribute identifies the partner service that the process service will be invoking, since that would make the partner service the service provider.

Note that both myRole and partnerRole attributes can be used by the same partnerLink element when it is expected that the process service will act as both service requestor and service provider with the same partner service. For example, during asynchronous communication between the process and partner services, the myRole setting indicates the process service’s role during the callback of the partner service.

Example: The partnerLinks construct containing one partnerLink element in which the process service is invoked by an external client partner, and four partnerLink elements that identify partner services invoked by the process service.

You’ll notice that in Example above, each of the partnerLink elements also contains a partnerLinkType attribute. This refers to the partnerLinkType construct, as explained next. The partnerLinkType element

For each partner service involved in a process, partnerLinkType elements identify the WSDL portType elements referenced by the partnerLink elements within the process definition. Therefore, these constructs are typically embedded directly within the WSDL documents of every partner service (including the process service). wsbpel-primer-draft-06 12 September 2006

Copyright © OASIS Open 2006. All Rights Reserved. Page 25 of 33 The partnerLinkType construct contains one role element for each role the service can play, as defined by the partnerLink myRole and partnerRole attributes. Therefore, a partnerLinkType will have either one or two child role elements.

... ...

Example: A WSDL definitions construct containing a partnerLinkType construct.

Note that multiple partnerLink elements can reference the same partnerLinkType. This is useful for when a process service has the same relationship with multiple partner services. All of the partner services can therefore use the same process service portType elements.

Note: In version 2.0 of the WS-BPEL specification it is being proposed that the portType element be changed so that it exists as an attribute of the role element. The variables element

WS-BPEL process services commonly use the variables construct to store state information related to the immediate workflow logic. Entire messages and data sets formatted as XSD schema types can be placed into a variable and retrieved later during the course of the process. The type of data that can be assigned to a variable element needs to be predefined using one of the following three attributes: messageType, element, or type.

The messageType attribute allows for the variable to contain an entire WSDL-defined message, whereas the element attribute simply refers to an XSD element construct. The type attribute can be used to just represent an XSD simpleType, such as string or integer.

Example: The variables construct hosting only some of the child variable elements used later by the Timesheet Submission Process.

Typically, a variable with the messageType attribute is defined for each input and output message processed by the process definition. The value of this attribute is the message name from the partner process definition. The getVariableProperty … function

WS-BPEL provides built-in functions that allow information stored in or associated with variables to be processed during the execution of a business process. getVariableProperty(variable name, property name)

This function allows global property values to be retrieved from variables. It simply accepts the variable and property names as input and returns the requested value. The sequence element

The sequence construct allows you to organize a series of activities so that they are executed in a predefined, sequential order. WS-BPEL provides numerous activities that can be used to express the workflow logic within the process definition. The remaining element descriptions in this section explain the fundamental set of activities used as part of our upcoming case study examples.

... ... ... ...

Note that sequence elements can be nested, allowing you to define sequences within sequences. The invoke element

This element identifies the operation of a partner service that the process definition intends to invoke during the course of its execution. The invoke element is equipped with five common attributes which further specify the details of the invocation (see table below).

Attribute Description partnerLink This element names the partner service via its corresponding partnerLink. portType The element used to identify the portType element of the partner service. operation The partner service operation to which the process service will need to send its request. inputVariable The input message that will be used to communicate with the partner service operation. Note that it is referred to as a variable because it is referencing a WS-BPEL variable element with a messageType attribute. outputVariable This element is used when communication is based on the request- response MEP. The return value is stored in a separate variable element. invoke element attributes.

Example: The invoke element identifying the target partner service details. The receive element

The receive element allows us to establish the information a process service expects upon receiving a request from an external client partner service. In this case, the process service is viewed as a service provider waiting to be invoked. wsbpel-primer-draft-06 12 September 2006

Copyright © OASIS Open 2006. All Rights Reserved. Page 28 of 33 The receive element contains a set of attributes, each of which is assigned a value relating to the expected incoming communication (see table below).

Attribute Description partnerLink The client partner service identified in the corresponding partnerLink construct. portType The partner service’s portType involved in the message transfer. operation The partner service’s operation that will be issuing the request to the process service. variable The process definition variable construct in which the incoming request message will be stored. createInstance When this attribute is set to “yes” the receipt of this particular request may be responsible for creating a new instance of the process. receive element attributes.

Note that this element can also be used to receive callback messages during an asynchronous message exchange.

Example: The receive element used in the Timesheet Submission Process definition to indicate the client partner service responsible for launching the process with the submission of a timesheet document. The reply element

Where there’s a receive element, there’s a reply element when a synchronous exchange is being mapped out. The reply element is responsible for establishing the details of returning a response message to the requesting client partner service. Because this element is associated with the same partnerLink element as its corresponding receive element, it repeats a number of the same attributes (see table below).

Attribute Description partnerLink The same partnerLink element established in the receive element. wsbpel-primer-draft-06 12 September 2006

Copyright © OASIS Open 2006. All Rights Reserved. Page 29 of 33 portType The same portType element displayed in the receive element. operation The same operation element from the receive element. variable The process service variable element that holds the message that is returned to the partner service. messageExchange It is being proposed that this optional attribute be added by the WS-BPEL 2.0 specification. It allows for the reply element to be explicitly associated with a message activity capable of receiving a message (such as the receive element). reply element attributes.

Example: A potential companion reply element to the previously displayed receive element. The switch, case, and otherwise elements

These three structured activity elements allow us to add conditional logic to our process definition, similar to the familiar select case/case else constructs used in traditional programming languages. The switch element establishes the scope of the conditional logic, wherein multiple case constructs can be nested to check for various conditions using a condition attribute. When a condition attribute resolves to “true,” the activities defined within the corresponding case construct are executed.

The otherwise element can be added as a catch all at the end of the switch construct. Should all preceding case conditions fail, the activities within the otherwise construct are executed.

... ...

Example: A skeleton case element wherein the condition attribute uses the getVariableData function to compare the content of the EmployeeResponseMessage variable to a zero value.

Copyright © OASIS Open 2006. All Rights Reserved. Page 30 of 33 Note: It has been proposed that the switch, case, and otherwise elements be replaced with if, elseif, and else elements in WS-BPEL 2.0. The assign, copy, from, and to elements

This set of elements simply gives us the ability to copy values between process variables, which allows us to pass around data throughout a process as information is received and modified during the process execution.

Example: Within this assign construct, the contents of the TimesheetSubmissionFailedMessage variable are copied to two different message variables.

Note that the copy construct can process a variety of data transfer functions (for example, only a part of a message can be extracted and copied into a variable). Also, from and to elements can contain optional part and query attributes that allow for specific parts or values of the variable to be referenced. The faultHandlers, catch, and catchAll elements

This construct can contain multiple catch elements, each of which provides activities that perform exception handling for a specific type of error condition. Faults can be generated by the receipt of a WSDL-defined fault message, or they can be explicitly triggered through the use of the throw element. The faultHandlers construct can consist of (or end with) a catchAll element to house default error handling activities.

... ...

Example: The faultHandlers construct hosting catch and catchAll child constructs. wsbpel-primer-draft-06 12 September 2006

The table below provides brief descriptions of other relevant parts of the WS-BPEL language.

Element Description compensationHandler A WS-BPEL process definition can define a compensation process that kicks in a series of activities when certain conditions occur to justify a compensation. These activities are kept in the compensationHandler construct. (For more information about compensations, see the Business activities section in Chapter 6.) correlationSets WS-BPEL uses this element to implement correlation, primarily to associate messages with process instances. A message can belong to multiple correlationSets. Further, message properties can be defined within WSDL documents. empty This simple element allows you to state that no activity should occur for a particular condition. eventHandlers The eventHandlers element enables a process to respond to events during the execution of process logic. This construct can contain onMessage and onAlarm child elements that trigger process activity upon the arrival of specific types of messages (after a predefined period of time, or at a specific date and time, respectively).

Exit See the terminate element description below.

Flow A flow construct allows you to define a series of activities that can occur concurrently and are required to complete after all have finished executing. Dependencies between activities within a flow construct are defined using the child link element.

Pick Similar to the eventHandlers element, this construct can also contain child onMessage and onAlarm elements, but is used more to respond to external events for which process execution is suspended. scope Portions of logic within a process definition can be sub-divided into scopes using this construct. This allows you to define variables, faultHandlers, correlationSets, compensationHandler, and eventHandlers elements local to the scope. exit This element effectively destroys the process instance. throw WS-BPEL supports numerous fault conditions. Using the throw element allows you to explicitly trigger a fault state in response to a specific condition.

Wait The wait element can be set to introduce an intentional delay within the process. Its value can be a set time or a predefined date. wsbpel-primer-draft-06 12 September 2006

Copyright © OASIS Open 2006. All Rights Reserved. Page 32 of 33 while This useful element allows you to define a loop. As with the case element, it contains a condition attribute that, as long as it continues resolving to “true”, will continue to execute the activities within the while construct.

Quick reference table providing short descriptions for additional WS-BPEL elements (listed in alphabetical order).

Summary of key points

 A WS-BPEL process definition is represented at runtime by the process service.  Services that participate in WS-BPEL defined processes are considered partner services, and are established as part of the process definition.  Numerous activity elements are provided by WS-BPEL to implement various types of process logic.