Web Services Business Process Execution Language Version 2.0

Committee Draft, 23^rd January 200621th December 2005

Document identifier:

wsbpel-specification-draft-01

Location:

http://www.oasis-open.org/apps/org/workgroup/wsbpel/

Editors:

Alexandre Alves, BEA <aalves@bea.com>
Assaf Arkin <arkin@intalio.com>

Sid Askary <saskary@nuperus.com>
Ben Bloch <ben_b54@hotmail.com>
Francisco Curbera, IBM <curbera@us.ibm.com>
Yaron Goland, BEA <ygoland@bea.com>
Neelakantan Kartha, Sterling Commerce <N_Kartha@stercomm.com>
Canyang Kevin Liu, SAP <kevin.liu@sap.com>
Vinkesh Mehta, Deloitte <vmehta@deloitte.com>

Satish Thatte, Microsoft <satisht@microsoft.com>
Prasad Yendluri, webMethods <pyendluri@webmethods.com>

Alex Yiu, Oracle <alex.yiu@oracle.com>
Alexandre Alves, BEA <aalves@bea.com>

Contributors:

{FirstName} {Last Name}, {Organization}

Editor’s Notes – KevinL – this section should be consolidated with Appendix H

Abstract:

This document defines a notation for specifying business process behavior based on Web Services. This notation 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 abstract away 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 templating. Business protocols, in contrast, use process descriptions that specify the mutually visible message exchange behavior of each of the parties involved in the protocol, without revealing their internal behavior. The process descriptions for business protocols are called abstract processes. WS-BPEL is meant to be used to model the behavior of both executable and abstract processes.

WS-BPEL provides a language for the formal specification of Executable and Abstract business processes and business interaction protocols. 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 is a draft version of the WS-BPEL TC specification, updated from the origninal BPEL4WS V1.1 specification dated May 5, 2003 that was submitted to the WS BPEL TC. See: http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/2046/BPEL%20V1-1%20May%205%202003%20Final.pdf

If you are on the <wsbpel@lists.oasis-open.org> list for committee members, send comments there. If you are not on that list, subscribe to the <wsbpel-comment@lists.oasis-open.org> list and send comments there. To subscribe, send an email message to <mailto:wsbpel-comment-request@lists.oasis-open.org> with the word "subscribe"as the body of the message.

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 WS-BPEL TC web page http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel

Copyright © 2004 OASIS Open, Inc. All Rights Reserved.

---

Table of Contents

1. Introduction

2. Notational Conventions

3. Relationship with Other Specifications

4. This Section Has Been Deleted

45. Core Concepts and Usage Patterns

56. Defining a Business Process

56.1. Initial Example

56.2. The Structure of a Business Process

56.3. Language Extensibility

5.4 Document Linking

56.54. The Lifecycle of a Business Process

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

67.1. Partner Link Types

67.2. Partner Links

6.3 Endpoint References

7.3. This Section Has Been Deleted

7.4. Endpoint References

78. Message PropertiesVariable Properties

78.1. Motivation

78.2. Defining Properties

7.3 Defining Property Aliases

89. Data Handling

89.1. Variables

89.2. Usage of Query and Expression Languages Variables

89.3. Expressions

8.4 Assignments Assignment

910. Correlation

910.1. Message Correlation

910.2. Defining and Using Correlation Sets

101. Basic Activities

101.1. Standard Attributes for Each Activity

101.2. Standard Elements for Each Activity

101.3. Invoking Web Service Operations

101.4. Providing Web Service Operations

101.5. Updating Variable Contents

101.6. Signaling Faults

101.7. WaitingWaiting

101.8. Doing Nothing

10.9 Extension Activity

10.10 Exit Activity

112. Structured Activities

112.1. SequenceSequence

112.2. If

112.3. WhileWhile

11.4 RepeatUntil

112.54. Pick

112.65. FlowFlow

11.7 ForEach

123. ScopesScopes

123.1. Data Handling and Partner Links

123.2. Error Handling in Business Processes

123.3. Compensation Handlers

123.4. Fault HandlersFault Handlers

123.5. Event HandlersEvent Handlers

12.6 Isolated Scopes

12.7 Extension Declarations

13.6. Isolated Scopes

14. Extensions for Executable Processes

14.1. Expressions

14.2. Variables

14.3. Assignment

14.4. Correlation

14.5. Web Service Operations

14.6. Terminating a Service Instance

14.7. Compensation

14.8. Event Handlers

135. WS-BPEL Abstract Processes

135.1. The Common Base

135.2 Abstract Process Profiles and the Semantics of Abstract Processes

15.3. Abstract Process Profile for Observable Behavior13.3. Abstract Process Profile for Observable Behavior

15.4 Abstract Process Template Profile13.4 Abstract Process Template Profile

146. Examples

146.1. Shipping Service: Observable Behavior Profile Abstract Process

16.2 Ordering Service14.2 Ordering Service

146.3. Loan Approval

146.4. Multiple Start Activities

157. Security Considerations

Appendixes

A. Standard Faults

B. Attributes and Defaults

C. XSD Schemas

D. Notices

E. Intellectual Property Rights

F. Revision History

G. ReferencesReferences (Normative)

H. References ( Non-Normative)

IH. Committee Members (Non-Normative)

---

1. Introduction

