WS BPEL public review issues list

This file last updated 22:51 31 Oct 2006 (UTC)

This is the issues list for the public review of the WS-BPEL 2.0 specification, maintained on behalf of the OASIS Web Services Business Process Execution Language Technical Committee. This review issues list is posted as a TC document to the OASIS WSBPEL TC pages on a regular basis (if it has changed). The current edition, as a TC document, is the most recent version of the document Current WS-BPEL Review Issues List in the "Issues" folder of the WSBPEL TC document list - the uri for this document includes the document number generated by the upload process. The list editor's working copy, which will always at least as recent as the formal upload and will usually include later updates, is available at this constant URI (which can thus be used as the base for the anchors to individual issue entries of the form "IssueRNN").

Comments received on the public comment list will generally be made issues on this list - the Origin field is used to identify these issues. Members of the TC can send issue proposals to the chairs, copying the issue list editor peter@furniss.co.uk. (The Submitter field identifies the TC member submitting the issue).

The issues list used in progressing the WS-BPEL spec to public review is now closed.

• Table of accepted, but unresolved issues, including issues with proposed resolutions
• Table of potential issues submitted to but not yet accepted by the TC
• Table of issues changed or added recently
• Table of all issues, ordered by issueID
  
  
• Detailed list of issues. The issues in this list have anchors of the form "IssueR1", "IssueR22".

Unresolved issues (open or resolution proposed)

Proposed issues - the TC has yet to decide if these should be opened for discussion or can be dealt with summarily

There are no resolved issues awaiting editing into spec

Issues changed or added since 22 Oct 2006

All issues, in order

The colour of the issue title is determined by the status: maroon=resolution proposed (4 issues), green=resolved (19 issues), purple=received (4 issues). (Those numbers count sub-issues as separate.) According to the TC issue procedures (issues process document), the formal status values are "open" and "resolved". The "In spec" entry in resolved issues indicates that the required editting has been checked into the repository version of the text, on or before the date given. Note that such changes are NOT reflected in the fixed public review text.

Issue R1: keepSrcElement behavior for virtual <assign>'s

The recent work on Issue 280 got me thinking about keepSrcElement as it relates to the virtual assigns used to describe the behavior of <fromParts>, <toParts>, and receiving into or transmitting an element variable.

Section 10.3 describes invoking with an element variable as equivalent to declaring an anonymous temporary WSDL message variable and using the element’s value to “set the value of the part”. It is reasonable to assume that the spec here is referencing the <assign> rules but it is not explicit.

Section 10.3.1 describes invoking with <toParts> as working as a single virtual <assign> using the same rules as the real <assign>. There is a normative MUST in this section which precludes the possibility of applying the keepSrcElement behavior since it is off by default on the real <copy>.

The lack of the keepSrcElement behavior for these virtual <assign>’s means that the root element of the variable being sent or received may change when it is copied to or from the WSDL message. This is definitely the behavior with <fromPart> and <toPart> and could be interpreted as being the behavior of the element variants of web service activities.
Submitter's proposal: I’d like to see the keepSrcElement behavior enabled for these virtual <assign>’s. Dieter has suggested adding “keepSrcElement” to the <fromPart> and <toPart> elements to control this behavior. I’m agreeable to this but we still need to handle the element style invokes and receives. If we want the behavior to be configurable as opposed to always enabled then perhaps we could add the keepSrcElement attribute to the web service activities as well.
Proposed resolution: Mark Ford, 25 Oct 2006
Links: Announcement, 7 Aug 2006     Mark Ford, 6 Oct 2006     Proposed resolution (Mark Ford, 25 Oct 2006)     Danny van der Rijn, 25 Oct 2006     Mark Ford, 25 Oct 2006     Danny van der Rijn, 25 Oct 2006     Mark Ford, 25 Oct 2006
Changes: 4 Aug 2006 - new issue;    16 Aug 2006 - fields: Links;    10 Sep 2006 - fields: Status, Note;    20 Sep 2006 - fields: Status;    6 Oct 2006 - fields: Links;    25 Oct 2006 - fields: Links, Status, Proposed resolution;    30 Oct 2006 - fields: Links

Issue R2: Zero or Negative Duration Values

The WS-BPEL 2.0 specification (public review draft) is silent w.r.t. the behavior if a specified duration has a zero or negative value.
Submitter's proposal: I propose that language is added which specifies that

