If we are ready to define a formal notion of MEP instances, then the
"usage" attribute becomes redundant.
If not, then the "usage" attribute would be a good balanced way to
handle the matching of receive and reply.
The questions are: do we want to introduce this potentially big concept
of MEP into BPEL in this stage of game? Do we want to introduce this
potentially big concept just for matching receive and reply? Will the
MEP be used for something else also?
My gut feeling is: it is OK to introduce to MEP into BPEL, if we are
using it more than matching receive and reply.
And, if we pass the "usage" attribute proposal and want to add MEP
instance in, say, next cycle of the spec, we can simply say you can
either use "usage" attribute (a simple way?) or "messageExchange"
attribute (a complicated but versatile way?) to associate receive and
reply and etc.
Just some thoughts ...
Regards,
Alex Yiu
Satish Thatte wrote:
I am confused by Alex's comment
(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).
If and when we do get into the MEP association, would we then have two
alternative ways to associate request and reply or messaging patterns in
general?
I don't see the difference between usage and messageExchange, except in
so far as one is allowed to use the same usage value for multiple
partnerLink operation combinations. I take the partnerLink/operation as
simply an implicit subscript on the usage value and then I have exactly
the same thing as a messageExchange. If we want to simply defer the
idea of scoping for messageExchange, that's fine, but I think we should
not create duplicate mechanisms for message patterns.
Satish
-----Original Message-----
From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Wednesday, August 11, 2004 4:39 PM
To: ygoland@bea.com
Cc: Francisco Curbera; wsbpel@lists.oasis-open.org; Alex Yiu
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_workgr
oup.php.
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_workgr
oup.php.
|