The goal of the Web Services effort is to achieve universal 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, Web Services Description Language (WSDL), and Universal Description, Discovery, and Integration (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, platformindependent 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 synchronous or uncorrelated asynchronous interactions. Models for business interactions typically assume sequences of peer-to-peer message exchanges, both synchronous and asynchronous, 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. Observable Mutually visible message exchange behavior of each of the parties involved can be described using an Abstract Process, 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 visible behavior.

Observable Visible behavior must clearly be described in a platform-independent manner and may capture behavioral aspects that have cross-enterprise business significance.

What are the concepts required to describe business processes? And what is the relationship of these concepts to those required to describe executable processes? To answer these questions, consider the following::

· Business processes invariably 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 concretized and thus can be executed, an abstract process may abstract away some of the required concrete operational details expressed by a fully 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 abstracting away operational details: (1) omission and (2) the use of explicit opaque tokens. Although a particular abstract process definition might contain complete information that would render it executable if interpreted as an executable process, 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 possible use case. One such use case might be to describe the observablevisible 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 – or the constraints required for a valid executable process that are not enforceable by the XML Schema – and on the semantics of that process.

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 usage area of an abstract process.

As mentioned earlier it is also possible to use WS-BPEL to define an executable business process. The logic and state of the process determine the nature and sequence of the Web Service interactions conducted at each business partner, and thus the observable behaviorinteraction protocols. While a WS-BPEL process definition is not required to be complete from a private implementation point of view, 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.

Even where private implementation aspects use platform-dependent functionality, which is likely in many if not most realistic cases, 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 behaviorprotocols. This is arguably the most attractive prospect 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 summary, we believe that abstract business process description is defined on top of and executable business process descriptions. require a common core of process description concepts. In this specification we clearly separate concepts required for abstract business process description from the core concepts for executable business process description by having an extension section. from the extensions required specifically for the two usage patterns. The WS-BPEL specification is focused on defining the common core, and adds only the essential extensions required for each usage pattern.

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 we call a partner link. 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. Finally, WS-BPEL introduces a mechanism to define how individual or composite activities within a process are to be compensated in cases where exceptions occur or a partner requests reversal.

WS-BPEL is layered on top of several XML specifications: WSDL 1.1, XML Schema 1.0, and XPath 1.0. WSDL messages and XML Schema type definitions provide the data model used by WS-BPEL processes. XPath provides 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.

2. Notational Conventions

The 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.

· 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.

· XSD schemas and WSDL definitions are provided as a formal definition of grammars [XML Schema Part 1] and [WSDL 1.1].

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 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/"

· plnk – http://schemas.xmlsoap.org/ws/2004/03/partner-link/”

· bpws – “http://schemas.xmlsoap.org/ws/2004/03/business-process/”

3. Relationship with Other Specifications

WS-BPEL depends on the following XML-based specifications: WSDL 1.1, XML Schema 1.0 and XPath 1.0.

Among these, 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 modeled 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 defines the message exchange protocols followed by the business process of a specific role in the interaction.

The definition of a WS-BPEL business process also follows the WSDL model of separation between the abstract message contents used by the business process and deployment information (messages and portType 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 (portTypes and operations); no references are made to the actual services used by a process instance.

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 has proven impossible. One area, discussed later in this document, is in fault naming. Another area is in support for overloaded operation names in WSDL portTypes. A BPEL processor MUST reject any WSDL portType 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. Finally a WS-BPEL processor MUST reject a WS-BPEL that refers to a portType that contain solicit-response or notification operations as defined in the WSDL 1.1 specification, this requirement MUST be statically enforced.

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.

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. Note that the description of the deployment of a WS-BPEL process is out of scope for this specification.

Introduction of service reference container (“bpws:service-ref”) is meant to avoid inventing a private WS-BPEL mechanism for web service endpoint references and to provide pluggability of different versions of service referencing or endpoint addressing schemes being used within a BPEL program without having explicit dependency to a particular version of specification.

With respect to [WS-I Basic Profile] (Basic Profile 1.1) all BPEL implementations SHOULD be configurable such that they can participate in Basic Profile 1.1 compliant interactions. A BPEL implementation MAY allow the Basic Profile 1.1 configuration to be disabled, even for scenarios encompassed by the Basic Profile 1.1. At the time this specification was completed, the WSDL v2.0 work was ongoing and not ready for consideration for WS-BPEL v2.0. Future versions of WS-BPEL may provide support for WSDL v2.0.

4.  This Section Has Been Deleted

45. Core Concepts and Usage Patterns

As noted in the introduction, we believe that the there are two usage patterns of WS-BPEL: abstract business process description business protocol description and executable business process description, where abstract business process description is defined on top of executable business process description. require a common core of process description concepts. In this specification we clearly separate concepts required for abstract business process descriptions from core concepts for executable business process by having extension section.the core concepts from the extensions required specifically for the two usage patterns. The WS-BPEL specification is focused on defining the common core, and adds only the essential extensions required for each usage pattern. These extensions are described in separate sections (Extensions for Executable Processes and WS-BPEL Abstract ProcessesExtensions for Business Protocols).

In a number of cases, the behavior of a process in a certain combination of circumstances is undefined, e.g., when a variable is used before being initialized. In the definition of the core concepts we simply note that the semantics in such cases is not defined. [AY1]

WS-BPEL takes it as a general principle that compliant implementations MAY choose to perform static analysis to detect and reject process definitions that may have undefined semantics. Such analysis is necessarily pessimistic and therefore might in some cases prevent the use of processes that would not, in fact, create situations with undefined semantics, either in specific uses or in any use.

In the executable usage pattern for WS-BPEL, situations of undefined semantics always result in standard faults in the WS-BPEL namespace. These cases will be described as part of the Extensions for Executable Processes in the specification. However, it is important to note that WS-BPEL uses exactly one standard internal fault for its core control semantics, namely, bpws:joinFailure. This is the only standard fault that plays a role in the core concepts of WS-BPEL. Of course, the occurrence of faults specified in WSDL portType definitions during web service invocation is accounted for in the core concepts as well. [AY2]

56. Defining a Business Process

65.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 the following figure. 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 tasks 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 tasks. 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 tasks are completed, invoice processing can proceed and the invoice is sent to the customer.

The WSDL portType 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 portTypes 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 "in the abstract" by referencing only the portTypes 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 partner link types 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 Partner Link Types, Partner Links, and Endpoint References). Partner link types 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 partner link type defines up to two "role" names, and lists the portTypes that each role must support for the interaction to be carried out successfully. In this example, two partner link types, "purchasingLT" and "schedulingLT", list a single role because, in the corresponding service interactions, one of the parties provides all the invoked operations: The "purchasingLT" partner link 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" partner link represents the interaction between the purchase order service and the scheduling service, in which only operations of the latter are invoked. The two other partner link types, "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 asynchronous notifications to be asynchronously sent ("invoiceCallbackPT" and "shippingCallbackPT" portTypes).

1234567890123456789012345678901234567890123456789012345678901234567890

 1 2 3 4 5 6

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

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

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

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

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

 schemalocation="http://manufacturing.org/xsd/purchase.xsd"/>
 </xsd:schema>
 </types>

 

 <message name="POMessage">

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

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

 </message>

 <message name="InvMessage">

  <part name="IVC" type="sns:Invoice"/>

 </message>

 <message name="orderFaultType">

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

 </message>

 <message name="shippingRequestMessage">

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

 </message>

 <message name="shippingInfoMessage">

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

 </message>

 <message name="scheduleMessage">

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

 </message>



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

 <portType name="purchaseOrderPT">

  <operation name="sendPurchaseOrder">

 <input message="pos:POMessage"/>

 <output message="pos:InvMessage"/>

 <fault name="cannotCompleteOrder"

  message="pos:orderFaultType"/>

  </operation>

 </portType>

 <portType name="invoiceCallbackPT">

  <operation name="sendInvoice">

 <input message="pos:InvMessage"/>

 </operation>

 </portType>

 <portType name="shippingCallbackPT">

  <operation name="sendSchedule">

 <input message="pos:scheduleMessage"/>

  </operation>

 </portType>

 

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

 <portType name="computePricePT">

  <operation name="initiatePriceCalculation">

 <input message="pos:POMessage"/>

  </operation>

  <operation name="sendShippingPrice">

 <input message="pos:shippingInfoMessage"/>

  </operation>

 </portType>

 

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

 <portType name="shippingPT">

  <operation name="requestShipping">

 <input message="pos:shippingRequestMessage"/>

 <output message="pos:shippingInfoMessage"/>

 <fault name="cannotCompleteOrder"

  message="pos:orderFaultType"/>

  </operation>

 </portType>

 

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

 <portType name="schedulingPT">

  <operation name="requestProductionScheduling">

 <input message="pos:POMessage"/>

  </operation>

  <operation name="sendShipingSchedule">

 <input message="pos:scheduleMessage"/>

  </operation>

 </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>

</definitions>

The business process for the order service is defined next. There are four major sections in this process definition:

· 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 data and process history based on messages exchanged.

· The <partnerLinks> section defines the different parties that interact with the business process in the course of processing the order. The four partnerLinks shown here correspond to the sender of the order (customer), as well as the providers of price (invoicingProvider), shipment (shippingProvider), and manufacturing scheduling services (schedulingProvider). Each partner link is characterized by a partner link type and a role name. This information identifies the functionality that must be provided by the business process and by the partner service for the relationship to succeed, that is, the portTypes that the purchase order process and the partner need to implement.

· The <faultHandlers> section contains fault handlers defining 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 portType and fault are defined, and the ncname of the fault. It is important to note, however, that because WSDL 1.1 does not require that fault names be unique within the namespace where the operation is defined, all faults sharing a common name and defined in the same namespace are indistinguishable. In spite of this serious WSDL limitation, WS-BPEL provides a uniform naming model for faults, in the expectation that future versions of WSDL will provide a better fault-naming model.

· 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.

1234567890123456789012345678901234567890123456789012345678901234567890

 1 2 3 4 5 6



<process name="purchaseOrderProcess"

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

 xmlns="http://schemas.xmlsoap.org/ws/2004/03/business-process/"

 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="POFault" messageType="lns:orderFaultType"/>

 <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">

 </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">

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

 </sources> 

  </invoke>

  <receive partnerLink="shipping"

 portType="lns:shippingCallbackPT"

 operation="sendSchedule"

 variable="shippingSchedule">

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

 </sources> 

  </receive>

 </sequence>

 <sequence>

  <invoke partnerLink="invoicing"

 portType="lns:computePricePT"

 operation="initiatePriceCalculation"

 inputVariable="PO">

  </invoke>

  <invoke partnerLink="invoicing"

 portType="lns:computePricePT"

 operation="sendShippingPrice"

 inputVariable="shippingInfo">

 <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">

  </invoke>

  <invoke partnerLink="scheduling"

 portType="lns:schedulingPT"

 operation="sendShippingSchedule"

 inputVariable="shippingSchedule">

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

 </targets> 

  </invoke>

 </sequence>

 </flow>

 <reply partnerLink="purchasing"

 portType="lns:purchaseOrderPT"

 operation="sendPurchaseOrder"

 variable="Invoice"/>

 </sequence>

</process>

56.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:

1234567890123456789012345678901234567890123456789012345678901234567890

 1 2 3 4 5 6



<process name="ncname" targetNamespace="uri"

 abstractProcessProfile="anyURI"?
 queryLanguage="anyURI"?

 expressionLanguage="anyURI"?

 suppressJoinFailure="yes|no"?
 exitOnStandardFault="yes|no"?
 xmlns="http://schemas.xmlsoap.org/ws/2004/03/business-process/">



<extensions>?
 <extension namespace="anyURI" mustUnderstand="yes|no"/>*
</extensions> 




<import namespace="uri" location="uri" importType="uri"/>*
 

<partnerLinks>?

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

 <partnerLink name="ncname" partnerLinkType="qname"

 myRole="ncname"? partnerRole="ncname"?>+

 </partnerLink>

</partnerLinks>



<variables>?

 <variable name="ncname" messageType="qname"?

 type="qname"? element="qname"?/>+

</variables>



<correlationSets>?

 <correlationSet name="ncname" properties="qname-list"/>+

</correlationSets>



<faultHandlers>?

<!-- Note: There must be at least one fault handler or default. -->

 <catch faultName="qname"? faultVariable="ncname"? 
 faultMessageType="qname"?
 faultElement="qname"?>*

 activity

 </catch>

 <catchAll>?

 activity

 </catchAll>

</faultHandlers>



<eventHandlers>?
<!-- Note: There must be at least one onEvent or onAlarm handler. -->
 <onEvent partnerLink="ncname" portType="qname"?
  operation="ncname" messageType="qname" variable="ncname"
 messageExchange="ncname"? >*
 <correlationSets>?
 <correlationSet name="ncname" 
 properties="qname-list"/>+
 </correlationSets>
 <correlations>?
 <correlation set="ncname"
 initiate="yes|join|no"?/>+
 </correlations>
  scope-activity
 </onEvent>
 <onAlarm>*

 ( 
  ( <for expressionLanguage="anyURI"?>duration-expr</for> |
  <until expressionLanguage="anyURI"?>deadline-expr</until> )
  <repeatEvery expressionLanguage="anyURI"?>
 duration-expr
  </repeatEvery>?

 ) |

  <repeatEvery expressionLanguage="anyURI"?>
 duration-expr
 </repeatEvery>
   scope-activity
 </onAlarm>
</eventHandlers>

 activity

</process>

The top-level attributes are as follows:

· abstractProcessProfile. This attribute provides the URI that identifies the profile of an abstract process. It is mandatory for abstract processes.

· queryLanguage. This attribute specifies the default XML query language used for selection of nodes in assignment, property definition, and other uses. 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. The URI of the corresponding XPath 1.0 specification is: http://www.w3.org/TR/1999/REC-xpath-19991116.

· 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. The URI of the corresponding XPath 1.0 specification is: http://www.w3.org/TR/1999/REC-xpath-19991116.

· 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. This attribute specifies if the process must exit if a WS-BPEL standard fault other than bpws:joinFailure is encountered[1]. 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 bpws:joinFailure is enountered. 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>.

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 and rejected by static analysis.

· abstractProcess. This attribute specifies whether the process being defined is abstract (rather than executable). The default for this attribute is "no".

The value of the queryLanguage and expressionLanguage attributes on the

<process> element are global defaults and can be overridden on

specific activities like <assign> using the mechanisms defined later in

this specification. In addition the queryLanguage attribute is also

available for use in defining BPEL property aliases in WSDL. BPEL processors

MUST:

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

· if any referenced language is unsupported by the BPEL processor then the processor MUST NOT process the submitted 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 previous section. Detailed description of <documention> is provided in next section, as it is a part of “Language Extensibility”.

The token "activity" can be any of the following:

· <receive>

· <reply>

· <invoke>

· <assign>

· <throw>

· <exit>

· <wait>

· <empty>

· <sequence>

· <if>

· <while>

· <repeatUntil>

· <forEach>

· <pick>

· <flow>

·

· <scope>

· <compensate>

· <rethrow>

· <validate>

· <extensionActivity>

The syntax of each of these elements, except <exit>, <compensate> and <rethrow>, is considered in the following paragraphs.

· <compensate> activity can be used ONLY within a fault handler or a compensation handler (i.e. <catch>, <catchAll> and <compensationHandler> elements).

· <rethrow> activity can be used ONLY within a fault handler (i.e. <catch> and <catchAll> elements).

The <receive> construct allows the business process to do a blocking wait for a matching message to arrive. The portType attribute on the <receive> 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 a <receive> activity. (For details of messageExchange, please see “Providing Web Service Operations” section).

1234567890123456789012345678901234567890123456789012345678901234567890

 1 2 3 4 5 6



<receive partnerLink="ncname" portType="qname"? operation="ncname"

 variable="ncname"? createInstance="yes|no"? 

 messageExchange="ncname"? 

 standard-attributes>

 standard-elements

 <correlations>?

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

 </correlations>
 <fromPart part="ncname" toVariable="ncname"/>*

</receive>

The <reply> construct allows the business process to send a message in reply to a message that was received through a <receive>. The combination of a <receive> and a <reply> forms a request-response operation on the 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 inbound message activity, such as, <receive>, <onMessage> and <onEvent>. (For details of messageExchange, please see “Providing Web Service Operations” section).

1234567890123456789012345678901234567890123456789012345678901234567890

 1 2 3 4 5 6



<reply partnerLink="ncname" portType="qname"? operation="ncname"

 variable="ncname"? faultName="qname"?

 messageExchange="ncname"?

 standard-attributes>

 standard-elements

 <correlations>?

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

 </correlations>
 <toPart part="ncname" fromVariable="ncname"/>*

</reply>

The <invoke> construct allows the business process to invoke a one-way or requestresponse operation on a portType offered by a partner. 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).