1. wait and onAlarm are immediately executed if a specified duration has a zero or negative value
2. zero or negative values are disallowed for repeatEvery

10.7. Delayed Execution - Wait Add to the end of the first paragraph: "If a specified duration value is zero or negative then the wait activity completes immediately."

11.5. Selective Event Processing – Pick Add to the end of the second bullet in the second paragraph: "If a specified duration value is zero or negative then <onAlarm> event occurs immediately. Again, the handling of race conditions is implementation dependent."

12.7.2. Alarm Events Add after the fourth sentence in the first paragraph: "If the specified duration value is zero or negative then the <onAlarm> event is executed immediately.". Add to the end of the first paragraph: "If the specified duration value is zero or negative then the standard fault bpel:invalidExpressionValue MUST be thrown."

12.7.4.1. Alarm Events Add to the end of the first paragraph: "If the specified duration value is zero or negative then the standard fault bpel:invalidExpressionValue MUST be thrown."

Text as in Dieter Koenig1, 26 Sep 2006
Links: Announcement, 10 Sep 2006     Proposed resolution (Dieter Koenig1, 21 Sep 2006)     Proposed resolution (Dieter Koenig1, 26 Sep 2006)
Changes: 10 Sep 2006 - new issue;    19 Sep 2006 - fields: Links;    20 Sep 2006 - fields: Status;    21 Sep 2006 - fields: Links, Status, Proposed resolution;    26 Sep 2006 - fields: Links, Status, Proposed resolution;    4 Oct 2006 - fields: Change status, Status, Proposed resolution, Resolution;    25 Oct 2006 - fields: In spec

Issue R3: Appendix H - earlier members need to be added

Among others, the following original BPEL4WS 1.1 authors are not listed - (checks need to be made whether they actually joined the TC)

• Tony Andrews, Microsoft
• Hitesh Dholakia, Siebel Systems
• Yaron Goland, BEA
• Johannes Klein, Microsoft
• Frank Leymann, IBM
• Dieter Roller, IBM
• Doug Smith, Siebel Systems
• Sanjiva Weerawarana, IBM

Issue R4: missing namespace prefix declaration in Section 15.4.1

Issue R5: Wrong namespace in Section 13.1.2

From the Action Item:

This section has a process snippet that introduces the "abstractProcessProfile" attribute. The xmlns for the process element is http://docs.oasis-open.org/wsbpel/2.0/process/executable but it should be http://docs.oasis-open.org/wsbpel/2.0/process/abstract

Issue R6: TOC is messed up in PDF version

The highest page number that the PDF TOC refers to is '3'

The TOC should have been regenerated prior to creating the PDF.
Resolution: Decided conf call 20 Sep 2006
Sent to editors for correction

Since the correction only concerns the final production of the alternative forms of the document, no editing is required.
Links: Announcement, 15 Sep 2006
Changes: 15 Sep 2006 - new issue;    19 Sep 2006 - fields: Links;    20 Sep 2006 - fields: Status, Resolution;    21 Sep 2006 - fields: In spec, Resolution;    4 Oct 2006 - fields: Change status

Issue R7: Figure 1 truncated in XHTML

Since the correction only concerns the final production of the alternative forms of the document, no editing is required.
Links: Announcement, 15 Sep 2006
Changes: 15 Sep 2006 - new issue;    19 Sep 2006 - fields: Links;    20 Sep 2006 - fields: Status, Resolution;    21 Sep 2006 - fields: In spec, Resolution;    4 Oct 2006 - fields: Change status

Issue R8: Create separate isolation domain for isolated scope's compensation handler

As the proposal in Alex Yiu, 20 Oct 2006
Links: Announcement, 18 Sep 2006     Alex Yiu, 4 Oct 2006     Mark Ford, 6 Oct 2006     Proposed resolution (Alex Yiu, 10 Oct 2006)     Proposed resolution (Alex Yiu, 18 Oct 2006)     Dieter Koenig1, 18 Oct 2006     Alex Yiu, 20 Oct 2006
Changes: 18 Sep 2006 - new issue;    19 Sep 2006 - fields: Links;    20 Sep 2006 - fields: Status;    4 Oct 2006 - fields: Links;    6 Oct 2006 - fields: Links;    11 Oct 2006 - fields: Links, Status, Proposed resolution;    18 Oct 2006 - fields: Links, Status, Proposed resolution;    21 Oct 2006 - fields: Links;    31 Oct 2006 - fields: Status, In spec, Proposed resolution, Resolution

