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>


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


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