Specification: Business Process Execution Language for Web Services Version 1.1

4.1. Core Concepts Clarification

We believe that the two usage patterns of business protocol description and executable business process description require a common core of process description concepts. In the 1.1 version of the specification we clearly separate the core concepts from the extensions required specifically for the two usage patterns. The main body of the specification defines the core concepts. The 14. Extensions for Executable Processes and the 15. Extensions for Business Protocols are defined in separate sections at the end of the specification. The separation of core concepts from extensions allows features required for specific usage patterns to be defined in a composable manner. It is conceivable that further extensions will be developed over time as the usage of the specification matures.

4.2. Terminology Changes

The following terminology changes have occurred

• Service Links are now called Partner Links

• Service Link Types are now called Partner Link Types

• Service References are now called Endpoint References

• Containers are now called Variables

The formal syntax has also been changed to reflect these terminology changes, including the replacement of the current partner element with a partnerLink element to reflect the fact that such a link is a conversational interface rather than reflective of a business relationship. A partner element reflective of a business relationship is added as described in the next section.

4.3. Feature Changes

The following changes have been made

• The terminate activity is now strictly limited to executable processes.

• Partner Link Type Roles are now limited to a single WSDL portType.

• A new partner element is added to allow grouping of Partner Links based on expected business enterprise relationships.

• Endpoint references (formerly service references) are now defined as given in [WS-Addressing].

• Message Properties are now limited to only be simple types.

• Web service interactions in abstract processes are now permitted to omit references to variables for inbound and outbound message data.

• Opaque assignment in abstract processes may now target Boolean variables, and variables of simple but unbounded types. In the latter case the semantics requires creation of a unique value similar to a GUID.

• The syntax for defining variables has been changed to use three mutually exclusive attributes messagetype, type and element. The first points to a WSDL message type definition. The second points to an XML Schema simple type. The third points to an XML Schema global element definition. This allows one to define variables using something other than WSDL message types. Only variables that are defined using messagetypes can be used as input or output targets in messaging operations.

• The ability to provide an in-line WSDL message type has been removed, since the vast majority of the uses of this feature will be replaced by the usage of XML Schema simple types and global elements.

• Correlation sets have now been added to the uniqueness requirement so that it is not legal to have two web service interactions outstanding if they have the same partner, port type, operation and correlation set(s).

• In case of activity termination, the activities wait, reply andinvoke are added to receive as being instantly terminated rather than being allowed to finish.

• The variable provided as the value of the faultVariable attribute in a catch handler to hold fault data is now scoped to the fault handler itself rather than being inherited from the associated scope.

• Variables and correlation sets can now be associated with local scopes rather than with the process as a whole. This permits easier management of visibility and lifetime for variables and repeated initiation of local correlation sets to allow multiple correlated conversations during, e.g., iterative behavior.

• Event handlers can now be associated with scopes, to permit a process or scope to be prepared to receive external events and requests concurrently with the main activity of the process or scope. This is especially helpful for events and requests that cannot be "scheduled" relative to the main activity, but may occur at unpredictable times.

• The Future Directions section has been dropped since this version forms the starting point for a formal standards process, which will define those directions.

6.1. Initial Example

Before describing the structure of business processes in detail, this section presents a simple example of a BPEL4WS 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 BPEL4WS 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 BPEL4WS 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 [partnerlinktypespartnerlinksandendpointreferences]). Partner link types can be used to represent dependencies between services, regardless of whether a BPEL4WS 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).

<definitions targetNamespace="http://manufacturing.org/wsdl/purchase"
      xmlns:sns="http://manufacturing.org/xsd/purchase"
      xmlns:pos="http://manufacturing.org/wsdl/purchase"
      xmlns:xsd="http://www.w3.org/2001/XMLSchema"
      xmlns="http://schemas.xmlsoap.org/wsdl/"
      xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/"> 

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

<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" type="xsd:string"/>
</message>
<message name="shippingRequestMessage">
   <part name="customerInfo" type="sns:customerInfo"/>