Issue R9: Remove LED Comment on eventHandlers declaration

<xsd:documentation>
       Child element onAlarm needs to be a LED, because there is another
       onAlarm element defined for the pick activity.
</xsd:documentation> 

This is only interesting to XSD authors, and so probably not for the general audience.
Submitter's proposal: Remove the comment
Resolution: Proposed in Diane Jordan, 4 Oct 2006, agreed conf call 4 Oct 2006

Text as in Diane Jordan, 4 Oct 2006
Links: Announcement, 19 Sep 2006     Danny van der Rijn, 19 Sep 2006     Danny van der Rijn, 20 Sep 2006     Alex Yiu, 20 Sep 2006     Diane Jordan, 4 Oct 2006
Changes: 19 Sep 2006 - new issue;    19 Sep 2006 - fields: Links;    20 Sep 2006 - fields: Status, Links;    4 Oct 2006 - fields: Status, Change status, Resolution, Links;    25 Oct 2006 - fields: In spec

Issue R10: Definition of IMA scope

I would like to request to open a review issue to improve the ease of understanding of the spec. The discussion was under the thread of subject: "A possible issue concerning the definition of IMA scope" started by Ron Ten-Hove.

If the issue is passed, we would just need to refine some cross-referencing of terms and bookmark.
Submitter's proposal:

Besides 10.4.1, another relevant part of IMA and message exchange handling is in section 12.2:

12.2. Message Exchange Handling

When the primary activity and the event handlers of a <scope> complete then all Web service interactions dependent on partner links or message exchanges declared inside of the <scope> need to be completed. An orphaned IMA occurs when an IMA using a partner link or message exchange, declared in the completing <scope> or its descendants, remains open. ....

I would suggest to do a brief update in 10.1.4 from:

Further if an open IMA goes out of scope prior to being closed

Further if an open IMA goes out of scope (known as an orphaned IMA) prior to being closed

(see section 12. Scopes for other details of bpel:missingReply).

(see section 12.2 Message Exchange Handling for other details of bpel:missingReply and orphaned IMA).

Text as in Alex Yiu, 22 Sep 2006
Links: Ron Ten-Hove, 23 Aug 2006     Danny van der Rijn, 23 Aug 2006     Alex Yiu, 23 Aug 2006     Monica J. Martin, 23 Aug 2006     Announcement, 19 Sep 2006     proposed resolution
Changes: 19 Sep 2006 - new issue;    19 Sep 2006 - fields: Links;    20 Sep 2006 - fields: Status;    25 Sep 2006 - fields: Proposed resolution, Status, Links;    4 Oct 2006 - fields: Change status, Status, Proposed resolution, Resolution;    25 Oct 2006 - fields: In spec

Issue R11: Section 12.7 Duplicated (Two Sections)

12.7. Event Handlers 12.7. Isolated Scopes
Proposed resolution: Verify and correct. Also, may need to verify and update other related section reference inconsistencies. Note, this Section 12.7 numbering change may affect at a minimum:

1. Sections subsequent to 12.7 Event Handlers
2. All references through the specification that reference those sections in 1. including any for static analysis where applicable.

Issue R12: Isolated Scopes

The isolated attribute of a scope, when set to "yes", provides control of concurrent access to shared resources: variables, partner links, and control dependency links. Its default value is "no". Such a scope is called an isolated scope.

The isolated attribute of a scope, when set to "yes", provides control of concurrent access to shared resources: variables, partner links, and control dependency links. Such a scope is called an isolated scope. The default value of the isolated attribute is "no".

Issue R13: BPEL partner link assignments

For the purpose of discussion, I'm considering a simple "router" process (R). The one operation exposed by this process includes 2 parts:

1. an amount (xsd:int)
2. the EPR of the requesting process (process REQ)

Based on content in the incoming request, the router chooses a process (process B) to "forward" the request to. Process B is expected to invoke an agreed upon operation on Process REQ, using the EPR information in the message.

There are 2 possible implementations:

1. The router process assigns from the receiving partner link to a variable (or message part) which is then relayed to process B. Process B then performs its activities and assigns this value to the a partner link which it uses to invoke an operation on REQ.
2. REQ is responsible to assign from "myrole" on the partner link facing the router into the a message it eventually sends it.

Based on my reading of the 8/23 draft, both implementations are supported.