1234567890123456789012345678901234567890123456789012345678901234567890

 1 2 3 4 5 6

 

<invoke partnerLink="ncname" portType="qname"? operation="ncname"

 inputVariable="ncname"? outputVariable="ncname"?

 standard-attributes>

 standard-elements

 <correlations>?

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

 pattern="in|out|out-in"/>+

 </correlations>

 <catch faultName=“qname”? faultVariable="ncname"?

 faultMessageType="qname"?>*

 activity

 </catch>

 <catchAll>?

 activity

 </catchAll>

 <compensationHandler>?

 activity

 </compensationHandler>
 <toPart part="ncname" fromVariable="ncname"/>*
 <fromPart part="ncname" toVariable="ncname"/>*

</invoke>

The <assign> construct can be 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. The syntax of the assignment activity is:

1234567890123456789012345678901234567890123456789012345678901234567890

 1 2 3 4 5 6

 

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

 standard-elements

 (<copy>
 from-spec
 to-spec
 </copy> |
 <extensibleAssign>
 ...assign-element-of-other-namespace...
 </extensibleAssign>) +

</assign>

The <validate> construct can be 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. The syntax of the validate activity is:

1234567890123456789012345678901234567890123456789012345678901234567890

 1 2 3 4 5 6



<validate variables="ncname-list" standard-attributes>

 standard-elements

</validate>

The <throw> construct generates a fault from inside the business process.

1234567890123456789012345678901234567890123456789012345678901234567890

 1 2 3 4 5 6

 

<throw faultName="qname" faultVariable="ncname"? standard-attributes>

 standard-elements

</throw>

The <wait> construct allows you to wait for a given time period or until a certain time has passed. Exactly one of the expiration criteria must be specified.

1234567890123456789012345678901234567890123456789012345678901234567890

 1 2 3 4 5 6

 

<wait standard-attributes>

 standard-elements
 ( <for expressionLanguage="anyURI"?>duration-expr</for> |
  <until expressionLanguage="anyURI"?>deadline-expr</until> )

</wait>

The <empty> construct allows you to insert a "no-op" instruction into a business process. This is useful for synchronization of concurrent activities, for instance.

1234567890123456789012345678901234567890123456789012345678901234567890

 1 2 3 4 5 6

 

<empty standard-attributes>

 standard-elements

</empty>