</message>
<message name="shippingInfoMessage">
   <part name="shippingInfo" type="sns:shippingInfo"/>
</message>
<message name="scheduleMessage">
   <part name="schedule" type="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">
       <plnk:portType name="pos:purchaseOrderPT"/>
   </plnk:role>
</plnk:partnerLinkType>

<plnk:partnerLinkType name="invoicingLT">
   <plnk:role name="invoiceService">
       <plnk:portType name="pos:computePricePT"/>
   </plnk:role>
   <plnk:role name="invoiceRequester">
       <plnk:portType name="pos:invoiceCallbackPT"/>
   </plnk:role>
</plnk:partnerLinkType>

<plnk:partnerLinkType name="shippingLT">
   <plnk:role name="shippingService">
       <plnk:portType name="pos:shippingPT"/>
   </plnk:role>
   <plnk:role name="shippingRequester">
       <plnk:portType name="pos:shippingCallbackPT"/>
   </plnk:role>
</plnk:partnerLinkType>

<plnk:partnerLinkType name="schedulingLT">
   <plnk:role name="schedulingService">
       <plnk:portType name="pos:schedulingPT"/>
   </plnk:role>
</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 simple types, 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 BPEL4WS, all faults, whether internal or resulting from a service invocation, are identified by a qualified name. In particular, each WSDL fault is identified in BPEL4WS 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, BPEL4WS 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.

<process name="purchaseOrderProcess" 
         targetNamespace="http://acme.com/ws-bp/purchase"
         xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
         xmlns:lns="http://manufacturing.org/wsdl/purchase">
   
   <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">
         <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>

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

         <sequence>
            <assign>
               <copy>
                  <from variable="PO" part="customerInfo"/>
                  <to variable="shippingRequest" 
                      part="customerInfo"/>
               </copy>
            </assign>
   
            <invoke  partnerLink="shipping" 
                     portType="lns:shippingPT" 
                     operation="requestShipping"
                     inputVariable="shippingRequest" 
                     outputVariable="shippingInfo">
               <source linkName="ship-to-invoice"/>
            </invoke>

            <receive partnerLink="shipping" 
                     portType="lns:shippingCallbackPT" 
                     operation="sendSchedule"
                     variable="shippingSchedule">
               <source linkName="ship-to-scheduling"/>
            </receive>

         </sequence>

         <sequence>

            <invoke  partnerLink="invoicing" 
                     portType="lns:computePricePT" 
                     operation="initiatePriceCalculation"
                     inputVariable="PO">
            </invoke>
            <invoke  partnerLink="invoicing" 
                     portType="lns:computePricePT" 
                     operation="sendShippingPrice"
                     inputVariable="shippingInfo">
               <target linkName="ship-to-invoice"/>
            </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">
               <target linkName="ship-to-scheduling"/>
            </invoke>
         </sequence>
      </flow>

      <reply partnerLink="purchasing" 
             portType="lns:purchaseOrderPT" 
             operation="sendPurchaseOrder" 
             variable="Invoice"/>
   </sequence>

</process>
		

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

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.

6.2. The Structure of a Business Process

This section provides a quick summary of the BPEL4WS 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="uri" 
         queryLanguage="anyURI"?
         expressionLanguage="anyURI"?
         suppressJoinFailure="yes|no"?
         enableInstanceCompensation="yes|no"?
         abstractProcess="yes|no"?
         xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/">

  <partnerLinks>?
    <!-- Note: At least one role must be specified. -->
    <partnerLink name="ncname" partnerLinkType="qname" 
             myRole="ncname"? partnerRole="ncname"?>+
    </partnerLink>
  </partnerLinks>

  <partners>?
     <partner name="ncname">+
      <partnerLink name="ncname"/>+
   </partner>
  </partners>

  <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"?>*
      activity
    </catch>
    <catchAll>?
      activity
    </catchAll>
  </faultHandlers>

  <compensationHandler>?
    activity
  </compensationHandler>

  <eventHandlers>?
    <!-- Note: There must be at least one onMessage or onAlarm handler. -->
    <onMessage partnerLink="ncname" portType="qname"
               operation="ncname" variable="ncname"?>
      <correlations>?
        <correlation set="ncname" initiate="yes|no"?>+
      <correlations>
      activity
    </onMessage>
    <onAlarm for="duration-expr"? until="deadline-expr"?>*
      activity
    </onAlarm>
  </eventHandlers>
    
  activity
