Re: [wsbpel] Issue 37 - Proposal for vote

["Monica J. Martin" <Monica.Martin@Sun.COM>]

Yuzo Fujishima wrote:

> Hi,
>
> Considering the comments given so far,
> I would like to go back to my original problem description
> and revise the proposed resolution as follows.
> Please let me know what you think.
>
> Revised proposed resolution:
>
> Part 1r: If an attempt is made to initiate a correlation set that is
>   already initiated, the standard fault bpws:correlationViolation
>   must be thrown by a compliant implementation. This rule is applied
>   only to executable processes.
>
> Part 2r: If a special treatment is required for multi-start cases,
>   it will be discussed as a separate issue.

mm1: Yuzo, thank you for your diligence in pursuing this issue. As the 
scope of the issue a) may require further discussion, b) other issues 
may relate to it and c) you have just sent in a revised proposal: Is it 
appropriate to vote on this today? Perhaps we can discuss today to 
understand the issues and separate what we are or are not voting on. If 
there are proposed explicit information that needs to be added to the 
specification, as Satish indicates, I suggest we propose such text (See 
***...***). Thanks.

>> Thatte: ......
>> ***All of this is reflected in the current specification, though 
>> probably not this explicitly.***  The ambiguity you pointed out in 
>> Issue 37 relates narrowly to the "multi-start activity" case.  In 
>> this case, the multiple start activities may have no correlation set 
>> with initiate="no" and thus they may all fail the A condition for 
>> correlated message delivery.  And yet for all but one of them, the 
>> message delivery needs to occur based on the correlated message rules 
>> rather than the createInstance rules.
>>  
>> Thus the problem is in condition A above.  In my view a good way to 
>> approach this is to address it via the createInstance attribute.  Add 
>> another value: createInstance="yes | no | alternate" where the 
>> alternate value signals the multi-start case.  We could then explain 
>> that in the case createInstance="alternate" the setting of initiate 
>> is "yes" for the receive that follows rule 1 and "no" for the 
>> receives that follow rule 2.  Therefore we should reserve the use of 
>> the initiate attribute for receives with createInstance="no" and 
>> disallow it for the "start activities".
>