New activities can be introduced for use in BPEL by placing them inside of the extensionActivity element. The contents of an extensionActivity element MUST be a single element that MUST make available BPEL's standard-attributes and standard-elements.

1234567890123456789012345678901234567890123456789012345678901234567890

 1 2 3 4 5 6



<extensionActivity>
 <???? standard-attributes>
  standard-elements
 </????>
</extensionActivity>

The <sequence> construct allows you to define a collection of activities to be performed sequentially in lexical order.

1234567890123456789012345678901234567890123456789012345678901234567890

 1 2 3 4 5 6

 

<sequence standard-attributes>

 standard-elements

 activity+

</sequence>

The <if> construct allows you to select exactly one branch of activity from a set of potential choices.

1234567890123456789012345678901234567890123456789012345678901234567890

 1 2 3 4 5 6



<if standard-attributes>

 standard-elements
 <condition expressionLanguage="anyURI"?>
 ... bool-expr ... 
 </condition>
 <then>

 activity
 </then>
 <elseif>*
 <condition expressionLanguage="anyURI"?>
 ... bool-expr ... 
 </condition>

 activity
 </elseif>
 <else>?
 activity

 </else>

</if>
 

The <while> construct allows you to indicate that an activity is to be repeated as long as a certain success criteria is met.

1234567890123456789012345678901234567890123456789012345678901234567890

 1 2 3 4 5 6

 

<while standard-attributes>
 standard-elements
 <condition expressionLanguage="anyURI"?>
 ... bool-expr ... 
 </condition>

 

 activity

</while>

The <repeatUntil> constructs allows you to indicate the repeated performance of a specified iterative activity. The iterative activity will continue to be performed so long as after it executes the given Boolean <repeatUntil> condition holds true.

1234567890123456789012345678901234567890123456789012345678901234567890

 1 2 3 4 5 6

 

<repeatUntil standard-attributes>
 standard-elements
 activity
 <condition expressionLanguage="anyURI"?>
 ... bool-expr ...
 </condition>
</repeatUntil>

The <forEach> construct is an iterator that will repeat its contained 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 will occur in parallel. In essence an implicit flow is dynamically created with N+1 copies of the foreach's scope activity as children. If <completionCondition> is specified within the <forEach> construct, the forEach activity MAY be completed without executing or finishing all the branches specified. The details of the early completion condition is specified within the <branches> construct.

1234567890123456789012345678901234567890123456789012345678901234567890

 1 2 3 4 5 6



<forEach counterName="ncname" parallel="yes|no" standard-attributes>
 standard-elements

 <iterator> 
 <startCounterValue expressionLanguage="anyURI">
 ...
 </startCounterValue>
 <finalCounterValue expressionLanguage="anyURI">
 ...
 </finalCounterValue>

 </iterator> 

 <completionCondition>
 <branches expressionLanguage="URI"?
 countCompletedBranchesOnly="yes|no"?>
 an-integer-expression
 </branches>
 </completionCondition>?
 scope-activity
</foreach>

The <pick> construct allows you to block and wait for a suitable message to arrive or for a time-out alarm to go off. When one of these triggers occurs, the associated activity is performed and the pick completes.

1234567890123456789012345678901234567890123456789012345678901234567890

 1 2 3 4 5 6

 

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

 standard-elements

 <onMessage partnerLink="ncname" portType="qname"?

 operation="ncname" variable="ncname"? 

 messageExchange="ncname"? >+

 <correlations>?

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

 </correlations>
 <fromPart part="ncname" toVariable="ncname"/>*

 activity

 </onMessage>

 <onAlarm>*
  ( <for expressionLanguage="anyURI"?>duration-expr</for> |
  <until expressionLanguage="anyURI"?>deadline-expr</until> )


 activity

 </onAlarm>

</pick>

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 (See also partnerLink description in the next section). The optional messageExchange attribute is used to associate a <reply> activity with a <onMessage> activity. (For details of messageExchange, please see “Providing Web Service Operations” section).

The <flow> construct allows you to specify one or more activities to be performed concurrently. Links can be used within concurrent activities to define arbitrary control structures.

1234567890123456789012345678901234567890123456789012345678901234567890

 1 2 3 4 5 6

 

<flow standard-attributes>

 standard-elements

 <links>?

 <link name="ncname">+

 </links>

 activity+

</flow>

The <scope> construct allows you to define a nested activity with its own associated variables, fault handlers, and compensation handler.

1234567890123456789012345678901234567890123456789012345678901234567890

 1 2 3 4 5 6

 

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

  standard-attributes>

 standard-elements
 <partnerLinks>?
  ... see above under <process> for syntax ...

 </partnerLinks>

 <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>?

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

 </compensationHandler>

 <terminationHandler>?

  ...

 </terminationHandler>

 <eventHandlers>?

  ...

 </eventHandlers>

 activity

</scope>
1234567890123456789012345678901234567890123456789012345678901234567890

 1 2 3  4 5 6

 

The <compensate> construct is used to invoke compensation on an inner scope that has already completed normally. This construct can be invoked only from within a fault handler or another compensation handler.

1234567890123456789012345678901234567890123456789012345678901234567890

 1 2 3 4 5 6

 

<compensate scope="ncname"? standard-attributes>

 standard-elements

</compensate>

The <exit> activity can be used to immediately terminate the behavior of a business process instance within which the <exit> activity is performed. All currently running activities MUST be terminated as soon as possible without any termination handling, fault handling, or compensation behavior.

1234567890123456789012345678901234567890123456789012345678901234567890

 1 2 3 4 5 6

 

<exit standard-attributes>

 standard-elements

</exit>

Note that the "standard-attributes" referred to above are:

1234567890123456789012345678901234567890123456789012345678901234567890

 1 2 3 4 5 6

 

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.

and that the "standard-elements" referred to above are:

1234567890123456789012345678901234567890123456789012345678901234567890

 1 2 3 4 5 6

<targets>?
 <joinCondition expressionLanguage="anyURI"?>?
 ... bool-expr ... 
 </joinCondition> 

 <target linkName="ncname" />+
</targets>
<sources>?

 <source linkName="ncname">+
 <transitionCondition expressionLanguage="anyURI"?>?
 ... bool-expr ... 
 </transitionCondition>
 </source>
</sources>

65.3. Language Extensibility

WS-BPEL contains constructs that are generally sufficient for expressing abstract and executable business processes. In some cases, however, it might be necessary to “extend” the WS-BPEL language with additional constructs from other XML namespaces.

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.

If, during the processing of a WS-BPEL process an element or an attribute of non-WS-BPEL namespace is encountered that is not recognized by the processor then the element and its children MUST be treated as if they were not present in the WS-BPEL process definition. The previously defined ignore semantics make it possible to add optional attributes or elements to WS-BPEL that can be safely ignored if not recognized. In the case of unsupported mandatory extensions (see section 13.7 “Extension Declarations”) the previous logic is unnecessary as the entire process definition will be rejected.

Extensions MUST NOT contradict the semantics of any element or attribute defined by the WS-BPEL specification. Extensions that affect the semantics of WS-BPEL processes MUST appear in the WS-BPEL process definition or its directly referenced WSDL portTypes, property alias definitions or property definitions.

Apart from core WS-BPEL process constructs, extensions are also allowed in WSDL-based WS-BPEL constructs, such as, <partnerLinkType>, <role>, <property> and <propertyAlias>. The same syntax pattern and semantic rules for extensions of core BPEL constructs are applied to these extensions as well. Particularly, <extension> directives of a WS-BPEL process are applied to all extensions used in WSDL-based WS-BPEL constructs, of which the WSDL definitions are transitively referenced by the process.

The optional <documentation> construct, an integral part of Language Extensibility, is applicable to any WS-BPEL Extensible construct. The content of <documentation> are for human-consumption. 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 Language Extensibility mechanism.

65.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.

The <import> element is used within a WS-BPEL process to explicitly indicate a dependency on external XML Schema or WSDL definitions. Any number of <import> elements may appear as initial children of the <process> element, before any other child element. Each <import> element contains a 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.

