Title: WS-BPEL 2.0 Specification Compliance
This page provides information on ODE's compliance to the final [WS-BPEL 2.0](ws-bpel-20.html) specification released by OASIS. ODE also implements [a few extensions](/extensions/) we deemed necessary.

<a name="WS-BPEL2.0SpecificationCompliance-StaticAnalysis"></a>
## Static Analysis
In this section the divergenced from the specification relating to static analysis requirements are described.

<a name="WS-BPEL2.0SpecificationCompliance-Variables"></a>
## Variables

<a name="WS-BPEL2.0SpecificationCompliance-Initialization"></a>
### Initialization

The inline `from-spec` used for variable initialization (BPEL 2.0 Section 8.1) is not supported, however a patch is available (see ODE-236).

<a name="WS-BPEL2.0SpecificationCompliance-ExternalVariables"></a>
### 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.  See [External Variables](/extensions/external-variables.html) for more information.

<a name="WS-BPEL2.0SpecificationCompliance-Activities"></a>
## Activities
In this section the divergences from the specification for each standard BPEL activity are described.

<a name="WS-BPEL2.0SpecificationCompliance-receive"></a>
### <[receive](receive.html)>
There are several major issues with support for the `<receive>` activity.

ODE does not yet support the `<fromPart>` syntax. Therefore, the `variable` attribute must be used. Furthermore, only message variables can be referenced with the `variable` attribute, whereas the [specification](ws-bpel-20.html) permits referencing of an element-typed variable if the WSDL for the request message contains a single element-typed part.

Multiple start activities as described in section 10.4, and 15.4 of the [specification](ws-bpel-20.html)) are not officially supported. This precludes the use of `initiate="join"`.

ODE does not provide the ordering guarantees described in section 10.4 of the [specification](ws-bpel-20.html). Also, it does not enforce the ordering requirements described in the same section. Hence, the BPEL code

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

is illegal according to the BPEL specification, but allowed by ODE.

The specification defines two standard faults --- `bpel:[conflictingRequest](conflictingrequest.html)` and `bpel:[conflictingReceive](conflictingreceive.html)` --- to deal with two similar error conditions relating to multiple outstanding requests on a single partner-link/operation/messageExchange tuple. ODE 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: ODE currently provides no variable validation.

<a name="WS-BPEL2.0SpecificationCompliance-reply"></a>
### <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.

<a name="WS-BPEL2.0SpecificationCompliance-invoke"></a>
### <[invoke](invoke.html)>
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.

<a name="WS-BPEL2.0SpecificationCompliance-assign"></a>
### <[assign](assign.html)>
The WS-BPEL 2.0 specification requires the <[assign](assign.html)> activity to be atomic. Currently in ODE, each `<copy>` is atomic.

The specification also provides for validating variables at the end of an assignment using the `validate` attribute. ODE does not support this. This means that the `bpel:[invalidVariables](invalidvariables.html)` fault is never thrown by an <[assign](assign.html)> 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. ODE 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](assign.html) for the `<assign>` activity for further details regarding non-standard extensions.

<a name="WS-BPEL2.0SpecificationCompliance-throw"></a>
### <throw>
The `<throw>` activity is fully compliant with the specification.

<a name="WS-BPEL2.0SpecificationCompliance-exit"></a>
### <exit>
The `<exit>` activity is fully compliant with the specification.

<a name="WS-BPEL2.0SpecificationCompliance-wait"></a>
### <wait>
The `<wait>` activity is fully compliant with the specification.

<a name="WS-BPEL2.0SpecificationCompliance-empty"></a>
### <empty>
The `<empty>` activity is fully compliant with the specification.

<a name="WS-BPEL2.0SpecificationCompliance-sequence"></a>
### <sequence>
The `<sequence>` activity is fully compliant with the specification.

<a name="WS-BPEL2.0SpecificationCompliance-if"></a>
### <if>
The `<if>` activity is fully compliant with the specification.

<a name="WS-BPEL2.0SpecificationCompliance-while"></a>
### <while>
The `<while>` activity is fully compliant with the specification.

<a name="WS-BPEL2.0SpecificationCompliance-repeatUntil"></a>
### <repeatUntil>
The `<repeatUntil>` activity is fully compliant with the specification.

<a name="WS-BPEL2.0SpecificationCompliance-forEach"></a>
### <forEach>
The `<forEach>` activity is fully compliant with the specification.  ODE supports both sequential and parallel for-each semantics.

<a name="WS-BPEL2.0SpecificationCompliance-pick"></a>
### <[pick](pick.html)>
The <[pick](pick.html)> activity has the same issues as the <[receive](receive.html)> activity.

<a name="WS-BPEL2.0SpecificationCompliance-flow`"></a>
### <flow>
The `<flow>` activity is fully compliant with the specification.

<a name="WS-BPEL2.0SpecificationCompliance-scope"></a>
### <scope>
Isolated scopes are implemented in ODE's experimental branch (as of September 2007) and will be released in ODE 2.x.

ODE v1.0/1.1 do not support isolated scopes nor do they support "exit on standard fault" semantics. Hence, a BPEL 2.0 process will be interpreted as if  any `isolated` and `exitOnStandardFault` attributes on `<scope>` elements did not exist.

<a name="WS-BPEL2.0SpecificationCompliance-compensate"></a>
### <[compensate](compensate.html)>
The `<compensate>` activity is not compliant with the specification. In ODE, 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  ODE expects one of these attributes must be specified.

<a name="WS-BPEL2.0SpecificationCompliance-compensateScope"></a>
### <compensateScope>
The `<compensateScope>` activity is fully compliant with the specification.

<a name="WS-BPEL2.0SpecificationCompliance-rethrow"></a>
### <rethrow>
The `<rethrow>` activity is fully compliant with the specification.

<a name="WS-BPEL2.0SpecificationCompliance-validate"></a>
### <[validate](validate.html)>
The `<validate>` activity is  _not_  implemented by ODE. Processescontaining such activities will cause a compilation failure.

<a name="WS-BPEL2.0SpecificationCompliance-extensionActivity"></a>
### <extensionActivity>
Activity extension is not supported in ODE. There is an implementation in the ODE experimental branch.