Web Services Business Process Execution Language Version 2.0

Committee Specification

31 January 2007

Specification URIs:

This Version:

http://docs.oasis-open.org/wsbpel/2.0/CS01/wsbpel-v2.0-CS01.html

http://docs.oasis-open.org/wsbpel/2.0/CS01/wsbpel-v2.0-CS01.doc

http://docs.oasis-open.org/wsbpel/2.0/CS01/wsbpel-v2.0-CS01.pdf

Previous Version:

http://docs.oasis-open.org/wsbpel/2.0/PR02/wsbpel-specification-draft.html

http://docs.oasis-open.org/wsbpel/2.0/PR02/wsbpel-specification-draft.doc

http://docs.oasis-open.org/wsbpel/2.0/PR02/wsbpel-specification-draft.pdf

 

Latest Version:

http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.html

http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.doc

http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.pdf

Technical Committee:

OASIS Web Services Business Process Execution Language (WSBPEL) TC

Chair(s):

Diane Jordan, IBM

John Evdemon, Microsoft

Editor(s):

Alexandre Alves, BEA

Assaf Arkin, Intalio

Sid Askary, Individual

Charlton Barreto, Adobe Systems

Ben Bloch, Systinet

Francisco Curbera, IBM

Mark Ford, Active Endpoints, Inc.

Yaron Goland, BEA

Alejandro Guízar, JBoss, Inc.

Neelakantan Kartha, Sterling Commerce

Canyang Kevin Liu, SAP

Rania Khalaf, IBM

Dieter König, IBM

Mike Marin, IBM, formerly FileNet Corporation

Vinkesh Mehta, Deloitte

Satish Thatte, Microsoft

Danny van der Rijn, TIBCO Software

Prasad Yendluri, webMethods

Alex Yiu, Oracle

 

Related work:

·         See Section 3.

Declared XML Namespace(s):

http://docs.oasis-open.org/wsbpel/2.0/process/abstract 

http://docs.oasis-open.org/wsbpel/2.0/process/executable

http://docs.oasis-open.org/wsbpel/2.0/plnktype

http://docs.oasis-open.org/wsbpel/2.0/serviceref 

http://docs.oasis-open.org/wsbpel/2.0/varprop

Abstract:

This document defines a language for specifying business process behavior based on Web Services. This language is called Web Services Business Process Execution Language (abbreviated to WS-BPEL in the rest of this document). Processes in WS-BPEL export and import functionality by using Web Service interfaces exclusively.

Business processes can be described in two ways. Executable business processes model actual behavior of a participant in a business interaction. Abstract business processes are partially specified processes that are not intended to be executed. An Abstract Process may hide some of the required concrete operational details. Abstract Processes serve a descriptive role, with more than one possible use case, including observable behavior and process template. WS-BPEL is meant to be used to model the behavior of both Executable and Abstract Processes.

WS-BPEL provides a language for the specification of Executable and Abstract business processes. By doing so, it extends the Web Services interaction model and enables it to support business transactions. WS-BPEL defines an interoperable integration model that should facilitate the expansion of automated process integration in both the intra-corporate and the business-to-business spaces.

Status:

This document was last revised or approved by the Web Services Business Process Execution Language (WSBPEL) TC on the above date. The level of approval is also listed above. Check the current location noted above for possible later revisions of this document. This document is updated periodically on no particular schedule.

Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at http://www.oasis-open.org/committees/wsbpel/.

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page (http://www.oasis-open.org/committees/wsbpel/ipr.php.

The non-normative errata page for this specification is located at http://www.oasis-open.org/committees/wsbpel/.

 

 

 

 

 

 

Notices

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.

Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply.

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.

The names "OASIS", “WSBPEL” and  “WS-BPEL” are trademarks of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance.

 

 

Table of Contents

Web Services Business Process Execution Language Version 2.0. Error! Bookmark not defined.

Public Review Draft 02, 20 November, 2006. Error! Bookmark not defined.

Notices. Error! Bookmark not defined.

Table of Contents. 4

1. Introduction. 6

2. Notational Conventions. 9

3. Relationship with Other Specifications. 11

4. Static Analysis of a Business Process. 13

5. Defining a Business Process. 14

5.1. Initial Example. 14

5.2. The Structure of a Business Process. 21

5.3. Language Extensibility. 31

5.4. Document Linking. 32

5.5. The Lifecycle of an Executable Business Process. 33

5.6. Revisiting the Initial Example. 34

6. Partner Link Types, Partner Links, and Endpoint References. 36

6.1. Partner Link Types. 36

6.2. Partner Links. 37

6.3. Endpoint References. 38

7. Variable Properties. 40

7.1. Motivation. 40

7.2. Defining Properties. 40

7.3 Defining Property Aliases. 41

8. Data Handling. 45

8.1. Variables. 45

8.2 Usage of Query and Expression Languages. 49

8.3. Expressions. 57

8.4. Assignment 59

9. Correlation. 74

9.1. Message Correlation. 74

9.2. Declaring and Using Correlation Sets. 76

10. Basic Activities. 84

10.1. Standard Attributes for All Activities. 84

10.2. Standard Elements for All Activities. 84

10.3. Invoking Web Service Operations – Invoke. 84

10.4. Providing Web Service Operations – Receive and Reply. 89

10.5. Updating Variables and Partner Links – Assign. 94

10.6. Signaling Internal Faults – Throw.. 94

10.7. Delayed Execution – Wait 95

10.8. Doing Nothing – Empty. 95

10.9. Adding new Activity Types – ExtensionActivity. 95

10.10. Immediately Ending a Process – Exit 96

10.11. Propagating Faults – Rethrow.. 96

11. Structured Activities. 98

11.1. Sequential Processing – Sequence. 98

11.2. Conditional Behavior – If 99

11.3. Repetitive Execution – While. 99

11.4. Repetitive Execution – RepeatUntil 100

11.5. Selective Event Processing – Pick. 100

11.6. Parallel and Control Dependencies Processing – Flow.. 102

11.7. Processing Multiple Branches – ForEach. 112

12. Scopes. 115

12.1. Scope Initialization. 116

12.2. Message Exchange Handling. 117

12.3. Error Handling in Business Processes. 117

12.4. Compensation Handlers. 118

12.5. Fault Handlers. 127

12.6 Termination Handlers. 135

12.7. Event Handlers. 137

12.8. Isolated Scopes. 143

13. WS-BPEL Abstract Processes. 147

13.1. The Common Base. 147

13.2. Abstract Process Profiles and the Semantics of Abstract Processes. 154

13.3. Abstract Process Profile for Observable Behavior 155

13.4. Abstract Process Profile for Templates. 159

14. Extension Declarations. 164

15. Examples. 166

15.1. Shipping Service. 166

15.2. Ordering Service. 171

15.3. Loan Approval Service. 179

15.4. Auction Service. 183

16. Security Considerations. 191

Appendix A. Standard Faults. 192

Appendix B. Static Analysis requirement summary (Non-Normative) 194

Appendix C. Attributes and Defaults. 206

Appendix D. Examples of Replacement Logic. 208

Appendix E. XML Schemas. 216

Appendix F. Revision History. 258

Appendix G. References. 276

1. Normative References. 276

2. Non-Normative References. 277

Appendix H. Committee Members (Non-Normative) 278

 

1. Introduction

The goal of the Web Services effort is to achieve interoperability between applications by using Web standards. Web Services use a loosely coupled integration model to allow flexible integration of heterogeneous systems in a variety of domains including business-to-consumer, business-to-business and enterprise application integration. The following basic specifications originally defined the Web Services space: SOAP [SOAP 1.1], Web Services Description Language (WSDL) [WSDL 1.1], and Universal Description, Discovery, and Integration (UDDI) [UDDI]. SOAP defines an XML messaging protocol for basic service interoperability. WSDL introduces a common grammar for describing services. UDDI provides the infrastructure required to publish and discover services in a systematic way. Together, these specifications allow applications to find each other and interact following a loosely coupled, platform independent model.

Systems integration requires more than the ability to conduct simple interactions by using standard protocols. The full potential of Web Services as an integration platform will be achieved only when applications and business processes are able to integrate their complex interactions by using a standard process integration model. The interaction model that is directly supported by WSDL is essentially a stateless model of request-response or uncorrelated one-way interactions.

Models for business interactions typically assume sequences of peer-to-peer message exchanges, both request-response and one-way, within stateful, long-running interactions involving two or more parties. To define such business interactions, a formal description of the message exchange protocols used by business processes in their interactions is needed. An Abstract Process may be used to describe observable message exchange behavior of each of the parties involved, without revealing their internal implementation. There are two good reasons to separate the public aspects of business process behavior from internal or private aspects. One is that businesses obviously do not want to reveal all their internal decision making and data management to their business partners. The other is that, even where this is not the case, separating public from private process provides the freedom to change private aspects of the process implementation without affecting the observable behavior. Observable behavior must clearly be described in a platform independent manner and captures behavioral aspects that may have cross enterprise business significance.

The following concepts for describing business processes should be considered:

·         Business processes include data-dependent behavior. For example, a supply-chain process depends on data such as the number of line items in an order, the total value of an order, or a deliver-by deadline. Defining business intent in these cases requires the use of conditional and time-out constructs.

·         The ability to specify exceptional conditions and their consequences, including recovery sequences, is at least as important for business processes as the ability to define the behavior in the "all goes well" case.

·         Long-running interactions include multiple, often nested units of work, each with its own data requirements. Business processes frequently require cross partner coordination of the outcome (success or failure) of units of work at various levels of granularity.

The basic concepts of WS-BPEL can be applied in one of two ways, Abstract or Executable.

A WS-BPEL Abstract Process is a partially specified process that is not intended to be executed and that must be explicitly declared as ‘abstract’. Whereas Executable Processes are fully specified and thus can be executed, an Abstract Process may hide some of the required concrete operational details expressed by an Executable artifact.

All the constructs of Executables Processes are made available to Abstract Processes; consequently, Executable and Abstract WS-BPEL Processes share the same expressive power. In addition to the features available in Executable Processes, Abstract Processes provide two mechanisms for hiding operational details: (1) the use of explicit opaque tokens and (2) omission. Although a particular Abstract Process definition might contain complete information that would render it Executable, its Abstract status states that any concrete realizations of it are permitted to perform additional processing steps that are not relevant to the audience to which it has been given.

Abstract Processes serve a descriptive role, with more than one use case. One such use case might be to describe the observable behavior of some or all of the services offered by an Executable Process. Another use case would be to define a process template that embodies domain-specific best practices. Such a process template would capture essential process logic in a manner compatible with a design-time representation, while excluding execution details to be completed when mapping to an Executable Process.

Regardless of the specific use case and purpose, all Abstract Processes share a common syntactic base. They have different requirements for the level of opacity and restrictions on which parts of a process definition may be omitted or hidden. Tailored uses of Abstract Processes have different effects on the consistency constraints and on the semantics of that process. Some of these required constraints are not enforceable by the XML Schema.

A common base specifies the features that define the syntactic universe of Abstract Processes. Given this common base, a usage profile provides the necessary specializations and semantics based on Executable WS-BPEL for a particular use of an Abstract Process.

As mentioned above it is possible to use WS-BPEL to define an Executable Business Process. While a WS-BPEL Abstract Process definition is not required to be fully specified, the language effectively defines a portable execution format for business processes that rely exclusively on Web Service resources and XML data. Moreover, such processes execute and interact with their partners in a consistent way regardless of the supporting platform or programming model used by the implementation of the hosting environment.

The continuity of the basic conceptual model between Abstract and Executable Processes in WS-BPEL makes it possible to export and import the public aspects embodied in Abstract Processes as process or role templates while maintaining the intent and structure of the observable behavior. This applies even where private implementation aspects use platform dependent functionality. This is  a key feature for the use of WS-BPEL from the viewpoint of unlocking the potential of Web Services because it allows the development of tools and other technologies that greatly increase the level of automation and thereby lower the cost in establishing cross enterprise automated business processes.

In this specification, the description of Abstract Business Processes is presented after Executable. We clearly differentiate concepts required for Abstract Business Process description from the concepts for Executable in the section 13. WS-BPEL Abstract Processes.

WS-BPEL defines a model and a grammar for describing the behavior of a business process based on interactions between the process and its partners. The interaction with each partner occurs through Web Service interfaces, and the structure of the relationship at the interface level is encapsulated in what is called a partnerLink. The WS-BPEL process defines how multiple service interactions with these partners are coordinated to achieve a business goal, as well as the state and the logic necessary for this coordination. WS-BPEL also introduces systematic mechanisms for dealing with business exceptions and processing faults. Moreover, WS-BPEL introduces a mechanism to define how individual or composite activities within a unit of work are to be compensated in cases where exceptions occur or a partner requests reversal.

WS-BPEL utilizes several XML specifications: WSDL 1.1, XML Schema 1.0, XPath 1.0 and XSLT 1.0. WSDL messages and XML Schema type definitions provide the data model used by WS-BPEL processes. XPath and XSLT provide support for data manipulation. All external resources and partners are represented as WSDL services. WS-BPEL provides extensibility to accommodate future versions of these standards, specifically the XPath and related standards used in XML computation.

A WS-BPEL process is a reusable definition that can be deployed in different ways and in different scenarios, while maintaining a uniform application-level behavior across all of them. The description of the deployment of a WS-BPEL process is out of scope for this specification.

2. Notational Conventions

The upper case keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119].

Namespace URIs of the general form "some-URI" represent some application dependent or context dependent URI as defined in [RFC 2396].

This specification uses an informal syntax to describe the XML grammar of the XML fragments that follow:

·         The syntax appears as an XML instance, but the values indicate the data types instead of values.

·         Grammar in bold has not been introduced earlier in the document, or is of particular interest in an example.

