OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



Yes, I think we need to have that clarification in the spec.
Yaron, do you think this clarification fits into the context of issue 139?

I do share a similar question. My terminologies / viewing angle may look 
a bit different. Few options listed on the table:
(A) it is a one-to-one relationship between the underlying  resources 
(e.g. network endpoints) and a partnerlink instance: i.e., a partnerLink 
instance is always an exclusive owner of those resources during the 
lifetime of the partnerLink
(B) it is a potentially one-to-many relationship between the underlying 
resources and partnerLink instances: i.e., multiple partnerLink 
instances can share the same resources. The sharing semantics varies 
depending on the nature of the resources. (An example could be 
multiplexing?)

Regards,
Alex Yiu


Yaron Y. Goland wrote:

> 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]