</process>
		

The top-level attributes are as follows:

• queryLanguage. This attribute specifies the XML query language used for selection of nodes in assignment, property definition, and other uses. The default for this attribute is XPath 1.0, represented by the URI of the XPath 1.0 specification: http://www.w3.org/TR/1999/REC-xpath-19991116.

• expressionLanguage. This attribute specifies the expression language used in the process. The default for this attribute is XPath 1.0, represented by the URI of the XPath 1.0 specification: 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".

• enableInstanceCompensation. This attribute determines whether the process instance as a whole can be compensated by platform-specific means. The default for this attribute is "no".

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

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

• <receive>

• <reply>

• <invoke>

• <assign>

• <throw>

• <terminate>>

• <wait>

• <empty>>

• <sequence>

• <switch>

• <while>

• <pick>

• <flow>

• <scope>>

• <compensate>

The syntax of each of these elements, except <terminate>, is considered in the following paragraphs. Although <terminate> is permitted as an interpretation of the token activity, it is only available in executable processes and as such is defined in the section on 14. Extensions for Executable Processes.

The <receive> construct allows the business process to do a blocking wait for a matching message to arrive.

  <receive partnerLink="ncname" portType="qname" operation="ncname"
           variable="ncname"? createInstance="yes|no"?
           standard-attributes>
    standard-elements
    <correlations>?
      <correlation set="ncname" initiate="yes|no"?>+
    </correlations>
  </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.

  <reply partnerLink="ncname" portType="qname" operation="ncname"
         variable="ncname"? faultName="qname"?
         standard-attributes>
    standard-elements
    <correlations>?
       <correlation set="ncname" initiate="yes|no"?>+
    </correlations>
  </reply>
		

The <invoke> construct allows the business process to invoke a one-way or request-response operation on a portType offered by a partner.

  <invoke partnerLink="ncname" portType="qname" operation="ncname"
          inputVariable="ncname"? outputVariable="ncname"?
          standard-attributes>
    standard-elements
    <correlations>?
       <correlation set="ncname" initiate="yes|no"? 
                    pattern="in|out|out-in"/>+
    </correlations>
    <catch faultName="qname" faultVariable="ncname"?>*
      activity
    </catch>
    <catchAll>?
      activity
    </catchAll>
    <compensationHandler>?
      activity
    </compensationHandler>
  </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. The syntax of the assignment activity is:

  <assign standard-attributes>
    standard-elements
    <copy>+
      from-spec
      to-spec
    </copy>
  </assign>
		

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

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

  <wait (for="duration-expr" | until="deadline-expr") standard-attributes>
    standard-elements
  </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.

  <empty standard-attributes>
    standard-elements
  </empty>
		

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

  <sequence standard-attributes>
    standard-elementsactivity+
  </sequence>
		

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

  <switch standard-attributes>
    standard-elements
    <case condition="bool-expr">+
      activity
    </case>
    <otherwise>?
      activity
    </otherwise>
  </switch>
		

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

  <while condition="bool-expr" standard-attributes>
     standard-elementsactivity
  </while>
		

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.

  <pick createInstance="yes|no"? standard-attributes>
    standard-elements
    <onMessage partnerLink="ncname" portType="qname"
               operation="ncname" variable="ncname"?>+
      <correlations>?
         <correlation set="ncname" initiate="yes|no"?>+
      </correlations>
      activity
    </onMessage>
    <onAlarm (for="duration-expr" | until="deadline-expr")>*
      activity
    </onAlarm>
  </pick>
		

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.

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

<scope variableAccessSerializable="yes|no" standard-attributes>
    standard-elements
    <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>
    <eventHandlers>?
      ...
    </eventHandlers>
    activity
  </scope>
		

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.

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

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

  name="ncname"?
  joinCondition="bool-expr"?
  suppressJoinFailure="yes|no"?
		