· “location”. The location attribute contains a URI indicating the location of a document that contains relevant definitions in the namespace specified. 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 document located at the location URI MUST identify the definitions it contains with a URI matching the URI indicated by the namespace attribute. The location attribute is a hint and that the BPEL Processor is not required to retrieve the document being imported from the specified location.

· “importType”. The importType attribute identifies the type of document being imported by providing an absolute URI that identifies the encoding language used in the document. 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. Note: 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.

A BPEL process definition MUST import all XML Schema and WSDL definitions it uses. This includes all XML Schema type and element definitions, all WSLD port types and message types as well as property and property alias definitions used by the process. In order to support the use of definitions from namespaces spanning multiple documents, a BPEL process MAY include more than one import declarations for the same namespace and importType, provided that those declarations include different location values. Import elements are conceptually unordered. It is an error 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 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 BPEL processor. In particular, this means that if an external item is used by a 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 the lack of transitivity of imports.

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

65.5 The Lifecycle of a Business Process

As noted in the introduction, the interaction model that is directly supported by WSDL is essentially a stateless client-server model of synchronous or uncorrelated asynchronous 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 Providing Web Service Operations and Pick).

To be instantiated, each business process must contain at least one such "start activity." That is, a receive/pick activity annotated with a createInstance="yes" attribute. See section 11.4 for more details on start activities.

If more than one start activity is enabled concurrently, then all such activities MUST share at least one common correlation set (see Correlation and the Multiple Start Activities example).

If a process contains exactly one start activity then the use of

correlation sets is unconstrained. This includes a pick with multiple onMessage branches; each such branch can use different correlation sets or no correlation sets.

A business process instance is terminated in one of the following ways:

· When the activity that defines the behavior of the process as a whole completes. In this case the termination is normal.

· When a fault reaches the process scope, and is either handled or not handled. In this case the termination is considered abnormal even if the fault is handled and the fault handler does not rethrow any fault. A compensation handler is never installed for a scope that terminates abnormally.

· When a process instance is explicitly terminated by an exit activity (see Terminating the Service Instance). In this case the termination is abnormal.

The structure of the main processing section 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).

A receive activity for an inbound request/response operation is said to be open if that activity has been performed and no corresponding reply activity has been performed. If the process instance reaches the end of its behavior, and one or more receive activities remain open, then the status of the instance becomes undefined. This condition indicates a modeling error that was not detected by static analysis.

The example makes the implicit assumption that the customer request can be processed in a reasonable amount of time, justifying the requirement that the invoker wait for a synchronous response (because this service is offered as a request-response operation). When that assumption does not hold, the interaction with the customer is better modeled as a pair of asynchronous message exchanges. In that case, the "sendPurchaseOrder" operation is a one-way operation and the asynchronous response is sent by invoking a second one-way operation on a customer "callback" interface. In addition to changing the signature of "sendPurchaseOrder" and defining a new portType to represent the customer callback interface, two modifications need to be made in the preceding example to support an asynchronous response to the customer. First, the partner link type "purchasingLT" that represents the process-customer connection needs to include a second role ("customer") listing the customer callback portType. Second, the <reply> activity in the process needs to be replaced by an <invoke> on the customer callback operation.

The processing taking place inside the <flow> element consists of three <sequence> blocks running concurrently. 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 links 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").

