[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 123 - Matching <reply> with <receive>
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]