Web Services Business Process Execution Language Version 2.0
Committee Draft, 17th May, 2006
Document identifier:
wsbpel-specification-draft-01
Location:
http://www.oasis-open.org/apps/org/workgroup/wsbpel/
Editors:
Alexandre Alves, BEA
Assaf Arkin, Intalio
Sid Askary
Ben Bloch
Francisco Curbera,
IBM
Yaron Goland, BEA
Neelakantan Kartha, Sterling Commerce
Canyang Kevin Liu,
SAP
Dieter König, IBM
Vinkesh Mehta, Deloitte
Satish Thatte, Microsoft
Danny
van der Rijn, TIBCO Software
Prasad Yendluri,
webMethods
Alex Yiu, Oracle
This document defines a language for specifying business process behavior based on Web Services. This language is called Web Services Business Process Execution Language (abbreviated to WS-BPEL in the rest of this document). Processes in WS-BPEL export and import functionality by using Web Service interfaces exclusively.
Business processes can be described in two ways. Executable business processes model actual behavior of a participant in a business interaction. Abstract business processes are partially specified processes that are not intended to be executed. An Abstract Process may hide some of the required concrete operational details. Abstract Processes serve a descriptive role, with more than one possible use case, including observable behavior and process templating. WS-BPEL is meant to be used to model the behavior of both Executable and Abstract Processes.
WS-BPEL provides a language for the specification of Executable and Abstract business processes. By doing so, it extends the Web Services interaction model and enables it to support business transactions. WS-BPEL defines an interoperable integration model that should facilitate the expansion of automated process integration in both the intra-corporate and the business-to-business spaces.
This is a draft version of the WS-BPEL TC specification, updated from the original BPEL4WS 1.1 specification dated May 5, 2003 that was submitted to the WS-BPEL TC.
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 © 2006 OASIS Open, Inc. All Rights Reserved.
Table of Contents
Web Services Business Process Execution Language Version 2.0
Committee Draft, 17th May, 2006
3. Relationship with Other Specifications
4. Static Analysis of a Business Process
5. Defining a Business Process
5.2. The Structure of a Business Process
5.5. The Lifecycle of an Executable Business Process
5.6. Revisiting the Initial Example
6. PartnerLinkTypes, PartnerLinks, and Endpoint References
8.2 Usage of Query and Expression Languages
9.2. Declaring and Using Correlation Sets
10.1. Standard Attributes for All Activities
10.2. Standard Elements for All Activities
10.3. Invoking Web Service Operations
10.4. Providing Web Service Operations
10.5. Updating Variable Contents
10.6. Signaling Internal Faults
10.9. Using Extension Activities
10.10. Immediately Ending a Process
10.11. Propagating Faults in a Fault Handler
12.2. Message Exchange Handling
12.3. Error Handling in Business Processes
13. WS-BPEL Abstract Processes
13.2. Abstract Process Profiles and the Semantics of Abstract Processes
13.3. Abstract Process Profile for Observable Behavior
13.4. Abstract Process Profile for Templates
15.1. Shipping Service: Observable Behavior Profile Abstract Process
15.4. Multiple Start Activities
C. Examples of Replacement Logic
F. Intellectual Property Rights
J. Committee Members (Non-Normative)
1. Introduction
The goal of the Web Services effort is to achieve interoperability between applications by using Web standards. Web Services use a loosely coupled integration model to allow flexible integration of heterogeneous systems in a variety of domains including business-to-consumer, business-to-business and enterprise application integration. The following basic specifications originally defined the Web Services space: SOAP [SOAP 1.1], Web Services Description Language (WSDL) [WSDL 1.1], and Universal Description, Discovery, and Integration (UDDI) [UDDI]. SOAP defines an XML messaging protocol for basic service interoperability. WSDL introduces a common grammar for describing services. UDDI provides the infrastructure required to publish and discover services in a systematic way. Together, these specifications allow applications to find each other and interact following a loosely coupled, platform independent model.
Systems integration requires more than the ability to conduct simple interactions by using standard protocols. The full potential of Web Services as an integration platform will be achieved only when applications and business processes are able to integrate their complex interactions by using a standard process integration model. The interaction model that is directly supported by WSDL is essentially a stateless model of 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. An Abstract Process may be used to describe observable message exchange behavior of each of the parties involved, without revealing their internal implementation. There are two good reasons to separate the public aspects of business process behavior from internal or private aspects. One is that businesses obviously do not want to reveal all their internal decision making and data management to their business partners. The other is that, even where this is not the case, separating public from private process provides the freedom to change private aspects of the process implementation without affecting the observable behavior. Observable behavior must clearly be described in a platform independent manner and captures behavioral aspects that may have cross enterprise business significance.
The following concepts for describing business processes should be considered:
· Business processes include data-dependent behavior. For example, a supply-chain process depends on data such as the number of line items in an order, the total value of an order, or a deliver-by deadline. Defining business intent in these cases requires the use of conditional and time-out constructs.
· The ability to specify exceptional conditions and their consequences, including recovery sequences, is at least as important for business processes as the ability to define the behavior in the "all goes well" case.
· Long-running interactions include multiple, often nested units of work, each with its own data requirements. Business processes frequently require cross partner coordination of the outcome (success or failure) of units of work at various levels of granularity.
The basic concepts of WS-BPEL can be applied in one of two ways, Abstract or Executable.
A WS-BPEL Abstract Process is a partially specified process that is not intended to be executed and that must be explicitly declared as ‘abstract’. Whereas Executable Processes are fully specified and thus can be executed, an Abstract Process may hide some of the required concrete operational details expressed by an Executable artifact.
All the constructs of Executables Processes are made available to Abstract Processes; consequently, Executable and Abstract WS-BPEL Processes share the same expressive power. In addition to the features available in Executable Processes, Abstract Processes provide two mechanisms for hiding operational details: (1) the use of explicit opaque tokens and (2) omission. Although a particular Abstract Process definition might contain complete information that would render it Executable, its Abstract status states that any concrete realizations of it are permitted to perform additional processing steps that are not relevant to the audience to which it has been given.
Abstract Processes serve a descriptive role, with more than one use case. One such use case might be to describe the observable behavior of some or all of the services offered by an Executable Process. Another use case would be to define a process template that embodies domain-specific best practices. Such a process template would capture essential process logic in a manner compatible with a design-time representation, while excluding execution details to be completed when mapping to an Executable Process.
Regardless of the specific use case and purpose, all Abstract Processes share a common syntactic base. They have different requirements for the level of opacity and restrictions on which parts of a process definition may be omitted or hidden. Tailored uses of Abstract Processes have different effects on the consistency constraints and on the semantics of that process. Some of these required constraints are not enforceable by the XML Schema.
A common base specifies the features that define the syntactic universe of Abstract Processes. Given this common base, a usage profile provides the necessary specializations and semantics based on Executable WS-BPEL for a particular use of an Abstract Process.
As mentioned above it is possible to use WS-BPEL to define an Executable Business Process. While a WS-BPEL Abstract Process definition is not required to be fully specified, the language effectively defines a portable execution format for business processes that rely exclusively on Web Service resources and XML data. Moreover, such processes execute and interact with their partners in a consistent way regardless of the supporting platform or programming model used by the implementation of the hosting environment.
The continuity of the basic conceptual model between Abstract and Executable Processes in WS-BPEL makes it possible to export and import the public aspects embodied in Abstract Processes as process or role templates while maintaining the intent and structure of the observable behavior. This applies even where private implementation aspects use platform dependent functionality. This is a key feature for the use of WS-BPEL from the viewpoint of unlocking the potential of Web Services because it allows the development of tools and other technologies that greatly increase the level of automation and thereby lower the cost in establishing cross enterprise automated business processes.
In this specification, the description of Abstract Business Processes is presented after Executable. We clearly differentiate concepts required for Abstract Business Process description from the concepts for Executable in the section "WS-BPEL Abstract Processes".
WS-BPEL defines a model and a grammar for describing the behavior of a business process based on interactions between the process and its partners. The interaction with each partner occurs through Web Service interfaces, and the structure of the relationship at the interface level is encapsulated in what is called a partnerLink. The WS-BPEL process defines how multiple service interactions with these partners are coordinated to achieve a business goal, as well as the state and the logic necessary for this coordination. WS-BPEL also introduces systematic mechanisms for dealing with business exceptions and processing faults. Moreover, WS-BPEL introduces a mechanism to define how individual or composite activities within a unit of work are to be compensated in cases where exceptions occur or a partner requests reversal.
WS-BPEL utilizes several XML specifications: WSDL 1.1, XML Schema 1.0, XPath 1.0 and XSLT 1.0. WSDL messages and XML Schema type definitions provide the data model used by WS-BPEL processes. XPath and XSLT provide support for data manipulation. All external resources and partners are represented as WSDL services. WS-BPEL provides extensibility to accommodate future versions of these standards, specifically the XPath and related standards used in XML computation.
A WS-BPEL process is a reusable definition that can be deployed in different ways and in different scenarios, while maintaining a uniform application-level behavior across all of them. The description of the deployment of a WS-BPEL process is out of scope for this specification.
2. Notational Conventions
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119].
Namespace URIs of the general form "some-URI" represent some application dependent or context dependent URI as defined in [RFC 2396].
This specification uses an informal syntax to describe the XML grammar of the XML fragments that follow:
· The syntax appears as an XML instance, but the values indicate the data types instead of values.
· Grammar in bold has not been introduced earlier in the document, or is of particular interest in an example.
· <-- description --> is a placeholder for elements from some "other" namespace (like ##other in XSD).
· Characters are appended to elements, attributes, and as follows: "?" (0 or 1), "*" (0 or more), "+" (1 or more). The characters "[" and "]" are used to indicate that contained items are to be treated as a group with respect to the "?", "*", or "+" characters.
· Elements and attributes separated by "|" and grouped by "(" and ")" are meant to be syntactic alternatives.
· The XML namespace prefixes (defined below) are used to indicate the namespace of the element being defined.
· The name of user defined extension activity is indicated by anyElementQName.
Examples starting with <?xml contain enough information to conform to this specification; other examples are fragments and require additional information to be specified in order to conform.
The examples and other explanatory material in this document are not fully specified unless otherwise noted. For instance, some examples import WSDL definitions that are not specified in this document.
XSD schemas are provided as a formal definition of grammars [XML Schema Part 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, non-normative and not semantically significant.
· xsi - "http://www.w3.org/2001/XMLSchema-instance"
· xsd - "http://www.w3.org/2001/XMLSchema"
· wsdl - "http://schemas.xmlsoap.org/wsdl/"
· plnk – "urn:oasis:names:tc:wsbpel:2.0:partnerlink"
· bpel – "urn:oasis:names:tc:wsbpel:2.0:process:executable"
· abstract – "urn:oasis:names:tc:wsbpel:2.0:process:abstract"
3. Relationship with Other Specifications
WS-BPEL refers to the following XML-based specifications: WSDL 1.1, XML Schema 1.0, XPath 1.0, XSLT 1.0 and Infoset. All WS-BPEL implementations SHOULD be configurable such that they can participate in Basic Profile 1.1 [WS-I Basic Profile] conforming interactions. A WS-BPEL implementation MAY allow the Basic Profile 1.1 configuration to be disabled, even for scenarios encompassed by the Basic Profile 1.1.
WSDL has the most influence on the WS-BPEL language. The WS-BPEL process model is layered on top of the service model defined by WSDL 1.1. At the core of the WS-BPEL process model is the notion of peer-to-peer interaction between services described in WSDL; both the process and its partners are exposed as WSDL services. A business process defines how to coordinate the interactions between a process instance and its partners. In this sense, a WS-BPEL process definition provides and/or uses one or more WSDL services, and provides the description of the behavior and interactions of a process instance relative to its partners and resources through Web Service interfaces. That is, WS-BPEL is used to describe the message exchanges followed by the business process of a specific role in the interaction.
The definition of a WS-BPEL business process follows the WSDL model of separation between the abstract message contents used by the business process and deployment information (messages and 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. WS-BPEL does not make any assumptions about the WSDL binding. Constraints, ambiguities, provided or missing capabilities of WSDL bindings are out of scope of this specification.
However, the abstract part of WSDL does not define the constraints imposed on the communication patterns supported by the concrete bindings. Therefore a WS-BPEL process may define behavior relative to a partner service that is not supported by all possible bindings, and it may happen that some bindings are invalid for a WS-BPEL process definition.
While WS-BPEL attempts to provide as much compatibility with WSDL 1.1 as possible there are three areas where such compatibility is not feasible.
· Fault naming with its restriction, as discussed later in this document [section link: to be done]
· Overloaded operation names in WSDL portTypes. Regardless of whether the WS-I Basic Profile configuration is enabled, a WS-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.
· portTypes that contain solicit-response or notification operations as defined in the WSDL 1.1 specification. Regardless of whether the WS-I Basic Profile configuration is enabled, a WS-BPEL processor MUST reject a WS-BPEL that refers to such portTypes.
At the time this specification was completed, various Web Service standards work, such as WSDL 2.0 and WS-Addressing, were ongoing and not ready for consideration for WS-BPEL 2.0. Future versions of WS-BPEL may provide support for these standards.
It should be noted that the examples provided in this specification adopt the Schema at location "http://schemas.xmlsoap.org/wsdl/2004-08-24.xsd" for the namespace URI http://schemas.xmlsoap.org/wsdl/ [WSDL 1.1]. This XML Schema incorporates fixes for known errors, and is the XML Schema selected by the WS-I BP 1.1 Errata (October 25, 2005).
4. Static Analysis of a Business Process
WS-BPEL takes it as a general principle that conformant implementations MUST perform basic static analysis listed in Appendix [TBD – xref to Issue 84] to detect and reject process definitions that fail any of those static analysis check. Please note that such analysis might in some cases prevent the use of processes that would not, in fact, create situations with errors, either in specific uses or in any use. For example, a WS-BPEL implementation will reject a process with <invoke> activity referring to an undefined variable, where the <invoke> activity may not be actually reached during execution of the process.
A WS-BPEL implementation MAY perform extra static analysis checking beyond the basic static analysis required by this specification to signal warnings or even reject process definitions. Such an implementation SHOULD be configurable to disable these non-specified static analysis checks.
5. Defining a Business Process
5.1. Initial Example
Before describing the structure of business processes in detail, this section presents a simple example of a WS-BPEL process for handling a purchase order. The aim is to introduce the most basic structures and some of the fundamental concepts of the language.
The operation of the process is very simple, and is represented in Figure 1. Dotted lines represent sequencing. Free grouping of sequences represents concurrent sequences. Solid arrows represent control links used for synchronization across concurrent activities. Note that this is not meant to be a definitive graphical notation for WS-BPEL processes. It is used here informally as an aid to understanding.
On receiving the purchase order from a customer, the process initiates three paths concurrently: calculating the final price for the order, selecting a shipper, and scheduling the production and shipment for the order. While some of the processing can proceed concurrently, there are control and data dependencies between the three paths. In particular, the shipping price is required to finalize the price calculation, and the shipping date is required for the complete fulfillment schedule. When the three concurrent paths are completed, invoice processing can proceed and the invoice is sent to the customer.
Figure 1: Purchase Order Purchase
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 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 partnerLinkTypes 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 PartnerLinkTypes, PartnerLinks, and Endpoint References). PartnerLinkTypes can be used to represent dependencies between services, regardless of whether a WS-BPEL business process is defined for one or more of those services. Each partnerLinkType defines up to two "role" names, and lists the portTypes that each role must support for the interaction to be carried out successfully. In this example, two partnerLinkTypes, "purchasingLT" and "schedulingLT", list a single role because, in the corresponding service interactions, one of the parties provides all the invoked operations: The "purchasingLT" partnerLinkType represents the connection between the process and the requesting customer, where only the purchase order service needs to offers a service operation ("sendPurchaseOrder"); the "schedulingLT" partnerLinkType represents the interaction between the purchase order service and the scheduling service, in which only operations of the latter are invoked. The two other partnerLinkTypes, "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).
<wsdl:definitions targetNamespace="http://manufacturing.org/wsdl/purchase"
xmlns:sns="http://manufacturing.org/xsd/purchase"
xmlns:pos="http://manufacturing.org/wsdl/purchase"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:plnk="http://schemas.xmlsoap.org/ws/2004/03/partner-link/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<wsdl:types> <xsd:schema> <xsd:import namespace="http://manufacturing.org/xsd/purchase"
schemaLocation="http://manufacturing.org/xsd/purchase.xsd"/> </xsd:schema> </wsdl:types>
<wsdl:message name="POMessage">
<wsdl:part name="customerInfo" type="sns:customerInfoType"/>
<wsdl:part name="purchaseOrder" type="sns:purchaseOrderType"/>
</wsdl:message>
<wsdl:message name="InvMessage">
<wsdl:part name="IVC" type="sns:InvoiceType"/>
</wsdl:message>
<wsdl:message name="orderFaultType">
<wsdl:part name="problemInfo" element=”sns:OrderFault"/>
</wsdl:message>
<wsdl:message name="shippingRequestMessage">
<wsdl:part name="customerInfo" element="sns:customerInfo"/>
</wsdl:message>
<wsdl:message name="shippingInfoMessage">
<wsdl:part name="shippingInfo" element="sns:shippingInfo"/>
</wsdl:message>
<wsdl:message name="scheduleMessage">
<wsdl:part name="schedule" element="sns:scheduleInfo"/>
</wsdl:message>
<!-- portTypes supported by the purchase order process -->
<wsdl:portType name="purchaseOrderPT">
<wsdl:operation name="sendPurchaseOrder">
<wsdl:input message="pos:POMessage"/>
<wsdl:output message="pos:InvMessage"/>
<wsdl:fault name="cannotCompleteOrder"
message="pos:orderFaultType"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:portType name="invoiceCallbackPT">
<wsdl:operation name="sendInvoice">
<wsdl:input message="pos:InvMessage"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:portType name="shippingCallbackPT">
<wsdl:operation name="sendSchedule">
<wsdl:input message="pos:scheduleMessage"/>
</wsdl:operation>
</wsdl:portType>
<!-- portType supported by the invoice services -->
<wsdl:portType name="computePricePT">
<wsdl:operation name="initiatePriceCalculation">
<wsdl:input message="pos:POMessage"/>
</wsdl:operation>
<wsdl:operation name="sendShippingPrice">
<wsdl:input message="pos:shippingInfoMessage"/>
</wsdl:operation>
</wsdl:portType>
<!-- portType supported by the shipping service -->
<wsdl:portType name="shippingPT">
<wsdl:operation name="requestShipping">
<wsdl:input message="pos:shippingRequestMessage"/>
<wsdl:output message="pos:shippingInfoMessage"/>
<wsdl:fault name="cannotCompleteOrder"
message="pos:orderFaultType"/>
</wsdl:operation>
</wsdl:portType>
<!-- portType supported by the production scheduling process -->
<wsdl:portType name="schedulingPT">
<wsdl:operation name="requestProductionScheduling">
<wsdl:input message="pos:POMessage"/>
</wsdl:operation>
<wsdl:operation name="sendShipingSchedule">
<wsdl:input message="pos:scheduleMessage"/>
</wsdl:operation>
</wsdl:portType>
<plnk:partnerLinkType name="purchasingLT">
<plnk:role name="purchaseService"
portType="pos:purchaseOrderPT"/>
</plnk:partnerLinkType>
<plnk:partnerLinkType name="invoicingLT">
<plnk:role name="invoiceService"
portType="pos:computePricePT"/>
<plnk:role name="invoiceRequester" portType="pos:invoiceCallbackPT"/>
</plnk:partnerLinkType>
<plnk:partnerLinkType name="shippingLT">
<plnk:role name="shippingService" portType="pos:shippingPT"/>
<plnk:role name="shippingRequester" portType="pos:shippingCallbackPT"/>
</plnk:partnerLinkType>
<plnk:partnerLinkType name="schedulingLT">
<plnk:role name="schedulingService"
portType="pos:schedulingPT"/>
</plnk:partnerLinkType>
</wsdl:definitions>
The business process for the order service is defined next. There are four major sections in this process definition. Note that the example provides a simple case. In order to complete it, additional elements may be needed such as correlationSets.
· The <partnerLinks> section defines the different parties that interact with the business process in the course of processing the order. The four partnerLinks shown here correspond to the sender of the order (customer), as well as the providers of price (invoicing provider), shipment (shipping provider), and manufacturing scheduling services (scheduling provider). Each partnerLink is characterized by a partnerLink type and either one or two role names. This information identifies the functionality that must be provided by the business process and by the partner service for the relationship to succeed, that is, the portTypes that the purchase order process and the partner need to implement.
· The <variables> section defines the data variables used by the process, providing their definitions in terms of WSDL message types, XML Schema types (simple or complex), or XML Schema elements. Variables allow processes to maintain state between message exchanges.
· The <faultHandlers> section contains faultHandlers 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.
· The rest of the process definition contains the description of the normal behavior for handling a purchase request. The major elements of this description are explained in the section following the process definition.
<process name="purchaseOrderProcess"
targetNamespace="http://example.com/ws-bp/purchase"
xmlns="http://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="shippingRequest" messageType="lns:shippingRequestMessage"/>
<variable name="shippingInfo" messageType="lns:shippingInfoMessage"/>
<variable name="shippingSchedule" messageType="lns:scheduleMessage"/>
</variables>
<faultHandlers>
<catch faultName="lns:cannotCompleteOrder" faultVariable="POFault" faultMessageType="lns:orderFaultType">
<reply partnerLink="purchasing"
portType="lns:purchaseOrderPT"
operation="sendPurchaseOrder"
variable="POFault"
faultName="cannotCompleteOrder"/>
</catch>
</faultHandlers>
<sequence>
<receive partnerLink="purchasing"
portType="lns:purchaseOrderPT"
operation="sendPurchaseOrder"
variable="PO"
createInstance="yes">
<documentation> Receive Purchase Order </documentation>
</receive>
<flow> <documentation> A parallel flow to handle shipping, invoicing and scheduling </documentation>
<links>
<link name="ship-to-invoice"/>
<link name="ship-to-scheduling"/>
</links>
<sequence>
<assign>
<copy>
<from>$PO.customerInfo</from> <to>$shippingRequest.customerInfo</to>
</copy>
</assign>
<invoke partnerLink="shipping"
portType="lns:shippingPT"
operation="requestShipping"
inputVariable="shippingRequest"
outputVariable="shippingInfo">
<documentation> Decide On Shipper </documentation>
<sources> <source linkName="ship-to-invoice"/>
</sources>
</invoke>
<receive partnerLink="shipping"
portType="lns:shippingCallbackPT"
operation="sendSchedule"
variable="shippingSchedule">
<documentation> Arrange Logistics </documentation>
<sources> <source linkName="ship-to-scheduling"/>
</sources>
</receive>
</sequence>
<sequence>
<invoke partnerLink="invoicing"
portType="lns:computePricePT"
operation="initiatePriceCalculation"
inputVariable="PO">
<documentation> Initial Price Calculation </documentation>
</invoke>
<invoke partnerLink="invoicing"
portType="lns:computePricePT"
operation="sendShippingPrice"
inputVariable="shippingInfo">
<documentation> Complete Price Calculation </documentation> <targets> <target linkName="ship-to-invoice"/>
</targets>
</invoke>
<receive partnerLink="invoicing"
portType="lns:invoiceCallbackPT"
operation="sendInvoice"
variable="Invoice"/> </sequence>
<sequence>
<invoke partnerLink="scheduling"
portType="lns:schedulingPT"
operation="requestProductionScheduling"
inputVariable="PO">
<documentation> Initiate Production Scheduling </documentation>
</invoke>
<invoke partnerLink="scheduling"
portType="lns:schedulingPT"
operation="sendShippingSchedule"
inputVariable="shippingSchedule">
<documentation> Complete Production Scheduling </documentation>
<targets> <target linkName="ship-to-scheduling"/>
</targets>
</invoke>
</sequence>
</flow>
<reply partnerLink="purchasing"
portType="lns:purchaseOrderPT"
operation="sendPurchaseOrder"
variable="Invoice"/>
<documentation> Invoke Processing </documentation>
</sequence>
</process>
5.2. The Structure of a Business Process
This section provides a quick summary of the WS-BPEL syntax. It provides only a brief overview; the details of each language construct are described in the rest of this document.
The basic structure of the language is:
<process name="NCName" targetNamespace="anyURI"
queryLanguage="anyURI"?
expressionLanguage="anyURI"?
suppressJoinFailure="yes|no"? exitOnStandardFault="yes|no"?xmlns="http://schemas.xmlsoap.org/ws/2004/03/business-process/">
<extensions>?
<extension namespace="anyURI" mustUnderstand="yes|no"/>*
</extensions>
<import namespace="anyURI"? location="anyURI"? importType="anyURI"/>*
<partnerLinks>?
<!-- Note: At least one role must be specified. -->
<partnerLink name="NCName" partnerLinkType="QName"
myRole="NCName"? partnerRole="NCName"?>+
</partnerLink>
</partnerLinks>
<messageExchanges>? <messageExchange name="NCName"/>+</messageExchanges>
<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 faultHandler -->
<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 eventHandler. --> <onEvent partnerLink="NCName" portType="QName"? operation="NCName" (messageType="QName" | element="QName")? variable="NCName"? messageExchange="NCName"? >* <correlations>? <correlation set="NCName" initiate="yes|join|no"?/>+ </correlations> <fromPart part="NCName" toVariable="NCName"/>* <scope ...> ... </scope> </onEvent> <onAlarm>*
<!-- Note: There must be at least one expression. --> ( <for expressionLanguage="anyURI"?>duration-expr</for> | <until expressionLanguage="anyURI"?>deadline-expr</until> )? <repeatEvery expressionLanguage="anyURI"?> duration-expr </repeatEvery>?
<scope ...> ... </scope> </onAlarm></eventHandlers>
activity
</process>
The top-level attributes are as follows:
· queryLanguage. This attribute specifies the query language used in the process for selection of nodes in assignment, property definition, etc. The default value for this attribute is: "urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0", which represents the usage of [XPath 1.0] within WS-BPEL 2.0.
· expressionLanguage. This attribute specifies the expression language used in the process. The default value for this attribute is: "urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0", which represents the usage of [XPath 1.0] within WS-BPEL 2.0.
· suppressJoinFailure. This attribute determines whether the joinFailure fault will be suppressed for all activities in the process. The effect of the attribute at the process level can be overridden by an activity using a different value for the attribute. The default for this attribute is "no" at the process level. When this attribute is not specified for an activity, it inherits its value from its closest enclosing activity or from the process if no enclosing activity specifies this attribute.
· exitOnStandardFault. If the value of this attribute is set to “yes”, then the process MUST exit immediately as if an <exit> activity has been reached, when a WS-BPEL standard fault other than bpel:joinFailure is enountered[1]. If the value of this attribute is set to “no”, then the process can handle a standard fault using a faultHandler. 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 faultHandler that explicitly targets the WS-BPEL standard faults MUST NOT be used in that scope. A process definition that violates this condition MUST be detected by static analysis and rejected by a conformant implementation.
· The syntax of Abstract Process has its own distinct target namespace. Additional top-level attributes are defined for Abstract Processes.
The value of the queryLanguage and expressionLanguage attributes on the <process> element are global defaults and can be overridden on specific constructs, such as <condition> of a <while> activity, as defined later in this specification. In addition, the queryLanguage attribute is also available for use in defining WS-BPEL propertyAliases in WSDL. WS-BPEL processors MUST:
· statically determine which languages are referenced by queryLanguage or expressionLanguage attributes either in the WS-BPEL process definition itself or in any WS-BPEL property definitions in associated WSDLs and
· if any referenced language is unsupported by the WS-BPEL processor then the processor MUST reject the submitted WS-BPEL process definition.
Note that: <documentation> construct may be added to virtually all WS-BPEL constructs as the formal way to annotate processes definition with human documentation. Examples of <documentation> construct can be found in the previous sections. Detailed description of <documention> is provided in the next section, as it is a part of “Language Extensibility”.
Each business process has one main activity.
A WS-BPEL activity can be any of the following:
· <receive>
· <reply>
· <invoke>
· <assign>
· <throw>
· <exit>
· <wait>
· <empty>
· <sequence>
· <if>
· <while>
· <repeatUntil>
· <forEach>
· <pick>
· <flow>
· <scope>
· <compensate>
· <compensateScope>
· <rethrow>
· <validate>
· <extensionActivity>
The syntax of each of these elements is described in the following paragraphs.
The <receive> activity allows the business process to wait for a matching message to arrive. The <receive> activity completes when the message arrives. The portType attribute on the <receive> activity is optional. If the portType attribute is included for readability, the value of the portType attribute MUST match the portType value implied by the combination of the specified partnerLink and the role implicitly specified by the activity (See also partnerLink description in the next section). The optional messageExchange attribute is used to associate a <reply> activity with a <receive> activity.
<receive partnerLink="NCName" portType="QName"? operation="NCName"
variable="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> activity allows the business process to send a message in reply to a message that was received by an inbound message activity (IMA), that is, <receive>, <onMessage>, or <onEvent>. The combination of an IMA and a <reply> forms a request-response operation on a WSDL portType for the process. The portType attribute on the <reply> activity is optional. If the portType attribute is included for readability, the value of the portType attribute MUST match the portType value implied by the combination of the specified partnerLink and the role implicitly specified by the activity (See also partnerLink description in the next section). The optional messageExchange attribute is used to associate a <reply> activity with an IMA.
<reply partnerLink="NCName" portType="QName"? operation="NCName"
variable="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> activity allows the business process to invoke a one-way or request-response operation on a portType offered by a partner. In the request-response case, the invoke activity completes when the response is received. The portType attribute on the <invoke> activity is optional. If the portType attribute is included for readability, the value of the portType attribute MUST match the portType value implied by the combination of the specified partnerLink and the role implicitly specified by the activity (See also partnerLink description in the next section).
<invoke partnerLink="NCName" portType="QName"? operation="NCName"
inputVariable="NCName"? outputVariable="NCName"?
standard-attributes>
standard-elements
<correlations>?
<correlation set="NCName" initiate="yes|join|no"?
pattern="request|response|request-response"/>+
</correlations>
<catch faultName="QName"? faultVariable="NCName"?
faultMessageType="QName"? faultElement="QName">*
activity
</catch>
<catchAll>?
activity
</catchAll>
<compensationHandler>?
activity
</compensationHandler> <toPart part="NCName" fromVariable="NCName"/>* <fromPart part="NCName" toVariable="NCName"/>*
</invoke>
The <assign> activity is used to update the values of variables with new data. An <assign> construct can contain any number of elementary assignments, including <copy> assign elements or data update operations defined as extension under other namespaces.
<assign validate="yes|no"? standard-attributes>
standard-elements
(<copy> from-spec to-spec </copy> | <extensibleAssign> ...assign-element-of-other-namespace... </extensibleAssign>) +
</assign>
The <validate> activity is used to validate the values of variables against their associated XML and WSDL data definition. The construct has a variables attribute, which points to the variables being validated.
<validate variables="NCName-list" standard-attributes>
standard-elements
</validate>
The <throw> activity is used to generate a fault from inside the business process.
<throw faultName="QName" faultVariable="NCName"? standard-attributes>
standard-elements
</throw>
The <wait> activity is used to wait for a given time period or until a certain point in time has been reached. Exactly one of the expiration criteria MUST be specified.
<wait standard-attributes>
standard-elements ( <for expressionLanguage="anyURI"?>duration-expr</for> | <until expressionLanguage="anyURI"?>deadline-expr</until> )
</wait>
The <empty> activity is a "no-op" in a business process. This is useful for synchronization of concurrent activities, for instance.
<empty standard-attributes>
standard-elements
</empty>
The <sequence> activity is used to define a collection of activities to be performed sequentially in lexical order.
<sequence standard-attributes>
standard-elements
activity+
</sequence>
The <if> activity is used to select exactly one activity for execution from a set of choices.
<if standard-attributes>
standard-elements <condition expressionLanguage="anyURI"?> ... bool-expr ... </condition> activity <elseif>* <condition expressionLanguage="anyURI"?> ... bool-expr ... </condition>
activity </elseif> <else>? activity
</else>
</if>
The <while> activity is used to define that the child activity is to be repeated as long as the specified condition is true.
<while standard-attributes> standard-elements <condition expressionLanguage="anyURI"?> ... bool-expr ... </condition>
activity
</while>
The <repeatUntil> activity is used to define that the child activity is to be repeated until the specified condition becomes true. The condition is tested after the child activity completes. The <repeatUntil> activity is used to execute the child activity at least once.
<repeatUntil standard-attributes> standard-elements activity <condition expressionLanguage="anyURI"?> ... bool-expr ... </condition></repeatUntil>
The <forEach> activity iterates its child scope activity exactly N+1 times where N equals the <finalCounterValue> minus the <startCounterValue>. If parallel="yes" then this is a parallel forEach where the N+1 instances of the enclosed scope activity SHOULD occur in parallel. In essence an implicit flow is dynamically created with N+1 copies of the forEach's scope activity as children. A <completionCondition> may be used within the <forEach> to allow the <forEach> activity to complete without executing or finishing all the branches specified.
<forEach counterName="NCName" parallel="yes|no" standard-attributes> standard-elements
<startCounterValue expressionLanguage="anyURI"> unsigned-integer-expression </startCounterValue> <finalCounterValue expressionLanguage="anyURI"> unsigned-integer-expression </finalCounterValue>
<completionCondition>? <branches expressionLanguage="anyURI"? countCompletedBranchesOnly="yes|no"?> unsigned-integer-expression </branches> </completionCondition> <scope ...> ... </scope></forEach>
The <pick> activity is used to wait for one of several possible messages to arrive or for a time-out to occur. When one of these triggers occurs, the associated child activity is performed. When the child activity completes then the <pick> activity completes.
The portType attribute on the <onMessage> activity is optional. If the portType attribute is included for readability, the value of the portType attribute MUST match the portType value implied by the combination of the specified partnerLink and the role implicitly specified by the activity. The optional messageExchange attribute is used to associate a <reply> activity with a <onMessage> activity.
<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 <flow> activity is used to specify one or more activities to be performed concurrently. Links can be used within a flow to define explicit control dependencies between nested child activites.
<flow standard-attributes>
standard-elements
<links>?
<link name="NCName"/>+
</links>
activity+
</flow>
The <scope> activity is used to define a nested activity with its own associated partnerLinks, messageExchanges, variables, correlationSets, faultHandlers, compensationHandler, terminationHandler, and eventHandlers.
<scope isolated="yes|no"? exitOnStandardFault="yes|no"?
standard-attributes>
standard-elements <partnerLinks>? ... see above under <process> for syntax ...
</partnerLinks> <messageExchanges>? ... see above under <process> for syntax ... </messageExchanges>
<variables>?
... see above under <process> for syntax ...
</variables>
<correlationSets>?
... see above under <process> for syntax ...
</correlationSets>
<faultHandlers>?
... see above under <process> for syntax ...
</faultHandlers>
<compensationHandler>?
...
</compensationHandler>
<terminationHandler>?
...
</terminationHandler>
<eventHandlers>?
... see above under <process> for syntax ...
</eventHandlers>
activity
</scope>
The <compensateScope> activity is used to start compensation on a specified inner scope that has already completed successfully. This activity MUST only be used from within a faultHandler, another compensationHandler, or a terminationHandler.
<compensateScope target="NCName"? standard-attributes>
standard-elements
</compensateScope>
The <compensate> activity is used to start compensation on all inner scopes that have already completed successfully, in default order. This activity MUST only be used from within a faultHandler,another compensationHandler, or a terminationHandler.
<compensate standard-attributes>
standard-elements
</compensate>
The <exit>