Observe that information is passed between the different activities in an implicit way through the sharing of globally visible data variables. In this example, the control dependencies represented by links are related to corresponding data dependencies, in one case on the availability of the shipper rates and in another on the availability of a shipping schedule. The information is passed from the activity that generates it to the activity that uses it by means of two global data variables ("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 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.

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

A very important, if not the most important, use case for WS-BPEL will be in describing cross-enterprise business interactions in which the business processes of each enterprise interact through Web Service interfaces with the processes of other enterprises. An important requirement for realistic modeling of business processing in this environment is the ability to model the required relationship with a partner process. 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 asynchronous messaging rather than on remote procedure calls. The notion of Partner links is used to directly model peer-to-peer conversational partner relationships. Partner links define the shape of a relationship with a partner by defining the message and port types 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 (“bpws:service-ref”), to represent the dynamic data required to describe a partner service endpoint.

It is important to emphasize that the notions of partner link and endpoint reference used here are preliminary. The specification for these concepts as they relate to Web Services is still evolving, and we expect normative definitions for them to emerge in future. The WS-BPEL specification will be updated to conform to the expected future standards.

76.1. Partner Link Types

A partner link type 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. The following example illustrates the basic syntax of a partner link type declaration:

1234567890123456789012345678901234567890123456789012345678901234567890

 1 2 3 4 5 6

 

<partnerLinkType name="BuyerSellerLink"

 xmlns="http://schemas.xmlsoap.org/ws/2004/03/partner-link/">

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

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

</partnerLinkType>

Each role specifies exactly one WSDL portType.

In the common case, portTypes of the two roles originate from separate namespaces. However, in some cases, both roles of a partner link type can be defined in terms of portTypes from the same namespace. The latter situation occurs for partner link types that define "callback" relationships between services.

The partner link type definition can be a separate artifact independent of either service's WSDL document. Alternatively, the partner link type definition can be placed within the WSDL document defining the portTypes from which the different roles are defined.

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 in all cases. This allows reuse of the WSDL target namespace specification and, more importantly, its import mechanism to import portTypes. For cases where a partnerLinkType declaration is linking the portTypes of two different services, the partnerLinkType declaration can be placed in a separate WSDL document (with its own targetNamespace).

The syntax for defining a partnerLinkType is:

1234567890123456789012345678901234567890123456789012345678901234567890

 1 2 3 4 5 6

 

<definitions name="ncname" targetNamespace="uri"

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

 ...

 <plnk:partnerLinkType name="ncname">

 <plnk:role name="ncname" portType="qname"/>

 <plnk:role name="ncname" portType="qname"/>?



 </plnk:partnerLinkType>

 ...

</definitions>

This defines a partner link type in the namespace indicated by the value of the "targetNamespace" attribute of the WSDL document element. The portTypes identified within roles are referenced by using QNames as for all top-level WSDL definitions.

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

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

76.2. Partner Links

The services with which a business process interacts are modeled as partner links in WS-BPEL. Each partner link is characterized by a partnerLinkType. More than one partner link 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.

1234567890123456789012345678901234567890123456789012345678901234567890

 1  2 3 4 5 6

 

<partnerLinks>

 <partnerLink name="ncname" partnerLinkType="qname"

 myRole="ncname"? partnerRole="ncname"?
 initializePartnerRole="yes|no"?>+

 </partnerLink>

</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 partnerLinks for simultaneous requests of the same kind (see Invoking Web Service Operations and Providing Web Service Operations).

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. In the degenerate case where a partnerLinkType has only one role, one of these attributes is omitted as appropriate.

Note that the partnerLink declarations specify the shape of the relationships that the WS-BPEL process will employ in its behavior. Before operations on a partner's service can be invoked via a partnerLink, the binding and communication data for the partner service must be available. The relevant information about a partner service can be set as part of business process deployment. This is outside the scope of WS-BPEL. However, it is also possible to select and assign actual partner services dynamically, and WS-BPEL provides the mechanisms to do so via assignment of endpoint references. In fact, because the partners are likely to be stateful, the service endpoint information needs to be extended with instance-specific information. WS-BPEL allows the endpoint references implicitly present in partnerLinks to be both extracted and assigned dynamically, and also to be set more than once. See Assignment for the mechanisms used for dynamic assignment of endpoint references to partner services.

The initializePartnerRole attribute specifies if the BPEL processor is required to initialize a partnerLink's partnerRole value. The attribute has no affect on the partnerRole's value after its initialization. The initializePartnerRole attribute MUST NOT be used on a partnerLink that does not have a partner role; this restriction MUST be statically enforced. If the initializePartnerRole attribute is set to "yes" then the BPEL processor MUST initialize the EPR for the specified partnerLink/partnerRole combination before that partnerRole is first referenced by the BPEL process. If the initializePartnerRole attribute is set to "no" then the BPEL processor MUST NOT initialize the EPR for the specified partnerLink/partnerRole combination before that partnerRole is first referenced by the BPEL process. If the initializePartnerRole attribute is omitted then its value MUST be treated as "no".

A partnerLink can be declared within a process or scope element. The name of a partnerLink should be unique amongst the names of all partnerLinks defined within the same immediately enclosing scope. This requirement MUST be statically enforced.. Access to partnerLink follows common lexical scoping rules, similar to the rules for variables. A partnerLink resolves to the nearest enclosing scope, regardless of the type of the partnerLink. If a local partnerLink declared in an enclosing scope, the local partnerLink will be used in local assignments and message sending/receiving activities. The lifecyle of a partnerLink is 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 whether it is declared on the process or scope element level.

76.34. Endpoint References

WSDL makes an important distinction between portTypes and ports. PortTypes 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 portTypes, 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.

Every partner role in a partnerLink in a WS-BPEL process instance is assigned a unique endpoint reference in the course of the deployment of the process or dynamically by an activity within the process.

Endpoint references associated with parterRole and myRole of partnerLinks are manifested as service reference containers (“bpws:service-ref”). This container is used as envelope to wrap around the actual endpoint reference value, when a WS-BPEL process interacts the endpoint reference of a partnerLink. It provides pluggability of different versions of service endpoint referencing schemes being used within a BPEL program. The design pattern here is similar to those of expression language, also known as open-content models.

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

Most likely, the URI of reference scheme and the namespace URI of the child element of bpws:service-ref are not necessarily the same. Typically, this optional attribute is used ONLY when the child element of the “bpws:service-ref” is ambiguous by itself. The optional attribute supplies further information to disambiguate the usage of the content. One example would be: different treatments of wsdl:service element, if wsdl:service is used as the endpoint reference.

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

If the attribute is specified, use the URI as the reference scheme of service endpoint and treat the content element within the wrapper accordingly. When the "reference-scheme" attribute is specified, the URI value is most likely different from the namespace URI of the content element for EPR.

When the BPEL container fails to interpret the combination of the "reference-scheme" attribute and the content element OR just the content element alone, a standard fault "bpws:unsupportedReference" must be thrown.

When WS-BPEL users interact and manipulate endpoint references of partnerLinks, The “bpws:service-ref” element are NOT exposed to WS-BPEL users in all cases. For example, when people try to do an assignment from the endpoint reference of myRole of partnerLink-A to that of partnerRole of partner-B. On the contrary, if people try to do assignment from a messageType or element based variable through expression or from a service-ref -form of from-spec, the “bpws:service-ref” is visible to WS-BPEL users.

78. Variable Properties

78.1. Motivation

78.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 correlation sets (see Correlation). 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 business protocols and abstract business processes.

87.1.2 Motivation for Variable Properties

Message properties are an instance of a more generic mechanism, variable properties. All variables in BPEL can have properties defined on them. Properties are useful on non-message variables as a way to isolate the BPEL process’s logic from the details of a particular variable’s definition. Using properties a 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 bulk of the BPEL process definition that manipulates that variable can remain unchanged.

87.2. Defining Properties

A property definition creates a globally unique name and associates it with an XML Schema type. The intent is not to create a new type. The intent is to create a name that has greater significance than the type itself. For example, a sequence number can be an integer, but the integer type does not convey this significance, whereas a globally named sequence-number property does. Properties can occur anywhere in a variable.

A typical use for a property in WS-BPEL is to name a token for correlation of service instances with messages. For performance reasons, properties used for correlation MUST be defined using XML Schema simple types, this restriction MUST be statically enforced. 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 global name is given to this use of the type by defining a property, as in the following example:

1234567890123456789012345678901234567890123456789012345678901234567890

 1  2 3 4 5 6

 

<definitions name="properties"

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

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

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

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

 

 <! -- import schema taxTypes.xsd -- >
 <!-- define a correlation property -->

 <bpws:property name="taxpayerNumber"

 type="txtyp:SSN"/>

 ...

</wsdl:definitions>

In correlation, the property name must have global 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 global and public significance. It is likely that they will be mapped to multiple messages, and therefore they need to be globally named as in the case of correlation properties. Such properties are essential, especially in abstract processes.

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 the property is available on 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 so that the target namespace and other useful aspects of WSDL are available.

The WS-BPEL standard namespace, "http//schemas.xmlsoap.org/ws/2004/03/business-process/", is used for property definitions. The syntax for a property definition is a new kind of WSDL definition as follows:

1234567890123456789012345678901234567890123456789012345678901234567890

 1 2 3 4 5 6

 

<wsdl:definitions name="ncname">

 <bpws:property name="ncname" type="qname"? element="qname"?/>

 ...

</wsdl:definitions>

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. The notion of aliasing is introduced to map a global property to a field in a specific message part or a value in a XML variable. The property name becomes an alias for the message part and location or XML variable value, and can be used as such in Expressions and Assignment in abstract business processes. As an example, consider the following WSDL message definition:

1234567890123456789012345678901234567890123456789012345678901234567890

 1 2 3 4 5 6



<definitions name="messages"

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

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

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




 <!-- define a WSDL application message -->
 <message name="taxpayerInfo">
  <part name="identification" element="txtyp:socialsecnumber"/>
 </message>
 ...
</definitions>

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

1234567890123456789012345678901234567890123456789012345678901234567890

 1 2 3 4 5 6



<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"

 

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

 

 <!-- define a correlation property -->

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

 ...

 <bpws:propertyAlias propertyName="tns:taxpayerNumber"

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

 <query>
 /txtyp:socialsecnumber
 </query>

 </bpws:propertyAlias>

</definitions>

The bpws:propertyAlias defines a globally named property tns:taxpayerNumber as an alias for a location in the identification part of the message type txmsg:taxpayerInfo.

The syntax for a propertyAlias definition is:

1234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6

<definitions name="ncname"
...
>

<bpws:propertyAlias propertyName="qname"
messageType="qname"? part="ncname"?

 type="qname"? element="qname"?>
  <query queryLanguage="anyURI"?>?
  ... queryString ...
  </query>
 </bpws:propertyAlias>

 ...

</wsdl:definitions>

The interpretation of the message and part attributes, as well as the <query> element is the same as in the corresponding from-spec in copy assignments (see Assignment).

78.3 Defining Property Aliases

Properties used in business protocols are typically embedded in application-visible variables. The notion of aliasing is introduced to map a global 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 Assignment in abstract business processes. As an example, consider the following WSDL message definition:

<definitions name="messages"

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

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

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

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

<message name="taxpayerInfoMsg">
<part name="identification" element="txtyp:taxPayerInfoElem"/>

</message>
...

</definitions>

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

<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"

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

<!-- define a correlation property -->
<bpws:property name="taxpayerNumber" type="txtyp:SSN"/>
...
<bpws:propertyAlias propertyName="tns:taxpayerNumber" messageType="txmsg:taxpayerInfoMsg" part="identification">

<query>
txtyp:socialsecnumber
</query>

</bpws:propertyAlias>

<bpws:propertyAlias propertyName="tns:taxpayerNumber"

element="txtyp:taxPayerInfoElem">

<query>
txtyp:socialsecnumber
</query>

</bpws:propertyAlias>

</definitions>

The first bpws:propertyAlias defines a globally named property tns:taxpayerNumber as an alias for a location in the identification part of the message type txmsg:taxpayerInfo.

The second bpws:propertyAlias provides a second definition for the same globally 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 propertyAlias definition is:

<definitions name="ncname"

... >

<bpws:propertyAlias propertyName="qname"

messageType="qname"? part="ncname"?

type="qname"? element="qname"?>

<query queryLanguage="anyURI"?>?

... queryString ...

</query>

</bpws:propertyAlias>

...

</wsdl:definitions>

A property alias element MUST use one of the three following combinations of attributes:

· messageType and part,

· type or

· element.

When a propertyAlias is used with the messageType/part combination then the property MUST be available on all BPEL variables where the qname value used in the messageType attribute on the declaration of both the variable and the propertyAlias are identical. The part attribute and query element is applied against the 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.

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

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

and

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

have the same output. Please see Assignment for details.

If a propertyAlias is used with a type attribute then the property MUST be available on all BPEL variables where the qname value used in the type attribute on the declaration of both the variable and the propertyAlias are identical. The query is applied against the 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 BPEL variables defined using a type.

If a propertyAlias is used with an element attribute then the property MUST be available on all BPEL variables where the qname value used in the element attribute on the declaration of both the variable and the propertyAlias are identical. The query is applied against the 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 BPEL variables defined using an element definition.

A BPEL process MUST NOT be accepted for processing if it defines two or more propertyAlias’s for the same property name and BPEL variable type. For example, it is not legal to define two propertyAlias’s for the property taxpayernumber and the messageType txmsg:taxpayerInfoMsg. The same logic would prohibit having two propertyAliases on the same element qname and property name value or two propertyAliases on the same type qname and property name value.

89. Data Handling

Business processes model stateful interactions. The state involved consists of messages received and sent as well as other relevant data such as time-out values. The maintenance of the state of a business process requires the use of state variables, which are called variables in WS-BPEL. 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 provides for the incorporation of future standards.

Executable processes are permitted to use the full power of data selection and assignment but are not permitted to use opaque values. Abstract processes, on the other hand, are permitted to hide behavior. Detailed differences are specified in the following sections.

9.3. Expressions

(Editor note: re-arranging the order of this section later for ease of tracking for this version)

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

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

·Deadline-valued expressions ("until" expression of onAlarm and wait)

·Duration-valued expressions ("for" expression of onAlarm and wait, "repeatEvery" expression of onAlarm)

·General expressions (assignment)

WS-BPEL provides an extensible mechanism for the language used in these expressions. The language is specified by the expressionLanguage attribute of the process element. In addition, language constructs that require or allow conditional expressions (such as “if”, “while” and others) provide the ability to override the default expression language for individual expressions. Compliant implementations of the current version of WS-BPEL MUST support the use of XPath 1.0 as the expression language. XPath 1.0 is indicated by the default value of the expressionLanguage attribute, 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. The URI of the corresponding XPath 1.0 specification is:

http://www.w3.org/TR/1999/REC-xpath-19991116

Given an expression language, it must be possible to query data from variables, to extract property values, and to query the status of links from within expressions. This specification defines those functions for XPath 1.0 only, and it is expected that other expressionlanguage bindings will provide equivalent functionality. The rest of this section is specific to XPath 1.0.

WS-BPEL introduces several extension functions to XPath's built-in functions to enable XPath 1.0 expressions to access information from the process. The extensions are defined in the standard WS-BPEL namespace http://schemas.xmlsoap.org/ws/2004/03/businessprocess/. The prefix "bpws:" is associated with this namespace.

Any qualified names used within XPath expressions are resolved by using namespace declarations currently in scope in the WS-BPEL document at the location of the expression.

The arguments to all XPath functions defined in this specification MUST be given as quoted strings. The previous requirement MUST be statically enforced. It is therefore illegal to pass into a 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 getVariableProperty("varA","propB") meets the previous requirement while getVariableProperty( $varA, string(getVariableProperty("varB","propB") ) does not. Note that the previous requirement institutes a restriction which does not exist in the XPath standard.

The following functions are defined by this specification:

bpws:getVariableProperty ('variableName', 'propertyName')

This function extracts global property values from variables. The first argument names the source variable for the data and the second is the qualified name (QName) of the global property to select from that variable (see Variable Properties). If the referenced property is not defined or if there does not exist a propertyAlias to associate the property with the referenced variable then the semantics of the process is undefined. The return value of this function is calculated by applying the appropriate propertyAlias for the requested property to the current value of the submitted variable. If the application of the XPATH in the propertyAlias to the variable value results in a response that contains anything other than exactly one information item and/or a collection of Character information items then a bpws:selectionFailure fault MUST be thrown.
These WS-BPEL-defined extension functions are available for use within all XPath 1.0 expressions.

The syntax of XPath 1.0 expressions for WS-BPEL is considered in the following paragraphs.

9.3.1. Boolean Expressions

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

9.3.2. Deadline-Valued 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.

9.3.3. Duration-Valued 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 XML Schema unawareness applies here as well.

9.3.4. 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).

If the execution of an expression results in an unhandled expression language execution fault, then the WS-BPEL standard fault bpws:subLanguageExecutionFault MUST be thrown.

89.1. Variables

(Editor note: re-arranging the order of this section later for ease of tracking for this version)

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.

Variables provide the means for holding messages that constitute 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.

The type of each variable may be a WSDL message type, an XML Schema type (simple or complex) or an XML Schema element. The syntax of the variables declaration is:

<variables>

 <variable name="ncname" messageType="qname"?

 type=”qname”? element=”qname”?/>+
 from-spec?

</variables>

The name of a variable MUST be unique amongst the names of all variables defined within the same immediately enclosing scope. This requirement MUST be statically enforced.. 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 variable names in 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. Variable access follows common lexical scoping rules. A variable resolves to the nearest enclosing scope, regardless of the type of the variable. 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 getVariableProperty functions.

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 BPEL element variable consists of a document information item (DII) that contains exactly one child, an element information item (EII) which is pointed at by the document element property. The EII is the value of the element variable.

If a BPEL implementation chooses to manifest a simpleType variable as an XML infoset, the infoset should consist of a DII that contains exactly one child, an EII which is pointed at by the document element property. The properties of the document element, specifically the namespace name and local name properties, are undefined by this specification, as such an implementation MUST specify whatever namespace name/local name values it likes. However the children of the document element MUST exclusively consist of a series of character information items (CharIIs) that represent the simpleType value.A BPEL implementation MAY choose to map simpleType variables to non-XML-infoset data-models defined in the expression/query language being used. (e.g. Boolean in XPath 1.0)

A variable can optionally be initialized by using an in-line from-spec. From-spec is defined in section 9.8.3. 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 assigns then 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. The previous discussion of virtual sequences and assigns is only meant for modeling purposes. The description is strictly intended to describe initialization behavior in terms of previously understood concepts but there is no intention that the behavior be seen as actually implying that any of the 'virtual' sequences or assigns exist as anything other than a model of the expected behavior.

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

The infoset for a complexType variable consists of a document information item that contains exactly one child, an element information item which is pointed at by the document element property. The properties of the document element, specifically the namespace name and local name properties, are undefined by this specification, as such an implementation MUST specify whatever legal property values it likes. However the children of the document element MUST exclusively consist of the complexType values assigned to the variable. In order to simplify data access, WSDL parts of WSDL message variables are manifested in BPEL as infosets, one infoset per WSDL message part. BPEL engines MUST follow 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 as specified below.

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 2.0 engine and are not specified by this document. The handling of this EII is similar to how WS-BPEL 2.0 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 2.0 submits and retrieves XML variable values using infoset definitions. But these models are not intended to require that WS-BPEL 2.0 implementations actually implement an infoset model, only that however variable binding is handled the end result duplicates the behaviors defined using the infoset model. For example, a WS-BPEL 2.0 implementation may choose to bind a simple type BPEL variable of type xs: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. E.g. if a xs:string variable is manifested as a string object, a xs:string message part MUST be manifested as a string object also. For detailed definition of manifestation of BPEL variables in XPath 1.0, please see “Binding BPEL Variables In XPath 1.0” section.

In summary, a 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 complexType variable or a WSDL message part

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

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"/>

Variables associated with message types can be specified as input or output variables for invoke, receive, and reply activities (see Invoking Web Service Operations and Providing Web Service Operations). When an invoke operation returns a fault message, this causes a fault in the current scope. The fault variable in the corresponding fault handler is initialized with the fault message received (see Scopes and Fault Handlers).

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 it belongs to. Thus, global variables are visible throughout the process. It is possible to "hide" a variable 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.

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 receiving 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 use 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 bpws:uninitializedVariable fault.

Values stored in variables can be mutated during the course of process execution. The validate activity can be used explicitly 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, listings the variables to validate. The attribute accepts one or more variable names (NCNames), separated by whitespaces. The variables attribute points to the variables being validated. The syntax of the validate activity is:

<validate variables="ncnames-list" standard-attributes>

 standard-elements

</validate>

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

A BPEL implementation MAY provide a mechanism to turn on/off any explicit validation. E.g. validate activity.

An BPEL implementation MAY provide a configurable mechanism to enable or disable schema validation of incoming and outgoing messages during the execution of Web Service related activities, e.g., receive, reply, pick, onEvent and invoke activities. The details of configuration mechanism is out of the scope of this specification.

98.2 Usage of Query and Expression Languages

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

98.2.1 Enclosing Elements

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

Definition of an Enclosing Element of a Query or Expression language: Whenever a query or expression language is used in BPEL (e.g. XPath 1.0), the Enclosing Element is defined as the parent element in the BPEL process definition that contains the Query or Expression. For example, in the following from specification example:

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

The "from" element is the Enclosing Element.

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, fault handlers, compensation handlers, etc. that are visible to a Query/Expression language are defined based on the visibility of those entities to the activity that the enclosing element is contained within. There is no requirement that a Query/Expression language must manifest all the different objects previously described, only that if such objects are accessible within the Query/Expression language then only the objects in scope to the enclosing element’s enclosing activity SHOULD be visible from within the Query/Expression language.

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

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

(2) a collection of XML infoset items e.g. $myFooVar/lines

(3) a sequence of Character Information Items 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. boolean)

