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>



Yaron,

Yes, your write-up serves a better base to be put into the spec, when 
this issue is passed.

One quickie comment about one terminology: triple vs tuple.
Personally, I would prefer "tuple", that is a more generalized and 
well-known term, compared with "triple".
http://www.fact-index.com/r/re/relational_model.html
http://www.fact-index.com/n/n_/n_tuple.html

And, there is only one open issue regarding whether to include the CS 
for matching.
I don't have a particularly strong opinion / deep thought (one way or 
the other) as of this moment.


Regards,
Alex Yiu


Yaron Y. Goland wrote:

> Alex, would it be fair to restate your proposal as:
>
> -----------------------------
> A reply activity is associated with a receive activity based on the 
> triple - partnerLink, operation, and usage. The value defined in usage 
> is scoped to the combination of partnerLink and operation. That is, it 
> is legal to use the same usage value in multiple simultaneously 
> incomplete receive activities so long as the combination of 
> partnerLink and operation on the receives are all different from each 
> other. An incomplete receive describes the state of a BPEL process 
> from the point that a request/response receive activity starts 
> execution until its associated reply begins execution.
>
> If there should ever be multiple simultaneous incomplete receive 
> activities which have the same partnerLink, operation and usage triple 
> then the bpws:conflictingReceive fault MUST be thrown on all the 
> conflicting receive activities.
>
> If the usage attribute is not specified on a receive then its value is 
> taken to be empty. For matching purposes two empty usage values on 
> receives with the same partnerLink and operation values are said to 
> match.
> -----------------------------
>
> The only open issue then is if we include correlation sets in this 
> matching algorithm.
>
> I think we should keep correlation sets out of associating receive and 
> replies. Correlation sets have a lot of semantics that may not 
> directly manifest themselves in BPEL. This entire issue is a good 
> example of that. Yuzo showed how one can have replies that either have 
> no or only a sub-set of correlation sets in common with the request. 
> That's why we had to introduce the usage attribute in the first place.
>
> I suspect BPEL will be a simpler programming language if we leave 
> correlation sets out of it. But anyone who wants to keep correlation 
> sets as part of the mechanism associating receive and reply needs to 
> provide specific language describing how all the edge cases will be 
> handled where a reply may have a subset (including the empty set) of 
> initialized correlations in common with the receive. The devil is in 
> the details and we need to have those details before we vote on 
> including correlation sets.
>
>     Thanks,
>
>         Yaron
>
>
> Alex Yiu wrote:
>
>>
>> Hi,
>>
>> I hope this email will clear up the picture of what I am proposing.
>>
>> Regards,
>> Alex Yiu
>>
>> ====================================
>>
>> "R1B" Proposal for Issue 123
>>
>> (1) Syntax-wise: It has the simplicity of "R1". An optional "usage" 
>> attribute is used to disambiguate among receive and reply pair. There 
>> is NO scope associated with "name"/"usage" identifer any more. It is 
>> merely a supplementary string which is a part of matching tuples 
>> between receive and reply. This usage identifier will NOT affect the 
>> actual existing partnerLink behavior in anyway. It is a pure BPEL 
>> language feature. The identifier is NOT a MEP instance. It has no 
>> lifecycle / lifetime / scope semantics.
>>
>> (The "messageExchange" name is not used for the attribute here. 
>> Because, we would like to clearly separate the "usage" attribute from 
>> MEP instances, which we may need to define its scope and lifecycle 
>> and etc).
>>
>> (2)
>> When the "usage" attribute is not used, the matching tuple for 
>> receive-reply is: (i.e. the current spec semantics)
>> (partnerLink-instance, operation-identifier)
>> [maybe matching with CS also, depending on the ongoing orthogonal 
>> "part (B)" discussion]
>>
>> See examples below.
>>
>> (3)
>> When the "usage" attribute is used, the matching tuple for 
>> receive-reply is: (i.e. the current spec semantics)
>> (partnerLink-instance, operation-identifier, usage-identifier)
>> [again, maybe matching with CS also, depending on the ongoing 
>> orthogonal "part (B)" discussion]
>>
>> See examples below.
>>
>> ---------------------------------------
>>
>> Example (2-i), it is legal to have the following sequence of operations.
>> <sequence>
>>   <receive partnerLink="p1" operation="op1" />
>>   <receive partnerLink="p1" operation="op2" />
>>   <reply partnerLink="p1" operation="op1" />
>>   <reply partnerLink="p1" operation="op2" />
>> </sequence>
>>
>> Example (2-ii), it is illegal to have the following sequence of 
>> operations.
>> <sequence>
>>   <receive partnerLink="p1" operation="op1" />
>>   <receive partnerLink="p1" operation="op1" />
>>   <reply partnerLink="p1" operation="op1" />
>>   <reply partnerLink="p1" operation="op1" />
>> </sequence>
>>
>>
>> Example (3-i), it is legal to have the following sequence of operations.
>> <sequence>
>>   <receive partnerLink="p1" operation="op1" usage="handleCust" />
>>   <receive partnerLink="p1" operation="op2" usage="handleCust" />
>>   <receive partnerLink="p2" operation="op1" usage="handleCust" />
>>   <receive partnerLink="p1" operation="op1" usage="handleShipper" />
>>   <receive partnerLink="p1" operation="op1"  />
>>   <receive partnerLink="p1" operation="op2"  />   <reply 
>> partnerLink="p1" operation="op1" usage="handleCust"/>
>>   <reply partnerLink="p1" operation="op2" usage="handleCust" />
>>   <reply partnerLink="p2" operation="op1" usage="handleCust" />
>>   <reply partnerLink="p1" operation="op1" usage="handleShipper"/>
>>   <reply partnerLink="p1" operation="op1"  />
>>   <reply partnerLink="p1" operation="op2"  />
>> </sequence>
>>
>> Example (3-ii), it is illegal to have the following sequence of 
>> operations.
>> <sequence>
>>   <receive partnerLink="p1" operation="op1" usage="foo"/>
>>   <receive partnerLink="p1" operation="op1" usage="foo" />
>>   <reply partnerLink="p1" operation="op1" usage="foo" />
>>   <reply partnerLink="p1" operation="op1" usage="foo" />
>> </sequence>
>>
>> ---------------------------------------
>> ====================================
>
>
> To unsubscribe from this mailing list (and be removed from the roster 
> of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. 
>
>




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