The questions for which I have no clear answer are:

1. Is implementation option a) supported ?

   Assuming it is, the spec in silent on IMA activities affecting the partner link for the purpose of assign activities, and the lifetime of the partner link value.

   My expectation would be that once an IMA activity has completed, assigning from the partner link would yield the reply-to EPR.

   Would this also require the partner link variants of the Assign activity to include a messageExchange attribute.

2. Assuming the above is valid, what would the schema type of the variable( or message part) into which the EPR is assigned be? serf:service-reference - in the case of message part, this would cause BPEL specific types to be "leaked" into the abstract WSDL. wsa:endpoint-reference - this would bind the BPEL process to a specific addressing scheme.

   In either case, it would be useful for the spec to be specific about this point (and an example would be great).

3. Section 6.3 ("Endpoint References")states:

   The <sref:service-ref> element is not always exposed to WS-BPEL process definitions. For example, it is not exposed in an assignment from the endpoint reference of myRole of partnerLink-A to that of partnerRole of partnerLink-B. On the contrary, it is exposed in an wsbpel-specification-assignment from a messageType or element based variable through expression or from a literal <sref:service-ref>.

   Section 8.4.3 states that the following is not a valid assignment: the selection result of the from-spec is a variable of a WSDL message type and that of the to-spec is not, or vice versa (parts of variables, selections of variable parts, or endpoint references cannot be assigned to/from variables of WSDL message types directly).

   It is not clear if these to sections are contradicting.

   If assignments to/from partner links is allowed (which is explicitly stated in section 8.4), what are the valid combinations?

close with no change. Explanation has been provided to address the questions raised by this comment. TC doesn't see a need for further action.
Links: Announcement, 20 Sep 2006     Dieter Koenig1, 22 Sep 2006     Dieter Koenig1, 25 Sep 2006     James Pasley, 25 Sep 2006     Danny van der Rijn, 25 Sep 2006     Dieter Koenig1, 26 Sep 2006     Diane Jordan, 16 Oct 2006     Diane Jordan, 23 Oct 2006
Changes: 20 Sep 2006 - new issue;    21 Sep 2006 - fields: Links;    22 Sep 2006 - fields: Links;    25 Sep 2006 - fields: Links;    26 Sep 2006 - fields: Links;    17 Oct 2006 - fields: Links;    25 Oct 2006 - fields: Status, In spec, Resolution, Links

Issue R14: Reference source not found in section 12.4

A fault inside a termination handler MUST NOT be not propagated to the enclosing scope (see section Error! Reference source not found.). Other than that, all of the statements about fault handlers apply to termination handlers as well.

The section link should be fixed. This applies to the HTML and PDF versions. Other versions might be affected too.

There are also broken links in 11.7 and 12.5
Resolution: Proposed and agreed, conf call 4 Oct 2006

Referred to editors for fixing
Links: Announcement, 21 Sep 2006
Changes: 21 Sep 2006 - new issue;    22 Sep 2006 - fields: Links;    4 Oct 2006 - fields: Status, Change status, Resolution;    25 Oct 2006 - fields: In spec

Issue R15: Fix description of abnormal process completion

Thanks to Monica for finding this inconsistency and Alex for providing some edits.
Submitter's proposal:

Change paragraph in Section 5.5 FROM:

A business process instance ends either normally or abnormally. The process ends normally when the main activity of the process completes. The process ends abnormally if either:

• a fault reaches the process scope, regardless of whether it is handled or not (see section 10.10. Immediately Ending a Process – Exit), or
• the process instance is explicitly ended by an exit activity (see section 10.10. Immediately Ending a Process).

TO:

A business process instance ends either normally or abnormally. The process ends normally when the main activity of the process completes. The process ends abnormally if either:

• a process level (explicit or default) fault handler completes or
• the execution of a process level fault handler itself faults (the effect of this particular case is similar to an <exit> activity or
• the process instance is explicitly ended by an exit activity (see section 10.10. Immediately Ending a Process).

As the proposal in Alex Yiu, 20 Oct 2006 with the amendment in Dieter Koenig1, 25 Oct 2006
Links: Alex Yiu, 4 Oct 2006     Alex Yiu, 4 Oct 2006     Danny van der Rijn, 4 Oct 2006     Danny van der Rijn, 4 Oct 2006     Announcement, 4 Oct 2006     Alex Yiu, 20 Oct 2006     Mark Ford, 20 Oct 2006     Monica J. Martin, 20 Oct 2006     Proposed resolution (Alex Yiu, 20 Oct 2006)     Proposed resolution (Dieter Koenig1, 25 Oct 2006)
Changes: 26 Sep 2006 - new issue;    4 Oct 2006 - fields: Status, Links;    6 Oct 2006 - fields: Links;    21 Oct 2006 - fields: Links, Status, Proposed resolution;    30 Oct 2006 - fields: Links, Status, Proposed resolution;    31 Oct 2006 - fields: In spec, Status, Proposed resolution, Resolution

Issue R16: confusing description of Message Exchange Handling

• If a fault handler has completed without any unhandled fault then a check for orphaned IMA’s MUST be made. If any orphaned IMA is detected then a new bpel:missingReply is thrown to the parent scope (similar to throwing or rethrowing other faults from a fault handler). However, if the fault handler is handling a bpel:missingReply fault and no new IMA's were created and left open by the fault handler, the new fault MUST NOT be generated and thrown. The newly thrown bpel:missingReply fault MUST encompass all orphaned IMA's. When the bpel:missingReply fault is thrown, all the orphaned IMA's are encompassed by the fault and are no longer considered orphaned.

I get lost after the second sentence. What fault is the 3rd sentence referring to? If it MUST NOT be generated and thrown, then what is the point of the 4th sentence?
Proposed resolution: Danny van der Rijn, 26 Oct 2006
Links: Proposed resolution (Danny van der Rijn, 4 Oct 2006)     Announcement, 4 Oct 2006     Mark Ford, 6 Oct 2006     Danny van der Rijn, 6 Oct 2006     Mark Ford, 6 Oct 2006     Danny van der Rijn, 6 Oct 2006     Proposed resolution (Danny van der Rijn, 26 Oct 2006)
Changes: 26 Sep 2006 - new issue;    4 Oct 2006 - fields: Links, Status, Proposed resolution;    6 Oct 2006 - fields: Links;    31 Oct 2006 - fields: Proposed resolution, Links

Issue R17: Schema for abstract processes is not valid

<xsd:complexType name="tOnAlarmEvent">
 <xsd:complexContent>
   <xsd:extension base="tExtensibleElements">
     <xsd:sequence>
       <xsd:choice>
         <xsd:sequence>
           <xsd:group ref="forOrUntilGroup" minOccurs="0"/>
           <xsd:element ref="repeatEvery" minOccurs="0"/>
         </xsd:sequence>
         <xsd:element ref="repeatEvery" minOccurs="0"/>
       </xsd:choice>
       <xsd:element ref="scope" minOccurs="0"/>
     </xsd:sequence>
   </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

This is not valid XML schema, because the content model is not deterministic. If in an instance document the first child element is <bpel:repeatEvery> it's not clear which path in the schema applies. Within the choice it can be either be the sequence path (forOrUntilGroup's minOccurs="0" allows that) or the second repeatEvery element reference path.
Submitter's proposal: The schema for abstract processes needs to be changed with the result that the content model is deterministic. I propose to replace the complex type found in the description above with the following complex type:

<xsd:complexType name="tOnAlarmEvent">
 <xsd:complexContent>
   <xsd:extension base="tExtensibleElements">
     <xsd:sequence>
       <xsd:group ref="forOrUntilGroup" minOccurs="0"/>
       <xsd:element ref="repeatEvery" minOccurs="0"/>
       <xsd:element ref="scope" minOccurs="0"/>
     </xsd:sequence>
   </xsd:extension>
 </xsd:complexContent>
</xsd:complexType> 

The copy of the schema in the appendix of the specification needs to be changed accordingly.
Resolution: Decided conf call, 18 Oct 2006

As submitter's proposal
Links: Announcement, 4 Oct 2006
Changes: 4 Oct 2006 - new issue;    6 Oct 2006 - fields: Links;    25 Oct 2006 - fields: In spec, Status, Change status, Resolution

Issue R18: Uniqueness of WSDL Faults

portType pT
    operation op
          input element = "a:b"
          output element = "a:c"
          fault name="fault1" element = "a:fault"
          fault name="fault2" element = "a:fault"

Most WSDL transports (e.g. SOAP) do not tranport fault names on the wire. Usually all that is transmitted is the "a:fault" element, wrapped in some information that does not include the fault name.

