Author: buildbot
Date: Fri Dec 28 11:35:43 2012
New Revision: 844093
Log:
Staging update by buildbot for ode
Modified:
websites/staging/ode/trunk/content/ (props changed)
websites/staging/ode/trunk/content/ws-bpel-20-specification-compliance.html
Propchange: websites/staging/ode/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Fri Dec 28 11:35:43 2012
@@ -1 +1 @@
-1426460
+1426465
Modified:
websites/staging/ode/trunk/content/ws-bpel-20-specification-compliance.html
==============================================================================
--- websites/staging/ode/trunk/content/ws-bpel-20-specification-compliance.html
(original)
+++ websites/staging/ode/trunk/content/ws-bpel-20-specification-compliance.html
Fri Dec 28 11:35:43 2012
@@ -86,7 +86,7 @@
<p>This page provides information on ODE's compliance to the final
<a href="ws-bpel-2.0.html">WS-BPEL 2.0</a> specification released by OASIS. ODE
also implements [a few extensions|BPEL Extensions] we deemed necessary.</p>
<p><a name="WS-BPEL2.0SpecificationCompliance-StaticAnalysis"></a></p>
<h2 id="static-analysis">Static Analysis</h2>
-<p>In this section the divergenced from the specification relating to static
analysis requirements are described. </p>
+<p>In this section the divergenced from the specification relating to static
analysis requirements are described.</p>
<p><a name="WS-BPEL2.0SpecificationCompliance-Variables"></a></p>
<h2 id="variables">Variables</h2>
<p><a name="WS-BPEL2.0SpecificationCompliance-Initialization"></a></p>
@@ -97,32 +97,32 @@
<p>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 <a
href="external-variables.html">External Variables</a> for more information.</p>
<p><a name="WS-BPEL2.0SpecificationCompliance-Activities"></a></p>
<h2 id="activities">Activities</h2>
-<p>In this section the divergences from the specification for each standard
BPEL activity are described. </p>
+<p>In this section the divergences from the specification for each standard
BPEL activity are described.</p>
<p><a
name="WS-BPEL2.0SpecificationCompliance-<code><[receive](receive.html)></code>"></a></p>
-<h3 id="receivereceivehtml"><code><[receive](receive.html)></code></h3>
+<h3 id="wzxhzdk13receivewzxhzdk14"><pre><<a
href="receive.html">receive</a>></pre></h3>
<p>There are several major issues with support for the
<code><receive></code> activity.</p>
-<p>ODE does not yet support the <code><fromPart></code> syntax.
Therefore, the <code>variable</code> attribute must be used. Furthermore, only
message variables can be referenced with the <code>variable</code> attribute,
whereas the <a href="ws-bpel-2.0.html">specification</a> permits referencing of
an element-typed variable if the WSDL for the request message contains a single
element-typed part. </p>
-<p>Multiple start activities as described in section 10.4, and 15.4 of the <a
href="ws-bpel-2.0.html">specification</a>) are not officially supported. This
precludes the use of <code>initiate="join"</code>. </p>
-<p>ODE does not provide the ordering guarantees described in section 10.4 of
the <a href="ws-bpel-2.0.html">specification</a>. Also, it does not enforce the
ordering requirements described in the same section. Hence, the BPEL code </p>
-<div class="codehilite"><pre><span class="nt"><flow></span>
- <span class="nt"><receive</span> <span class="err">...</span> <span
class="na">createInstance=</span><span class="s">"yes"</span> <span
class="nt">/></span>
- <span class="nt"><assign</span> <span class="err">...</span> <span
class="nt">/></span>
+<p>ODE does not yet support the <code><fromPart></code> syntax.
Therefore, the <code>variable</code> attribute must be used. Furthermore, only
message variables can be referenced with the <code>variable</code> attribute,
whereas the <a href="ws-bpel-2.0.html">specification</a> permits referencing of
an element-typed variable if the WSDL for the request message contains a single
element-typed part.</p>
+<p>Multiple start activities as described in section 10.4, and 15.4 of the <a
href="ws-bpel-2.0.html">specification</a>) are not officially supported. This
precludes the use of <code>initiate="join"</code>.</p>
+<p>ODE does not provide the ordering guarantees described in section 10.4 of
the <a href="ws-bpel-2.0.html">specification</a>. Also, it does not enforce the
ordering requirements described in the same section. Hence, the BPEL code</p>
+<div class="codehilite"><pre><span class="nt"><flow></span>
+ <span class="nt"><receive</span> <span class="err">...</span> <span
class="na">createInstance=</span><span class="s">"yes"</span> <span
class="nt">/></span>
+ <span class="nt"><assign</span> <span class="err">...</span> <span
class="nt">/></span>
<span class="nt"></flow></span>
</pre></div>
-<p>is illegal according to the BPEL specification, but allowed by ODE. </p>
-<p>The specification defines two standard faults ---
<code>bpel:[conflictingRequest](conflictingrequest.html)</code> and
<code>bpel:[conflictingReceive]</code> --- 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 <code>conflictingReceive</code> is thrown whenever
either of the conditions occurs. That is to say, in certain cases a
<code>conflictingReceive</code> indicates a <code>conflictingRequest</code>,
and <code>conflictingRequest</code> is never thrown. </p>
+<p>is illegal according to the BPEL specification, but allowed by ODE.</p>
+<p>The specification defines two standard faults ---
<code>bpel:[conflictingRequest](conflictingrequest.html)</code> and
<code>bpel:[conflictingReceive]</code> --- 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 <code>conflictingReceive</code> is thrown whenever
either of the conditions occurs. That is to say, in certain cases a
<code>conflictingReceive</code> indicates a <code>conflictingRequest</code>,
and <code>conflictingRequest</code> is never thrown.</p>
<p>Finally, the <code>validate</code> attribute --- if present --- is ignored:
ODE currently provides no variable validation.</p>
<p><a
name="WS-BPEL2.0SpecificationCompliance-<code><[reply](reply.html)></code>"></a></p>
<h3 id="replyreplyhtml"><code><[reply](reply.html)></code></h3>
-<p>The conformance issues with the <code><reply></code> activity mirror
those of the <code><receive></code> activity as described above: the
<code><toPart></code> syntax is not supported, and <code>variable</code>
attributes must reference message-typed variables. </p>
+<p>The conformance issues with the <code><reply></code> activity mirror
those of the <code><receive></code> activity as described above: the
<code><toPart></code> syntax is not supported, and <code>variable</code>
attributes must reference message-typed variables.</p>
<p><a
name="WS-BPEL2.0SpecificationCompliance-<code><[invoke](invoke.html)></code>"></a></p>
<h3 id="invokeinvokehtml"><code><[invoke](invoke.html)></code></h3>
-<p>Again, as in the <code><receive>></code> and
<code><reply></code> activities, the <code><toPart>></code> and
<code><fromPart>></code> syntax are not supported. Similarly, the
<code>inputVariable</code> and <code>outputVariable</code> attributes must
reference message-typed variables. Here too, the <code>validate</code>
attribute is ignored. </p>
+<p>Again, as in the <code><receive>></code> and
<code><reply></code> activities, the <code><toPart>></code> and
<code><fromPart>></code> syntax are not supported. Similarly, the
<code>inputVariable</code> and <code>outputVariable</code> attributes must
reference message-typed variables. Here too, the <code>validate</code>
attribute is ignored.</p>
<p><a
name="WS-BPEL2.0SpecificationCompliance-<code><[assign](assign.html)></code>"></a></p>
<h3 id="assignassignhtml"><code><[assign](assign.html)></code></h3>
-<p>The WS-BPEL 2.0 specification requires the
<code><[assign](assign.html)></code> activity to be atomic. Currently in
ODE, each <code><copy></code> is atomic. </p>
+<p>The WS-BPEL 2.0 specification requires the
<code><[assign](assign.html)></code> activity to be atomic. Currently in
ODE, each <code><copy></code> is atomic.</p>
<p>The specification also provides for validating variables at the end of an
assignment using the <code>validate</code> attribute. ODE does not support
this. This means that the
<code>bpel:[invalidVariables](invalidvariables.html)</code> fault is never
thrown by an <code><[assign]></code> activity.</p>
<p>Inline assignment as part of the variable declaration isn't currently
supported.</p>
<p>ODE currently uses the <code>expressionLanguage</code> attribute to
determine the language used in assignments instead of using the
<code>queryLanguage</code> attribute.</p>
@@ -162,15 +162,14 @@
<p>The <code><flow></code> activity is fully compliant with the
specification.</p>
<p><a
name="WS-BPEL2.0SpecificationCompliance-<code><[scope](scope.html)></code>"></a></p>
<h3 id="scopescopehtml"><code><[scope](scope.html)></code></h3>
-<p>Isolated scopes are implemented in ODE trunk (as of September 2007) and
will be released in ODE 1.2/2.0.<br />
-</p>
+<p>Isolated scopes are implemented in ODE trunk (as of September 2007) and
will be released in ODE 1.2/2.0.</p>
<p>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 <code>isolated</code> and <code>exitOnStandardFault</code> attributes on
<code><scope></code> elements did not exist.</p>
<p><a
name="WS-BPEL2.0SpecificationCompliance-<code><[compensate](compensate.html)></code>"></a></p>
<h3
id="compensatecompensatehtml"><code><[compensate](compensate.html)></code></h3>
-<p>The <code><compensate></code> activity is not compliant with the
specification. In ODE, this activity has the same effect and syntax as
<code><compensateScope></code>. In addition, the <code>scope</code>
attribute may be used in place of the <code>target</code> attribute with the
same effect; and ODE expects one of these attributes must be specified. </p>
+<p>The <code><compensate></code> activity is not compliant with the
specification. In ODE, this activity has the same effect and syntax as
<code><compensateScope></code>. In addition, the <code>scope</code>
attribute may be used in place of the <code>target</code> attribute with the
same effect; and ODE expects one of these attributes must be specified.</p>
<p><a
name="WS-BPEL2.0SpecificationCompliance-<code><[compensateScope](compensatescope.html)></code>"></a></p>
<h3
id="compensatescopecompensatescopehtml"><code><[compensateScope](compensatescope.html)></code></h3>
-<p>The <code><compensateScope></code> activity is fully compliant with
the specification. </p>
+<p>The <code><compensateScope></code> activity is fully compliant with
the specification.</p>
<p><a
name="WS-BPEL2.0SpecificationCompliance-<code><[rethrow](rethrow.html)></code>"></a></p>
<h3 id="rethrowrethrowhtml"><code><[rethrow](rethrow.html)></code></h3>
<p>The <code><rethrow></code> activity is fully compliant with the
specification.</p>
