RE: [sca-bpel] ISSUE 20: SCA-BPEL spec can not require bpel:mustUndersta

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

From: Danny van der Rijn [mailto:dannyv@tibco.com]
Sent: Tuesday, April 29, 2008 3:41 PM
To: sca-bpel@lists.oasis-open.org
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:

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

<extension

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

mustUnderstand="yes" />

</extensions>

...

</process>

sca-bpel message