where the default values are as follows:

• name. No default value (that is, unnamed)

• joinCondition. The logical OR of the liveness status of all links that are targeted at this activity

• suppressJoinFailure. No

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

  <target linkName="ncname"/>*
  <source linkName="ncname" transitionCondition="bool-expr"?/>*
		

where the default value of the "transitionCondition" attribute is "true()", the truth-value function from the default expression language XPath 1.0.

6.3. Language Extensibility

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

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

Extensions MUST NOT change the semantics of any element or attribute from the BPEL4WS namespace.

6.4. 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. BPEL4WS, builds on WSDL by assuming that all external interactions of the business process occur through Web Service operations. However, BPEL4WS 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 BPEL4WS business process definition can be thought of as a template for creating business process instances.

The creation of a process instance in BPEL4WS 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 11.4. Providing Web Service Operations and 12.4. Pick).

To be instantiated, each business process must contain at least one such "start activity." This must be an initial activity in the sense that there is no basic activity that logically precedes it in the behavior of the process.

If more than one start activity is enabled concurrently, then all such activities must use at least one correlation set and must use the same correlation sets (see 10. Correlation and the 16.3. Multiple Start Activities example).

If exactly one start activity is expected to instantiate the process, 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 a terminate activity (see 14.6. Terminating a Service Instance). In this case the termination is abnormal.

• If a compensation handler is specified for the business process as a whole (see 13.3. Compensation Handlers), a business process instance can be compensated after normal completion by platform-specific means. This functionality is enabled by setting the enableInstanceCompensation attribute of the process to "yes".

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

<partnerLinkType name="BuyerSellerLink"
        xmlns="http://schemas.xmlsoap.org/ws/2003/05/partner-link/">
  <role name="Buyer">
    <portType name="buy:BuyerPortType"/>
  </role>
  <role name="Seller">
    <portType name="sell:SellerPortType"/>
  </role>
</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:

<definitions name="ncname" targetNamespace="uri"
     xmlns="http://schemas.xmlsoap.org/wsdl/"
     xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/">
  ...
  <plnk:partnerLinkType name="ncname">
    <plnk:role name="ncname">
      <plnk:portType name="qname"/>
    </plnk:role>
    <plnk:role name="ncname">?
      <plnk:portType name="qname"/>
    </plnk:role>
  </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.

7.2. Partner Links

The services with which a business process interacts are modeled as partner links in BPEL4WS. 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.

  <partnerLinks>
    <partnerLink name="ncname" partnerLinkType="qname" 
             myRole="ncname"? partnerRole="ncname"?>+
    </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 11.3. Invoking Web Service Operations and 11.4. 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 static shape of the relationships that the BPEL4WS 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 BPEL4WS. However, it is also possible to select and assign actual partner services dynamically, and BPEL4WS 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. BPEL4WS allows the endpoint references implicitly present in partnerLinks to be both extracted and assigned dynamically, and also to be set more than once. See 9.3. Assignment for the mechanisms used for dynamic assignment of endpoint references to partner services.

7.3. Business Partners

While a partner link represents a conversational relationship between two partner processes, relationships with a business partner in general require more than a single conversational relationship to be established. To represent the capabilities required from a business partner, BPEL4WS uses the partner element. A partner is defined as a subset of the partner links of the process, as shown in the example below.

 
<partner name="SellerShipper"
        xmlns="http://schemas.xmlsoap.org/ws/2003/05/partner-link/">
  <partnerLink name="Seller"/>
  <partnerLink name="Shipper"/>
</partner>
		

Partner definitions are optional and need not cover all the partner links defined in the process. From the process perspective a partner definition introduces a constraint on the functionality that a business partner is required to provide. In the example above, the partner definition states that the same business partner ("SellerShipper") is required to provide the services associated with the the roles of seller and shipper. Partner definitions MUST NOT overlap, that is, a partner link MUST NOT appear in more than one partner definition.

The syntax for partner definitions is given below:

<partners>
  <partner name="ncname">+
    <partnerLink name="ncname"/>+
  </partner>
</partners>
		

7.4. 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 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 BPEL4WS to dynamically select a provider for a particular type of service and to invoke their operations. BPEL4WS 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.

BPEL4WS uses the notion of endpoint reference defined in [WS-Addressing]. Every partner role in a partnerLink in a BPEL4WS 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.

8.1. Motivation

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 10. 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 BPEL4WS. 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.

8.2. Defining Properties

A property definition creates a globally unique name and associates it with an XML Schema simple 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 message, including in the message context.

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

<definitions name="properties"
      targetNamespace="http://example.com/properties.wsdl"
      xmlns:tns="http://example.com/properties.wsdl"
      xmlns:txtyp="http://example.com/taxTypes.xsd"
      xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
      xmlns="http://schemas.xmlsoap.org/wsdl/">

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

The WSDL extensibility mechanism is used to define properties so that the target namespace and other useful aspects of WSDL are available. The BPEL4WS standard namespace, "http://schemas.xmlsoap.org/ws/2003/03/business-process/", is used for property definitions. The syntax for a property definition is a new kind of WSDL definition as follows:

<wsdl:definitions name="ncname"
   xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/">
    <bpws:property name="ncname" type="qname"/>
    ...
</wsdl:definitions>
		

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. The property name becomes an alias for the message part and location, and can be used as such in 9.1. Expressions and 9.3. Assignment in abstract business processes.

<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:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
         xmlns="http://schemas.xmlsoap.org/wsdl/">

    <!-- define a correlation property -->
    <bpws:property name="taxpayerNumber" type="txtype:SSN"/>
     ...
    <bpws:propertyAlias propertyName="tns:taxpayerNumber"   
       messageType="txmsg:taxpayerInfo" part="identification" 
       query="/socialsecnumber"/>
    </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:

<definitions name="ncname"
          ...
      xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/">
 
    <bpws:propertyAlias propertyName="qname" 
            messageType="qname" part="ncname" query="queryString"/>
    ...
</wsdl:definitions>
		

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

9.1. Expressions

BPEL4WS 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 switch cases)

• Deadline-valued expressions ("until" attribute of onAlarm and wait)

• Duration-valued expressions ("for" attribute of onAlarm and wait)

• General expressions (assignment)

BPEL4WS provides an extensible mechanism for the language used in these expressions. The language is specified by the expressionLanguage attribute of the process element. Compliant implementations of the current version of BPEL4WS 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:

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 expression-language bindings will provide equivalent functionality. The rest of this section is specific to XPath 1.0.

BPEL4WS 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 BPEL4WS namespace "http://schemas.xmlsoap.org/ws/2003/03/business-process/". 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 BPEL4WS document at the location of the expression.

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 8. Message Properties). If the given property does not appear in any of the parts of the variable's message type, then the semantics of the process is undefined. The return value of this function is a node set containing the single node representing the property. If the given property definition selects a node set of a size other than one, then the semantics of the process is undefined.

bpws:getLinkStatus ('linkName') 
		

This function returns a Boolean indicating the status of the link (see 12.5.1. Link Semantics). If the status of the link is positive the value is true, and if the status is negative the value is false. This function MUST NOT be used anywhere except in a join condition. The linkName argument MUST refer to the name of an incoming link for the activity associated with the join condition. These restrictions MUST be statically enforced.

These BPEL4WS-defined extension functions are available for use within all XPath 1.0 expressions.

The syntax of XPath 1.0 expressions for BPEL4WS is considered in the following paragraphs.

9.2. Variables

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 simple type or an XML Schema element. The syntax of the variables declaration is:

  <variables>
    <variable name="ncname" messageType="qname"?
                type="qname"? element="qname"?/>+
  </variables>
		