Yet 10.3 states that "This results in a fault identified in WS-BPEL by a QName formed by the target namespace of the corresponding port type and the fault name." We have no way of deriving, in this case, whether we're talking about foo:fault1 or foo:fault2.

Possible resolutions include

• changing the fault catching behavior to not use fault name, but its data type
• disallowing WSDLs that use the same element in more than one fault in an operation. (In the whole WSDL?)
• explicitly specifying rules for inferring fault names. For example, we could say that "a:fault" will always be turned into "foo:fault1" and "foo:fault2" will never be inferred.

Change 10.3, page 86 from

In WSDL it is possible to declare an operation that declares more than one fault using the same data type. Certain WSDL bindings do not provide enough information for the WS-BPEL process to infer which fault was intended. In this case, the WS-BPEL process MUST infer the first fault declared for the operation that matches the transmitted data. A result of this requirement is that a process may have different behavior when deployed against different bindings.

In WSDL it is possible to define an operation that declares more than one fault using the same data type. Certain WSDL bindings do not provide enough information for the WS-BPEL processor to determine which fault was intended. In this case, the WS-BPEL processor MUST select the fault that: Matches the transmitted data and Occurs first in lexical order in the operation definition A result of this requirement is that a process, which uses the <catch> construct based on faultName and deals with such an operation definition, may have different behavior when deployed against different bindings.

and section 3, P. 11 change to

While WS-BPEL attempts to provide as much compatibility with WSDL 1.1 as possible there are three areas where such compatibility is not feasible. Fault naming with its restriction, as discussed later in this document (see section 10.3 Involing Web service operations)

Issue R19: Syntax-fault in example on page 168

<invoke partnerLink="customer"
    operation="shippingNotice"
    inputVariable="shipNotice" />
<correlations>
    <correlation set="shipOrder" pattern="request" /> </correlations> </invoke>

<invoke partnerLink="customer"
    operation="shippingNotice"
    inputVariable="shipNotice">
    <correlations>
        <correlation set="shipOrder" pattern="request" />
    </correlations>
</invoke>

As submitter's proposal
Links: Announcement, 11 Oct 2006
Changes: 11 Oct 2006 - new issue;    12 Oct 2006 - fields: Links;    25 Oct 2006 - fields: Status, Change status, Resolution, In spec

Issue R20: Fault handling example in Section 12.5 is incorrect

I also don’t think the text below the example should reference the catch logic via xml-syntax. Change <catch>-logic-A to catch-logic-A since that is what appears in the example.
Submitter's proposal:

Change from:

For example, foo:Elem1, foo:Elem2, foo:Elem3, foo:Elem4, foo:Elem5 are all globally declared elements. Elem2 is declared with its substitutionGroup attribute referring to Elem1. The same relationship is declared between Elem3 and Elem2, and between Elem4 and Elem3, and between Elem5 and Elem4. Consider a scope with the following fault handlers:

<scope>
  <faultHandlers>
    <catch faultName="foo:BarFaultName" faultElement="foo:Elem2">
      ... catch-logic-A ...
    </catch>
    <catch faultName="foo:BarFaultName" faultElement="foo:Elem4">
      ... catch-logic-B ...
    </catch>
    <catch faultName="foo:BarFaultName">
      ... catch-logic-C ...
    </catch>
  </faultHandlers>
</scope>

If the fault data element is “foo:Elem5”, the <catch>-logic-A based on “foo:Elem4” will be matched. If fault data element is “foo:Elem3”, the <catch>-logic-B based on “foo:Elem2” will be matched. If fault data element is “foo:Elem1”, the <catch>-logic-C will be matched.

For example, foo:Elem1, foo:Elem2, foo:Elem3, foo:Elem4, foo:Elem5 are all globally declared elements. Elem2 is declared with its substitutionGroup attribute referring to Elem1. The same relationship is declared between Elem3 and Elem2, and between Elem4 and Elem3, and between Elem5 and Elem4. Consider a scope with the following fault handlers:

<scope>
  <faultHandlers>
    <catch faultName="foo:BarFaultName" faultElement="foo:Elem2">
      ... catch-logic-A ...
    </catch>
    <catch faultName="foo:BarFaultName" faultElement="foo:Elem4">
      ... catch-logic-B ...
    </catch>
    <catch faultName="foo:BarFaultName">
      ... catch-logic-C ...
    </catch>
  </faultHandlers>
</scope>

