Page Comparison

...

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 under this sectionbelow 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.

...

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.

...

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 WS-BPEL 2.0 specification requires the <assign> activity to be atomic. Currently in WSO2 BPS, each <copy> is atomic.

The specification also provides for validating variables at the end of an assignment using the validate attribute. WSO2 BPS does not support this. This means that the bpel:invalidVariables fault is never thrown by an <assign> activity.

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.

There are no other known divergences from the specification relating to the <assign> activity that would prevent the execution of valid BPEL assignments. WSO2 BPS provides certain (non-standard) extensions to the <assign> activity that do not conform to the specification's requirements for assignment extensions. Consult the reference page for the <assign> activity for further details regarding non-standard extensions.

<throw>

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

...

<rethrow>

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

...

<validate>

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

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.

...

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

<flow>

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

<scope>

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

...

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.

<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. Processescontaining such activities will cause a compilation failure.

<extensionActivity>

...

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