The name of a variable should be unique within its own scope. If a local variable has the same name and same messageType/type/element as a variable defined in an enclosing scope, the local variable will be used in local assignments and/or getVariableProperty functions. It is not permitted to have variables with same name but different messageType/type/element within an enclosing scope hierarchy. The behavior of such variables is not defined.

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 simple type. Attribute element refers to an XML Schema element. An XML Schema complex type must be associated with an element to be used by a BPEL4WS variable.

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 11.3. Invoking Web Service Operations and 11.4. 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 13. Scopes and 13.4. 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.

9.3. Assignment

Copying data from one variable to another is a common task within a business process. The assign activity can be used to copy data from one variable to another, as well as to construct and insert new data using expressions. The use of expressions is primarily motivated by the need to perform simple computation (such as incrementing sequence numbers) that is required for describing business protocol behavior. Expressions operate on message selections, properties, and literal constants to produce a new value for a variable property or selection. Finally, this activity can also be used to copy endpoint references to and from partner links.

The assign activity contains one or more elementary assignments.

  <assign standard-attributes>
    standard-elements
    <copy>+
      from-spec
      to-spec
    </copy>
  </assign>
		

The assign activity copies a type-compatible value from the source ("from-spec") to the destination ("to-spec"). The from-spec MUST be one of the following forms except for the opaque form available in abstract processes:

<from variable="ncname" part="ncname"?/>
<from partnerLink="ncname" endpointReference="myRole|partnerRole"/>
<from variable="ncname" property="qname"/>
<from expression="general-expr"/>
<from> ... literal value ... </from>
		

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

<to variable="ncname" part="ncname"?/>
<to partnerLink="ncname"/>
<to variable="ncname" property="qname"/>
		

In the first from-spec and to-spec variants the variable attribute provides the name of a variable. If the type of the variable is a WSDL messge type the optional part attribute MAY be used to provide the name of a part within that variable. When the variable is defined using XML Schema simple type or element, the part attribute MUST NOT be used.

The second from-spec and to-spec variants allow dynamic manipulation of the endpoint references associated with partner links. The value of the partnerLink attribute is the name of a partnerLink declared in the process. In the case of from-specs, the role must also be specified because a process might need to communicate an endpoint reference corresponding to either its own role or the partner's role within the partnerLink. The value "myRole" means that the endpoint reference of the process with respect to that partnerLink is the source, while the value "partnerRole" means that the partner's endpoint reference for the partnerLink is the source. For the to-spec, the assignment is only possible to the partnerRole, hence there is no need to specify the role. The type of the value used in partnerLink-style from/to-specs is always an endpoint reference (see 7. Partner Link Types, Partner Links, and Endpoint References).

The third from-spec and to-spec variants allow explicit manipulation of message properties (see 8. Message Properties) occurring in variables. The property forms are especially useful for abstract processes, because they provide a way to clearly define how distinguished data elements in messages are being used.

The fourth ("expression") from-spec variant allows processes to perform simple computations on properties and variables (for example, increment a sequence number).

The fifth from-spec variant allows a literal value to be given as the source value to assign to a destination. The type of the literal value MUST be the type of the destination (to-spec). The type of the literal value MAY be optionally indicated inline with the value by using XML Schema's instance type mechanism (xsi:type).

<complexType name="tAddress">
  <sequence>
    <element name="number" type="xsd:int"/>
    <element name="street" type="xsd:string"/>
    <element name="city" type="xsd:string"/>
    <element name="phone">
      <complexType>
        <sequence>
          <element name="areacode" type="xsd:int"/>
          <element name="exchange" type="xsd:int"/>
          <element name="number" type="xsd:int"/>
        </sequence>
      </complexType>
    </element>
  </sequence>
</complexType>

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

<message name="person" xmlns:x="http://tempuri.org/bpws/example">
  <part name="full-name" type="xsd:string"/>
  <part name="address" element="x:address"/>
</message>
			

<variable name="c1" messageType="x:person"/>
<variable name="c2" messageType="x:person"/>
<variable name="c3" element="x:address"/>
			

<assign>
  <copy>
    <from variable="c1"/>
    <to variable="c2"/>
  </copy>
  <copy>
    <from variable="c1" part = "address"/>
    <to variable="c3"/>
  </copy>
</assign>