If the fault data element is “foo:Elem5”, the catch-logic-B based on “foo:Elem4” will be matched. If fault data element is “foo:Elem3”, the catch-logic-A based on “foo:Elem2” will be matched. If fault data element is “foo:Elem1”, the catch-logic-C will be matched.

As submitter's proposal
Links: Announcement, 16 Oct 2006
Changes: 16 Oct 2006 - new issue;    17 Oct 2006 - fields: Links;    25 Oct 2006 - fields: In spec, Status, Change status, Resolution

Issue R21: Static Analysis requirement for Variable Reference Resolution, Section 12.7.1 and Appendix B

The variable references are resolved to the associated scope only and MUST NOT be resolved to the ancestor scopes.

Note, this text already exists as stated in Section 12.7.1.
Proposed resolution: Monica J. Martin, 23 Oct 2006
Links: Announcement, 16 Oct 2006     Proposed resolution (Monica J. Martin, 23 Oct 2006)
Changes: 16 Oct 2006 - new issue;    17 Oct 2006 - fields: Links;    25 Oct 2006 - fields: Links, Status, Proposed resolution

Issue R22: <rethrow> of Fault Name and Fault Data Where Present

The <rethrow> activity is used in fault handlers to rethrow the fault they caught. It can be used only within a fault handler (<catch> and <catchAll>). Modifications to the fault data MUST be ignored by <rethrow>. For example, if the logic in a fault handler modifies the fault data and then call <rethrow>, the original fault data would be rethrown and not the modified fault data. Similarly if a fault is caught using the shortcut that allows message type faults with one part defined using an element to be caught by fault handlers looking for the same element type, then a <rethrow> would rethrow the original message type data (see section 12.5. Fault Handlers).

The <rethrow> activity is used in fault handlers to rethrow the fault they caught, i.e. the fault name and fault data of the original fault where present. It can be used only within a fault handler (<catch> and <catchAll>). Modifications to the fault data MUST be ignored by <rethrow>. For example, if the logic in a fault handler modifies the fault data and then call <rethrow>, the original fault data would be rethrown and not the modified fault data. Similarly if a fault is caught using the shortcut that allows message type faults with one part defined using an element to be caught by fault handlers looking for the same element type, then a <rethrow> would rethrow the original message type data (see section 12.5. Fault Handlers).

As proposed in Monica J. Martin, 18 Oct 2006
Links: Announcement, 17 Oct 2006     Proposed resolution (Monica J. Martin, 18 Oct 2006)
Changes: 17 Oct 2006 - new issue;    18 Oct 2006 - fields: Links, Status, Resolution;    25 Oct 2006 - fields: Status, Change status, Resolution, In spec

Issue R23: Clarification on Schema Variable Validation

As submitter's proposal
Links: referenced pdf document (document details)     Announcement, 17 Oct 2006
Changes: 17 Oct 2006 - new issue;    17 Oct 2006 - fields: Links;    18 Oct 2006 - fields: Links;    25 Oct 2006 - fields: Status, Change status, Resolution, In spec

Issue R24: Externally referenced locally-scoped partnerLinks

However, the last sentence of section 6.2 says:

The initial binding information of a <partnerLink> can be set as a part of business process deployment, regardless of whether it is declared on the <process> or <scope> element level.

What identifier should deployment descriptors use to reference these locally-scoped partnerLinks for the purpose of initializePartnerRole?
Links: Announcement, 17 Oct 2006     Dieter Koenig1, 18 Oct 2006     Danny van der Rijn, 18 Oct 2006
Changes: 17 Oct 2006 - new issue;    18 Oct 2006 - fields: Links

Issue R25: wording for conflictingReceive and ambiguousReceive

In this constraint, "two or more receive activities" should not be interpreted as meaning "two or more instances of the same receive activity", but instead: "two or more instances of different receive activities". Indeed, it is possible that the same "receive activity" within a scope nested in an event handler or parallel foreach, is "enabled" multiple times simultaneously, possibly once for each instance of the scope. In such cases, I am assuming that "conflictingReceive" should not be thrown (otherwise, most "receive activities" appearing in a parallel foreach or event handler would unavoidably lead to faults). Consider the following example:

<foreach ... parallel="yes" ...>
  <scope>
    <partnerLinks>
       <partnerLink name="PL1" ... />
    </partnerLinks>
    <correlationSets>
       <correlationSet name="S1" ... />+
    </correlationSets>
    <invoke name="RA1" partnerLink="PL1" ... operation="OP1" inputVariable="...">
      <correlation set="S1" initiate="yes"/>
    </invoke>
    <receive name="RA" partnerLink="PL1" ... operation="OP1" ...>
      <correlation set="S1" initiate="no"/>
    </receive>
  </scope>
</foreach>

On the other hand, the following example may lead to a "conflictingReceive", as one instance of activity "RA1" may be enabled at the same time as one instance of "RA2".

<flow>
   <receive name="RA1" partnerLink="PL1" portType="PT1" operation="OP1" ...>
     <correlation set="S1" .../>
   </receive>
   <receive name="RA2" partnerLink="PL1" portType="PT1" operation="OP1">
     <correlation set="S1" .../>
   </receive>
</flow>

The first example discussed above also illustrates that the wording in the definition of "ambiguousReceive" in Appendix A warrants some clarification. The current definition says: "Thrown when a business process instance simultaneously enables two or more IMAs for the same partnerLink, portType, operation but different correlationSets, and the correlations of multiple of these activities match an incoming request message." The above is an example where two enabled instances of the same IMA may match the same incoming message.
Links: Announcement, 18 Oct 2006     Dieter Koenig1, 26 Oct 2006
Changes: 18 Oct 2006 - new issue;    18 Oct 2006 - fields: Links;    30 Oct 2006 - fields: Links

Issue R26: Default Compensation Order Conflict

scope name="S0"
   flow
      scope name="S1"
         scope name="A"
            source link="fromAtoB"
         ...
      scope name="S2"
         scope name="B"
            target link="fromAtoB"
         ...
      activity name="E"

Further assume that activity "E" now throws a fault which is caught by the default fault handler of scope "S0".

1. All running activities inside of scope "S0" are terminated, and the default termination handler of scope "S1" compensates scope "A".
2. The default fault handler of scope "S0" then compensates scope "S2", which in turn compensates scope "B".

The observed compensation order "A then B" is caused by the sequence "first termination, then fault handling". OTOH, the required compensation order "B then A" implied by the control dependency of "B" on "A".

This is a contradiction.

Note that this situation cannot occur when the scope "S1" is an isolated scope. In this case, the link "fromAtoB" cannot leave the scope "S1" before it completes. In this case, scope "S1" always completes before scope "S2", and compensation of "A" cannot be caused by a termination handler before scope "B" is compensated.

Moreover, this conflict is irrelevant if scope "S1" OR scope "S2" only contain default compensation handlers, because in this case, no custom compensation logic can be executed in the wrong order.
Submitter's proposal: In order to avoid conflicts between the termination-handling / fault-handling sequence and the default compensation order, different strategies can be considered, for example, enforcing the absence of such conflicts during static analysis. A less restrictive approach is proposed here, which only affects the runtime behavior.

At the end of section 12.5.2, add the following paragraph:

"The default compensation order is initiated by default termination handlers and default fault handlers, and recursively carried forward by compensation handlers. The termination phase always precedes the fault handling phase (see section 12.6. Termination Handlers). This sequence must not create a conflict with the default compensation order of scopes that are in a control dependency relationship. If all of the following is true:

1. scope "S2" has a direct peer-scope dependency on scope "S1"
2. the scope-controlled set of activities of scope "S1" contains default termination handlers
3. the scope-controlled set of activities of scope "S1" AND scope "S2" both contain at least one custom compensation handler then a WS-BPEL processor MUST execute these scopes as if "S2" had a control dependency on scope "S1".

Issue R27: Faults and Parallelism in Termination Handlers

Example 1. Assume that a custom termination handler contains a parallel forEach activity or a flow activity. In either case, assume that multiple concurrent branches are active. If one branch faults, the specification does not tell whether the other branches are allowed to complete or terminated.

Example 2. Assume that a default termination handler that compensates a compensation handler instance group. If one compensation handler instance faults, the specification does not tell whether the other compensation handler instances are allowed to complete or terminated.
Submitter's proposal: Add the following to the end of section 12.6.:

"If a custom termination handler contains parallel activities and one of these activities propagates a fault then all concurrent activities in the termination handler MUST be terminated. Likewise, if a default termination handler compensates a compensation handler instance group and one of the compensation handler instances propagates a fault then the other compensation handler instances of the compensation handler instance group MUST be terminated."

This file last updated 22:51 31 Oct 2006 (UTC)