RE: [sca-bpel] ISSUE 20: SCA-BPEL spec can not require bpel:mustUnderstand to be true

http://www.osoa.org/jira/browse/BPEL-20

 

From: Danny van der
Rijn [mailto:] 

Sent: Tuesday, April 29, 2008 3:41
PM

To: 

Subject: [sca-bpel] NEW ISSUE:
Title: SCA-BPEL spec can not require bpel:mustUnderstand to be true

 

TARGET: SCA C+I WS-BPEL spec, General

DESCRIPTION: Section 3 currently reads as follows:

"It is possible to
use WS-BPEL processes in conjunction with SCA, while the processes have no
knowledge of SCA. A few SCA concepts are only available to
WS-BPEL processors that support SCA specific extensions.  The capabilities
that require knowledge of SCA are provided by an SCA extension, which must be
declared in any process definition as follows:

<process ...>

   <extensions>

      <extension

        
namespace="http://docs.oasis-open.org/ns/opencsa/sca-bpel/200801"

        
mustUnderstand="yes" />

   </extensions>

   ...

</process>

"

This is too restrictive.  There should be no requirement on the value of
bpel:mustUnderstand.  Let's examine what the attribute actually
means.  From section 14 of the BPEL spec itself:

" 

If a WS-BPEL processor does not support one or
more of the extensions with mustUnderstand="yes", then the process definition MUST be rejected.

Optional extensions are extensions which the WS-BPEL process MAY ignore. There is no requirement to declare
any optional extensions. Optional extension can be declared using the
extensions element with mustUnderstand="no". The
purpose of allowing optional extensions to be declared using the extensions
element is to provide a well defined location where additional information
about the optional extension can be found.

"

Reading the current language of both specifications, consider the following
edge case:

<process...>

    <extensions>

       <extension namespace="http://docs.oasis-open.org/ns/opencsa/sca-bpel/200801"
mustUnderstand="yes" />

    <extensions/>

    ... a process where NO items from the sca-bpel namespace are
used ...

   OR

   ... a process where sca-bpel items are used, but the processor
need not know about them in order to run ...

</process>

In this case, a "vanilla" BPEL processor will process the file with
no issue.  An SCA-BPEL processor MUST reject the process as invalid, since
the requirement in section 3 is not followed.

This is not correct behavior.  SCA-BPEL processors must accept a superset
of what BPEL processors can process.  To do otherwise would introduce a
nightmare of compatibility issues.

PROPOSAL: change the wording in Section 3 to read as follows

It is possible to use WS-BPEL processes in conjunction with SCA, while the
processes have no knowledge of SCA. A few SCA concepts are only available to
WS-BPEL processors that support SCA specific extensions.  The capabilities
that require knowledge of SCA are provided by an SCA extension, whose namespace
is "http://docs.oasis-open.org/ns/opencsa/sca-bpel/200801". 
An example of using the namespace in a BPEL process is as follows:

<process ...>

   <extensions>

      <extension

        
namespace="http://docs.oasis-open.org/ns/opencsa/sca-bpel/200801"

        
mustUnderstand="yes" />

   </extensions>

   ...

</process>