Re: [wsbpel] Re: Issues 26 and 49

[Monica Martin <monica.martin@sun.com>]

Danny van der Rijn wrote:

>ok, i guess i must have missed that.   sounds like my issue is irrelevant
>then.
>
>danny
>  
>
mm1: Danny, in the two comments that are extracted from Assaf below, 
don't we still have two items to clarify either by improvement in 
specification wording or more definition clarity. Assaf states the two 
cases with different conditions:

    * Where you have the same partnerLink and portType but a different
      correlation set.  How to match the <reply> to the <receive>.
    * Where you have a pick and an event handler, the portType,
      operation, partnerLink but the process can't deterministically
      decide which of the activities to send the message.

Thanks.

>  
>
>>Arkin:.................This is the most precise the spec is on this particular point. The
>>features change section (page 13) actually clarifies the intent, but not
>>in a normative way:
>>
>>"Correlation sets have now been added to the uniqueness requirement so
>>that it is not
>>legal to have two web service interactions outstanding if they have the
>>same partner,
>>port type, operation and correlation set(s)."
>>..................
>>
>>So my understanding is that a synchronous operation starts with the
>><receive> and ends with the <reply>, unless a reply has been sent, the
>>operation is still outstanding, and so no other <receive> is allowed at
>>that point in time. So the following sequence:
>>
>>sequence
>>  receive X
>>  receive Y
>>  reply X
>>  reply Y
>>
>>is illegal if X and Y are the same partner/operation/correlation.
>>However, if X and Y are the same partner/operation but different
>>correlations, then the sequence is legal, but only if one could figure
>>out how to match the reply to the receive. Which in my opinion should be
>>spelled out more clearly.
>>
>>........continued...............
>>
>>scope
>>  . . .
>>  pick
>>    onMessage X
>>   . . ..
>>  eventHandler
>>    onMessage Y
>>
>>where X and Y are the same partner/operation/correlation. In this case
>>once the <pick> activity is performed, it competes with the enabled
>>event handler for the same message. The process cannot decide which of
>>these activities to forward the message to, and so this definition is
>>undeterministic.
>>
>>arkin
>>    
>>