[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 123 - Proposal to Vote
That is not how I read Alex' text. I think what he means to say is that in addition to the pLink/portType/operation/ values one can encode the messageExchange attribute to disambiguate the match between receives and replies, as required. Not that you would introduce a new partner link to do so. Partner links have certain semantics associated with them after all, since they represent conversations between two services; the partner link structure of a process tells you a lot about its compositional structure and its interactions with other applications. IMO using the construct to disambiguate between conflicting receives would be an abuse of the original semantics of partner link concept. Paco "Yaron Y. Goland" <ygoland@bea.com> To: Alex Yiu <alex.yiu@ORACLE.COM> cc: Yuzo Fujishima <fujishima@bc.jp.nec.com>, wsbpel@lists.oasis-open.org 09/10/2004 04:02 Subject: [wsbpel] Issue - 123 - Proposal to Vote PM Please respond to ygoland I propose that we close issue 123 with no action. The logic for this proposal is that anytime there is a conflict between receives it can be resolved by introducing new partnerLinks. Hence we can resolve the problem without having to add any features to the spec. Thanks, Yaron Alex Yiu wrote: > > ----------------------------------------------------- > A reply activity is associated with a receive activity based on the > tuple - partnerLink, operation, and messageExchange. The value defined > in messageExchange is scoped to the combination of partnerLink and > operation. That is, it is legal to use the same messageExchange 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 > messageExchange tuple then the *bpws:conflictingRequest* fault MUST be > thrown within the BPEL process on the conflicting receive activities > subsequent to the execution of *the successful *incomplete receive . > > If a reply activity cannot be associated with an incomplete receive > activity by matching the tuples and this error situation is not caught > during static analysis, then *bpws:missingRequest* fault MUST be thrown > within the BPEL process on the reply activity. Because conflicting > requests should have been rejected at the time <receive> is executed, > there cannot be more than one corresponding <receive> at the time > <reply> is executed. > > If the messageExchange attribute is not specified on a receive then its > value is taken to be empty. For matching purposes two empty > messageExchange values on receives with the same partnerLink and > operation values are said to match. Empty value does not match with > other non-empty values. > > (Please note: there are existing text paragraphs in the spec, which > enforces that no more than one <receive>s are waiting for a message > associated with the same partner link, port type, operation, and > correlation sets. This constraint still exists and will not be affected > by the proposal of Issue 123. This proposal simply add one more > constraint to receive, when <reply> are needed to be associated with > <receive>.) > ----------------------------------------------------- > 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]