·         <-- description --> is a placeholder for elements from some "other" namespace (like ##other in XSD).

·         Characters are appended to elements, attributes, and as follows: "?" (0 or 1), "*" (0 or more), "+" (1 or more). The characters "[" and "]" are used to indicate that contained items are to be treated as a group with respect to the "?", "*", or "+" characters.

·         Elements and attributes separated by "|" and grouped by "(" and ")" are meant to be syntactic alternatives.

·         The XML namespace prefixes (defined below) are used to indicate the namespace of the element being defined.

·         The name of user defined extension activity is indicated by anyElementQName.

Syntax specifications are highlighted as follows:

<variables>

   <variable name="BPELVariableName"

             messageType="QName"?

             type="QName"?

             element="QName"?>+

      from-spec?

   </variable>

</variables>

Examples starting with <?xml contain enough information to conform to this specification; other examples are fragments and require additional information to be specified in order to conform.

The examples and other explanatory material in this document are not fully specified unless otherwise noted. For instance, some examples import WSDL definitions that are not specified in this document.

Examples are highlighted as follows:

<variable xmlns:ORD="http://example.com/orders"

          name="orderDetails" messageType="ORD:orderDetails" />

XSD Schemas are provided as a definition of grammars [XML Schema Part 1]. Where there is disagreement between the separate XML schema files, the XML schemas in the appendices, any pseudo-schema in the descriptive text, and the normative descriptive text, the normative descriptive text will take precedence over the separate XML Schema files. The separate XML Schema files take precedence over any pseudo-schema and over any XML schema included in the appendices. The WS-BPEL XML Schemas offer supplementary normative XML syntax details, such as details regarding extensibility of a WS-BPEL process definition, as long as those XML syntax details do not violate explicit normative descriptive text.

XML Schemas only enforce a subset of constraints described in the normative descriptive text. Hence, a WS-BPEL artifact, such as a process definition, can be valid according to the XML Schemas only but not valid according to the normative descriptive text.

This specification uses a number of namespace prefixes throughout; their associated URIs are listed below. Note that the choice of any namespace prefix is arbitrary, non-normative and not semantically significant.

·        xsi - "http://www.w3.org/2001/XMLSchema-instance"

·        xsd - "http://www.w3.org/2001/XMLSchema"

·        wsdl - "http://schemas.xmlsoap.org/wsdl/"

·        vprop - "http://docs.oasis-open.org/wsbpel/2.0/varprop"

·        sref - "http://docs.oasis-open.org/wsbpel/2.0/serviceref"

·        plnk – "http://docs.oasis-open.org/wsbpel/2.0/plnktype"

·        bpel – "http://docs.oasis-open.org/wsbpel/2.0/process/executable"

·        abstract – "http://docs.oasis-open.org/wsbpel/2.0/process/abstract"

3. Relationship with Other Specifications

WS-BPEL refers to the following XML-based specifications: WSDL 1.1, XML Schema 1.0, XPath 1.0, XSLT 1.0 and Infoset. All WS-BPEL implementations SHOULD be configurable such that they can participate in Basic Profile 1.1 [WS-I Basic Profile] conforming interactions. A WS-BPEL implementation MAY allow the Basic Profile 1.1 configuration to be disabled, even for scenarios encompassed by the Basic Profile 1.1.

WSDL has the most influence on the WS-BPEL language. The WS-BPEL process model is layered on top of the service model defined by WSDL 1.1. At the core of the WS-BPEL process model is the notion of peer-to-peer interaction between services described in WSDL; both the process and its partners are exposed as WSDL services. A business process defines how to coordinate the interactions between a process instance and its partners. In this sense, a WS-BPEL process definition provides and/or uses one or more WSDL services, and provides the description of the behavior and interactions of a process instance relative to its partners and resources through Web Service interfaces. That is, WS-BPEL is used to describe the message exchanges followed by the business process of a specific role in the interaction.

The definition of a WS-BPEL business process follows the WSDL model of separation between the abstract message contents used by the business process and deployment information (messages and port type versus binding and address information). In particular, a WS-BPEL process represents all partners and interactions with these partners in terms of abstract WSDL interfaces (port types and operations); no references are made to the actual services used by a process instance. WS-BPEL does not make any assumptions about the WSDL binding. Constraints, ambiguities, provided or missing capabilities of WSDL bindings are out of scope of this specification.

However, the abstract part of WSDL does not define the constraints imposed on the communication patterns supported by the concrete bindings. Therefore a WS-BPEL process may define behavior relative to a partner service that is not supported by all possible bindings, and it may happen that some bindings are invalid for a WS-BPEL process definition.

While WS-BPEL attempts to provide as much compatibility with WSDL 1.1 as possible there are three areas where such compatibility is not feasible.

·        Fault naming with its restriction, as discussed later in this document (see section 10.3. Invoking Web Service Operations – Invoke)

·        [SA00002] Overloaded operation names in WSDL port types. Regardless of whether the WS-I Basic Profile configuration is enabled, a WS-BPEL processor MUST reject any WSDL port type definition that includes overloaded operation names. This restriction was deemed appropriate as overloaded operations are rare, they are actually banned in the WS-I Basic Profile and supporting them was felt to introduce more complexity than benefit.

·        [SA00001] Port types that contain solicit-response or notification operations as defined in the WSDL 1.1 specification. Regardless of whether the WS-I Basic Profile configuration is enabled, a WS-BPEL processor MUST reject a WS-BPEL that refers to such port types. 

At the time this specification was completed, various Web Service standards work, such as WSDL 2.0 and WS-Addressing, were ongoing and not ready for consideration for WS-BPEL 2.0. Future versions of WS-BPEL may provide support for these standards.

It should be noted that the examples provided in this specification adopt the Schema at location "http://schemas.xmlsoap.org/wsdl/2004-08-24.xsd" for the namespace URI http://schemas.xmlsoap.org/wsdl/ [WSDL 1.1].  This XML Schema incorporates fixes for known errors, and is the XML Schema selected by the [WS-I Basic Profile 1.1 Errata] (October 25, 2005).

4. Static Analysis of a Business Process

WS-BPEL takes it as a general principle that conformant implementations MUST perform basic static analysis listed in Appendix B to detect and reject process definitions that fail any of those static analysis checks. Please note that such analysis might in some cases prevent the use of processes that would not, in fact, create situations with errors, either in specific uses or in any use. For example, a WS-BPEL implementation will reject a process with <invoke> activity referring to an undefined variable, where the <invoke> activity may not be actually reached during execution of the process.

A WS-BPEL implementation MAY perform extra static analysis checking beyond the basic static analysis required by this specification to signal warnings or even reject process definitions. Such an implementation SHOULD be configurable to disable these non-specified static analysis checks.

5. Defining a Business Process

5.1. Initial Example

Before describing the structure of business processes in detail, this section presents a simple example of a WS-BPEL process for handling a purchase order. The aim is to introduce the most basic structures and some of the fundamental concepts of the language.

The operation of the process is very simple, and is represented in Figure 1: Purchase Order Process Outline. Dotted lines represent sequencing. Free grouping of sequences represents concurrent sequences. Solid arrows represent control links used for synchronization across concurrent activities. Note that this is not meant to be a definitive graphical notation for WS-BPEL processes. It is used here informally as an aid to understanding.

On receiving the purchase order from a customer, the process initiates three paths concurrently: calculating the final price for the order, selecting a shipper, and scheduling the production and shipment for the order. While some of the processing can proceed concurrently, there are control and data dependencies between the three paths. In particular, the shipping price is required to finalize the price calculation, and the shipping date is required for the complete fulfillment schedule. When the three concurrent paths are completed, invoice processing can proceed and the invoice is sent to the customer.

 

 

Figure 1: Purchase Order Process - Outline

The WSDL port type offered by the service to its customers (purchaseOrderPT) is shown in the following WSDL document. Other WSDL definitions required by the business process are included in the same WSDL document for simplicity; in particular, the port types for the Web Services providing price calculation, shipping selection and scheduling, and production scheduling functions are also defined there. Observe that there are no bindings or service elements in the WSDL document. A WS-BPEL process is defined by referencing only the port types of the services involved in the process, and not their possible deployments. Defining business processes in this way allows the reuse of business process definitions over multiple deployments of compatible services.

The <partnerLinkType>s included at the bottom of the WSDL document represent the interaction between the purchase order service and each of the parties with which it interacts (see section 6. Partner Link Types, Partner Links, and Endpoint References). <PartnerLinkType>s can be used to represent dependencies between services, regardless of whether a WS-BPEL business process is defined for one or more of those services. Each <partnerLinkType> defines up to two "role" names, and lists the port types that each role must support for the interaction to be carried out successfully. In this example, two <partnerLinkType>s, "purchasingLT" and "schedulingLT", list a single role because, in the corresponding service interactions, one of the parties provides all the invoked operations: The "purchasingLT" <partnerLinkType>represents the connection between the process and the requesting customer, where only the purchase order service needs to offers a service operation ("sendPurchaseOrder"); the "schedulingLT" <partnerLinkType>represents the interaction between the purchase order service and the scheduling service, in which only operations of the latter are invoked. The two other <partnerLinkType>s, "invoicingLT" and "shippingLT", define two roles because both the user of the invoice calculation and the user of the shipping service (the invoice or the shipping schedule) must provide callback operations to enable notifications to be sent ("invoiceCallbackPT" and "shippingCallbackPT" port types).

 

 

<wsdl:definitions

   targetNamespace="http://manufacturing.org/wsdl/purchase"

   xmlns:sns="http://manufacturing.org/xsd/purchase"

   xmlns:pos="http://manufacturing.org/wsdl/purchase"

   xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"

   xmlns:plnk="http://docs.oasis-open.org/wsbpel/2.0/plnktype"

   xmlns:xsd="http://www.w3.org/2001/XMLSchema">

 

   <wsdl:types>

      <xsd:schema>

         <xsd:import namespace="http://manufacturing.org/xsd/purchase"

          schemaLocation="http://manufacturing.org/xsd/purchase.xsd" />

      </xsd:schema>

   </wsdl:types>

 

   <wsdl:message name="POMessage">

      <wsdl:part name="customerInfo" type="sns:customerInfoType" />

      <wsdl:part name="purchaseOrder" type="sns:purchaseOrderType" />

   </wsdl:message>

   <wsdl:message name="InvMessage">

      <wsdl:part name="IVC" type="sns:InvoiceType" />

   </wsdl:message>

   <wsdl:message name="orderFaultType">

      <wsdl:part name="problemInfo" element=”sns:OrderFault " />

   </wsdl:message>

   <wsdl:message name="shippingRequestMessage">

      <wsdl:part name="customerInfo" element="sns:customerInfo" />

   </wsdl:message>

   <wsdl:message name="shippingInfoMessage">

      <wsdl:part name="shippingInfo" element="sns:shippingInfo" />

   </wsdl:message>

   <wsdl:message name="scheduleMessage">

      <wsdl:part name="schedule" element="sns:scheduleInfo" />

   </wsdl:message>

 

   <!-- portTypes supported by the purchase order process -->

   <wsdl:portType name="purchaseOrderPT">

      <wsdl:operation name="sendPurchaseOrder">

         <wsdl:input message="pos:POMessage" />

         <wsdl:output message="pos:InvMessage" />

         <wsdl:fault name="cannotCompleteOrder"

            message="pos:orderFaultType" />

      </wsdl:operation>

   </wsdl:portType>

   <wsdl:portType name="invoiceCallbackPT">

      <wsdl:operation name="sendInvoice">

         <wsdl:input message="pos:InvMessage" />

      </wsdl:operation>

   </wsdl:portType>

   <wsdl:portType name="shippingCallbackPT">

      <wsdl:operation name="sendSchedule">

         <wsdl:input message="pos:scheduleMessage" />

      </wsdl:operation>

   </wsdl:portType>

 

   <!-- portType supported by the invoice services -->

   <wsdl:portType name="computePricePT">

      <wsdl:operation name="initiatePriceCalculation">

         <wsdl:input message="pos:POMessage" />

      </wsdl:operation>

      <wsdl:operation name="sendShippingPrice">

         <wsdl:input message="pos:shippingInfoMessage" />

      </wsdl:operation>

   </wsdl:portType>

 

   <!-- portType supported by the shipping service -->

   <wsdl:portType name="shippingPT">

      <wsdl:operation name="requestShipping">

         <wsdl:input message="pos:shippingRequestMessage" />

         <wsdl:output message="pos:shippingInfoMessage" />

         <wsdl:fault name="cannotCompleteOrder"

            message="pos:orderFaultType" />

      </wsdl:operation>

   </wsdl:portType>

 

   <!-- portType supported by the production scheduling process -->

   <wsdl:portType name="schedulingPT">

      <wsdl:operation name="requestProductionScheduling">

         <wsdl:input message="pos:POMessage" />

      </wsdl:operation>

      <wsdl:operation name="sendShippingSchedule">

         <wsdl:input message="pos:scheduleMessage" />

      </wsdl:operation>

   </wsdl:portType>

 

   <plnk:partnerLinkType name="purchasingLT">

      <plnk:role name="purchaseService"

         portType="pos:purchaseOrderPT" />

   </plnk:partnerLinkType>

 

   <plnk:partnerLinkType name="invoicingLT">

      <plnk:role name="invoiceService"

         portType="pos:computePricePT" />

      <plnk:role name="invoiceRequester"

         portType="pos:invoiceCallbackPT" />

   </plnk:partnerLinkType>

 

   <plnk:partnerLinkType name="shippingLT">

      <plnk:role name="shippingService"

         portType="pos:shippingPT" />

      <plnk:role name="shippingRequester"

         portType="pos:shippingCallbackPT" />

   </plnk:partnerLinkType>

 

   <plnk:partnerLinkType name="schedulingLT">

      <plnk:role name="schedulingService"

         portType="pos:schedulingPT" />

   </plnk:partnerLinkType>

 

</wsdl:definitions>

The business process for the order service is defined next. There are four major sections in this process definition. Note that the example provides a simple case. In order to complete it, additional elements may be needed such as <correlationSets>.

·         The <partnerLinks> section defines the different parties that interact with the business process in the course of processing the order. The four <partnerLink> definitions shown here correspond to the sender of the order (customer), as well as the providers of price (invoicing provider), shipment (shipping provider), and manufacturing scheduling services (scheduling provider). Each <partnerLink> is characterized by a partnerLinkType and either one or two role names. This information identifies the functionality that must be provided by the business process and by the partner service for the relationship to succeed, that is, the port types that the purchase order process and the partner need to implement.

·         The <variables> section defines the data variables used by the process, providing their definitions in terms of WSDL message types, XML Schema types (simple or complex), or XML Schema elements. Variables allow processes to maintain state between message exchanges.

·         The <faultHandlers>section contains fault handlersdefining the activities that must be performed in response to faults resulting from the invocation of the assessment and approval services. In WS-BPEL, all faults, whether internal or resulting from a service invocation, are identified by a qualified name. In particular, each WSDL fault is identified in WS-BPEL by a qualified name formed by the target namespace of the WSDL document in which the relevant port type and fault are defined, and the NCName of the fault.

·         The rest of the <process> definition contains the description of the normal behavior for handling a purchase request. The major elements of this description are explained in the section following the process definition.

<process name="purchaseOrderProcess"

   targetNamespace="http://example.com/ws-bp/purchase"

   xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable"

   xmlns:lns="http://manufacturing.org/wsdl/purchase">

 

   <documentation xml:lang="EN">

      A simple example of a WS-BPEL process for handling a purchase

      order.

   </documentation>

 

   <partnerLinks>

      <partnerLink name="purchasing"

         partnerLinkType="lns:purchasingLT" myRole="purchaseService" />

      <partnerLink name="invoicing" partnerLinkType="lns:invoicingLT"

         myRole="invoiceRequester" partnerRole="invoiceService" />

      <partnerLink name="shipping" partnerLinkType="lns:shippingLT"

         myRole="shippingRequester" partnerRole="shippingService" />

      <partnerLink name="scheduling"

         partnerLinkType="lns:schedulingLT"

         partnerRole="schedulingService" />

   </partnerLinks>

 

   <variables>

      <variable name="PO" messageType="lns:POMessage" />

      <variable name="Invoice" messageType="lns:InvMessage" />

      <variable name="shippingRequest"

         messageType="lns:shippingRequestMessage" />

      <variable name="shippingInfo"

         messageType="lns:shippingInfoMessage" />

      <variable name="shippingSchedule"

         messageType="lns:scheduleMessage" />

   </variables>

 

   <faultHandlers>

      <catch faultName="lns:cannotCompleteOrder"

         faultVariable="POFault"

         faultMessageType="lns:orderFaultType">

         <reply partnerLink="purchasing"

            portType="lns:purchaseOrderPT"

            operation="sendPurchaseOrder" variable="POFault"

            faultName="cannotCompleteOrder" />

      </catch>

   </faultHandlers>

 

   <sequence>

      <receive partnerLink="purchasing" portType="lns:purchaseOrderPT"

         operation="sendPurchaseOrder" variable="PO"

         createInstance="yes">

         <documentation>Receive Purchase Order</documentation>

      </receive>

 

      <flow>

         <documentation>

            A parallel flow to handle shipping, invoicing and

            scheduling

         </documentation>

         <links>

            <link name="ship-to-invoice" />

            <link name="ship-to-scheduling" />

         </links>

         <sequence>

            <assign>

               <copy>

                  <from>$PO.customerInfo</from>

                  <to>$shippingRequest.customerInfo</to>

               </copy>

            </assign>

            <invoke partnerLink="shipping" portType="lns:shippingPT"

               operation="requestShipping"

               inputVariable="shippingRequest"

               outputVariable="shippingInfo">

               <documentation>Decide On Shipper</documentation>

               <sources>

                  <source linkName="ship-to-invoice" />

               </sources>

            </invoke>

            <receive partnerLink="shipping"

               portType="lns:shippingCallbackPT"

               operation="sendSchedule" variable="shippingSchedule">

               <documentation>Arrange Logistics</documentation>

               <sources>

                  <source linkName="ship-to-scheduling" />

               </sources>

            </receive>

         </sequence>

         <sequence>

            <invoke partnerLink="invoicing"

               portType="lns:computePricePT"

               operation="initiatePriceCalculation"

               inputVariable="PO">

               <documentation>

                  Initial Price Calculation

               </documentation>

            </invoke>

            <invoke partnerLink="invoicing"

               portType="lns:computePricePT"

               operation="sendShippingPrice"

               inputVariable="shippingInfo">

               <documentation>

                  Complete Price Calculation

               </documentation>

               <targets>

                  <target linkName="ship-to-invoice" />

               </targets>

            </invoke>

            <receive partnerLink="invoicing"

               portType="lns:invoiceCallbackPT"

               operation="sendInvoice" variable="Invoice" />

         </sequence>

         <sequence>

            <invoke partnerLink="scheduling"

               portType="lns:schedulingPT"

               operation="requestProductionScheduling"

               inputVariable="PO">

               <documentation>

                  Initiate Production Scheduling

               </documentation>

            </invoke>

            <invoke partnerLink="scheduling"

               portType="lns:schedulingPT"

               operation="sendShippingSchedule"

               inputVariable="shippingSchedule">

               <documentation>

                  Complete Production Scheduling

               </documentation>

               <targets>

                  <target linkName="ship-to-scheduling" />

               </targets>

            </invoke>

         </sequence>

      </flow>

      <reply partnerLink="purchasing" portType="lns:purchaseOrderPT"

         operation="sendPurchaseOrder" variable="Invoice">

         <documentation>Invoice Processing</documentation>

      </reply>

   </sequence>

 

</process>

5.2. The Structure of a Business Process

This section provides a quick summary of the WS-BPEL syntax. It provides only a brief overview; the details of each language construct are described in the rest of this document.

The basic structure of the language is:

<process name="NCName" targetNamespace="anyURI"

   queryLanguage="anyURI"?

   expressionLanguage="anyURI"?

   suppressJoinFailure="yes|no"?

   exitOnStandardFault="yes|no"?

   xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable">

 

   <extensions>?

      <extension namespace="anyURI" mustUnderstand="yes|no" />+

   </extensions>

 

   <import namespace="anyURI"?

      location="anyURI"?

      importType="anyURI" />*

 

   <partnerLinks>?

      <!-- Note: At least one role must be specified. -->

      <partnerLink name="NCName"

         partnerLinkType="QName"

         myRole="NCName"?

         partnerRole="NCName"?

         initializePartnerRole="yes|no"?>+

      </partnerLink>

   </partnerLinks>

 

   <messageExchanges>?

      <messageExchange name="NCName" />+

   </messageExchanges>

 

   <variables>?

      <variable name="BPELVariableName"

         messageType="QName"?

         type="QName"?

         element="QName"?>+

         from-spec?

      </variable>

   </variables>

 

   <correlationSets>?

      <correlationSet name="NCName" properties="QName-list" />+

   </correlationSets>

 

   <faultHandlers>?

      <!-- Note: There must be at least one faultHandler -->

      <catch faultName="QName"?

         faultVariable="BPELVariableName"?

         ( faultMessageType="QName" | faultElement="QName" )? >*

         activity

      </catch>

      <catchAll>?

         activity

      </catchAll>

   </faultHandlers>

 

   <eventHandlers>?

      <!-- Note: There must be at least one onEvent or onAlarm. -->

      <onEvent partnerLink="NCName"

         portType="QName"?

         operation="NCName"

         ( messageType="QName" | element="QName" )?

         variable="BPELVariableName"?

         messageExchange="NCName"?>*

         <correlations>?

            <correlation set="NCName" initiate="yes|join|no"? />+

         </correlations>

         <fromParts>?

            <fromPart part="NCName" toVariable="BPELVariableName" />+

         </fromParts>

         <scope ...>...</scope>

      </onEvent>

      <onAlarm>*

         <!-- Note: There must be at least one expression. -->

         (

         <for expressionLanguage="anyURI"?>duration-expr</for>

         |

         <until expressionLanguage="anyURI"?>deadline-expr</until>

         )?

         <repeatEvery expressionLanguage="anyURI"?>

            duration-expr

         </repeatEvery>?

         <scope ...>...</scope>

      </onAlarm>

   </eventHandlers>

   activity

</process>

The top-level attributes are as follows:

·         queryLanguage. This attribute specifies the query language used in the process for selection of nodes in assignment. The default value for this attribute is: "urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0", which represents the usage of [XPath 1.0] within WS-BPEL 2.0.

·         expressionLanguage. This attribute specifies the expression language used in the <process>. The default value for this attribute is: "urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0", which represents the usage of [XPath 1.0] within WS-BPEL 2.0.

·         suppressJoinFailure. This attribute determines whether the joinFailure fault will be suppressed for all activities in the process. The effect of the attribute at the process level can be overridden by an activity using a different value for the attribute. The default for this attribute is "no" at the process level.  When this attribute is not specified for an activity, it inherits its value from its closest enclosing activity or from the <process> if no enclosing activity specifies this attribute.

·         exitOnStandardFault. If the value of this attribute is set to “yes”, then the process MUST exit immediately as if an <exit> activity has been reached, when a WS-BPEL standard fault other than bpel:joinFailure is encountered[1]. If the value of this attribute is set to “no”, then the process can handle a standard fault using a fault handler. The default value for this attribute is “no”. When this attribute is not specified on a <scope> it inherits its value from its enclosing <scope> or <process>.

[SA00003] If the value of exitOnStandardFault of a <scope> or <process> is set to “yes”, then a fault handler that explicitly targets the WS-BPEL standard faults MUST NOT be used in that scope. A process definition that violates this condition MUST be detected by static analysis and MUST be rejected by a conformant implementation. 

·         The syntax of Abstract Process has its own distinct target namespace. Additional top-level attributes are defined for Abstract Processes.

The value of the queryLanguage and expressionLanguage attributes on the <process> element are global defaults and can be overridden on specific constructs, such as <condition> of a <while> activity, as defined later in this specification. In addition, the queryLanguage attribute is also available for use in defining WS-BPEL <vprop:propertyAlias>es in WSDL. WS-BPEL processors MUST:

·         statically determine which languages are referenced by queryLanguage or expressionLanguage attributes either in the WS-BPEL process definition itself or in any WS-BPEL property definitions in associated WSDLs and

·         [SA00004] if any referenced language is unsupported by the WS-BPEL processor then the processor MUST reject the submitted WS-BPEL process definition.

Note that: <documentation> construct may be added to virtually all WS-BPEL constructs as the formal way to annotate processes definition with human documentation. Examples of <documentation> construct can be found in the previous sections. Detailed description of <documention> is provided in the next section 5.3. Language Extensibility.

Each business process has one main activity.

A WS-BPEL activity can be any of the following:

·         <receive>

·         <reply>

·         <invoke>

·         <assign>

·         <throw>

·         <exit>

·         <wait>

·         <empty>

·         <sequence>

·         <if>

·         <while>

·         <repeatUntil>

·         <forEach>

·         <pick>

·         <flow>

·         <scope>

·         <compensate>

·         <compensateScope>

·         <rethrow>

·         <validate>

·         <extensionActivity>

The syntax of each of these elements is described in the following paragraphs.

The <receive> activity allows the business process to wait for a matching message to arrive. The <receive> activity completes when the message arrives. The portType attribute on the <receive> activity is optional. [SA00005] If the portType attribute is included for readability, the value of the portType attribute MUST match the portType value implied by the combination of the specified partnerLink and the role implicitly specified by the activity (see also partnerLink description in the next section). The optional messageExchange attribute is used to associate a <reply> activity with a <receive> activity.

<receive partnerLink="NCName"

   portType="QName"?

   operation="NCName"

   variable="BPELVariableName"?

   createInstance="yes|no"?

   messageExchange="NCName"?

   standard-attributes>

   standard-elements

   <correlations>?

      <correlation set="NCName" initiate="yes|join|no"? />+

   </correlations>

   <fromParts>?

      <fromPart part="NCName" toVariable="BPELVariableName" />+

   </fromParts>

</receive>

The <reply> activity allows the business process to send a message in reply to a message that was received by an inbound message activity (IMA), that is, <receive>, <onMessage>, or <onEvent>. The combination of an IMA and a <reply> forms a request-response operation on a WSDL portType for the process. The portType attribute on the <reply> activity is optional. If the portType attribute is included for readability, the value of the portType attribute MUST match the portType value implied by the combination of the specified partnerLink and the role implicitly specified by the activity (see also partnerLink description in the next section). The optional messageExchange attribute is used to associate a <reply> activity with an IMA.

<reply partnerLink="NCName"

   portType="QName"?

   operation="NCName"

   variable="BPELVariableName"?

   faultName="QName"?

   messageExchange="NCName"?

   standard-attributes>

   standard-elements

   <correlations>?

      <correlation set="NCName" initiate="yes|join|no"? />+

   </correlations>

   <toParts>?

      <toPart part="NCName" fromVariable="BPELVariableName" />+

   </toParts>

</reply>

The <invoke> activity allows the business process to invoke a one-way or request-response operation on a portType offered by a partner. In the request-response case, the invoke activity completes when the response is received. The portType attribute on the <invoke> activity is optional. If the portType attribute is included for readability, the value of the portType attribute MUST match the portType value implied by the combination of the specified partnerLink and the role implicitly specified by the activity (see also partnerLink description in the next section).

<invoke partnerLink="NCName"

   portType="QName"?

   operation="NCName"

   inputVariable="BPELVariableName"?

   outputVariable="BPELVariableName"?

   standard-attributes>

   standard-elements

   <correlations>?

      <correlation set="NCName" initiate="yes|join|no"?

         pattern="request|response|request-response"? />+

   </correlations>

   <catch faultName="QName"?

      faultVariable="BPELVariableName"?

      faultMessageType="QName"?

      faultElement="QName"?>*

      activity

   </catch>

   <catchAll>?

      activity

   </catchAll>

   <compensationHandler>?

      activity

   </compensationHandler>

   <toParts>?

      <toPart part="NCName" fromVariable="BPELVariableName" />+

   </toParts>

   <fromParts>?

      <fromPart part="NCName" toVariable="BPELVariableName" />+

   </fromParts>

</invoke>

The <assign> activity is used to update the values of variables with new data. An <assign> construct can contain any number of elementary assignments, including <copy> assign elements or data update operations defined as extension under other namespaces.

<assign validate="yes|no"? standard-attributes>

   standard-elements

   (

   <copy keepSrcElementName="yes|no"? ignoreMissingFromData="yes|no"?>

      from-spec

      to-spec

   </copy>

   |

   <extensionAssignOperation>

      assign-element-of-other-namespace

   </extensionAssignOperation>

   )+

</assign>

The <validate> activity is used to validate the values of variables against their associated XML and WSDL data definition. The construct has a variables attribute, which points to the variables being validated.

<validate variables="BPELVariableNames" standard-attributes>

   standard-elements

</validate>

The <throw> activity is used to generate a fault from inside the business process.

<throw faultName="QName"

   faultVariable="BPELVariableName"?

   standard-attributes>

   standard-elements

</throw>

The <wait> activity is used to wait for a given time period or until a certain point in time has been reached. Exactly one of the expiration criteria MUST be specified.

<wait standard-attributes>

   standard-elements

   (

   <for expressionLanguage="anyURI"?>duration-expr</for>

   |

   <until expressionLanguage="anyURI"?>deadline-expr</until>

   )

</wait>

The <empty> activity is a "no-op" in a business process. This is useful for synchronization of concurrent activities, for instance.

<empty standard-attributes>

   standard-elements

</empty>

The <sequence> activity is used to define a collection of activities to be performed sequentially in lexical order.

<sequence standard-attributes>

   standard-elements

   activity+

</sequence>

The <if> activity is used to select exactly one activity for execution from a set of choices.

<if standard-attributes>

   standard-elements

   <condition expressionLanguage="anyURI"?>bool-expr</condition>

   activity

   <elseif>*

      <condition expressionLanguage="anyURI"?>bool-expr</condition>

      activity

   </elseif>

   <else>?

      activity

   </else>

</if>

The <while> activity is used to define that the child activity is to be repeated as long as the  specified <condition> is true.

<while standard-attributes>

   standard-elements

   <condition expressionLanguage="anyURI"?>bool-expr</condition>

   activity

</while>

The <repeatUntil> activity is used to define that the child activity is to be repeated until the specified <condition> becomes true. The <condition> is tested after the child activity completes. The <repeatUntil> activity is used to execute the child activity at least once.

<repeatUntil standard-attributes>

   standard-elements

   activity

   <condition expressionLanguage="anyURI"?>bool-expr</condition>

</repeatUntil>

The <forEach> activity iterates its child scope activity exactly N+1 times where N equals the <finalCounterValue> minus the <startCounterValue>. If parallel="yes" then this is a parallel <forEach> where the N+1 instances of the enclosed <scope> activity SHOULD occur in parallel. In essence an implicit flow is dynamically created with N+1 copies of the <forEach>'s <scope> activity as children. A <completionCondition> may be used within the <forEach> to allow the <forEach> activity to complete without executing or finishing all the branches specified.

<forEach counterName="BPELVariableName" parallel="yes|no"

   standard-attributes>

   standard-elements

   <startCounterValue expressionLanguage="anyURI"?>

      unsigned-integer-expression

   </startCounterValue>

   <finalCounterValue expressionLanguage="anyURI"?>

      unsigned-integer-expression

   </finalCounterValue>

   <completionCondition>?

      <branches expressionLanguage="anyURI"?

         successfulBranchesOnly="yes|no"?>?

         unsigned-integer-expression

      </branches>

   </completionCondition>

   <scope ...>...</scope>

</forEach>

The <pick> activity is used to wait for one of several possible messages to arrive or for a time-out to occur. When one of these triggers occurs, the associated child activity is performed. When the child activity completes then the <pick> activity completes.

The portType attribute on the <onMessage> activity is optional. If the portType attribute is included for readability, the value of the portType attribute MUST match the portType value implied by the combination of the specified partnerLink and the role implicitly specified by the activity. The optional messageExchange attribute is used to associate a <reply> activity with a <onMessage> event.

<pick createInstance="yes|no"? standard-attributes>

   standard-elements

   <onMessage partnerLink="NCName"

      portType="QName"?

      operation="NCName"

      variable="BPELVariableName"?

      messageExchange="NCName"?>+

      <correlations>?

         <correlation set="NCName" initiate="yes|join|no"? />+

      </correlations>

      <fromParts>?

         <fromPart part="NCName" toVariable="BPELVariableName" />+

      </fromParts>

      activity

   </onMessage>

   <onAlarm>*

      (

      <for expressionLanguage="anyURI"?>duration-expr</for>

      |

      <until expressionLanguage="anyURI"?>deadline-expr</until>

      )

      activity

   </onAlarm>

</pick>

The <flow> activity is used to specify one or more activities to be performed concurrently. <links> can be used within a <flow> to define explicit control dependencies between nested child activities.

<flow standard-attributes>

   standard-elements

   <links>?

      <link name="NCName" />+

   </links>

   activity+

</flow>

The <scope> activity is used to define a nested activity with its own associated <partnerLinks>, <messageExchanges>, <variables>, <correlationSets>, <faultHandlers>, <compensationHandler>, <terminationHandler>, and <eventHandlers>.

<scope isolated="yes|no"? exitOnStandardFault="yes|no"?

   standard-attributes>

   standard-elements

   <partnerLinks>?

      ... see above under <process> for syntax ...

   </partnerLinks>

   <messageExchanges>?

      ... see above under <process> for syntax ...

   </messageExchanges>

   <variables>?

      ... see above under <process> for syntax ...

   </variables>

   <correlationSets>?

      ... see above under <process> for syntax ...

   </correlationSets>

   <faultHandlers>?

      ... see above under <process> for syntax ...

   </faultHandlers>

   <compensationHandler>?

      ...

   </compensationHandler>

   <terminationHandler>?

      ...

   </terminationHandler>

   <eventHandlers>?

      ... see above under <process> for syntax ...

   </eventHandlers>

   activity

</scope>

The <compensateScope> activity is used to start compensation on a specified inner scope that has already completed successfully. [SA00007] This activity MUST only be used from within a fault handler, another compensation handler, or a termination handler.

<compensateScope target="NCName" standard-attributes>

   standard-elements

</compensateScope>

The <compensate> activity is used to start compensation on all inner scopes that have already completed successfully, in default order. [SA00008] This activity MUST only be used from within a fault handler, another compensation handler, or a termination handler.

<compensate standard-attributes>

   standard-elements

</compensate>

The <exit> activity is used to immediately end a business process instance within which the <exit> activity is contained.

<exit standard-attributes>

   standard-elements

</exit>

The <rethrow> activity is used to rethrow the fault that was originally caught by the immediately enclosing fault handler. [SA00006] The <rethrow> activity MUST only be used within a fault handler (i.e. <catch> and <catchAll> elements). This syntactic constraint MUST be statically enforced.

<rethrow standard-attributes>

   standard-elements

</rethrow>

The <extensionActivity> element is used to extend WS-BPEL by introducing a new activity type. The contents of an <extensionActivity> element MUST be a single element that MUST make available WS-BPEL's standard-attributes and standard-elements.

<extensionActivity>

   <anyElementQName standard-attributes>

      standard-elements

   </anyElementQName>

</extensionActivity>

The "standard-attributes" referenced above are:

name="NCName"? suppressJoinFailure="yes|no"?

where the default values are as follows:

·         name: No default value (that is, the default is unnamed)

·        suppressJoinFailure: When this attribute is not specified for an activity, it inherits its value from its closest enclosing activity or from the process if no enclosing activity specifies this attribute.

The "standard-elements" referenced above are:

<targets>?

   <joinCondition expressionLanguage="anyURI"?>?

      bool-expr

   </joinCondition>

   <target linkName="NCName" />+

</targets>

<sources>?

   <source linkName="NCName">+

      <transitionCondition expressionLanguage="anyURI"?>?

         bool-expr

      </transitionCondition>

   </source>

</sources>

5.3. Language Extensibility

WS-BPEL supports extensibility by allowing namespace-qualified attributes to appear on any WS-BPEL element and by allowing elements from other namespaces to appear within WS-BPEL defined elements. This is allowed in the XML Schema specifications for WS-BPEL.

Extensions are either mandatory or optional (see section 14. Extension Declarations). [SA00009] In the case of mandatory extensions not supported by a WS-BPEL implementation, the process definition MUST be rejected. Optional extensions not supported by a WS-BPEL implementation MUST be ignored.

In addition, WS-BPEL provides two explicit extension constructs: <extensionAssignOperation> and <extensionActivity>. Specific rules for these constructs are described in sections 8.4. Assignment and 10.9. Adding new Activity Types – ExtensionActivity.

Extensions MUST NOT contradict the semantics of any element or attribute defined by the WS-BPEL specification.

Extensions are allowed in WS-BPEL constructs used in WSDL definitions, such as <partnerLinkType>, <role>, <vprop:property> and <vprop:propertyAlias>. The same syntax pattern and semantic rules for extensions of WS-BPEL constructs are applied to these extensions as well. For the WSDL definitions transitively referenced by a WS-BPEL process, extension declaration directives of this WS-BPEL process are applied to all extensions used in WS-BPEL constructs in these WSDL definitions (see section 14. Extension Declarations).

The optional <documentation> construct is applicable to any WS-BPEL extensible construct. Typically, the contents of <documentation> are for human targeted annotation. Example types for those content are: plain text, HTML and XHTML. Tool-implementation specific information (e.g. the graphical layout details) should be added through elements and attributes of other namespaces, using the general WS-BPEL extensibility mechanisms.

5.4. Document Linking

A WS-BPEL process definition relies on XML Schema and WSDL 1.1 for the definition of  datatypes and service interfaces. Process definitions also rely on other constructs such as partner link types, variable properties and property aliases (defined later in this specification) which are defined within WSDL 1.1 documents using the WSDL 1.1 language extensibility feature.

<import namespace="anyURI"?

   location="anyURI"?

   importType="anyURI" />*

The <import> element is used within a WS-BPEL process to declare a dependency on external XML Schema or WSDL definitions. Any number of <import> elements may appear as children of the <process> element. Each <import> element contains one mandatory and two optional attributes.

·        namespace. The namespace attribute specifies an absolute URI that identifies the imported definitions. This attribute is optional. An import element without a namespace attribute indicates that external definitions are in use which are not namespace qualified. [SA00011] If a namespace is specified then the imported definitions MUST be in that namespace. [SA00012] If no namespace is specified then the imported definitions MUST NOT contain a targetNamespace specification. If either of these rules are not met then the process definition MUST be rejected by a conforming WS-BPEL implementation. The namespace http://www.w3.org/2001/XMLSchema is imported implicitly. Note, however, that there is no implicit XML Namespace prefix defined for http://www.w3.org/2001/XMLSchema.

·        location. The location attribute contains a URI indicating the location of a document that contains relevant definitions. The location URI may be a relative URI, following the usual rules for resolution of the URI base (XML Base and RFC 2396). The location attribute is optional. An <import> element without a location attribute indicates that external definitions are used by the process but makes no statement about where those definitions may be found. The location attribute is a hint and a WS-BPEL processor is not required to retrieve the document being imported from the specified location.

·        importType. The mandatory importType attribute identifies the type of document being imported by providing an absolute URI that identifies the encoding language used in the document. [SA00013] The value of the importType attribute MUST be set to "http://www.w3.org/2001/XMLSchema" when importing XML Schema 1.0 documents, and to "http://schemas.xmlsoap.org/wsdl/" when importing WSDL 1.1 documents. Other importType URI values MAY be used here.

Observe that according to these rules, it is permissible to have an <import> element without namespace and location attributes, and only containing an importType attribute. Such an <import> element indicates that external definitions of the indicated type are in use which are not namespace qualified, and makes no statement about where those definitions may be found.

[SA00010] A WS-BPEL process definition MUST import all XML Schema and WSDL definitions it uses. This includes all XML Schema type and element definitions, all WSDL port types and message types as well as <vprop:property> and <vprop:propertyAlias> definitions used by the process. [SA00053], [SA00054] A WS-BPEL processor MUST verify that all message parts referenced by a <vprop:propertyAlias>, <from>, <to>, <fromPart>, and <toPart> are found in their respective WSDL message definitions. In order to support the use of definitions from namespaces spanning multiple documents, a WS-BPEL process MAY include more than one import declaration for the same namespace and importType, provided that those declarations include different location values. <import> elements are conceptually unordered. [SA00014] A WS-BPEL process definition MUST be rejected if the imported documents contain conflicting definitions of a component used by the importing process definition (as could be caused, for example, when the XSD redefinition mechanism is used).

Schema definitions defined in the types section of a WSDL document which is imported by a WS-BPEL process definition are considered to be effectively imported themselves and are available to the process for the purpose of defining XML Schema variables. However, documents (or namespaces) imported by an imported document (or namespace) MUST NOT be transitively imported by the WS-BPEL processor. In particular, this means that if an external item is used by a WS-BPEL process, then a document (or namespace) that defines that item MUST be directly imported by the process; observe however that this requirement does not limit the ability of the imported document itself to import other documents or namespaces. The following example clarifies some of the issues related to the lack of transitivity of imports.

Assume a document D1 defines a type called d1:Type. However, d1:Type's definition could depend on another type called d2:Type which is defined in document D2. D1 could include an import for D2 thus making d2:Type's definition available for use within the definition of d1:Type. If a WS-BPEL process refers to d1:Type it must import document D1. By importing D1 the WS-BPEL process can legally refer to d1:Type. But the WS-BPEL process could not refer to d2:Type even though D1 imports D2. This is because transitivity of import is not supported by WS-BPEL. Note, however, that D1 can still import D2 and d1:Type can still use d2:Type in its definition. In order to allow the WS-BPEL process to refer to d2:Type it would be necessary for the WS-BPEL process to directly import document D2.

5.5. The Lifecycle of an Executable Business Process

As noted in the introduction, the interaction model that is directly supported by WSDL is essentially a stateless client-server model of request-response or uncorrelated one-way interactions. WS-BPEL, builds on WSDL by assuming that all external interactions of the business process occur through Web Service operations. However, WS-BPEL business processes represent stateful long-running interactions in which each interaction has a beginning, defined behavior during its lifetime, and an end. For example, in a supply chain, a seller's business process might offer a service that begins an interaction by accepting a purchase order through an input message, and then returns an acknowledgement to the buyer if the order can be fulfilled. It might later send further messages to the buyer, such as shipping notices and invoices. The seller's business process remembers the state of each such purchase order interaction separately from other similar interactions. This is necessary because a buyer might be carrying on many simultaneous purchase processes with the same seller. In short, a WS-BPEL business process definition can be thought of as a template for creating business process instances.

The creation of a process instance in WS-BPEL is always implicit; activities that receive messages (that is, <receive> activities and <pick> activities) can be annotated to indicate that the occurrence of that activity causes a new instance of the business process to be created. This is done by setting the createInstance attribute of such an activity to "yes". When a message is received by such an activity, an instance of the business process is created if it does not already exist (see sections 10.4. Providing Web Service Operations – Receive and Reply  and 11.5. Selective Event Processing – Pick).

A start activity is a <receive> or a <pick> activity annotated with a createInstance="yes" attribute. [SA00015] Each executable business process MUST contain at least one start activity (see section 10.4. Providing Web Service Operations – Receive and Reply  for more details on start activities).

If more than one start activity exists in a process and these start activities contain <correlations> then all such activities MUST share at least one common <correlation> (see the example in section 9.2. Declaring and Using Correlation Sets).

If a process contains exactly one start activity then the use of <correlationSets> is unconstrained. This includes a pick with multiple <onMessage> branches; each such branch can use different <correlationSets> or no <correlationSets>.

A business process instance ends either normally or abnormally. The process ends normally when the main activity and all event handler instances of the process complete without propagating any fault. The process ends abnormally if either:

5.6. Revisiting the Initial Example

In the purchaseOrderProcess example in section 5.1. Initial Example, the structure of the main activity of the process is defined by the outer <sequence> element, which states that the three activities contained inside are performed in order. The customer request is received (<receive> element), then processed (inside a <flow> section that enables concurrent behavior), and a reply message with the final approval status of the request is sent back to the customer (<reply>). Note that the <receive> and <reply> elements are matched respectively to the <input> and <output> messages of the "sendPurchaseOrder" operation invoked by the customer, while the activities performed by the process between these elements represent the actions taken in response to the customer request, from the time the request is received to the time the response is sent back (reply).

The processing taking place inside the <flow> element consists of three concurrent <sequence> activities. The synchronization dependencies between activities in the three concurrent sequences are expressed by using <links> to connect them. The <links> are defined inside the <flow> and are used to connect a source activity to a target activity. Note that each activity declares itself as the source or target of a <link> by using the nested <source> and <target> elements. In the absence of <links>, the activities nested directly inside a <flow> proceed concurrently. In the example, however, the presence of two <link>s introduces control dependencies between the activities performed inside each sequence. For example, while the price calculation can be started immediately after the request is received, shipping price can only be added to the invoice after the shipper information has been obtained; this dependency is represented by the <link> (named "ship-to-invoice") that connects the first call on the shipping provider ("requestShipping") with sending shipping information to the price calculation service ("sendShippingPrice"). Likewise, shipping scheduling information can only be sent to the manufacturing scheduling service after it has been received from the shipper service; thus the need for the second <link> ("ship-to-scheduling").

Data is shared between different activities through shared variables, for example, the two <variable>s "shippingInfo" and "shippingSchedule".

Certain operations can return faults, as defined in their WSDL definitions. For simplicity, it is assumed here that the two operations return the same fault ("cannotCompleteOrder"). When a fault occurs, normal processing is terminated and control is transferred to the corresponding fault handler, as defined in the <faultHandlers>section. In this example the fault handler uses a <reply> element to return a fault to the customer (note the faultName attribute in the <reply> element).

Finally, it is important to observe how an assignment activity is used to transfer information between data variables. The simple assignments shown in this example transfer a message part from a source variable to a message part in a target variable, but more complex forms of assignments are also possible.

6. Partner Link Types, Partner Links, and Endpoint References

An important use case for WS-BPEL is describing cross enterprise business interactions in which the business processes of each enterprise interact through Web Service interfaces. Therefore, WS-BPEL provides the ability to model the required relationships between partner processes. WSDL already describes the functionality of a service provided by a partner, at both the abstract and concrete levels. The relationship of a business process to a partner is typically peer-to-peer, requiring a two-way dependency at the service level. In other words, a partner represents both a consumer of a service provided by the business process and a provider of a service to the business process. This is especially the case when the interactions are based on one-way operations rather than on request-response operations. The notion of <partnerLinks> is used to directly model peer-to-peer conversational partner relationships. <partnerLinks> define the shape of a relationship with a partner by defining the portTypes used in the interactions in both directions. However, the actual partner service may be dynamically determined within the process. WS-BPEL uses a notion of endpoint reference, manifested as a service reference container <sref:service-ref>, to represent the data required to describe a partner service endpoint.

Introduction of service reference container <sref:service-ref>avoids inventing a private WS-BPEL mechanism for web service endpoint references. It also provides pluggability of different versions of service referencing or endpoint addressing schemes being used within WS-BPEL.

6.1. Partner Link Types

A <partnerLinkType> characterizes the conversational relationship between two services by defining the roles played by each of the services in the conversation and specifying the portType provided by each service to receive messages within the context of the conversation. Each <role> specifies exactly one WSDL portType. The following example illustrates the basic syntax of a <partnerLinkType>declaration:

<plnk:partnerLinkType name="BuyerSellerLink">

   <plnk:role name="Buyer" portType="buy:BuyerPortType" />

   <plnk:role name="Seller" portType="sell:SellerPortType" />

</plnk:partnerLinkType>

The extensibility mechanism of WSDL 1.1 is used to define <partnerLinkType> as a new definition type to be placed as an immediate child element of a <wsdl:definitions>element. This allows reuse of the WSDL target namespace specification and its import mechanism to import portType definitions. The <partnerLinkType> definition can be a separate artifact independent of either service's WSDL document. Alternatively, the <partnerLinkType> definition can be placed within the WSDL document defining the portTypes from which the different roles are defined.

The syntax for defining a <partnerLinkType> is:

<wsdl:definitions name="NCName" targetNamespace="anyURI" ...>

   ...

   <plnk:partnerLinkType name="NCName">

      <plnk:role name="NCName" portType="QName" />

      <plnk:role name="NCName" portType="QName" />?

   </plnk:partnerLinkType>

   ...

</wsdl:definitions>

This defines a <partnerLinkType> in the namespace indicated by the value of the targetNamespace attribute of the WSDL document element. The portTypes identified within <role>s are referenced by using QNames according to the rules in WSDL specifications.

Note that in some cases it can be meaningful to define a <partnerLinkType>containing exactly one <role> instead of two. That defines a partner linking scenario where one partner expresses a capability to link with any other partner, without placing any requirements on the other partner.

Examples of <partnerLinkType> declarations are found in various business process examples in this specification.

6.2. Partner Links

The services with which a business process interacts are modeled as partner links in WS-BPEL. Each <partnerLink> is characterized by a partnerLinkType. More than one <partnerLink> can be characterized by the same partnerLinkType. For example, a certain procurement process might use more than one vendor for its transactions, but might use the same partnerLinkType for all vendors.

<partnerLinks>

   <partnerLink name="NCName"

      partnerLinkType="QName"

      myRole="NCName"?

      partnerRole="NCName"?

      initializePartnerRole="yes|no"? />+

</partnerLinks>

Each <partnerLink> is named, and this name is used for all service interactions via that <partnerLink>. This is critical, for example, in correlating responses to different <partnerLink>s for simultaneous requests of the same kind (see section 10.3. Invoking Web Service Operations – Invoke and 10.4. Providing Web Service Operations – Receive and Reply ).

Within a <partnerLink>, the role of the business process itself is indicated by the attribute myRole and the role of the partner is indicated by the attribute partnerRole. When a partnerLinkType has only one role, one of these attributes is omitted as appropriate. [SA00016] Note that a <partnerLink> MUST specify the myRole, or the partnerRole, or both. This syntactic constraint MUST be statically enforced.

The <partnerLink> declarations specify the relationships that a WS-BPEL process will employ in its behavior. In order to utilize operations via a <partnerLink>, the binding and communication data, including endpoint references (EPR), for the <partnerLink> must be available (see also section 10.3. Invoking Web Service Operations – Invoke). The relevant information about a <partnerLink> can be set as part of business process deployment. This is outside the scope of the WS-BPEL specification. Partner link types establish a relationship between WSDL port types of two Web services. The purpose of partner link types is to keep this relationship clear within the process, and make processes with more than one partner easier to understand. No other syntactic or semantic relationships are implied by partner link types in this specification. It is also possible to bind partner links dynamically. WS-BPEL provides the mechanisms to do so via assignment of endpoint references (see section 8.4. Assignment). Since the partners are likely to be stateful, the service endpoint information may need to be extended with instance-specific information.

The initializePartnerRole attribute specifies whether the WS-BPEL processor is required to initialize a <partnerLink>'s partnerRole value. The attribute has no affect on the partnerRole's value after its initialization. [SA00017] The initializePartnerRole attribute MUST NOT be used on a partner link that does not have a partner role; this restriction MUST be statically enforced. If the initializePartnerRoleattribute is set to "yes" then the WS-BPEL processor MUST initialize the EPR of the partnerRole before that EPR is first utilized by the WS-BPEL process. An example would be when an EPR is used in an <invoke> activity. If the initializePartnerRole attribute is set to "no" then the WS-BPEL processor MUST NOT initialize the EPR of the partnerRole before that EPR is first utilized by the WS-BPEL process. If the initializePartnerRoleattribute is omitted then the partner role MAY be initialized by a WS-BPEL processor.

When initializePartnerRole is set to “yes”, the EPR value used in partnerRole initialization is typically specified as a part of WS-BPEL process deployment or execution environment configuration. Hence, the initializePartnerRoleattribute may be used as a part of process deployment contract.

A <partnerLink> can be declared within a <process> or <scope> element. [SA00018] The name of a <partnerLink> MUST be unique among the names of all partner links defined within the same immediately enclosing scope. This requirement MUST be statically enforced. Access to a <partnerLink> follows common lexical scoping rules. The lifecycle of a <partnerLink> is the same as the lifecycle of the scope declaring the <partnerLink>. The initial binding information of a <partnerLink> can be set as a part of business process deployment, regardless of whether it is declared on the <process> or <scope> element level.

6.3. Endpoint References

WSDL makes an important distinction between port types and ports. Port types define abstract functionality by using abstract messages. Ports provide actual access information, including communication service endpoints and (by using extension elements) other deployment related information such as public keys for encryption. Bindings provide the glue between the two. While the user of a service must be statically dependent on the abstract interface defined by port types, some of the information contained in port definitions can typically be discovered and used dynamically.

The fundamental use of endpoint references is to serve as the mechanism for dynamic communication of port-specific data for services. An endpoint reference makes it possible in WS-BPEL to dynamically select a provider for a particular type of service and to invoke their operations. WS-BPEL provides a general mechanism for correlating messages to stateful instances of a service, and therefore endpoint references that carry instance-neutral port information are often sufficient. However, in general it is necessary to carry additional instance-identification tokens in the endpoint reference itself.

Endpoint references associated with partnerRole and myRole of <partnerLink>s are manifested as service reference containers (<sref:service-ref>). This container is used as an envelope to wrap the actual endpoint reference value. The design pattern here is similar to those of expression language, also known as open-content models, for example:

<sref:service-ref reference-scheme="http://example.org">

   <foo:barEPR xmlns:foo="http://example.org">...</foo:barEPR>

</sref:service-ref>

The <sref:service-ref> has an optional attribute called reference-scheme to denote the URI of the reference interpretation scheme of service endpoint, which is the child element of <sref:service-ref>.

The URI of reference-scheme and the namespace URI of the child element of <sref:service-ref> will not necessarily be the same. The optional reference-scheme attribute SHOULD be used when the child element of the <sref:service-ref> is ambiguous by itself. This optional attribute supplies further information to disambiguate the usage of the content. For example, if wsdl:service is used as the endpoint reference, different treatments of the wsdl:service element may occur.

If that attribute is not specified, the namespace URI of the content element within the wrapper MUST be used to determine the reference scheme of service endpoint.

If the attribute is specified, the URI SHOULD be used as the reference scheme of service endpoint and the content element within the wrapper is treated accordingly.

When a WS-BPEL implementation fails to interpret the combination of the reference-scheme attribute and the content element or just the content element alone, a standard fault "unsupportedReference" MUST be thrown.

The <sref:service-ref> element is not always exposed to WS-BPEL process definitions. For example, it is not exposed in an assignment from the endpoint reference of myRole of partnerLink-A to that of partnerRole of partnerLink-B. On the contrary, it is exposed in an assignment from a messageType or element based variable through expression or from a literal <sref:service-ref>.

7. Variable Properties

7.1. Motivation

7.1.1 Motivation for Message Properties

The data in a message consists conceptually of two parts: application data and protocol relevant data, where the protocols can be business protocols or infrastructure protocols providing higher quality of service. An example of business protocol data is the correlation tokens that are used in <correlationSets> (see section 9.2. Declaring and Using Correlation Sets). Examples of infrastructure protocols are security, transaction, and reliable messaging protocols. The business protocol data is usually found embedded in the application-visible message parts, whereas the infrastructure protocols almost always add implicit extra parts to the message types to represent protocol headers that are separate from application data. Such implicit parts are often called message context because they relate to security context, transaction context, and other similar middleware context of the interaction. Business processes might need to gain access to and manipulate both kinds of protocol-relevant data. The notion of message properties is defined as a general way of naming and representing distinguished data elements within a message, whether in application-visible data or in message context. For a full accounting of the service description aspects of infrastructure protocols, it is necessary to define notions of service policies, endpoint properties, and message context. This work is outside the scope of WS-BPEL. Message properties are defined here in a sufficiently general way to cover message context consisting of implicit parts, but the use in this specification focuses on properties embedded in application-visible data that is used in the definition of Abstract and Executable Business Processes.

 

7.1.2 Motivation for Variable Properties

Message properties are an instance of a more generic mechanism, <variable> properties. All variables in WS-BPEL can have properties defined on them. Properties are useful on non-message variables as a way to isolate the WS-BPEL process’s logic from the details of a particular variable’s definition. Using properties a WS-BPEL process can isolate its variable initialization logic in one place and then set and get properties on that <variable> in order to manipulate it. If the <variable>’s definition is later changed the rest of the WS-BPEL process definition that manipulates that variable can remain unchanged.

7.2. Defining Properties

A <vprop:property> definition creates a unique name for a WS-BPEL process definition and associates it with an XML Schema type. The intent is to create a name that has semantic significance beyond the type itself. For example, a sequence number can be an integer, but the integer type does not convey this significance, whereas a named sequence-number property does. Properties can refer to any parts of a variable.

A typical use for a <vprop:property> in WS-BPEL is to name a token for correlation of service instances with messages. For example, a social security number might be used to identify an individual taxpayer in a long-running multiparty business process regarding a tax matter. A social security number can appear in many different message types, but in the context of a tax-related process it has a specific significance as a taxpayer ID. Therefore a name is given to this use of the type by defining a <vprop:property>, as in the following example:

<wsdl:definitions name="properties"

   targetNamespace="http://example.com/properties.wsdl"

   xmlns:tns="http://example.com/properties.wsdl"

   xmlns:txtyp="http://example.com/taxTypes.xsd"

   xmlns:vprop="http://docs.oasis-open.org/wsbpel/2.0/varprop"

   xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">

 

   <!-- import schema taxTypes.xsd -->

  

   <!-- define a correlation property -->

   <vprop:property name="taxpayerNumber" type="txtyp:SSN" />

   ...

  

</wsdl:definitions>

In correlation, the property name must have process-wide significance to be of any use. Properties such as price, risk, response latency, and so on, which are used in conditional behavior in a business process, have similar significance. It is likely that they will be mapped to multiple messages, and therefore they need to be named as in the case of correlation properties.

Even in the general case of properties on XML typed WS-BPEL variables the property name should maintain its generic nature. The name is intended to identify a certain kind of value, often with an implied semantic. Any variable on which the property is available is therefore expected to provide a value that meets not just the syntax of the property definition but also its semantics.

The WSDL extensibility mechanism is used to define properties. The target namespace and other useful aspects of WSDL are available to them.

The syntax for a property definition is a new kind of WSDL definition as follows:

<wsdl:definitions name="NCName">

   <vprop:property name="NCName" type="QName"? element="QName"? />

   ...

</wsdl:definitions>

 [SA00019] Either the type or element attributes MUST be present but not both. Properties used in business protocols are typically embedded in application-visible message data.

7.3 Defining Property Aliases

The notion of aliasing is introduced to map a property to a field in a specific message part or variable value. The property name becomes an alias for the message part and/or location, and can be used as such in expressions and assignments. As an example, consider the following WSDL message definition:

<wsdl:definitions name="messages"

   targetNamespace="http://example.com/taxMessages.wsdl"

   xmlns:txtyp="http://example.com/taxTypes.xsd"

   xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">

 

   <!-- define a WSDL application message -->

   <wsdl:message name="taxpayerInfoMsg">

      <wsdl:part name="identification"

         element="txtyp:taxPayerInfoElem" />

   </wsdl:message>

   ...

 

</wsdl:definitions>

 

The definition of a property and its location in a particular field of the message are shown in the next WSDL fragment:

 

<wsdl:definitions name="properties"

   targetNamespace="http://example.com/properties.wsdl"

   xmlns:tns="http://example.com/properties.wsdl"

   xmlns:txtyp="http://example.com/taxTypes.xsd"

   xmlns:txmsg="http://example.com/taxMessages.wsdl" ...>

 

   <!-- define a correlation property -->

   <vprop:property name="taxpayerNumber" type="txtyp:SSN" />

   ...

 

   <vprop:propertyAlias propertyName="tns:taxpayerNumber"

      messageType="txmsg:taxpayerInfoMsg" part="identification">

      <vprop:query>txtyp:socialsecnumber</vprop:query>

   </vprop:propertyAlias>

 

   <vprop:propertyAlias propertyName="tns:taxpayerNumber"

      element="txtyp:taxPayerInfoElem">

      <vprop:query>txtyp:socialsecnumber</vprop:query>

   </vprop:propertyAlias>

 

</wsdl:definitions>

The first <vprop:propertyAlias> defines a named property tns:taxpayerNumberas an alias for a location in the identification part of the message type txmsg:taxpayerInfoMsg.

The second <vprop:propertyAlias> provides a second definition for the same named property tns:taxpayerNumber but this time as an alias for a location inside of the element txtyp:taxPayerInfoElem.

The presence of both aliases means that it is possible to retrieve the social security number from both a variable holding a message of messageType txmsg:taxpayerInfo as well as an element defined using txtyp:taxPayerInfoElem.

The syntax for a <vprop:propertyAlias> definition is:

<wsdl:definitions name="NCName" ...>

 

   <vprop:propertyAlias propertyName="QName"

      messageType="QName"?

      part="NCName"?

      type="QName"?

      element="QName"?>

      <vprop:query queryLanguage="anyURI"?>?

         queryContent

      </vprop:query>

   </vprop:propertyAlias>

   ...

  

</wsdl:definitions>


The interpretation of the messageType and part attributes, as well as the <query> element is the same as in the corresponding from-spec in copy assignments (see section 8.4. Assignment). The one exception is that the default value of the queryLanguage attribute for the <query> element within a <vprop:propertyAlias> is urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0.

 

[SA00020] A <vprop:propertyAlias> element MUST use one of the three following combinations of attributes:

If a <vprop:propertyAlias> is defined with the messageType/part combination then the property MUST be available on all WS-BPEL variables where the messageType QName of the variable declaration is identical to that of the <vprop:propertyAlias>. The part attribute and <query> element are applied against the WS-BPEL messageType variable to either set or get the property variable in the same way that the part attribute and <query> element are used in the first from and to specs in <copy> assignments.

If a <vprop:propertyAlias> is defined with a type attribute then the property MUST be available on all WS-BPEL variables where the type QName of the variable declaration is identical to that of the <vprop:propertyAlias>. The query is applied against the WS-BPEL variable to either set or get the property variable in the same way that the query is used in the first from and to specs in copy assignments when applied against WS-BPEL variables defined using a type.

If a <vprop:propertyAlias> is defined with an element attribute then the property MUST be available on all WS-BPEL variables where the element QName of the variable declaration is identical to that of the <vprop:propertyAlias>. The query is applied against the WS-BPEL variable to either set or get the property variable in the same way that the query is used in the first from and to specs in copy assignments when applied against WS-BPEL variables defined using an element definition.

Using the same “tns:taxpayerNumber” example from above, for a message variable “myTaxPayerInfoMsg” of messageType txmsg:taxpayerInfoMsg:

   <from variable="myTaxPayerInfoMsg" property="tns:taxpayerNumber" />

and

   <from>$myTaxPayerInfoMsg.identification/txtyp:socialsecnumber</from>

have the same output (see section 8.4. Assignment for details).

[SA00022] A WS-BPEL process definition MUST NOT be accepted for processing if it defines two or more property aliases for the same property name and WS-BPEL variable type. For example, it is not legal to define two property aliasesfor the property tns:taxpayerNumber and the messageType txmsg:taxpayerInfoMsg. The same logic would prohibit having two property aliases on the same element QName and property name value or two property aliases on the same type QName and property name value.

[SA00021] Static analysis MUST detect property usages where property aliases for the associated variable's type are not found in any WSDL definitions directly imported by the WS-BPEL process.  As described in 8. Data Handling and 9. Correlation, property usages in WS-BPEL include <correlationSets>, getVariableProperty functions as well as assign activity copy <from> and <to> property formats.

8. Data Handling

Business processes specify stateful interactions involving the exchange of messages between partners. The state of a business process includes the messages that are exchanged as well as intermediate data used in business logic and in composing messages sent to partners. The maintenance of the state of a business process requires the use of variables. Furthermore, the data from the state needs to be extracted and combined in interesting ways to control the behavior of the process, which requires data expressions. Finally, state update requires a notion of assignment. WS-BPEL provides these features for XML data types and WSDL message types. The XML family of standards in these areas is still evolving, and using the process-level attributes for query and expression languages allows for the incorporation of future standards.

Both Executable and Abstract Processes are permitted to use the full power of data selection and assignment. Executable Processes are not permitted to use opaque expressions, while Abstract Processes are permitted to use them to hide behavior. Detailed differences are specified in the following sections.

8.1. Variables

Variables provide the means for holding messages that constitute a part of the state of a business process. The messages held are often those that have been received from partners or are to be sent to partners. Variables can also hold data that are needed for holding state related to the process and never exchanged with partners.

WS-BPEL uses three kinds of variable declarations: WSDL message type, XML Schema type (simple or complex), and XML Schema element. The syntax of the <variables> declaration is:

<variables>

   <variable name="BPELVariableName"

      messageType="QName"?

      type="QName"?

      element="QName"?>+

      from-spec?

   </variable>

</variables>

An example of a <variable> declaration using a message type declared in a WSDL document with the targetNamespace "http://example.com/orders":

<variable xmlns:ORD="http://example.com/orders"

   name="orderDetails"

   messageType="ORD:orderDetails" />

Each <variable> is declared within a <scope> and is said to belong to that scope. Variables that belong to the global process scope are called global variables. Variables may also belong to other, non-global scopes, and such variables are called local variables. Each variable is visible only in the scope in which it is defined and in all scopes nested within the scope to which it belongs. Thus, global variables are visible throughout the process. It is possible to hide a variable declared in an outer scope by declaring a variable with an identical name in an inner scope. These rules are exactly analogous to those in programming languages with lexical scoping of variables.

[SA00023] The name of a <variable> MUST be unique among the names of all variables defined within the same immediately enclosing scope. This requirement MUST be statically enforced. [SA00024] Variable names are NCNames (as defined in XML Schema specification) but in addition they MUST NOT contain the “.” character.  This restriction is necessary because the “.” character is used as a delimiter in WS-BPEL's default binding to XPath 1.0  (i.e. the binding identified by "urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"). The delimiter separates the WS-BPEL message type variable name and the name of one of its WSDL message parts. The concatenation of the WSDL message variable name, the delimiter and the WSDL part name is used as an XPath variable reference which manifests the XML Infoset of the corresponding WSDL message part.

In this specification, the type BPELVariableName is used to describe the name of a <variable>. It is derived from the XML Schema NCName as described below. The type BPELVariableNames is used to describe a list of variable names.

<xsd:simpleType name="BPELVariableName">

   <xsd:restriction base="xsd:NCName">

      <xsd:pattern value="[^\.]+" />

   </xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name="BPELVariableNames">

   <xsd:restriction>

      <xsd:simpleType>

         <xsd:list itemType="tns:BPELVariableName" />

      </xsd:simpleType>

      <xsd:minLength value="1" />

   </xsd:restriction>

</xsd:simpleType>

Variable access follows common lexical scoping rules. A variable resolves to the nearest enclosing scope, regardless of the type of the variable, except as described in 12.7. Event Handlers. If a local variable has the same name as a variable defined in an enclosing scope, the local variable will be used in local assignments and/or the bpel:getVariableProperty function (as defined below).

[SA00025] The messageType, type or element attributes are used to specify the type of a variable. Exactly one of these attributes MUST be used. Attribute messageType refers to a WSDL message type definition. Attribute type refers to an XML Schema type (simple or complex). Attribute element refers to an XML Schema element.

Using [Infoset] terminology, the infoset for a WS-BPEL element variable consists of a Document Information Item (DII) that contains exactly one child, an Element Information Item (EII) which is referenced by the document element property. The EII is the value of the element variable.

If a WS-BPEL implementation chooses to manifest a simple type variable as an XML infoset, the infoset SHOULD consist of a DII that contains exactly one child, which is an EII referenced by the document element property. The properties of the document element, specifically the namespace name and local name properties, are undefined by this specification. An implementation MUST specify a namespace name/local name value. However the children of the document element MUST exclusively consist of a series of Character Information Items (CIIs) that represent the simple type value. A WS-BPEL implementation MAY choose to map simple type variables to non-XML-infoset data-models defined in the expression/query language being used (e.g. Boolean in XPath 1.0).

The infoset for a complex type variable consists of a DII that contains exactly one child, which is an EII referenced by the document element property. The properties of the document element, specifically the namespace name and local name properties, are undefined by this specification. An implementation MUST specify a namespace name/local name value. However the children of the document element MUST exclusively consist of the complex type values assigned to the variable.

 

In order to simplify data access, WSDL parts of WSDL message variables are manifested in WS-BPEL as infosets, one infoset per WSDL message part. WS-BPEL engines MUST use the following algorithm when manifesting a WSDL message part as an infoset:

 

for each part in the WSDL message definition,

Step 1 –     Create a synthetic DII which has no children other than those specified in step 2.

Step 2a –  If the WSDL message part is defined using the type attribute then create an EII as a child of the document element. The local name and namespace name of the newly created EII are determined by the WS-BPEL processor and are not specified by this document. The handling of this EII is similar to how WS-BPEL handles the containers for complex and simple type XML variables. The contents of the new EII are required to conform to the contents defined by the referenced type definition.

Step 2b –   If the WSDL message part is defined using the element attribute then create an EII as a child of the document element which manifests the element defined by the referenced type definition.

The previous models are conceptual; they define how WS-BPEL submits and retrieves XML variable values using infoset definitions. WS-BPEL processors are not required to implement an infoset model. Regardless of how the variable binding is handled, the end result SHOULD duplicate the behavior defined using the infoset model above. For example, a WS-BPEL implementation may choose to bind a simple type WS-BPEL variable of type xsd:string directly to a string object in XPath 1.0. The choice of mapping MUST be consistently applied to variables and WSDL message part values of the same XML Schema type. For example, if a xsd:string variable is manifested as a string object, a xsd:string message part MUST be manifested as a string object also. For detailed definition of manifestation of WS-BPEL variables in XPath 1.0, see section 8.2.2 Binding WS-BPEL Variables In XPath 1.0.

In summary, a WS-BPEL variable is manifested as XML Infoset items in one of the following ways:

(1)   a single XML infoset item: e.g. an element or complex type variable or a WSDL message part

(2)   a sequence of CIIs for simple type data: e.g. used to manifest a string (these items may be manifested as a non XML infoset item when needed, e.g. Boolean)

A variable can optionally be initialized by using an in-line from-spec. From-spec is defined in section 8.4. Conceptually the in-line variable initializations are modeled as a virtual <sequence> activity that contains a series of virtual <assign> activities, one for each variable being initialized, in the order they are listed in the variable declarations. The virtual <assign> activities each contain a single virtual <copy> whose from-spec is as given in the variable initialization and the to-spec points to the variable being created.

[SA00026] Variable initialization logic contained in scopes that contain or whose children contain a start activity MUST only use idempotent functions in the from-spec. The use of idempotent functions allows for all the values for such variables to be pre-computed and re-used on each process instance.

A global variable is in an uninitialized state at the beginning of a process. A local variable is in an uninitialized state at the start of the scope it belongs to. Note that non-global scopes in general start and complete their behavior more than once in the lifetime of the process instance they belong to. Variables can be initialized by a variety of means including assignment and receipt of a message. Variables can be partially initialized with property assignment or when some but not all parts in the message type of the variable are assigned values.

An attempt during process execution to read a variable or, in the case of a message type variable, a part of a variable before it is initialized MUST result in the standard bpel:uninitializedVariable fault. This includes the <invoke>and <reply> activity, where the presence of an uninitialized part also results in the standard fault bpel:uninitializedVariable.

Variable Validation

Values stored in variables can be mutated during the course of process execution. The <validate> activity can be used to ensure that values of variables are valid against their associated XML data definition, including XML Schema simple type, complex type, element definition and XML definitions of WSDL parts. The <validate> activity has a variables attribute, listing the variables to validate. The attribute accepts one or more variable names (BPELVariableName), separated by whitespaces. The syntax of the validate activity is:

<validate variables="BPELVariableNames" standard-attributes>

   standard-elements

</validate>

When one or more variables are invalid against their corresponding XML definition, a standard fault of bpel:invalidVariables fault MUST be thrown.

A WS-BPEL implementation MAY provide a mechanism to turn on/off any explicit validation, for example, the <validate> activity.

A WS-BPEL implementation MAY validate incoming and outgoing messages during the execution of message related activities, e.g., <receive>, <reply>, <pick>, <onEvent> and <invoke> activities. If such Schema validation is enabled and messages are invalid, "bpel:invalidVariables" fault SHOULD be thrown during those message activities.

8.2 Usage of Query and Expression Languages

This section describes the relationship between Query/Expression languages and WS-BPEL from two different perspectives. The first perspective is WS-BPEL's view of the query/expression languages. That view is restricted to what information WS-BPEL will make available for use by the Query/Expression language. The second perspective is the Query/Expression language's view of WS-BPEL, specifically how XPath 1.0's execution context is initialized by WS-BPEL.

WS-BPEL provides an extensible mechanism for the language used in queries and expressions. The languages are specified by the queryLanguage and expressionLanguageattributes of the process element. WS-BPEL constructs that require or allow queries or expressions provide the ability to override the default query/expression language for individual queries/expressions. WS-BPEL implementations MUST support the use of [XPath 1.0] as the query and expression language. XPath 1.0 is indicated by the default value of the queryLanguage and expressionLanguageattribute, which is:

urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0

which represents the usage of XPath 1.0 within WS-BPEL 2.0.

If the execution of a query or an expression yields an unhandled language fault, the WS-BPEL standard fault bpel:subLanguageExecutionFault MUST be thrown.

8.2.1 Enclosing Elements

In order to describe the view that WS-BPEL provides to Query/Expression languages it is necessary to introduce a new term - Enclosing Element.

Definition (Enclosing Element). An Enclosing Element is defined as the parent element in the WS-BPEL process definition that contains the Query or Expression. In the following example, the <from> element is the Enclosing Element.

<process>

   ...

   <from>$myVar/abc/def</from>

   ...

</process>

The in-scope namespaces of the enclosing element are the namespaces visible to the Query/Expression language. (Note: XPath 1.0 does not have default namespace concept.)

 

The links, variables, partnerLinks, etc. that are visible to a Query/Expression language are defined based on the entities’ visibility to the activity that the Enclosing Element is contained within. Query/Expression languages need not manifest all the different objects. Only the objects in scope to the Enclosing Element’s enclosing activity SHOULD be visible from within the Query/Expression language.

 

Evaluation of a WS-BPEL expression or query will yield one of the following (here we use XPath 1.0 expressions as examples):

 

·        a single XML infoset item: e.g. $myFooVar/lines/line[2]

·        a collection of XML infoset items e.g. $myFooVar/lines/*

·        a sequence of CIIs for simple type data
e.g.
$myFooVar/lines/line[2]/text()
(Please note this sequence of items may be manifested as a non XML infoset item when needed. e.g. as a Boolean)

·        a variable reference: e.g. <from>$myFooVar</from>

 

8.2.2 Binding WS-BPEL Variables In XPath 1.0

With the exception of link expressions whose variable access syntax and semantics are described in section 8.2.4 Default use of XPath 1.0 for Expression Languages, WS-BPEL variables are accessible in XPath expressions via XPath variable bindings. Specifically, all WS-BPEL variables visible from the Enclosing Element of an XPath expression MUST be made available to the XPath processor by manifesting the WS-BPEL variable as an XPath variable binding whose name is the same as the WS-BPEL variable's name, except in the case of variables declared with a WSDL messageType, which requires some special handling (discussed below).

 

WS-BPEL variables declared using an element MUST be manifested as a node-set XPath variable with a single member node. That node is a synthetic DII that contains a single child, the document element, which is the value of the WS-BPEL variable. The XPath variable binding will bind to the document element. For example, given the following Schema definition:

<xsd:element name="StatusContainer">

   <xsd:complexType>

      <xsd:sequence>

         <xsd:element name="statusDescription" type="xsd:string"

            form="qualified" />

      </xsd:sequence>

   </xsd:complexType>

</xsd:element>

And given the following variable declaration:

<variable name="AStatus" element="e:StatusContainer" />

Then a WS-BPEL XPath expression to access the value of the statusDescription element, assuming the AStatus variable is in scope, would look like:

$AStatus/e:statusDescription

$AStatus points at the variable's document element, StatusContainer. So to access StatusContainer's child statusDescription it is only necessary to specify the child's element name.

WS-BPEL variables declared using a complex type MUST be manifested as a node-set XPath variable with one member node containing the anonymous document element that contains the actual value of the WS-BPEL complex type variable. The XPath variable binds to the document element. For example, given the following Schema definition:

<xsd:complexType name="AuctionResults">

   <xsd:sequence>

      <xsd:element name="AuctionResult" maxOccurs="unbounded"

         form="qualified">

         <xsd:complexType>

            <xsd:attribute name="AuctionID" type="xsd:int" />

            <xsd:attribute name="Result" type="xsd:string" />

         </xsd:complexType>

      </xsd:element>

   </xsd:sequence>

</xsd:complexType>

And given the following variable declaration:

<variable name="Results" type="e:AuctionResults" />

Then a WS-BPEL XPath expression to access the value of the second AuctionID attribute would look like:

$Results/e:AuctionResult[2]/@AuctionID

$Results points at the variable’s document element, AuctionResult[2] points to the second AuctionResult child of the document element, and @AuctionID points to the AuctionID attribute on the selected AuctionResult element.

 

WS-BPEL messageType variables MUST be manifested in XPath as a series of variables, one variable per part in the messageType. Each variable is named by concatenating the message variable's name, the "." character and the name of the part. The data in a WS-BPEL messageType variable is not made available as one single XPath variable to general XPath processing under the default query and expression language binding. For example, if a messageType variable was named "myMessageTypeVar" and it contained two parts, "msgPart1" and "msgPart2" then the XPath binding that had "myMessageTypeVar" in scope would manifest two XPath variables, $myMessageTypeVar.msgPart1 and $myMessageTypeVar.msgPart2.

 

WSDL message parts are always defined using either an XSD element, an XSD complex type or a XSD simple type. As such the manifestation of these message parts in XPath can be handled in the same manner as specified herein for element, complex type and simple type WS-BPEL variables.

 

Below is a full example of how a WSDL message type is manifested in WS-BPEL XPath.

<message name="StatusMessage">

   <part name="StatusPart1" element="e:StatusContainer" />

   <part name="StatusPart2" element="e:StatusContainer" />

</message>

And given the following variable declaration:

<variable name="StatusVariable" messageType="e:StatusMessage" />

Then a WS-BPEL XPath expression to access the second part’s statusDescription element would look like:

$StatusVariable.StatusPart2/e:statusDescription

It is possible to write XPath queries that can simultaneously query across multiple parts of a WSDL message variable by applying a union operator to create one single nodeset. For example:

( $StatusVariable.StatusPart1

| $StatusVariable.StatusPart2 )//e:statusDescription 

WS-BPEL simple type variables MUST be manifested directly as either an XPath string, Boolean or float object. If the XML Schema type of the WS-BPEL simple type variable is xsd:boolean or any types that are restrictions of xsd:boolean then the WS-BPEL variable MUST be manifested as an XPath Boolean object. If the XML Schema type of the WS-BPEL simple type variable is xsd:float, xsd:int, xsd:unsignedInt or any restrictions of those types then the WS-BPEL variable MUST be manifested as an XPath float object. Any other XML Schema types MUST be manifested as an XPath string object.

The precision of the float object in XPath 1.0 is not sufficient to capture the full value of some XML Schema data types, such as xsd:decimal. XSD numeric values that cannot be expressed without loss of accuracy as XPath float objects MUST be translated into XPath string objects by a WS-BPEL processor.

8.2.3 XPath 1.0 Perspective and WS-BPEL

The XPath 1.0 specification [XPATH 1.0] defines five points that define the context in which an XPath expression is evaluated. Those points are reproduced below:

·         a node (the context node)

·         a pair of non-zero positive integers (the context position and the context size)

·         a set of variable bindings

·         a function library

·         the set of namespace declarations in scope for the expression

The following sections define how these contexts are initialized in WS-BPEL for different types of WS-BPEL Expression and Query Language contexts.

8.2.4 Default use of XPath 1.0 for Expression Languages

When XPath 1.0 is used for an Expression Language, except as specified in the sections 8.2.5 Use of XPath 1.0 for Expression Languages in Join Conditions, the XPath context is initialized as follows:

 

Context node

None

Context position

None

Context size

None

A set of variable bindings

Variables visible to the Enclosing Element as defined by the WS-BPEL scope rules 

A function library

WS-BPEL and core XPath 1.0 functions MUST be available and processor-specific functions MAY be available

Namespace declaration

In-scope namespace declarations from Enclosing Element

 

It is worth emphasizing that as defined by the XPath 1.0 standard when resolving an XPath the namespace prefixes used inside of the variable (e.g. WS-BPEL variables) are irrelevant. The only prefixes that matter are the in-scope namespaces.

For example, imagine a WS-BPEL variable named “FooVar” of “foo” element type with value:

<a:foo xmlns:a="http://example.com">

   <a:bar>23</a:bar>

</a:foo>

The following XPath would return the value 23:

<from xmlns:b="http://example.com">$FooVar/b:bar/text()</from>

Notice that in the previous example the bar element is referred to use the 'b' namespace prefix rather than the 'a' namespace prefix that is used inside the actual value.

It is also worth emphasizing that XPath 1.0 explicitly requires that any element or attribute used in an XPath expression that does not have a namespace prefix must be treated as being namespace unqualified. That is, even if there is a default namespace defined on the enclosing element, the default namespace will not be applied.

Using the same value for Foo as provided previously the following would return a bpel:selectionFailure fault (in Executable WS-BPEL), because it fails to select any node in the context of <copy> operation:

<from xmlns="http://example.com">$FooVar/bar/text()</from>

The values inside of the XPath do not inherit the default namespace of the enclosing element. So the 'bar' element referenced in the XPath does not have any namespace value what so ever and therefore does not match with the bar element in the FooVar variable which has a namespace value of http://example.com.

Allowing WS-BPEL variables to manifest as XPath variable bindings enables WS-BPEL programmers to create powerful XPath expressions involving multiple WS-BPEL variables. For example:

<assign>

   <copy>

      <from>$po/lineItem[@prodCode=$myProd]/amt * $exchangeRate</from>

      <to>$convertedPO/lineItem[@prodCode=$myProd]/amt</to>

   </copy>

</assign>

[SA00027] When XPath 1.0 is used as an expression language in WS-BPEL there is no context node available. Therefore the legal values of the XPath Expr (http://www.w3.org/TR/xpath#NT-Expr) production must be restricted in order to prevent access to the context node.

Specifically, the "LocationPath" (http://www.w3.org/TR/xpath#NT-LocationPath) production rule of "PathExpr" (http://www.w3.org/TR/xpath#NT-PathExpr) production rule MUST NOT be used when XPath is used as an expression language. The previous restrictions on the XPath Expr production for the use of XPath as an expression language MUST be statically enforced.

The result of this restriction is that the "PathExpr" will always start with a "PrimaryExpr" (http://www.w3.org/TR/xpath#NT-PrimaryExpr) for WS-BPEL expression or query language XPaths. It is worth remembering that PrimaryExprs are either variable references, expressions, literals, numbers or function calls, none of which can access the context node.

Extra restrictions are applied to XPath usage as an expression language within to-spec (see section 8.4. Assignment).

8.2.5 Use of XPath 1.0 for Expression Languages in Join Conditions

When XPath 1.0 is used as an Expression Language in a join condition, the XPath context is initialized as follows:

 

Context node

None

Context position

None

Context size

None

A set of variable bindings

Links that target the activity that the Enclosing Element is contained within 

A function library

Core XPath functions MUST be available, [SA00028] WS-BPEL functions MUST NOT be available, and processor-specific functions MAY be available.

Namespace declaration

In-scope namespace declarations from Enclosing Element

 

As explained in section 11.5.1 expressions in join conditions may only access the status of links that target the join condition's enclosing activity. No other data may be made available. To this end the only variable bindings made available to join conditions are ones that access link status.

<link> status is obtained via XPath variable bindings, manifesting <link>s that target the activity containing the Enclosing Element as XPath variable bindings of identical name. That is, if there is a <link> called "ABC" that targets the activity then there must be an XPath variable binding called "ABC". Link variables are manifested as XPath Boolean objects whose value will be set to the link's value.

Below is an example of a <joinCondition> inside of a <targets> element:

<targets>

   <target linkName="link1" />

   <target linkName="link2" />

   <joinCondition>$link1 and $link2</joinCondition>

</targets>

8.2.6 Use of XPath 1.0 for Query Languages in Copy Operations and Property Aliases

When XPath 1.0 is used as Query Language in the first variant of from-spec and to-spec in <copy> assignments (also known as variable variant) or a <vprop:propertyAlias>, the XPath context is initialized as follows:

 

 

Variable variant from-spec or to-spec

<vprop:propertyAlias>

Context node

See below

See below

Context position

1

1

Context size

1

1

A set of variable bindings

Variables visible to the Enclosing Element as defined by the WS-BPEL scope rules 

There MUST NOT be any variable bindings available when XPath is used as the query language in a <vprop:propertyAlias>

A function library

WS-BPEL and core XPath 1.0 functions MUST be available and processor-specific functions MAY be available

Core XPath functions MUST be available, [SA00029] WS-BPEL functions MUST NOT be available, and processor-specific functions MAY be available.

Namespace declaration

In-scope namespace declarations from Enclosing Element

In-scope namespace declarations from Enclosing Element (note that the Enclosing Element is in a <vprop:propertyAlias> defined in a WSDL definition)

 

The context node is determined as follows:

·        When the from-spec or to-spec references a messageType variable or the <vprop:propertyAlias>’s messageType/part attributes are used:

o       If the message part is based on a complex type or an element, the context node MUST point to a node-list containing a single node which is the EII for the referenced part specified in section 8.2.2 Binding WS-BPEL Variables In XPath 1.0.

o       If the message part is based on a simple type, the context node MUST point to the XPath object specified in section 8.2.2 Binding WS-BPEL Variables In XPath 1.0.

·        When the from-spec or to-spec references an XML Schema type variable or the <vprop:propertyAlias>’s type attribute is used:

o       If the type is a complex type, the context node MUST point to a node-list containing a single node which is the EII for the referenced part specified in section 8.2.2 Binding WS-BPEL Variables In XPath 1.0.

o       If the type is a simple type, the context node MUST point to the XPath object specified in section 8.2.2 Binding WS-BPEL Variables In XPath 1.0.

·        When the from-spec or to-spec references an XML Schema element variable or the <vprop:propertyAlias>’s element attribute is used, the context node MUST point to a node-list containing a single node which is the EII for the referenced part specified in section 8.2.2 Binding WS-BPEL Variables In XPath 1.0.

None of the previously listed restrictions on the syntax of the XPath expression apply to a <query> in from-spec/to-spec and <vprop:propertyAlias> because it has a defined context node. Any legal XPath expression may be used. An absolute or relative path can be used in a <vprop:propertyAlias> as both resolve to the context node which is the root node.

This example shows a <vprop:propertyAlias> using a relative XPath query. It returns an lvalue:

<vprop:propertyAlias propertyName="p:price"

   messageType="my:POMsg"

   part="poPart">

   <vprop:query>price</vprop:query>

</vprop:propertyAlias>

In contrast, this example shows a <vprop:propertyAlias> using an absolute XPath query. It does not return an lvalue:

<vprop:propertyAlias propertyName="p:goldCustomerPrice"

   messageType="my:POMsg"

   part="poPart">

   <vprop:query>(/p:po/price * 0.9)</vprop:query>

</vprop:propertyAlias>

There is no requirement that <query> return lvalues. When the <query> used in a variable variant to-spec or the <query> of <vprop:propertyAlias> used in a property variant to-spec does not return an lvalue, an attempt to assign to such a to-spec MUST fail with a bpel:selectionFailure (as defined in section 8.4. Assignment). Multiple nodes may be selected with this <vprop:propertyAlias> feature. However, those selections may be then filtered in the rest of expression and result in one node returned.

8.3. Expressions

WS-BPEL uses several types of expressions, as follows (relevant usage contexts are listed in parentheses):

·         Boolean expressions (transition, join, while, and if conditions)

·         Deadline expressions (until expression of <onAlarm> and <wait>)

·         Duration expressions (for expression of <onAlarm> and <wait>, <repeatEvery> expression of <onAlarm>)

·         Unsigned Integer expressions (<startCounterValue>, <finalCounterValue>, and <branches> in <forEach>)

·         General expressions (<assign>)

When the above first four types of expressions are being used, the corresponding expressions SHOULD return values which are valid according to the corresponding XML Schema types:

·         Boolean expressions should return valid values of xsd:boolean

·         Deadline expressions should return valid values of xsd:date and xsd:dateTime

·         Duration expressions should return valid values of xsd:duration

·         Unsigned Integer expressions should return valid values of xsd:unsignedInt

Otherwise, a bpel:invalidExpressionValue fault SHOULD be thrown. Implicit data conversion or casting MAY be applied when computing returned values from expressions, based on the data model or type conversion semantics established in the underlying expression language.

The following values conversion and validity checking semantics MUST be applied when WS-BPEL's default binding to XPath 1.0 is used as the expression language:

·         For WS-BPEL Boolean expressions, XPath's boolean(object) function is used to convert the expression result into a Boolean value if needed.

·         For WS-BPEL Deadline expressions, XPath's string(object) function is used to convert the expression result into a string value if needed. The string value MUST be valid values of xsd:date and xsd:dateTime. Otherwise, a bpel:invalidExpressionValuefault MUST be thrown.

·         For WS-BPEL Duration expressions, XPath's string(object) function is used to convert the expression result into a string value if needed. The string value MUST be valid values of xsd:duration. Otherwise, a bpel:invalidExpressionValuefault MUST be thrown.

·         For WS-BPEL Unsigned Integer expressions, XPath's number(object) function is used to convert the expression result into a numeric value if needed. The numeric value MUST be valid values of xsd:unsignedInt (i.e. neither negative or NaN and it must be an integer value). Otherwise, a bpel:invalidExpressionValue fault MUST be thrown.

The following XPath extension functions are defined by WS-BPEL and MUST be supported by a WS-BPEL implementation:

·        getVariableProperty, described below

·        doXslTransform, described in section 8.4. Assignment

These extensions are defined in the standard WS-BPEL namespace (see section 5.3. Language Extensibility for an overall discussion of WS-BPEL Language Extensibility) .

Any qualified names used within XPath expressions MUST be resolved by using namespace declarations currently in scope in the WS-BPEL document at the location of the expression. Null prefixes MUST be handled as specified in [XSLT 1.0] section 2.4 (i.e., a null prefix means that the empty namespace is used).

The function signature of bpel:getVariableProperty is:

   object bpel:getVariableProperty(string, string)

This function extracts property values from variables. The first argument names the source variable for the data and the second is the QName of the property to select from that variable (see section 7. Variable Properties). [SA00031] The second argument MUST be a string literal conforming to the definition of QName in section 3. Relationship with Other Specifications, and these constraints MUST be enforced by static analysis.

The return value of this function is calculated by applying the appropriate <vprop:propertyAlias> for the requested property to the current value of the submitted variable.

[SA00030] The arguments to bpel:getVariableProperty MUST be given as quoted strings. The previous requirement MUST be statically enforced. It is therefore illegal to pass into a WS-BPEL XPath function any XPath variables, the output of XPath functions, a XPath location path or any other value that is not a quoted string. This means, for example, that bpel:getVariableProperty("varA","b:propB") meets the previous requirement while bpel:getVariableProperty( $varA, string(bpel:getVariableProperty("varB", "b:propB") ) does not. Note that the previous requirement institutes a restriction which does not exist in the XPath standard.

8.3.1. Boolean Expressions

These are expressions that conform to the XPath 1.0 Expr production where the evaluation results in Boolean values.

8.3.2. Deadline Expressions

These are expressions that conform to the XPath 1.0 Expr production where the evaluation results in values that are of the XML Schema types dateTime or date.

Note that XPath 1.0 is not XML Schema aware. As such, none of the built-in functions of XPath 1.0 are capable of producing or manipulating dateTime or date values. However, it is possible to write a constant (literal) that conforms to XML Schema definitions and use that as a deadline value or to extract a field from a variable (part) of one of these types and use that as a deadline value. XPath 1.0 will treat that literal as a string literal, but the result can be interpreted as a lexical representation of a dateTime or date value.

8.3.3. Duration Expressions

These are expressions that conform to the XPath 1.0 Expr production where the evaluation results in values that are of the XML Schema type duration. The preceding discussion about XPath 1.0's lack of XML Schema awareness applies here as well.

8.3.4. Unsigned Integer Expressions

These are expressions that conform to the XPath 1.0 Expr production where the evaluation results in number object values that are of the XML Schema type unsignedInt.

8.3.5. General Expressions

These are expressions that conform to the XPath 1.0 Expr production where the evaluation results in any XPath value type (string, number, or Boolean). 

8.4. Assignment

The <assign> activity can be used to copy data from one variable to another, as well as to construct and insert new data using expressions. The use of expressions is primarily motivated by the need to perform simple computation (such as incrementing sequence numbers). Expressions operate on variables, properties, and literal constants to produce a new value. The <assign>activity can also be used to copy endpoint references to and from partnerLinks. It is also possible to include extensible data manipulation operations defined as extension elements under namespaces different from the WS-BPEL namespace. If the element contained within the extensionAssignOperation element is not recognized by the WS-BPEL processor and is not subject to a mustUnderstand="yes" requirement from an extension declaration then the extensionAssignOperation operation MUST be ignored. (See section 14 Extension Declarations).

Finally, it is possible to include extensible data manipulation operations defined as extension elements under namespaces different from the WS-BPEL namespace (see section 5.3. Language Extensibility).

The <assign> activity contains one or more elementary operations.

<assign validate="yes|no"? standard-attributes>

   standard-elements

   (

   <copy keepSrcElementName="yes|no"? ignoreMissingFromData="yes|no"?>

      from-spec to-spec

   </copy>

   |

   <extensionAssignOperation>

      assign-element-of-other-namespace

   </extensionAssignOperation>

   )+

</assign>

The <assign> activity copies a type-compatible value from the source ("from-spec") to the destination ("to-spec"), using the <copy> element. [SA00032] Except in Abstract Processes, the from-spec MUST be one of the following variants:

<from variable="BPELVariableName" part="NCName"?>

   <query queryLanguage="anyURI"?>?

      queryContent

   </query>

</from>

<from partnerLink="NCName" endpointReference="myRole|partnerRole" />

<from variable="BPELVariableName" property="QName" />

<from expressionLanguage="anyURI"?>expression</from>

<from><literal>literal value</literal></from>

<from/>

In Abstract Processes, the from-spec MUST be either one of the above or the opaque variant described in section 13.1.3. Hiding Syntactic Elements

The to-spec MUST be one of the following variants:

<to variable="BPELVariableName" part="NCName"?>

   <query queryLanguage="anyURI"?>?

      queryContent

   </query>

</to>

<to partnerLink="NCName" />

<to variable="BPELVariableName" property="QName" />

<to expressionLanguage="anyURI"?>expression</to>

<to/>

A to-spec MUST return an lvalue. If a to-spec does not return an lvalue then a bpel:selectionFailure MUST be thrown. An lvalue, in the context of XPath, is a node-list containing a single node from a variable or a partnerLink identified by the to-spec. The restrictions listed in 8.2.4 Default use of XPath 1.0 for Expression Languages MUST apply to XPath used as a query language. [SA00033] In addition, the XPath query MUST begin with an XPath VariableReference. This restriction MUST be statically enforced.

Variable variant: in the first from-spec and to-spec variants the variable attribute provides the name of a variable. If the type of the variable is a WSDL messageType the optional part attribute may be used to provide the name of a part within that variable. [SA00034] When the variable is defined using XML Schema types (simple or complex) or element, the part attribute MUST NOT be used. An optional <query> element may be used to select a value from the source or target variable or message part. The computed value of the query MUST be one of the following:

·       a single XML information item other than a CII, for example, EII and AII

·       a sequence of zero or more CIIs: this is mapped to a Text Node or a string in the XPath 1.0 data model

 

PartnerLink variant: the second from-spec and to-spec variants allow manipulation of the endpoint references associated with partnerLinks. The value of the partnerLink attribute is the name of a partnerLink that is in scope. In the case of from-specs, the role MUST be specified. The value “myRole” means that the endpoint reference of the process with respect to that partnerLink is the source, while the value “partnerRole” means that the partner’s endpoint reference for the partnerLink is the source. [SA00035] [SA00036] If the value “myRole” or “partnerRole” is used, the corresponding <partnerLink> declaration MUST specify the corresponding myRole or partnerRole attribute. This restriction MUST be statically enforced. For the to-spec, the assignment is only possible to the partnerRole, hence there is no need to specify the role. [SA00037] Therefore, the to-spec can only refer to a <partnerLink> of which the declaration specifies the partnerRole attribute. This restriction MUST be statically enforced. The type of the value referenced by partnerLink-style from/to-specs is always a <sref:service-ref> element (see section 6. Partner Link Types, Partner Links, and Endpoint References).

An attempt during process execution to read a partner link before its partnerRole EPR is initialized MUST result in the bpel:uninitializedPartnerRole standard fault. Partner roles of partner links are read when they are referenced in an <invoke> or the <from> part of a <copy> in an <assign> activity.

Property variant: the third from-spec and to-spec variants allow data manipulation using properties (see section 7. Variable Properties). The property value generated by the from-spec is generated in the same manner as the value returned by the bpel:getVariableProperty()function. The property variants provide a way to clearly define how distinguished data elements in messages are being used.

Expression variant: in the fourth from-spec variant, an expression language, identified by the optional expressionLanguage attribute, is used to return a value. In the fourth to-spec variant, an expression language, identified by the optional expressionLanguage attribute, is used to select a value. This computed value of the expression MUST be one of the followings:

·       a single XML information item other than a CII, for example, EII and AII

·       a sequence of zero or more CIIs: this is mapped to a Text Node or a string in the XPath 1.0 data model

It is possible to use either the first form of from-spec/to-spec or the fourth form of from-spec/to-spec to perform copy on non-message variables and parts of message variables, as this specification defines how to manifest non-message variables and parts of message variables as XML Infoset information items. However, only the first form of from-spec/to-spec is able to copy an entire message variable including all of its parts. Other from-spec and to-spec variants are only able to refer to a single part in a WSDL message type variable and so cannot copy all of the parts at once.

Literal variant: the fifth from-spec variant allows a literal value to be given as the source value to assign to a destination. The literal value to be assigned is included within a <literal> element in order to prevent conflicts with standard extensibility elements under <from>. The <literal> element itself does not allow standard extensibility. The type of the literal value MAY be optionally indicated inline with the value by using XML Schema's instance type mechanism (xsi:type).

The fifth from-spec variant returns values as if it were a from-spec that selects the children of the <literal> element in the WS-BPEL source code. [SA00038] The return value MUST be a single EII or Text Information Item (TII) only. This constraint MUST be enforced during static analysis.(see section 8.4.1. Selection Result of Copy Operations for the definition of TIIs). The XML parsing context of the <literal> element in the source code, such as XML Namespace, is carried into the parsing of the children within the <literal> element. An empty <literal/> element returns an empty TII. Here are some examples for illustration:

<assign>

   <copy>

      <from>

         <literal xmlns:foo="http://example.com">

            <foo:bar />

         </literal>

      </from>

      <to variable="myFooBarElemVar" />

   </copy>

   <copy>

      <from>

         <literal>

            <![CDATA[<foo:bar/>]]>

         </literal>

      </from>

      <to variable="myStringVar" />

   </copy>

   <copy>

      <from>

         <literal />

      </from>

      <to variable="myStringVar" />

   </copy>

</assign>

The first <copy> above copies a <foo:bar/> element with a “foo” prefix associated to “http://example.com” namespace into “myFooBarElemVar”. The second <copy> copies a string whose value is “<foo:bar/>” into “myStringVar”. The last <copy> copies an empty string into “myStringVar”.

The literal from-spec variant also allows a literal <sref:service-ref> value to be assigned to a partnerLink, when used with the partnerLink variant of the to-spec.

Empty variant: The sixth from-spec variant and fifth to-spec variant are included to explicitly show that from-spec and to-spec are extensible. Note that if these variants are not extended, or the extensions are not understood, they MUST behave as if they were an expression variant returning zero nodes.

In addition to <copy> specifications, other extensibility data manipulation elements MAY be included in an assign activity, inside an <extensionAssignOperation> element. The extensibility data manipulation elements MUST belong to a namespace different from the WS-BPEL namespace.

Attributes of Assign and Copy

The optional keepSrcElementName attribute of the <copy> construct is used to specify whether the element name of the destination (as selected by the to-spec) will be replaced by the element name of the source (as selected by the from-spec) during the copy operation (see section 8.4.2. Replacement Logic of Copy Operations).

The optional ignoreMissingFromData attribute of the <copy> construct is used to specify whether a bpel:selectionFailure standard fault is suppressed as specified in section 8.4.1. Selection Result of Copy Operations. The default value of the ignoreMissingFromData is "no".

The optional validate attribute can be used with the <assign> activity. Its default value is "no". When validate is set to "yes", the <assign> activity validates all the variables being modified by the activity. A WS-BPEL implementation MAY provide a mechanism to turn on/off any explicit validation. E.g. validate attribute at assign.

If the "validate" part of the <assign> activity fails, that is, one of the variables is invalid against its corresponding XML definition, a standard fault bpel:invalidVariables MUST be thrown.

If there is any fault during the execution of an assignment activity the destination variables MUST be left unchanged, as they were at the start of the activity (as if the assign activity were atomic). This applies regardless of the number of assignment elements within the overall assignment activity.

The assign activity MUST be executed as if, for the duration of its execution, it was the only activity in the process being executed.

The copy mechanism as described thus far, when combined with the default XPath 1.0 expression language, cannot perform complex XML transformations. To address this restriction in a portable fashion, a WS-BPEL processor MUST support the bpel:doXslTransform() XPath 1.0 extension function. The function signature of bpel:doXslTransform is:

   object bpel:doXslTransform(string, node-set, (string, object)*)

where:

·        The first parameter is an XPath string providing a URI naming the style sheet to be used by the WS-BPEL processor. [SA00039] This MUST take the form of a string literal. The purpose of this constraint is to allow implementations to statically analyze the process (and named style sheets) for variable dependencies; it MUST be enforced by static analysis.

·        The second parameter is an XPath node set providing the source document for the transformation to be performed by the WS-BPEL processor. This set MUST contain a single EII (i.e. an element node in XPath 1.0 data model). If it does not, the WS-BPEL processor MUST throw a bpel:xsltInvalidSource fault. The single EII as specified by this parameter MUST be treated as the single child of the root node of the source tree for XSLT processing.

·        The optional parameters that follow MUST appear in pairs. Each pair is defined as:

o       an XPath string parameter providing the qualified name of an XSLT parameter

o       an XPath object parameter providing the value for the named XSLT parameter. It can be an XPath Expr.

[SA00040] The WS-BPEL processor MUST enforce the pairing of these parameters by static analysis (i.e., an odd number of parameters must cause a static analysis error).

·        The function MUST return the result of the transformation. The result is one of the following infoset items, depending on the XSLT output method employed by the selected style sheet:

o       A single TII (an XPath 1.0 text node), created by the XSLT "text" or "html" output methods, or

o       A single EII (an XPath element node that is the single child of the root of the result tree), which is created by the XSLT "xml" output method.

The WS-BPEL processor MUST execute the bpel:doXslTransform function such that all of the following apply:

·        The first parameter, naming the style sheet to be used, MUST be used to find the style sheet corresponding to the given URI. This is accomplished in an implementation-dependent fashion. If the style sheet corresponding to the given URI cannot be found, the WS-BPEL processor MUST throw a bpel:xsltStylesheetNotFound fault.

·        The processor MUST perform an XSLT 1.0 transformation, as described in section 5.1 (Processing Model) of the XSLT 1.0 specification, using the named style sheet as primary sheet, the provided source EII as the source document, and the result tree as the result of the transformation.

·        XSLT global parameters ([XSLT 1.0], section 11.4 of the XSLT 1.0 specification) are used to pass additional values from the WS-BPEL process to the XSLT processor. The optional parameters for doXslTransform function come in the form of name-value pair in the argument list, as described above. They are used to identify the XSLT global parameters by QName, and to supply values for the named global parameters. [SA00041] The global parameter names MUST be string literals conforming to the definition of QName in section 3 of [Namespaces in XML], and these constraints MUST be enforced by static analysis. The WS-BPEL processor MUST pass the given global parameter names and values to the XSLT processor.

·        If any XSLT processing faults occur during the transformation, then a bpel:subLanguageExecutionFault MUST be thrown.

Since XSLT is a side effect-free language, execution of the transformation cannot by definition cause any changes to WS-BPEL variables referred to in the style sheet.

The first XPath function parameter, which names the style sheet, has similar semantics as the location attribute of an <import> element. Style sheets associated with a process (through its doXslTransform invocations) SHOULD be considered part of the process definition, like WSDL definitions and XML Schemas referenced by an <import> element.

bpel:doXslTransform Examples

The following examples show complex document transformation and iterative document construction.

Complex document transformation. A common pattern in WS-BPEL processes involves receiving an XML document from one service, converting it to a different Schema to form a new request message, and sending the new request to another service. Such documentation conversion can be accomplished using XSLT via the bpel:doXslTransform function.

<variables>

   <variable name="A" element="foo:AElement" />

   <variable name="B" element="bar:BElement" />

</variables>

...

<sequence>

   <invoke ... inputVariable="..." outputVariable="A" />

   <assign>

      <copy>

         <from>

            bpel:doXslTransform("urn:stylesheets:A2B.xsl", $A)

         </from>

         <to variable="B" />

      </copy>

   </assign>

   <invoke ... inputVariable="B" ... />

</sequence>

In the sequence, a service is invoked, and the result (foo:AElement) copied to variable A. The <assign> activity is used to transform the contents of variable A to bar:BElement, and copy the result of that transformation to variable B. Variable B is used to invoke another service.

The style sheet A2B.xsl would contain the XSL rules for converting documents of Schema foo:AElement to Schema bar:BElement.

Iterative document construction. Suppose that a document is constructed by repeatedly calling a service, and accumulating the result in an XML variable. The loop might look something like this:

<variables>

   <variable name="PO" element="foo:POElement" />

   <variable name="OutVar" element="foo:ItemElement" />

</variables>

 

<!-- ... PO is initialized ... -->

 

<!-- Iteratively add more items to PO until complete -->

<while>

   <condition>...</condition>

   <sequence>

      <!-- Fetch next chunk into OutVar -->

      <invoke ... inputVariable="..." outputVariable="OutVar" />

      <assign>

         <copy>

            <from>

               bpel:doXslTransform( "urn:stylesheets:AddToPO.xsl",

                                    $PO, "NewItem", $OutVar)

            </from>

            <to variable="PO" />

         </copy>

      </assign>

   </sequence>

</while>

The optional parameters given in the doXslTransform call specify that the XSLT parameter named "NewItem" is set with the value of the WS-BPEL variable OutVar. To allow the XSLT style sheet access to this value, it contains a global (top-level) parameter with a name matching that given in the third parameter of the function call shown above.

<xsl:transform version="1.0"

   xmlns:xsl="http://www.w3.org/1999/XSL/Transform" ...>

   <!-- NewItem variable set by WS-BPEL process;

        defaults to empty item -->

   <xsl:param name="NewItem">

      <foo:itemElement />

   </xsl:param>

   ...

</xsl:transform>

The style sheet contains a template that appends the value of global parameter NewItem (the value of OutVar from the process instance)to the existing list of items in the PO variable.

<xsl:template match="foo:itemElement">  <!-- line 1 -->

   <xsl:copy-of select="." />           <!-- line 2 -->

   <xsl:if test="position()=last()">    <!-- line 3 -->

      <xsl:copy-of select="$NewItem" /> <!-- line 4 -->

   </xsl:if>                            <!-- line 5 -->

</xsl:template>                         <!-- line 6 -->

This template copies all existing items in the source document (lines 1 & 2) and appends the contents of the XSLT parameter NewItem to the list of items (lines 3 & 4). It tests to see if the current node is at the end of the item list (line 3) and copies the result-tree fragment from the XSLT parameter NewItem to follow the last item (line 4).

If PO has a value of:

<foo:poElement>

   <foo:itemElement>item 1</foo:itemElement>

</foo:poElement>

at the beginning of an iteration of the <while> loop and the <invoke> activity returns a value of <foo:itemElement>item 2</foo:itemElement>, evaluation of the <from> expression will result in a value of:

<foo:poElement>

   <foo:itemElement>item 1</foo:itemElement>

   <foo:itemElement>item 2</foo:itemElement>

</foo:poElement>

which, when the <copy> operation completes, becomes the new value of the PO variable.

8.4.1. Selection Result of Copy Operations

The selection result of the from-spec or to-spec used within a <copy> operation MUST be one of the following three Information Items: Element Information Item (EII), Attribute Information Item (AII), or Text Information Item (TII). EII and AII are defined in [Infoset], while TII is defined in this specification to bridge the gap between the XML Infoset Model and other common XML data models, such as XPath 1.0.

A Text Information Item (TII) is a sequence of zero or more Character Information Items, according to document order; as such, a TII is not manifested in and of itself directly in XML serialization. When mapped to the XPath 1.0 model, it generalizes a string object (which has zero or more characters) and text node (which has one or more characters). A TII lvalue MUST NOT be empty. A TII rvalue MAY be mapped to a text node, a string/Boolean/Number object in XPath 1.0, while a TII lvalue MUST be mapped to a text node.

If the selection result of a from-spec or a to-spec belongs to Information Items other than EII, AII or TII, a bpel:selectionFailure fault MUST be thrown. If any of the unsupported Information Items are contained within the selection result, they MUST be preserved; the only restriction is that they MUST NOT be directly selected by the from-spec or the to-spec as the top-level item.

The <copy> operation is a one-to-one replacement operation. If the optional ignoreMissingFromData attribute has the value of "yes" and the from-spec returns zero XML information items then the <copy> MUST be a "no-op"; no bpel:selectionFailure is thrown. In this case, the to-spec MUST not be evaluated. A bpel:selectionFailure MUST still be thrown in the following cases, even if the ignoreMissingFromData attribute has the value of "yes":

1.      the from-spec selects multiple XML information items

2.      the from-spec selects one XML information item and the to-spec does not select exactly one XML information item

If the ignoreMissingFromData attribute has the value of "no" this requires that both the from-spec and to-spec MUST select exactly one of the three information items described above. If the from-spec or to-spec do not select exactly one information item during execution, then the standard fault bpel:selectionFailure MUST be thrown. The following table illustrates the behavior of the ignoreMissingFromData attribute in the <copy> operation:

returned nodes

ignoreMissingFromData

from

to

“no”

“yes”

0

0

selectionFailure

no-op

0

1

selectionFailure

no-op

0

N

selectionFailure

no-op

1

0

selectionFailure

selectionFailure

1

1

copy

copy

1

N

selectionFailure

selectionFailure

N

0

selectionFailure

selectionFailure

N

1

selectionFailure

selectionFailure

N

N

selectionFailure

selectionFailure

            ignoreMissingFromData Logic Table

Literal values (the literal variant of from-spec) MUST contain either a single TII or a single EII as its top-level value. When the rvalue of a from-spec is an AII, the to-spec is set to a TII constructed from the normalized value property of the AII as specified in section 8.4.2. Replacement Logic of Copy Operations.

When using the partnerLink variants of from-spec and to-spec with a non-partnerLink variant of the respective from-spec and to-spec in a <copy> operation, the partnerLink variants should be treated as if they produce an rvalue and lvalue of an EII whose [local name] is “service-ref” and [namespace name] is "http://docs.oasis-open.org/wsbpel/2.0/serviceref".

8.4.2. Replacement Logic of Copy Operations

This section provides rules for replacing data referenced by the to-spec in a <copy> operation. Detailed examples are provided in Appendix Appendix D. Examples of Replacement Logic.

Replacement Logic for WSDL Message Variables

When the from-spec and to-spec of a <copy> operation both select WSDL message variables, the value of the from-spec message variable MUST be copied, becoming the value of the to-spec message variable. If the from-spec message variable is completely uninitialized then the standard bpel:uninitializedVariable fault is thrown. If the from-spec message variable is partially initialized then any uninitialized parts of the from-spec variable result in the same parts of the to-spec variable becoming uninitialized. The original message parts of the to-spec message variable will not be available after the <copy> operation.

Replacement Table for XML Data Item

When the from-spec (Source) and to-spec (Destination) select one of three Information Items types, a WS-BPEL processor MUST use the following replacement rules identified in the table below:

Source\Destination

EII

AII

TII

EII

RE

RC

RC

AII

RC

RC

RC

TII

RC

RC

RC

            Replacement Logic Table

 

·        RE (Replace-Element-properties):

o       Replace the element at the destination with a copy of the entire element at the source, including [children] and [attribute] properties.

An optional
keepSrcElementName attribute is provided to further refine the behavior. [SA00042] It is only applicable when the results of both from-spec and to-spec are EIIs, and MUST NOT be explicitly set in other cases. A WS-BPEL processor MAY enforce this checking through static analysis of the expression/query language. If a violation is detected during runtime, a bpel:selectionFailure fault MUST be thrown.

§         When the keepSrcElementName attribute is set to “no”, the name (i.e. [namespace name] and [local name] properties) of the original destination element is used as the name of the resulting element. This is the default value.

§         When the keepSrcElementName attribute is set to “yes”, the source element name is used as the name of the resulting destination element.

When the keepSrcElementName attribute is set to “yes” and the destination element is the Document EII of an element-based variable or an element-based part of a WSDL message-type-based variable, a WS-BPEL processor MUST make sure the name of the source element belongs to the substitutionGroup of the destination element used in the element variable declaration or WSDL part definition. The substitutionGroup relation is determined by XML Schemas known to the WS-BPEL processor. [SA00094] A WS-BPEL processor MAY enforce this checking through static analysis of the expression/query language. If a violation is detected during runtime, a bpel:mismatchedAssignmentFailure fault MUST be thrown.

 

·        RC (Replace-Content):

o       To obtain the source content:

§         Once the information item is returned from the source, a TII will be computed based upon it. This source content TII is based on a series of CIIs, generally based on the document order (unless a sorting specification is present in the underlying expression or query), taken from the returned information item. The CIIs are copied, concatenated together, and the resulting value is assigned to the TII. This is analogous to the XPath 1.0 string() function.

§         If the source is an EII with an xsi:nil="true", a selectionFailure fault MUST be thrown. This check is performed during EII-to-AII or EII-to-TII copy.

o       To replace the destination content:

§         If the destination is an EII, all [children] properties (if any) are removed and the source content TII is added as the child of the EII.

§         If the destination is an AII, the value of AII is replaced with the TII from the source. The value MUST be normalized, in accordance with the XML 1.0 Recommendation (section 3.3.3 Attribute Value Normalization: http://www.w3.org/TR/1998/REC-xml-19980210#AVNormalize).

§         If the destination is a TII, the TII in the destination is replaced with the TII from the source.

·        In addition, the following rules apply:

·        Information items referenced by the to-spec MUST be an lvalue. In the XPath 1.0 data model, a TII lvalue MUST be a text node.

·        A bpel:mismatchedAssignmentFailure fault MUST be thrown when the to-spec selects a TII as an lvalue, which does NOT belong to a WS-BPEL variable of an XSD string type (or a type derived from XSD string), and one of the following is computed as an rvalue from the from-spec:

o       a TII which has zero CIIs

o       an AII which has an empty string as its [normalized value]

o       an EII which has zero CIIs as its descendants, that is, its [children] and nested [children]. Note that applying XPath 1.0 string() function to this kind of EII would yield an empty string.

·        Attribute values are not text nodes in XPath 1.0. Attribute nodes have a string value that corresponds to the XML normalized attribute value, which is a TII.

Using <copy> to initialize variables

When the destination selected by the to-spec in a <copy> operation is un-initialized, which is either an entire WS-BPEL variable or a message part, that destination MUST first be initialized before executing the replacement rules defined above, as if the following has been applied:

This initialization behavior is an integral part of an atomic <assign> activity.

Handling Non-XML Infoset Data Objects in <copy>

Simple type variables and values MAY be allowed to manifest as non-XML infoset data objects, such as boolean, string, or float, as defined in XPath 1.0. Also expressions may return non-XML infoset data objects, for example:

   <from>number($order/amt) * 0.8</from>

To consistently apply the above replacement rules, such non-XML infoset data are handled as TIIs. This is achieved through converting data to strings, as TII resembles a string object. More specifically, when the XPath 1.0 data model is used in WS-BPEL, "string(object)" (http://www.w3.org/TR/1999/REC-xpath-19991116#function-string) coercion MUST be used to convert boolean or number objects to strings. A WS-BPEL processor MAY skip the actual conversion if the result of <copy> remains the same.

XML Namespace Preservation

In the <copy> operation, the [in-scope namespaces] properties from the source (similar to other XML infoset item properties) MUST be preserved in the result at the destination. A WS-BPEL processor may use a namespace-aware XML infrastructure to maintain the XML namespace consistency.

In some XML Schema designs, QName may be used for attribute or element values. When a TII or an AII containing a QName value is selected via a Schema-unaware expression/query language, its data model will fail to capture the namespace property of the QName value. Therefore, the XML namespace may be lost. Note that XPath 1.0 is Schema unaware.

For example, where the value of attrX is a QName ("myPrefix:somename") and the value of "foo:bar3" is another QName ("myPrefix:somename2"). When "foo:bar2/@attrX" is copied as the source with XPath 1.0 data model, the namespace declaration for "myPrefix" might be missing in the destination.

<foo:bar1 xmlns:myPrefix="http://example.org"

   xmlns:foo="http://example.com ">

   <foo:bar2 attrX="myPrefix:somename" />

   <foo:bar3>myPrefix:somename2</foo:bar3>

</foo:bar1>

8.4.3. Type Compatibility in Copy Operations

[SA00043] For a copy operation to be valid, the data referred to by the from-spec and the to-spec MUST be of compatible types.

The following situations are considered type incompatible:

·         the selection results of both the from-spec and the to-spec are variables of a WSDL message type, and the two variables are not of the same WSDL message type (two WSDL message types are the same if their QNames are equal).

·         the selection result of the from-spec is a variable of a WSDL message type and that of the to-spec is not, or vice versa (parts of variables, selections of variable parts, or endpoint references cannot be assigned to/from variables of WSDL message types directly).

·         the selection result of the from-spec is an EII, that of the to-spec is a Document EII of an element-based variable or an element-based part of a WSDL message-type-based variable, the keepSrcElementName attribute is set to “yes” and the name of the source element does not belong to the substitutionGroup of the destination (see section 8.4.2. Replacement Logic of Copy Operations).

If any incompatible types are detected during assignment, the standard fault bpel:mismatchedAssignmentFailure MUST be thrown.

8.4.4. Assignment Example

Assume the following complex type definition in the namespace "http://example.org/bpel/example":

<complexType name="tAddress">

   <sequence>

      <element name="number" type="xsd:int" />

      <element name="street" type="xsd:string" />

      <element name="city" type="xsd:string" />

      <element name="phone">

         <complexType>

            <sequence>

               <element name="areacode" type="xsd:int" />

               <element name="exchange" type="xsd:int" />

               <element name="number" type="xsd:int" />

            </sequence>

         </complexType>

      </element>

   </sequence>

</complexType>

 

<element name="address" type="tAddress" />

Assume that the following WSDL message definition exists for the same target namespace:

<message name="person" xmlns:x="http://example.org/bpel/example">

   <part name="full-name" type="xsd:string" />

   <part name="address" element="x:address" />

</message>

Also assume the following WS-BPEL variable declarations:

<variable name="c1" messageType="x:person" />

<variable name="c2" messageType="x:person" />

<variable name="c3" element="x:address" />

The example illustrates copying one variable to another as well as copying a variable part to a variable of compatible element type:

<assign>

   <copy>

      <from variable="c1" />

      <to variable="c2" />

   </copy>

   <copy>

      <from>$c1.address</from>

      <to variable="c3" />

   </copy>

</assign>

9. Correlation

The information provided so far suggests that the target for messages that are delivered to a business process service is the WSDL port of the recipient service. This is an illusion because, by their very nature, stateful business processes are instantiated to act in accordance with the history of an extended interaction. Therefore, messages sent to such processes need to be delivered not only to the correct destination port, but also to the correct instance of the business process that provides the port.  Messages which create a new business process instance, are a special case, as described in 5.5. The Lifecycle of an Executable Business Process.

In the object-oriented world, such stateful interactions are mediated by object references, which intrinsically provide the ability to reach a specific object (instance) with the right state and history for the interaction. This works reasonably well in tightly coupled implementations where a dependency on the structure of the implementation is normal. In the loosely coupled world of Web Services, the use of such references would create a fragile set of implementation dependencies that would not survive the independent evolution of business process implementation details at each business partner. In this world, the answer is to rely on the business data and communication protocol headers that define the wire-level contract between partners; and to avoid the use of implementation-specific tokens for instance routing whenever possible.

Consider a supply-chain situation where a buyer sends a purchase order to a seller. Suppose the buyer and seller have a stable business relationship and are statically configured to send documents related to purchasing interactions to the URLs associated with the relevant WSDL service ports. The seller needs to return an acknowledgement for the order, and the acknowledgement must be routed to the correct business process instance at the buyer. The obvious and standard mechanism to do this is to carry a business token in the purchase order message (such as a purchase order number) that is copied into the acknowledgement message for correlation. The token can be in the message envelope, in a header, or in the business document (purchase order) itself. In either case, the exact location and type of the token in the relevant messages is fixed and instance independent. Only the value of the token is instance dependent. Therefore, the structure and position of the correlation tokens in each message can be expressed declaratively in the business process description. The WS-BPEL notion of a correlation set, described below, provides this feature. The declarative information allows infrastructure which conforms to WS-BPEL to use correlation tokens to provide instance routing automatically.

The declaration of correlation relies on declarative properties of messages. A property is simply a "field" within a message identified by a query. This is only possible when the message structure is well-defined (for example, described using an XML Schema). The use of correlation tokens is restricted to message parts described in this way. The actual wire format of such messages can be non-XML, for example, EDI flat files, based on different bindings for port types.

9.1. Message Correlation

During its lifetime, a business process instance typically holds one or more conversations with partners involved in its work. Conversations may be based on sophisticated transport infrastructure that correlates the messages involved in a conversation by using some form of conversation identity and routes them automatically to the correct process instance without the need to specify any correlation information within the business process. However, in many cases conversations involve more than two parties or use lightweight transport infrastructure with correlation tokens embedded directly in the application data being exchanged. In such cases, it is often necessary to provide additional application-level mechanisms to match messages and conversations with the business process instances for which they are intended.

Correlation patterns can become quite complex. The use of a particular set of correlation tokens does not, in general, span the entire interaction between a process instance and a partner, but spans a part of the interaction. Correlated exchanges may nest and overlap, and messages may carry several sets of correlation tokens. For example, a buyer might start a correlated exchange with a seller by sending a purchase order (PO) message and using a PO number embedded in the message as the correlation token. The PO number is used in the acknowledgement message by the seller. The seller might later send an invoice message that carries the PO number, to correlate it with the original PO, and also carries an invoice number so that future payment-related messages need to carry only the invoice number as the correlation token. The invoice message thus carries two separate correlation tokens and participates in two overlapping correlated message exchanges.

WS-BPEL addresses correlation scenarios by providing a declarative mechanism to specify correlated groups of operations within a process instance. A set of correlation tokens is defined as a set of properties shared by all messages in the correlated group. Such a set of properties is called a correlation set.

<correlationSets>?

   <correlationSet name="NCName" properties="QName-list" />+

</correlationSets>

A <correlationSet> can be declared within a process or scope element in a manner that is analogous to a variable declaration. [SA00044] The name of a <correlationSet> MUST be unique among the names of all <correlationSet> defined within the same immediately enclosing scope. This requirement MUST be statically enforced. Access to a <correlationSet>follows common lexical scoping rules.

A process' <correlationSet> is in an uninitiated state at the beginning of a process. A scope's <correlationSet> is in an uninitiated state at the start of the scope to which it belongs. Note that scopes may start and complete their behavior more than once in the lifetime of the process instance if they are contained in repeatable constructs or event handlers. In this case, the <correlationSet> initiation semantics applies to each instance of the scope.

A <correlationSet> resembles a late-bound constant rather than a variable. The binding of values to a <correlationSet> is triggered by a specially marked send or receive message operation. A <correlationSet> can be initiated only once during the lifetime of the scope to which it belongs. Once initiated, the <correlationSet> MUST retain its values, regardless of any variable updates. Thus, a process' <correlationSet> can be initiated at most once during the lifetime of the process instance.  Its values, once initiated, can be thought of as an identity of the business process instance. A scope’s <correlationSet>instance is available for binding each time the corresponding scope starts.

In multiparty business conversations, each participant process in a correlated message exchange acts either as the originator or as a follower of the exchange. The originator process sends the first message (as part of an operation invocation) that starts the conversation, and therefore defines the values of the properties in the <correlationSet> that tag the conversation. All other participants are followers that bind their <correlationSet>’s in the conversation by receiving an incoming message that provides the values of the properties in the <correlationSet>. Both originator and followers mark the first activity in their respective groups as the activity that initiates the <correlationSet>.

9.2. Declaring and Using Correlation Sets

Correlation can be used on every messaging activity (<receive>, <reply>, <onMessage>, <onEvent>, and <invoke>). WS-BPEL does not assume the use of any sophisticated conversational transport protocols for messaging. In cases where such protocols are used, the explicit use of correlation in WS-BPEL can be reduced to those activities that establish the conversational connections. These protocol mechanisms MAY be used implicitly with or without any explicit use of correlation. 

[SA00045] Properties used in a <correlationSet> MUST be defined using XML Schema simple types.  This restriction MUST be statically enforced. Each <correlationSet> is a named group of properties that, taken together, serve to identify a conversation. A given message can carry information that matches or initiates one or more correlation sets.

The correlation set specifications are used in <invoke>, <receive>, and <reply> activities (see sections 10.3. Invoking Web Service Operations and 10.4. Providing Web Service Operations – Receive and Reply); in the <onMessage>branches of <pick> activities, and in the <onEvent>variant of <eventHandlers> (see sections 11.5. Pick and 12.5.1. Message Events). These <correlation> specifications identify the correlation sets by name and are used to indicate which correlation sets (i.e., the corresponding property sets) occur in the messages being sent and received. The initiate attribute on a <correlation> specification is used to indicate whether the correlation set is being initiated.

After a correlation set is initiated, the values of the properties for a correlation set must be identical for all the messages in all the operations that carry the correlation set and occur within the corresponding scope until its completion. This correlation consistency constraint MUST be observed in all cases of initiate values. The legal values of the initiate attribute are: "yes""join", "no". The default value of the initiate attribute is "no".

The bullets above describe the correlation set Initiation Constraint. If multiple correlation sets are used in an outbound message activity (e.g., <invoke>), both initiation constraint and consistency constraints MUST be observed for all correlation sets used. If multiple correlation sets are used in an inbound message activity (IMA) (e.g. <receive>), then the initiation constraint MUST be observed for all correlation sets used. If any one of the correlation sets does not follow the constraints above, the standard fault bpel:correlationViolation MUST be thrown.

When multiple correlation sets are used in an IMA with initiate="no", a message MUST match all such correlation sets for that message to be delivered to the activity in the given process instance. When correlation set in a message does not match an already initiated correlation set in the process instance or if the correlation set is not initiated, the message MUST not be delivered to an IMA. Therefore, the correlation set consistency constraint checking is not applicable for IMA.

If an inbound Web service request message arrives and both (1) no running process instance can be identified by a message correlation set mechanism and (2) all inbound message activities referencing the Web service operation have the createInstance attribute set to "no" are true then this scenario is out of scope of this specification because there is no process instance that would be able to handle it.

When a bpel:correlationViolation is thrown by an <invoke> activity because of a violation on the response of a request/response operation, the response MUST be received before the bpel:correlationViolation is thrown.  In all other cases of bpel:correlationViolation, the message that causes the fault MUST NOT be sent or received.

Observe that in order to retrieve correlation values from a message, a processor MUST find a matching <vprop:propertyAlias> and apply it to the message. A <vprop:propertyAlias> is considered matching with a message if:

1.      the messageType attribute value used in <vprop:propertyAlias>definition matches the QName of the WSDL message type associated with the message;

or

2.      the message is associated with a WSDL message type where the message contains a single part defined by an element and the element attribute value used in <vprop:propertyAlias> definition matches the QName of the element used to define the WSDL part.

This matching <vprop:propertyAlias> constraint MUST be statically enforced. If both a messageType and element based <vprop:propertyAlias> match the message, then the messageType based <vprop:propertyAlias>MUST take priority. A type based <vprop:propertyAlias> is never considered for retrieving correlation values. These matching rules apply only to retrieving correlation values and have no effect on selecting a <vprop:propertyAlias> for use in a from-spec, to-spec, or bpel:getVariableProperty.

In the case in which the application of the <vprop:propertyAlias>results in a response that contains anything other than exactly one information item and/or a collection of Character Information Items then a bpel:selectionFailure fault MUST be thrown.

In the case of <invoke>, when the operation invoked is a request/response operation, a pattern attribute on the <correlation> specification is used to indicate whether the correlation applies to the outbound message (“request”), the inbound message (“response”), or both (“request-response”). [SA00046] The pattern attribute used in <invoke> is required for request-response operations, and disallowed when a one-way operation is invoked. Any violation of this rule MUST be detected during static analysis. In the case of <invoke>, when the operation invoked is an one-way operation, or in the case of <reply>, the usage of correlation sets with initiate="no" is for message validation purposes only. With this, a business process can ensure that the message to be sent carries the expected correlation tokens.

<correlations>

   <correlation set="NCName"

      initiate="yes|join|no"?

      pattern="request|response|request-response"? />+

</correlations>

Following is an extended example of correlation. It begins by defining four message properties: customerID, orderNumber, vendorID and invoiceNumber. All of these properties are defined as part of the "http://example.com/supplyCorrelation" namespace defined by the document:

<wsdl:definitions name="properties"

   targetNamespace="http://example.com/supplyCorrelation"

   xmlns:tns="http://example.com/supplyCorrelation" ...>

 

   <!-- define correlation properties -->

   <vprop:property name="customerID" type="xsd:string" />

   <vprop:property name="orderNumber" type="xsd:int" />

   <vprop:property name="vendorID" type="xsd:string" />

   <vprop:property name="invoiceNumber" type="xsd:int" />

 

</wsdl:definitions>

These properties are names with XML Schema simple types. They are abstract in the sense that their occurrence in variables needs to be separately specified (see section  7. Variable Properties). The example continues by defining purchase order and invoice messages and by using the concept of aliasing to map the abstract properties to fields within the message data identified by selection.

<wsdl:definitions name="correlatedMessages"

   targetNamespace="http://example.com/supplyMessages"

   xmlns:tns="http://example.com/supplyMessages"

   xmlns:cor="http://example.com/supplyCorrelation"

   xmlns:po="http://example.com/po.xsd" ...>

 

   <wsdl:import namespace="http://example.com/supplyCorrelation"

      location="..." />

 

   <!-- define schema types for PO and invoice information -->

   <wsdl:types>

      <xsd:schema targetNamespace="http://example.com/po.xsd">

         <xsd:complexType name="PurchaseOrder">

            <xsd:element name="CID" type="xsd:string" />

            <xsd:element name="order" type="xsd:int" />

            ...

         </xsd:complexType>

         <xsd:complexType name="PurchaseOrderResponse">

            <xsd:element name="CID" type="xsd:string" />

            <xsd:element name="order" type="xsd:int" />

            <xsd:element name="VID" type="xsd:string" />

            <xsd:element name="invNum" type="xsd:int" />

            ...

         </xsd:complexType>

         <xsd:complexType name="PurchaseOrderRejectType">

            <xsd:element name="CID" type="xsd:string" />

            <xsd:element name="order" type="xsd:int" />

            <xsd:element name="reason" type="xsd:string" />

            ...

         </xsd:complexType>

         <xsd:complexType name="InvoiceType">

            <xsd:element name="VID" type="xsd:string" />

            <xsd:element name="invNum" type="xsd:int" />

         </xsd:complexType>

         <xsd:element name="PurchaseOrderReject"

            type="po:PurchaseOrderRejectType" />

         <xsd:element name="Invoice" type="po:invoiceType" />

      </xsd:schema>

   </wsdl:types>

 

   <wsdl:message name="POMessage">

      <wsdl:part name="PO" type="po:PurchaseOrder" />

   </wsdl:message>

   <wsdl:message name="POResponse">

      <wsdl:part name="RSP" type="po:PurchaseOrderResponse" />

   </wsdl:message>

   <wsdl:message name="POReject">

      <wsdl:part name="RJCT" element="po:PurchaseOrderReject" />

   </wsdl:message>

   <wsdl:message name="InvMessage">

      <wsdl:part name="IVC" element=“po:Invoice " />

   </wsdl:message>

 

   <vprop:propertyAlias propertyName="cor:customerID"

      messageType="tns:POMessage" part="PO">

      <vprop:query>CID</vprop:query>

   </vprop:propertyAlias>

   <vprop:propertyAlias propertyName="cor:orderNumber"

      messageType="tns:POMessage" part="PO">

      <vprop:query>Order</vprop:query>

   </vprop:propertyAlias>

   <vprop:propertyAlias propertyName="cor:customerID"

      messageType="tns:POResponse" part="RSP">

      <vprop:query>CID</vprop:query>

   </vprop:propertyAlias>

   <vprop:propertyAlias propertyName="cor:orderNumber"

      messageType="tns:POResponse" part="RSP">

      <vprop:query>Order</vprop:query>

   </vprop:propertyAlias>

   <vprop:propertyAlias propertyName="cor:vendorID"

      messageType="tns:POResponse" part="RSP">

      <vprop:query>VID</vprop:query>

   </vprop:propertyAlias>

   <vprop:propertyAlias propertyName="cor:invoiceNumber"

      messageType="tns:POResponse" part="RSP">

      <vprop:query>InvNum</vprop:query>

   </vprop:propertyAlias>

   <vprop:propertyAlias propertyName="cor:vendorID"

      messageType="tns:InvMessage" part="IVC">

      <vprop:query>VID</vprop:query>

   </vprop:propertyAlias>

   <vprop:propertyAlias propertyName="cor:invoiceNumber"

      messageType="tns:InvMessage" part="IVC">

      <vprop:query>InvNum</vprop:query>

   </vprop:propertyAlias>

   ...

</wsdl:definitions>

Finally, the portType used is defined, in a separate WSDL document.

<wsdl:definitions name="purchasingPortType"

   targetNamespace="http://example.com/purchasing"

   xmlns:smsg="http://example.com/supplyMessages"

   xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">

 

   <wsdl:import namespace="http://example.com/supplyMessages"

      location="..." />

 

   <wsdl:portType name="PurchasingPT">

      <wsdl:operation name="Purchase">

         <wsdl:input message="smsg:POMessage" />

         <wsdl:output message="smsg:POResponse" />

         <wsdl:fault name="tns:RejectPO" message="smsg:POReject" />

      </wsdl:operation>

      <wsdl:operation name="PurchaseRequest">

         <wsdl:input message="smsg:POMessage" />

      </wsdl:operation>

   </wsdl:portType>

   <wsdl:portType name="BuyerPT">

      <wsdl:operation name="PurchaseResponse">

         <wsdl:input message="smsg:POResponse" />

      </wsdl:operation>

      <wsdl:operation name="PurchaseReject">

         <wsdl:input message="smsg:POReject" />

      </wsdl:operation>

   </wsdl:portType>

  

</wsdl:definitions>

Both the properties and their mapping to purchase order and invoice messages will be used in the following correlation examples.

<correlationSets xmlns:cor="http://example.com/supplyCorrelation">

 

   <!-- Order numbers are particular to a customer,

        this set is carried in application data -->

   <correlationSet name="PurchaseOrder"

      properties="cor:customerID cor:orderNumber" />

 

   <!-- Invoice numbers are particular to a vendor,

      this set is carried in application data -->

   <correlationSet name="Invoice"

      properties="cor:vendorID cor:invoiceNumber" />

     

</correlationSets>

A message can carry the tokens of one or more correlation sets. The first example shows an interaction in which a purchase order is received in a one-way inbound request and a confirmation including an invoice is sent in the one-way response. The PurchaseOrder <correlationSet> is used in both activities so that the one-way response is validated against the correlation set to correlate with the request at the buyer. The <receive> activity initiates the PurchaseOrder <correlationSet>. The buyer is therefore the leader and the receiving business process is a follower for this <correlationSet>. The <invoke> activity sending the one-way response also initiates a new <correlationSet>called Invoice. The business process is the leader of this correlated exchange and the buyer is a follower. The response message is thus a part of two separate conversations, and forms the bridge between them.

In the following, the prefix SP: represents the namespace "http://example.com/purchasing".

<receive partnerLink="Buyer" portType="SP:PurchasingPT"

   operation="PurchaseRequest" variable="PO">

 

   <correlations>

      <correlation set="PurchaseOrder" initiate="yes" />

   </correlations>

</receive>

...

<invoke partnerLink="Buyer" portType="SP:BuyerPT"

   operation="PurchaseResponse" inputVariable="POResponse">

 

   <correlations>

      <correlation set="PurchaseOrder" initiate="no" />

      <correlation set="Invoice" initiate="yes" />

   </correlations>

</invoke>

Alternatively, the response might have been a rejection (such as an "out-of-stock" message), which in this case the conversation correlated by the <correlationSet> PurchaseOrder does not trigger a new conversation correlated with Invoice. The pattern attribute is not used, since the operation is one-way.

<invoke partnerLink="Buyer" portType="SP:BuyerPT"

   operation="PurchaseReject" inputVariable="POReject">

 

   <correlations>

      <correlation set="PurchaseOrder" initiate="no" />

   </correlations>

</invoke>

From the perspective of the buyer's business process, the correlation sets are defined in an one-way invoke activity used for sending the purchase order and in a pick activity used for receiving the purchase order response or rejection message, respectively.

<invoke partnerLink="Seller" portType="SP:PurchasingPT"

   operation="PurchaseRequest" variable="PO">

 

   <correlations>

      <correlation set="PurchaseOrder" initiate="yes" />

   </correlations>

</invoke>

...

<pick>

   <onMessage partnerLink="Seller" portType="SP:BuyerPT"

      operation="PurchaseResponse" variable="POResponse">

      <correlations>

         <correlation set="PurchaseOrder" initiate="no" />

         <correlation set="Invoice" initiate="yes" />

      </correlations>

      ...

      <!-- handle the response message -->

   </onMessage>

 

   <onMessage partnerLink="Seller" portType="SP:BuyerPT"

      operation="PurchaseReject" variable="POReject">

      <correlations>

         <correlation set="PurchaseOrder" initiate="no" />

      </correlations>

      ...

      <!-- handle the reject message -->

   </onMessage>

</pick>

Alternatively, if the request-response purchasing operation is used in the buyer's business process, the correlation sets are specified for the request and response messages of the invoke activity, respectively. The PO rejection from the seller is sent via a fault message.

<invoke partnerLink="Seller" portType="SP:PurchasingPT"

   operation="Purchase" inputVariable="sendPO"

   outputVariable="getResponse">

 

   <correlations>

      <correlation set="PurchaseOrder" initiate="yes"

         pattern="request" />

      <correlation set="Invoice" initiate="yes" pattern="response" />

   </correlations>

 

   <catch faultName="SP:RejectPO" faultVariable="POReject"

      faultMessageType="smsg:POReject">

      ...

      <!-- handle the fault -->

   </catch>

</invoke>

An <invoke> can consist of two messages: an outgoing request message and an incoming reply message. The <correlationSet>s applicable to each message must be separately considered, because they can be different. In this case the PurchaseOrder correlation applies to the outgoing request that initiates it, while the Invoice correlation applies to the incoming reply and is initiated by the reply. Because the PurchaseOrdercorrelation is initiated by an outgoing message, the buyer is the leader of that correlation. However, the buyer is a follower of the Invoice correlation because the values of the correlation properties for Invoice are initiated by the reply message of the seller received by the buyer.

10. Basic Activities          

WS-BPEL activities perform the process logic. Activities are divided into 2 classes:  basic and structured.  Basic activities are those which describe elemental steps of the process behavior.  Structured activities encode control-flow logic, and therefore can contain other basic and/or structured activities recursively. Structured activities are described in section 11. Structured Activities.

10.1. Standard Attributes for All Activities

Each activity has two optional standard attributes: the name of the activity and suppressJoinFailure (see section 5.2. The Structure of a Business Process for the definition) indicating whether a join fault should be suppressed if it occurs. WS-BPEL language extensibility allows for other namespace-qualified attributes to be added. The name attribute is used to provide machine-processable names for activities.  WS-BPEL only makes programmatic use of the names of scope activities. See section 12.4.3. Invoking a Compensation Handler for uniqueness constraints of the name attribute. For a full discussion of the suppressJoinFailure attribute, see section 11.6. Parallel and Control Dependencies Processing – Flow

name="NCName"?

suppressJoinFailure="yes|no"?

10.2. Standard Elements for All Activities

Each activity has optional containers <sources> and <targets>, which contain standard elements <source> and <target> respectively. WS-BPEL language extensibility allows these to be extended by adding namespace-qualified elements.  These, source and target, elements are used to establish synchronization relationships through links (see section 11.6. Parallel and Control Dependencies Processing – Flow).

<targets>?

   <joinCondition expressionLanguage="anyURI"?>?

      bool-expr

   </joinCondition>

   <target linkName="NCName" />+

</targets>

 

<sources>?

   <source linkName="NCName">+

      <transitionCondition expressionLanguage="anyURI"?>?

         bool-expr

      </transitionCondition>

   </source>

</sources>

10.3. Invoking Web Service Operations – Invoke

The <invoke> activity is used to call Web Services offered by service providers (see section 6. Partner Link Types, Partner Links, and Endpoint References). The typical use is invoking an operation on a service, which is considered a basic activity. The <invoke> activity can enclose other activities, inlined in compensation handler and fault handlers, as detailed below. Operations can be request-response or one-way operations, corresponding to WSDL 1.1 operation definitions. WS-BPEL uses the same basic syntax for both, with some additional options for the request-response case.

The syntax of the <invoke> activity is summarized below.

<invoke partnerLink="NCName"

   portType="QName"?

   operation="NCName"

   inputVariable="BPELVariableName"?

   outputVariable="BPELVariableName"?

   standard-attributes>

   standard-elements

   <correlations>?

      <correlation set="NCName" initiate="yes|join|no"?

         pattern="request|response|request-response"? />+

   </correlations>

   <catch faultName="QName"?

      faultVariable="BPELVariableName"?

      faultMessageType="QName"?

      faultElement="QName"?>*

      activity

   </catch>

   <catchAll>?

      activity

   </catchAll>

   <compensationHandler>?

      activity

   </compensationHandler>

   <toParts>?

      <toPart part="NCName" fromVariable="BPELVariableName" />+

   </toParts>

   <fromParts>?

      <fromPart part="NCName" toVariable="BPELVariableName" />+

   </fromParts>

</invoke>

One-way invocation requires only the inputVariable (or its equivalent <toPart> elements) since a response is not expected as part of the operation (see section 10.4. Providing Web Service Operations – Receive and Reply ). Request-response invocation requires both an inputVariable (or its equivalent <toPart> elements) and an outputVariable (or its equivalent <fromPart> elements). If a WSDL message definition does not contain any parts, then the associated attributes, inputVariable or outputVariable, MAY be omitted, [SA00047] and the <fromParts> or <toParts> construct MUST be omitted. Zero or more correlationSets can be specified to correlate the business process instance with a stateful service at the partner’s side (see section 9. Correlation).

If an <invoke> activity is used on a partnerLink whose partnerRole EPR is not initialized then a bpel:uninitializedPartnerRole fault MUST be thrown.

In the case of a request-response invocation, the operation might return a WSDL fault message. This results in a fault identified in WS-BPEL by a QName formed by the target namespace of the corresponding port type and the fault name. To ensure consistent fault identification, this uniform naming mechanism MUST be followed even though it does not match the WSDL’s fault-naming model. WSDL 1.1 does not require fault names to be unique within the namespace where the service operation is defined. Therefore, in WSDL 1.1 it is necessary to specify a port type name, an operation name, and the fault name to uniquely identify a fault. Using WSDL 1.1's scheme would limit the ability to use fault-identification and handling mechanisms to deal with invocation faults. In WSDL it is possible to define an operation that declares more than one fault using the same data type. Certain WSDL bindings do not provide enough information for the WS-BPEL processor to determine which fault was intended. In this case, the WS-BPEL processor MUST select the fault that:

·         Matches the transmitted data and

·         Occurs first in lexical order in the operation definition. 

A result of this requirement is that a process, which uses the <catch> construct based on faultName and deals with such an operation definition, may have different behavior when deployed against different bindings.

Faults in WS-BPEL are defined only in terms of a fault name and optional fault data. This means, for example, that if a fault is generated from a messaging activity (as opposed to the <throw> activity (see section 10.6. Signaling Internal Faults) or a system fault), there is no need to keep track of the port type or operation the message activity was using when the fault was received. In consequence, all faults sharing a common name, defined in the same namespace and sharing the same data type (or lack thereof) are indistinguishable in WS-BPEL. Faults of a particular name may be associated with multiple variable types.  The <catch> construct in WS-BPEL facilitates differentiation of faults with the same name, but with different message or variable types. For details regarding fault handling and <catch>, see section 12.5. Fault Handlers.

An <invoke> activity can be associated with another activity that acts as its compensation action. Thus, a <compensationHandler> can be invoked either explicitly, or by the default <compensationHandler>of the enclosing scope (see sections 12. Scopes and 12.3. Error Handling in Business Processes).

Semantically, the specification of local fault handlers and/or a local compensation handler is equivalent to the presence of an implicit <scope> activity immediately enclosing the <invoke> providing these handlers. The implicit <scope> activity assumes the name of the <invoke> activity it encloses, its suppressJoinFailureattribute, as well as its <sources> and <targets>. For example, the following:

<invoke name="purchase"

   suppressJoinFailure="yes"

   partnerLink="Seller"

   portType="SP:Purchasing"

   operation="Purchase"

   inputVariable="sendPO"

   outputVariable="getResponse">

   <targets>

      <target linkName="linkA" />

   </targets>

   <sources>

      <source linkName="linkB" />

   </sources>

   <catch faultName="SP:rejectPO">...</catch>

   <compensationHandler>

      <invoke partnerLink="Seller"

         portType="SP:Purchasing"

         operation="CancelPurchase"

         inputVariable="getResponse"

         outputVariable="getConfirmation" />

   </compensationHandler>

</invoke>

is equivalent to:

<scope name="purchase" suppressJoinFailure="yes">

   <targets>

      <target linkName="linkA" />

   </targets>

   <sources>

      <source linkName="linkB" />

   </sources>

   <faultHandlers>

      <catch faultName="SP:rejectPO">...</catch>

   </faultHandlers>

   <compensationHandler>

      <invoke partnerLink="Seller"

         portType="SP:Purchasing"

         operation="CancelPurchase"

         inputVariable="getResponse"

         outputVariable="getConfirmation" />

   </compensationHandler>

 

   <invoke name="purchase"

      partnerLink="Seller"

      portType="SP:Purchasing"

      operation="Purchase"

      inputVariable="sendPO"

      outputVariable="getResponse" />

</scope>

In this example, the call to the Purchase operation can be compensated, if necessary, by a call to the CancelPurchase operation (see section 12.4. Compensation Handlers for details).

[SA00048] When the optional inputVariable and outputVariable attributes are being used in an <invoke> activity, the variables referenced by inputVariable and outputVariable MUST be messageType variables whose QName matches the QName of the input and output message type used in the operation, respectively, except as follows: if the WSDL operation used in an <invoke> activity uses a message containing exactly one part which itself is defined using an element, then a variable of the same element type as used to define the part MAY be referenced by the inputVariable and outputVariable attributes respectively. The result of using a variable in the previously defined circumstance MUST be the equivalent of declaring an anonymous temporary WSDL message variable based on the associated WSDL message type. The copying of the element data between the anonymous temporary WSDL message variable and the element variable acts as a single virtual <assign> with one <copy> operation whose keepSrcElementName attribute is set to "yes". The virtual <assign> MUST follow the same semantics and use the same faults as a real <assign>. In the case of an inputVariable, the value of the variable referenced by the attribute will be used to set the value of the part in the anonymous temporary WSDL message variable. In the case of an outputVariable, the value of the received part in the temporary WSDL message variable will be used to set the value of the variable referenced by the attribute.

10.3.1. Mapping WSDL Message Parts

The <toParts> element provides an alternative to explicitly creating multi-part WSDL messages from the contents of WS-BPEL variables. By using the <toParts> element, an anonymous temporary WSDL variable is declared based on the type specified by the relevant WSDL operation's input message. The <toPart> elements, as a group, act as the single virtual <assign>, with each <toPart> acting as a <copy>. At most one <toPart> exists for each part in the WSDL message definition. Each <copy> operation copies data from the variable indicated in the fromVariable attribute into the part of the anonymous temporary WSDL variable referenced in the part attribute of the <toPart> element (see section 8.4. Assignment). If the <copy> operation is copying an element variable to an element part then the keepSrcElementName option for the operation is set to "yes". The virtual <assign> MUST follow the same semantics and use the same faults as a real <assign>. [SA00050] When <toParts> is present, it is required to have a <toPart> for every part in the WSDL message definition; the order in which parts are specified is irrelevant. Parts not explicitly represented by <toPart> elements would result in uninitialized parts in the target anonymous WSDL variable used by the <invoke> or <reply> activity. Such processes with missing <toPart> elements MUST be rejected during static analysis. [SA00051] The inputVariable attribute MUST NOT be used on an <invoke> activity that contains <toPart> elements.

The <fromPart> element is similar to the <toPart> element. The <fromPart> element is used to retrieve data from an incoming multi-part WSDL message and place it into individual WS-BPEL variables. When a WSDL message is received on an <invoke> activity that uses <fromPart> elements, the message is placed in an anonymous temporary WSDL variable of the type specified by the relevant WSDL operation's output message. The <fromPart> elements, as a group, act as a single virtual <assign>, with each <fromPart> acting as a <copy>. Each <copy> operation copies the data at the part of the anonymous temporary WSDL variable referenced in the part attribute of the <fromPart> into the variable indicated in the toVariable attribute. If the <copy> operation is copying an element part to an element variable then the keepSrcElementName option for the operation is set to "yes". The virtual <assign> MUST follow the same semantics and generate the same faults as a real <assign> (see section 8.4. Assignment). When a <fromPart> is present in an <invoke>, it is not required to have a <fromPart> for every part in the WSDL message definition, nor is the order in which parts are specified relevant. Parts not explicitly represented by <fromPart> elements are not copied from the anonymous WSDL variable to the variable.  [SA00052] The outputVariable attribute MUST NOT be used on an <invoke> activity that contains a <fromParts> element.

The choice to use the inputVariable form instead of the <toParts> form, or vice versa, creates no restriction on which outputVariable or <fromParts> form is used.  Similarly, the choice to use the outputVariable form instead of the <fromParts> form, or vice versa, creates no restriction on which inputVariable or <toParts> form is used.

The virtual <assign> created as a consequence of the <fromPart> or <toPart> elements occurs as part of the scope of the <invoke> activity and therefore any fault that is thrown are caught by an <invoke>’s inline fault handler when defined. The <toPart> or <fromPart> elements MAY be used with WSDL messages that only have a single part.

See section 9. Correlation for an explanation of the correlation semantics.

10.4. Providing Web Service Operations – Receive and Reply

A business process provides services to its partners through inbound message activities (IMA - <receive>, <pick> and <onEvent>) and corresponding <reply> activities. This section describes the details of <receive> and <reply> activities (see sections 11.5. Selective Event Processing – Pick and 12.7.1. Message Events for <onEvent>).

A <receive> activity specifies the partnerLink that contains the myRole used to receive messages, the portType (optional) and operation that it expects the partner to invoke. The value of the partnerRole in the partnerLink is not used when processing a <receive> activity. In addition, <receive>  specifies a variable, using the variable attribute, that is to be used to receive the message data. An alternative to the variable attribute is the use of <fromPart> elements. The syntax and semantics of the <fromPart> elements as used on the <receive> activity are the same as specified for the <invoke> activity in section 10.3.1. Mapping WSDL Message Parts. [SA00055] Including the restriction that if <fromPart> elements are used on a <receive> activity then the variable attribute MUST NOT be used on the same activity. If a WSDL message definition does not contain any parts, then the associated variable attribute MAY be omitted, [SA00047] and the <fromParts> construct MUST be omitted. The syntax of the <receive> activity is summarized below:

<receive partnerLink="NCName"

   portType="QName"?

   operation="NCName"

   variable="BPELVariableName"?

   createInstance="yes|no"?

   messageExchange="NCName"?

   standard-attributes>

   standard-elements

   <correlations>?

      <correlation set="NCName" initiate="yes|join|no"? />+

   </correlations>

   <fromParts>?

      <fromPart part="NCName" toVariable="BPELVariableName" />+

   </fromParts>

</receive>

The <receive> activity plays a role in the lifecycle of a business process. The only way to instantiate a business process in WS-BPEL is to annotate a <receive> activity (or a <pick> activity) with the createInstance attribute set to "yes" (see section 11.5. Selective Event Processing – Pickfor a variant). The default value of this attribute is "no". A start activity is a <receive> or <pick> activity that is annotated with a createInstance="yes" attribute, or an <extensionActivity> child element. In order for the <extensionActivity> child element to qualify as a start activity, it MUST exhibit the behavior of receiving an inbound message. [SA00056] Non-start activities except <scope>, <flow>, <sequence> or <extensionActivity> activities MUST have a control dependency on a start activity (see section 12.5.2. Default Compensation Order for the definition of a control dependency). If an <extensionActivity> does not have a control dependency on a start activity then the <extensionActivity> child element MUST be a structured activity containing the start activity. This structured activity MUST be consistent with the WS-BPEL process instantiation model, that is, it MUST not be a repeatable activity. If an <extensionActivity> child element is itself a start activity or contains a start activity then the namespace of the <extensionActivity> child element MUST be declared with mustUnderstand="yes". For other semantic constraints, see section 5.3. Language Extensibility. The logical order of performing activities is determined by static analysis. For an explanation of the messageExchange attribute, see the <reply> activity description in section 10.4.1. Message Exchanges.

It is permissible to have multiple start activities. An initial start activity is the start activity that caused a particular process instance to be instantiated. As specified in section 12. Scopes, the initial start activity MUST complete execution before any other start activities are allowed to execute. This allows any inbound message used in start activities to create the process instance since the order in which these messages arrive is unpredictable. [SA00057] If a process has multiple start activities with correlation sets then all such activities MUST share at least one common correlation set and all common correlation sets defined on all the activities MUST have the value of the initiate attribute be set to "join" (see section 9. Correlation). Conforming implementations MUST ensure that only one of the inbound messages that match a single process instance actually instantiate the business process. (It will usually be the first one to arrive, but this is implementation dependent) Other incoming messages in the concurrent initial set MUST be delivered to the corresponding <receive> activities in the already created instance.

The following example is not allowed, since the <assign> activity is not a start activity:

<flow>

   <!-- this example is illegal -->

   <receive ... createInstance="yes" />

   <assign ... />

</flow>

The following example is allowed, since the <assign> activity will not be performed prior to or simultaneously with the <receive> activity:

<flow>

   <links>

      <link name="RecvToAssign" />

   </links>

   <receive ... createInstance="yes">

      <sources>

         <source linkName="RecvToAssign" />

      </sources>

   </receive>

   <assign>

      <targets>

         <target linkName="RecvToAssign" />

      </targets>

      ...

   </assign>

</flow>

 [SA00058] In a <receive> or <reply> activity, the variable referenced by the variable attribute MUST be a messageType variable whose QName matches the QName of the input (for <receive>) or output (for <reply>) message type used in the operation, except as follows: if the WSDL operation uses a message containing exactly one part which itself is defined using an element, then a WS-BPEL variable of the same element type as used to define the part MAY be referenced by the variable attribute of the <receive> or <reply> activity. The result of using a WS-BPEL variable in the previously defined circumstance MUST be equivalent to declaring an anonymous temporary WSDL message variable based on the associated WSDL message type. The copying of the element data between the anonymous temporary WSDL message variable and the element variable acts as a single virtual <assign> with one <copy> operation whose keepSrcElementName attribute is set to "yes". The virtual <assign> MUST follow the same semantics and use the same faults as a real <assign>. In the case of a <receive> activity, the incoming part’s value will be used to set the value of the variable referenced by the variable attribute. In the case of a <reply> activity the value of the variable referenced by the variable attribute will be used to set the value of the part in the anonymous temporary WSDL message variable that is sent out. In the case of a <reply> sending a fault, the same logic applies.

The <fromParts> element in a <receive> activity is used as an alternative to indicate that the data from a received message is to be directly copied to WS-BPEL variables from a corresponding anonymous WSDL message variable. Similarly, the <toParts> element is used as an alternative to have data from WS-BPEL variables directly copied into an anonymous WSDL message used by the <reply> activity (see section 10.3.1. Mapping WSDL Message Parts for rules on the use of these two elements).

A <receive> is a blocking activity in that it will not complete until a matching message is received by the process instance. A business process instance MUST NOT simultaneously enable two or more <receive> activities for the same partnerLink, portType, operation and correlationSet(s) (including WS-BPEL processor-specific correlation). If during the execution of a business process instance, two or more receive activity instances for the same partnerLink, operation and correlationSet(s) are simultaneously enabled, then the standard fault bpel:conflictingReceive MUST be thrown (note bpel:conflictingReceive differs from bpel:conflictingRequest, see section 10.4.1. Message Exchanges). There may be receive activity instances on an operation where the partnerLink and correlationSet(s) are different, yet indistinguishable to a WS-BPEL processor at runtime. In these cases, a WS-BPEL processor SHOULD throw a bpel:conflictingReceive fault. If a business process instance simultaneously enables two or more IMAs for the same partnerLink, portType, operation but different correlationSet(s), and the correlations of multiple of these activities match an incoming request message, then the bpel:ambiguousReceive standard fault MUST be thrown by all IMAs whose correlation set(s) match the incoming message. For the purpose of these constraints, an <onMessage> clause in a <pick> and an <onEvent> event handler are equivalent to a <receive> (see sections 11.5. Selective Event Processing – Pick and 12.7.1. Message Events).

Race conditions may occur in a business process execution. Messages that target a particular process instance may arrive before the corresponding <receive> activity is started.   For example, consider a process that receives a series of messages in a loop where all the messages use the same correlation. At runtime, the messages will arrive independent of the iterations of the loop. The fact that the correlation is already initiated, however, should enable the runtime engine and messaging platform to recognize that these messages are correlated to the process instance, and handle those messages appropriately. Another example is a process that may invoke a remote service then initiate a correlation set for an expected callback message.  For a variety of reasons, the callback message may arrive before the corresponding <receive> activity is started. The correlation data in the arriving message should enable the engine to recognize that the message is targeted for this process instance. Process engines MAY employ different mechanisms to handle such race conditions. This specification does not mandate any specific mechanism. Details of message delivery mechanisms are outside of the scope of this specification. However, a WS-BPEL processor should deliver messages to the process instance according to the quality of service of the underlying message delivery and transport mechanisms. For the purposes of handling race conditions, an <onMessage> clause in a <pick> and an <onEvent> event handler are equivalent to a receive (see sections 11.5. Selective Event Processing – Pick and 12.7.1. Message Events).

The <reply> activity is used to send a response to a request previously accepted through an inbound message activity such as the <receive> activity. These responses are only meaningful for request-response interactions. A one-way “response” can be sent by invoking the corresponding one-way operation on the partnerLink. A <reply> activity may specify a variable attribute that references the variable that contains the message data to be sent. If a WSDL message definition does not contain any parts, then the associated variable attribute MAY be omitted, [SA00047] and the <toParts> construct MUST be omitted. The syntax and semantics of the <toPart> elements as used on the <reply> activity are the same as specified in section 10.3.1. Mapping WSDL Message Parts for the <invoke> activity, [SA00059] including the restriction that if <toPart> elements are used on a <reply> activity then the variable attribute MUST NOT be used on the same activity.

<reply partnerLink="NCName"

   portType="QName"? operation="NCName"

   variable="BPELVariableName"?

   faultName="QName"?

   messageExchange="NCName"?

   standard-attributes>

   standard-elements

   <correlations>?

      <correlation set="NCName" initiate="yes|join|no"? />+

   </correlations>

   <toParts>?

      <toPart part="NCName" fromVariable="BPELVariableName" />+

   </toParts>

</reply>

The <reply> activity has two potential forms. First, in a normal response, the faultName attribute is not used and the variable attribute (or its equivalent <toPart> elements), when present, will indicate a variable with the response message. Second, when the response indicates a fault, the faultName attribute is used and the variable attribute (or its equivalent <toPart> elements), when present, will indicate a variable for the corresponding fault. The faultName attribute SHOULD refer to a fault defined in the operation used in the <reply> activity and the variable SHOULD match the message type associated with the referenced fault as well (note: the matching semantics here refer to points #1 and #2 in <catch> related matching rules in section 12.5. Fault Handlers). WS-BPEL treats faults based on abstract WSDL 1.1 operation definitions. This limits the ability of a WS-BPEL process to determine the information transmitted when faults are returned over a SOAP binding (see section 10.3. Invoking Web Service Operations – Invoke). 

10.4.1. Message Exchanges

The optional messageExchange attribute is used to disambiguate the relationship between inbound message activities (IMA) and <reply> activities. The explicit use of messageExchangeis needed only where the execution can result in multiple IMA-<reply>pairs (e.g. <receive>-<reply> pair) on the same partnerLink and operationbeing executed simultaneously.  [SA00060] In these cases, the process definition MUST explicitly mark the pairing-up relationship.

 

A <reply> activity is associated with an IMA, such as, <receive>,<onMessage> and <onEvent> based on the tuple partnerLink, operation, and messageExchange.  [SA00061] The name used in the optional messageExchange attribute MUST resolve to a messageExchangedeclared in a scope (where the process is considered the root scope) which encloses the <reply> activity and its corresponding IMA.  This resolution follows the same scoping rules as correlation set resolution.

 

An open IMA describes the state of a Web Service operation from the point that a request-response IMA starts execution until an associated <reply>activity completes successfully. If a <reply> activity faults, the IMA is still open and another <reply> activity MAY be attempted, for example from a fault handler. It is illegal to have multiple simultaneous open IMAs, with the same partnerLink, operation and messageExchange tuple.  A WS-BPEL processor MUST throw a bpel:conflictingRequest fault when a conflicting IMA begins execution.  It is legal to use the same messageExchange in multiple simultaneously open IMAs as long as the combination of partnerLink and operation on the IMAs are all different from each other. Note that bpel:conflictingRequest is semantically different from bpel:conflictingReceive, because it is possible to create the conflictingRequestby consecutively receiving the same request on a specific partnerLink, operation and messageExchange tuple, while conflictingReceive fault is not triggered (see section 10.4. Providing Web Service Operations – Receive and Reply  above for conflictingReceivesemantics).

 

If a <reply> activity cannot be associated with an open IMA by matching the tuple partnerLink, operation, and messageExchange then a WS-BPEL processor MUST throw a bpel:missingRequest fault on the <reply> activity. Since conflicting requests are rejected at the time the IMA begins execution there cannot be more than one corresponding IMA at the time a <reply> activity is executed.

When the primary activity and the event handlers of a <scope> complete then all Web service interactions dependent on partner links or message exchanges declared inside of the <scope> need to be completed. An open IMA using a partner link or message exchange declared in a completing or completed <scope> is termed as an orphaned IMA. Detection of orphaned IMAs will cause a bpel:missingReply fault to be thrown. Orphaned IMAs are defined and discussed in further detail in section 12.2. Message Exchange Handling. Accordingly, if a process instance completes with one or more open IMAs then a bpel:missingReply fault MUST be thrown as well.

If the messageExchange attribute is not specified on an IMA or <reply>then the activity's messageExchange is automatically associated with a default messageExchangewith no name.  Default messageExchange's are implicitly declared by the <process>and the immediate child scopes of <onEvent> and the parallel form of <forEach>. Other occurrences of <scope> activities do not provide a default messageExchange. Default messageExchange instances, just like non-default messageExchange