RE: [wsbpel] Issue R25 - Proposal to vote

The parallel <forEach> case from the submitter would not fault with a conflictingReceive because each iteration of a parallel <forEach> is a separate copy of the <scope>. As such, the conflcitingReceive test passes since they are different partner links and different correlation sets. The description of a parallel <forEach> describes the <forEach> as being equivalent to a <flow> with one copy of the <scope> for each iteration.

The test for conflictingReceives is not sufficient to prevent all cases of ambiguity during message dispatch but it serves to remove one well defined case. In order to handle any other cases, we introduced a separate fault called ambiguousReceive which is thrown if an ambiguity is detected during the message dispatch.

The proposal below expands the test for conflictingReceive to include a check of the values of a partner link and correlationSet(s). As I mentioned during the call, I am concerned about using the term “values” without defining it, especially with a normative MUST. For example, what’s the value of a partner link?

I’m also opposed to the possible amendment since it’s not portable. I would prefer that the behavior is consistent across all implementations. I think the existing text is fine as it is.

From: Diane Jordan [mailto:drj@us.ibm.com]
Sent: Tuesday, November 14, 2006 6:07 PM
To: wsbpel@lists.oasis-open.org
Subject: [wsbpel] Issue R25 - Proposal to vote

We discussed the following motion to close R25 and deferred the vote. Please review the current motion and potential amendment in preparation for the next discussion.

In secton 10.4, change

From: If during the execution of a business process instance, two or more receive activities for the same partnerLink, operation and correlationSet(s) are simultaneously enabled, then the standard fault bpel:conflictingReceive MUST be thrown (note bpel:conflictingReceive differs from bpel:conflictingRequest, see section 10.4.1. Message Exchanges).

To: If during the execution of a business process instance, two or more receive activity instances for the same operation and the same values of partnerLink and correlationSet(s)are simultaneously enabled, then the standard fault bpel:conflictingReceive MUST be thrown (note bpel:conflictingReceive differs from bpel:conflictingRequest, see section 10.4.1. Message Exchanges).

Possible amendment discussed:

If during the execution of a business process instance, two or more *IMA instances* for the same partnerLink, operation and correlationSet(s) are simultaneously enabled, then the standard fault bpel:conflictingReceive MUST be thrown (note bpel:conflictingReceive differs from bpel:conflictingRequest, see section 10.4.1. Message Exchanges). *There are other cases where two or more indistinguishable receive activity instances are enabled. In these cases, a WS-BPEL processor MAY throw a bpel:conflictingReceive fault.*

Regards, Diane
IBM Emerging Internet Software Standards
drj@us.ibm.com
(919)254-7221 or 8-444-7221, Mobile: 919-624-5123, Fax 845-491-5709

wsbpel message