Re: [wsbpel] Issue - 123 - Matching <reply> with <receive>

["Yaron Y. Goland" <ygoland@bea.com>]

I think Alex has brought up a really important point. There is an 
assumption hiding in issue 123 that I think we need to flush out.

Are partnerLinks intended to be used for multiple simultaneous 
conversations or are they really mostly intended to handle one 
conversation at a time?

123 is only interesting if we routinely expect people to use a single 
partnerLink to host multiple independent conversations. The only time 
that really seems required would be in a parallel for-each but 123 won't 
solve the problems with parallel for-each because it requires statically 
declaring the association names.

If we expect people to use multiple partnerLinks, e.g. one per 
conversation, then we don't need 123 because anytime there is an 
ambiguity as to which receive a reply is associated with the programmer 
can break the ambiguity by using a new partnerLink.

	Food for thought,

		Yaron

P.S. If one had code:

receive partnerLink="foo" operation="bar"
receive partnerLink="foo" operation="bar"
reply partnerLink="foo" operation="bar"
reply partnerLink="foo" operation="bar"

There is an ambiguity as to which receive the reply is replying to. So 
if the code was changed to:

Assign
    copy
        from
           partnerLink name="foo" role="partnerRole"
        to
           partnerLink name="blah"
receive partnerLink="foo" operation="bar"
receive partnerLink="blah" operation="bar"
reply partnerLink="foo" operation="bar"
reply partnerLink="blah" operation="bar"


Alex Yiu wrote:

> 
> ------------------------------------------------------
> * How adding partnerlinks can help? *
> 
> Adding partnerlinks (may be or may not be locally scoped) can already 
> help us to resolve ambiguity between multiple receive reply activities 
> in some cases even without using "messageElement"/"usage" attribute. For 
> example:
> 
> <scope>
>   ...
>   <partnerLink name="plink1" partnerLinkType="foo:LT1" ... />
>   <partnerLink name="plink2" partnerLinkType="foo:LT1" ... />
>   ...
>   <sequence>
>     <receive partnerLink="plink1" operation="op1" ... />
>       ...
>       <receive partnerLink="plink2" operation="op1" ... />
>       ...
>       <reply partnerLink="plink2" operation="op1" ... />
>     ...
>     <reply partnerLink="plink1" operation="op1" ... />
>   </sequence>
> </scope>
> 
> With the introduction of "plink2" (may or may not be locally scoped), 
> the ambiguity of receive activities of same operations are gone. And, 
> the locally scoped partnerLink technique should work quite well for 
> concurrent flows also.
> ------------------------------------------------------
> 
> 
> Regards,
> Alex Yiu
> 
>