(4) a variable reference: e.g. <from>$myFooVar</from> <to>$myBarVar</to>

98.2.2 Binding BPEL Variables In XPath 1.0

With the exception of Link expressions whose variable access syntax and semantics are described in section 9.8.2.4, BPEL variables are accessible in XPath expressions in BPEL processes via XPath 1.0 variable bindings. Specifically, all BPEL variables visible from the enclosing element of an XPath 1.0 expression MUST be made available to the XPath 1.0 processor by manifesting the BPEL variable as an XPath variable binding whose name is the same as the BPEL variable's name, except the case of WSDL message variables declared with a messageType, which requires some special handling (discussed below).

BPEL variables declared using an element are 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 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="xs:string" form="qualified" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

And given the following variable declaration:

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

Then a 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 StatusMessage's child statusDescription it is only necessary to specify the child's element name.

BPEL variables declared using a complex type are manifested as a node-set XPath variable with one member node that contains the anonymous document element that itself contains the actual value of the BPEL complex type variable. The XPath variable binding will bind to the document element. For example, given the following schema definition:

<xs:complexType name="AuctionResults">

<xs:sequence>

<xs:element name="AuctionResult" maxOccurs="unbounded" form="qualified">

<xs:complexType>

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

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

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

And given the following variable declaration:

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

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

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

