com.atlassian.confluence.content.render.xhtml.migration.exceptions.UnknownMacroMigrationException: The macro 'next_previous_link3' is unknown.

WS-BPEL 2.0 Specification Compliance

Owned by Former user (Deleted)
Last updated: Feb 22, 2014 by Former user (Deleted)Version comment
8 min read

This page provides information on WSO2 BPS's compliance to the final WS-BPEL 2.0 specification released by OASIS.

Variable Initialization

Variable initialization using in-line spec is fully supported. (WS-BPEL 2.0 Section 8.1: http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html#_Toc164738495)

External Variables

In addition to regular variables that are managed by the engine according to the BPEL specification, Ode adds support for variables whose content is stored externally, yet transparently accessible from the engine.

Activities

Divergences from the WS-BPEL 2.0 specification (http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html) for each standard BPEL activity is described below along with the activities that are compliant.

<throw>

The <throw> activity is fully compliant with the specification.

<exit>

The <exit> activity is fully compliant with the specification.

<wait>

The <wait> activity is fully compliant with the specification.

<empty>

The <empty> activity is fully compliant with the specification.

<sequence>

The <sequence> activity is fully compliant with the specification.

<if>

The <if> activity is fully compliant with the specification.

<while>

The <while> activity is fully compliant with the specification.

<repeatUntil>

The <repeatUntil> activity is fully compliant with the specification.

<flow>

The <flow> activity is fully compliant with the specification.

<receive>

There are several major issues with support for the <receive> activity. Since WSO2 BPS does not yet support the <fromPart> syntax, the variable attribute must be used. Furthermore, only message variables can be referenced with the variable attribute, whereas the specification permits referencing of an element-typed variable, if the WSDL for the request message contains a single element-typed section.

Multiple start activities as described in section 10.4, and 15.4 (http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html#_Toc164738541) of the specification are not officially supported. This precludes the use of initiate="join". WSO2 BPS does not provide the ordering guarantees described in section 10.4 of the specification. Also, it does not enforce the ordering requirements described in the same section. Therefore, the BPEL code below is illegal according to the BPEL specification, but allowed by WSO2 BPS.

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

The specification defines two standard faults ? bpel:conflictingRequest and bpel:conflictingReceive ? to deal with two similar error conditions relating to multiple outstanding requests on a single partner-link/operation/messageExchange tuple. WSO2 BPS does not distinguish between these two conditions and 'conflictingReceive' is thrown whenever either of the conditions occurs. That is to say, in certain cases a conflictingReceive indicates a conflictingRequest, and conflictingRequest is never thrown.

Finally, the validate attribute, if present, is ignored. WSO2 BPS currently provides no variable validation.

<pick>

The <pick> activity has the same issues as the <receive> activity.

<reply>

The conformance issues with the <reply> activity mirror those of the <receive> activity as described above. The <toPart> syntax is not supported, and variable attributes must reference message-typed variables.

<invoke>

Again, as in the <receive> and <reply> activities, the <toPart> and <fromPart> syntax are not supported. Similarly, the inputVariable and outputVariable attributes must reference message-typed variables. Here too, the validate attribute is ignored.

<compensateScope>

The <compensateScope> activity is fully compliant with the specification.

<rethrow>

The <rethrow> activity is fully compliant with the specification.

<validate>

The <validate> activity is not implemented by WSO2 BPS. Processes containing such activities will cause a compilation failure.

<extensionActivity>

Activity extension is fully supported in WSO2 BPS.

<forEach>

The <forEach> activity is fully compliant with the specification. WSO2 BPS supports both sequential and parallel for-each semantics.

<scope>

Isolated scopes are implemented in ODE trunk and available with WSO2 BPS 1.1.0 as a result.

<compensate>

The <compensate> activity is not compliant with the specification. In WSO2 BPS, this activity has the same effect and syntax as <compensateScope>. In addition, the scope attribute may be used in place of the target attribute with the same effect; and WSO2 BPS expects one of these attributes must be specified.

<assign>

Given below are the known divergences from the specification relating to the <assign> activity.

  • The WS-BPEL 2.0 specification requires the <assign> activity to be atomic. Currently in WSO2 BPS, each <copy> is atomic.
  • The specification provides for validating variables at the end of an assignment using the validate attribute. WSO2 BPS does not support this, meaning that the bpel:invalidVariables fault is never thrown by an <assign> activity in WSo2 BPS.
  • Inline assignment as part of the variable declaration isn't currently supported.

Ode currently uses the expressionLanguage attribute to determine the language used in assignments instead of using the queryLanguage attribute. WSO2 BPS provides certain (non-standard) extensions to the <assign> activity that do not conform to the specification's requirements for assignment extensions. Some of them are discussed through the following synopsis.

<assignvalidate="yes|no"? standard-attributes>
   standard-elements
   (
   <copykeepSrcElementName="yes|no"? ignoreMissingFromData="yes|no"?>
      from-spec
      to-spec
   </copy>
   |
   <extensionAssignOperation>
      assign-element-of-other-namespace
   </extensionAssignOperation>
   )+
</assign>

Throws following faults:

Introduction to the <assign> Activity

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. It can also be used to copy endpoint references to and from partnerLinks.

Each <assign> is made up of any number of <copy> entries, which are each made up of a "to-spec" (lvalue), and a from-spec (rvalue).

  • ignoreMissingFormData - (optional) Should the bpel:selectionFailure standard fault be suppressed?
    • yes - suppress standard faults
    • no - (default) do not suppress standard faults
  • validate - (optional, WSO2 BPS doesn't support this) validate modified variables?
    • yes - the <assign> activity validates all the variables deing modified by the activity. If the validation fails the bpel:invalidVariables fault is thrown.
    • no - (default) do not validate the modified variables
  • <copy> - defines a lvalue, rvalue pair.
    • keepSrcElementName - (optional) should the element name of the destination (as selected by the to-spec) be replaced by the element name of the source (as selected by the from-spec)?
      • yes - element names are replaced
      • no - (default) element names are not replaced
    • <from> - specifies the rvalue
    • <to> - specifies the lvale
  • <extensionAssignOperation> - a container for assignment extensions. If the element contained within the extensionAssignOperation elements not recognized by ODE and is not subjected to a mustUnderstand="yes" requirement from an extension declaration, then the element will be ignored.

The following types of variants are available in the <assign> activity.

From/To-Spec Variants

The <assign> activity copies a type-compatible value from the source ("from-spec") to the destination ("to-spec"), using <copy> element. The from-spec must be one of the following:

<fromvariable="BPELVariableName"part="NCName"?><queryqueryLanguage="anyURI"?>?
      queryContent
   </query></from>
<frompartnerLink="NCName"endpointReference="myRole|partnerRole"/>
<fromvariable="BPELVariableName"property="QName"/>
<fromexpressionLanguage="anyURI"?>expression</from>
<from><literal>literal value</literal></from>
<fromvariable="BPELVariableName"extension="QName"/><!-- non-standard extension -->

The to-spec must be one of the following:

<tovariable="BPELVariableName"part="NCName"?><queryqueryLanguage="anyURI"?>?
      queryContent
   </query></to>
<topartnerLink="NCName"/>
<tovariable="BPELVariableName"property="QName"/>
<toexpressionLanguage="anyURI"?>expression</to>
<tovariable="BPELVariableName"extension="QName"/><!-- WSO2 BPS SPECIFIC -->

A to-spec must return an lvalue. If a to-spec does not return an lvalue then a bpel:selectionFailure will be thrown. In the context of XPath, an lvalue is a node-list containing a single node from a variable or a partnerLink identified by the to-spec (e.g. the XPath expression concat("foo""bar") is not an lvalue).

Assignment is an atomic operation; that is, either all <copy> s succeed, or no changes are made. In WSO2 BPS each <copy> is atomic

Variable Variant

Selects value stored in a BPEL variable

<to|from variable="BPELVariableName"part="NCName"?><queryqueryLanguage="anyURI"?>?
      queryContent
   </query></to|from>
  • variable - (required) name of the variable
  • part - (optional) if the type of this variable is a WSDL messageType, this attribute may be used to provide the name of a part within that variable. This attribute must not be used when the variable is defined using XML schema types or element.
  • <query> element may be used to select a value from the source or target variable or message part. The computed value of the query must be one the following:
    • a sigle XML node, for example an attribute or an element
    • test(i. e. a text node, CDATA section, string-valued XPath expression, etc..)
PartnerLink Variant

Allows manipulation of the endpoint references associated with partnerLinks.

<frompartnerLink="NCName"endpointReference="myRole|partnerRole"/>
<topartnerLink="NCName"/>
  • partnerLink - name of the partnerLink
  • role - the role or "side" of the partnerLink
    • myRole - the endpoint reference of the process
    • partnerRole - the partner's endpoint reference

For from-specs, the role attribute must be specified, while for the to-spec, the assignment is only possible to the partnerRole. Therefore, specifying the role is not required and the to-spec can only refer to a <partnerLink> of which the declaration specifies the partnerRole attribute. The type of the value referenced by partnerLink-style from/to-specs is always a <sref:service-ref> element.

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

Property Variant

Allows data manipulation using properties. The property value generated by the from-spec is generated in the same manner as the value returned by the bpel:getVariableProperty() function.

<to|from variable="BPELVariableName"property="QName"/>
  • variable - name of the variable referenced
  • property - name of the property to apply to the variable
Expression Variant

In the Expression Variant, an expression language (typically XPath), is used to calculate a value.

<to|from expressionLanguage="anyURI"?>expression</from>
  • expressionLanguage - (optional) identifies the expression language.
  • expression - the expression whose syntax is determined by the expression language.

The computed value of the expression must be one of the following:

  • a single XML node, for example, an attribute or an element.
  • text(i. e. a text node, CDATA section, string-valued XPath expression, etc.)
Literal Variant

The literal variant allows a literal value to be given as the rvalue.

<from><literal>literal value</literal></from>
  • literal value - value to be assigned

The type of the literal value may be optionally indicated inline with the value by using XML Schema's instance type mechanism (xsi:type). The literal content must be either a single element or text. An empty <literal/> element is equivalent to an empty text node.

Empty Variant

Empty variant exists for extensibility purposes. It is not supported by WSO2 BPS.

<from|to/>
Insert Variant (Non-Standard Extension)

Faults

  • bpel:invalidVariables - A modified variable does not conform to its schema and the validate flag is set to yes.
  • bpel:selectionFailure - The node(s) selected by a from/to-spec is (are) invalid. This includes cases when the to-spec returns a node that is not an lvalue, when multiple nodes are selected, or when no node is selected.
  • bpel:subLanguageExecutionFault - Evaluating the expression (in the expression variant), or the query (in the variable variant) generates an error. For example, when a divide-by-zero is attempted.
  • bpel:uninitializedVariable - The variable referenced in the from-spec is not initialized.
  • bpel:mismatchedAssignmentFailure - The nodes selected by the to-spec and from-spec are not compatible. For example, this could occur if an attempt was made to assign a text node to an element variable, or an element variable was assigned to a message variable.
Examples
  • The following assigns a childless element bar in namespace http://example.com to an element-typed variable myFooBarElemVar:
<assign>
   <copy>
       <from><literalxmlns:foo="http://example.com"><foo:bar/></literal></from><tovariable="myFooBarElemVar"/>
   </copy>
</assign>
  • The following assigns the string "FooBar" to a string-typed variable myStringVar:
<assign>
   <copy>
      <from>
         <literal><![CDATA[FooBar]]></literal>
      </from>
      <tovariable="myStringVar"/>
   </copy>
</assign>
  • The following assigns the string "" (i.e. the empty string) to a string-typed variable myStringVar:
<assign> 
   <copy>
      <from>
         <literal/>
      </from>
      <tovariable="myStringVar"/>
   </copy>
</assign>
  • The following illustrates copying one variable (c1) to another (c2) as well as copying a variable part (address part of variable c1) to a variable of compatible element type (c3):
<assign>
    <copy>
       <fromvariable="c1"/>
       <tovariable="c2"/>
    </copy>
    <copy>
       <from>$c1.address</from>
       <tovariable="c3"/>
    </copy>
</assign>
com.atlassian.confluence.content.render.xhtml.migration.exceptions.UnknownMacroMigrationException: The macro 'next_previous_links2' is unknown.