Re: [wsbpel] Issue - R25 - wording for conflictingReceive andambiguousReceive

[Dieter Koenig1 <dieterkoenig@de.ibm.com>]

+1

In your forEach example, the partner links PL1 and the correlation sets S1
are different instances that must not lead to conflictingReceive.

In your flow example, partner link,  port type, operation, and correlation
sets are the same for both receive activities, so if they are enabled
simultaneously (which is extremely likely) then conflictingReceive is
thrown. This is not a candidate for ambigousReceive as that only applies in
cases of different correlation sets.

So some clarification in the wording is desirable.

Kind Regards
DK
                                                                       
 Dieter König                                Mail: dieterkoenig@de.ibm.com         IBM Deutschland Entwicklung GmbH
                                                                       
 Senior Technical Staff Member               Tel (office): (+49) 7031-16-3426      Schönaicher Strasse 220
                                                                       
 Architect, Business Process Choreographer   Fax (office): (+49) 7031-16-4890      71032 Böblingen
                                                                       
 Member, Technical Expert Council            Tel (home office): (+49) 7032-201464  Germany
                                                                       





                                                                       
             ws-bpel issues                                            
             list editor                                               
             <peter@furniss.co                                          To
             .uk>                      wsbpel@lists.oasis-open.org     
                                                                        cc
             18.10.2006 23:47                                          
                                                                   Subject
                                       [wsbpel] Issue - R25 - wording for
             Please respond to         conflictingReceive and          
             wsbpel@lists.oasi         ambiguousReceive                
                s-open.org                                             
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       




This issue has been added to the wsbpel issue list with a status of
"received". The status will be changed to "open" if a motion to open the
issue is proposed and that motion is approved by the TC. A motion could
also be proposed to close it without further consideration. Otherwise it
will remain as "received".


The issues list is posted as a Technical Committee document to the OASIS
WSBPEL TC pages on a regular basis. The current edition, as a TC document,
is the most recent version of the document entitled in the "Issues" folder
of the WSBPEL TC document list - the next posting as a TC document will
include this issue. The list editor's working copy, which will normally
include an issue when it is announced, is available at this constant URL.
Issue - R25 - wording for conflictingReceive and ambiguousReceive


Status: received
Date added: 18 Oct 2006
Origin: Public comment - Marlon Dumas, 18 Oct 2006
Date submitted: 18 October 2006
Description: The following statement may need to be clarified in the spec:
"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."


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>



In this example, it is likely that multiple instances of the IMA "RA" may
be enabled simultaneously. But no "conflictingReceive" would be thrown.


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.
Changes: 18 Oct 2006 - new issue



To comment on this issue (including whether it should be accepted), please
follow-up to this announcement on the wsbpel@lists.oasis-open.org list
(replying to this message should automatically send your message to that
list), or ensure the subject line as you send it starts "Issue - R25 -
[anything]" or is a reply to such a message. If you want to formally
propose a resolution to an open issue, please start the subject line "Issue
- R25 - Proposed resolution", without any Re: or similar.


To add a new issue, see the issues procedures document