$AunctionResults 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 2.0 messageType variables are manifested in XPath 1.0 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 local name of the part. The data in a 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 XPath 1.0 binding that had "myMessageTypeVar" in scope would manifest two XPath 1.0 variables, $myMessageTypeVar.msgPart1 and $myMessageTypeVar.msgPart2. Please note that section 2.3 of [WSDL 1.1] requires that all part names within the same WSDL message definition must be unique.

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 2.0 variables.

Below is a full example of how a WSDL message type is manifested in WS-BPEL 2.0 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 BPEL XPath expression to access the second part’s statusDescription element would look like:

$StatusVariable.StatusPart2/e:statusDescription

Note: It is possible to write XPath 1.0 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:amount

BPEL simpleType variables are manifested directly as either an XPath string, Boolean or float object. If the XML schema type of the BPEL simpleType variable is xs:Boolean or any types that are restrictions of xs:Boolean then the BPEL variable will be manifested as an XPath Boolean object. If the XML schema type of the BPEL simpleType variable is xs:float, xs:int, xs:unsignedInt or any restrictions of those types then the BPEL variable will be manifested as an XPath float object. Any other XML schema types will be manifested as an XPath string object.

XPath 1.0 only has a single numeric object, float. Float is a 64 bit IEEE floating point number. However the resolution of the float object is not sufficient to capture the full value of some XML Schema data types. For example, a XSD decimal number must support at least 18 digits where as an XPath float only has to support approximately 16 digits. XSD numeric values that cannot be expressed without loss of accuracy as XPath float objects are instead translated into XPath string objects. XPath string objects can be explicitly translated into XPath float objects using the XPath number() function. Similarly if an XPath string object is used in a situation that calls for an XPath float object the XPath processor will automatically translate the XPath string object to an XPath float object. But implementers should be aware that if the accuracy of the XML schema type is greater than supported by the XPath float object then accuracy will be lost during the translation from string object to float object.

98.2.3 XPath 1.0 perspective and WS-BPEL

Section 1 of 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 BPEL for different types of BPEL expression and query language contexts.

98.2.4 Default use of XPath 1.0 for Expression and Query Languages

When XPath 1.0 is used for a Query or Expression Language, except as otherwise specified, 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 BPEL scope rules 

· A function library = core XPath and BPWS function libraries MUST be available and an engine specific function library 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. BPEL variables) are irrelevant. The only prefixes that matter are the in-scope namespaces.

For example, imagine a 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 bpws:selectionFailure fault (in executable BPEL), because it fails to select any node in the context of <copy> operation:

<bpws:from xmlns="http://example.com">$FooVar/bar/text()</bpws: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 BPEL variables to manifest as XPath variable bindings enables BPEL programmers to create powerful XPath expressions involving multiple BPEL variables. For example:

<assign>

   <copy>

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

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

   </copy>

</assign>

When XPath 1.0 is used as an expression or query language in BPEL, with the exception of propertyAlias definitions, 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 or query language (except in the case of propertyAlias which is covered separately). 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 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.

A query language is used when an lvalue needs to be returned. In addition to the previously listed restrictions, which except where otherwise indicated MUST apply to XPaths used as a query language, additional restrictions are also needed to ensure that the returned value of a query language expression is an lvalue. Specifically, when XPath is used as a query language the XPath MUST begin with a "VariableReference" and this restriction MUST be statically enforced.

98.2.5 Use of XPath 1.0 for Expression Languages in Join Conditions

When XPath 1.0 is used as an Expression Language for 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 the target the activity that the Enclosing Element is contained within 

· A function library = the core XPath function library MUST be available, the BPWS function library MUST NOT be available and an engine specific function library MAY be available.

· Namespace declaration = in-scope namespace declarations from Enclosing Element

As explained in section 12.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. Also note that link status is only available in join conditions which is why links are not bound to XPath variables in any other context.

Link status is made available via XPath variable bindings by manifesting links that target the activity that contains 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>

98.2.6 Use of XPath 1.0 for Query Languages in propertyAliases

When XPath 1.0 is used as Query Language for a propertyAlias, the XPath context is initialized as follows:

· Context node =

· When messageType/part attributes are used:

o If the message part is based on a complex type or an element, the context node will point to node-list containing a single node which is the EII for the referenced part where the EII is defined as specified in section 9.8.2.2.

o If the message part is based on a simple type, the context node will point to the XPath object specified for the particular variable type in section 9.8.2.2.

· When type attribute is used:

o If the type is a complex type, the context node will point to node-list containing a single node which is the EII for the referenced part where the EII is defined as specified in section 9.8.2.2.

o If the type is a simple type, the context node will point to the XPath object specified for the particular variable type in section 9.8.2.2.

· When element attribute is used, the context node will point to node-list containing a single node which is the EII for the referenced part where the EII is defined as specified in section 9.8.2.2.

· Context position = 1 ; Context Size = 1

· A set of variable bindings = There MUST NOT be any variable bindings available when XPath is used as query language in propertyAlias

· A function library = The core XPath function library MUST be available, the BPWS function library MUST NOT be available and an engine specific function library MAY be available.

· Namespace declaration = in-scope namespace declarations from Enclosing Element (note that in the past enclosing elements were always themselves enclosed within an activity, that is not the case here since propertyAliases are defined in WSDL files. But since there are no variable bindings to worry about this difference should not matter.)

propertyAlias is unique in BPEL in that it has a defined context node. Therefore none of the previously listed restrictions on the syntax of the XPath expression apply here. Any legal XPath expression may be used. It does not matter if an absolute or relative path is used in a propertyAlias as both will resolve to the context node since the context node in this case is the root node.

For example:

<propertyAlias propertyName="p:poId"
messageType="my:POMsg" part="poPart">
    <query> po/id</query>
</propertyAlias>

Or

<propertyAlias propertyName="p:poId"
messageType="my:POMsg" part="poPart">
    <query>(po/id + 1)</query>
</propertyAlias>

There is no requirement that property aliases return lvalues but it is worth pointing out that an attempt to assig