[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 123 - Matching <reply> with <receive>
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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]