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>



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]