[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 244 - Proposal for Vote
Dieter, I agree with your proposal, but I think we should reconcile the languages used in sec. 10.4 and Appendix A when defining conflictingRequest.: Sec. 10.4 refers to "incomplete inbound message activities" and "incomplete receive activity", while your proposed text for Appendix A mentions "active synchronous inbound requests". I think the same language should be used throughout, otherwise readers will get confused. Ugo > -----Original Message----- > From: > wsbpel-return-6228-ugo.corda=sun.com@lists.oasis-open.org > [mailto:wsbpel-return-6228-ugo.corda=sun.com@lists.oasis-open. > org] On Behalf Of Dieter Koenig1 > Sent: Monday, February 27, 2006 7:32 AM > To: wsbpel@lists.oasis-open.org > Subject: [wsbpel] Issue 244 - Proposal for Vote > > > In order to fix the definition of bpws:conflictingRequest, > and remove bpws:invalidReply in favor of bpws:missingRequest, > I propose the following changes to the spec. > > Note that all remaing references to the tuple (partner link, > port type, operation, correlation set) - dealing with > bpws:conflictingReceive - are correct. > > ---------------- > (1) Section 10.4 - paragraph 10 - wrong text: > The correlation between a request and the corresponding reply > is based on the constraint that more than one outstanding > synchronous request from a specific partner link for a > particular portType, operation and correlation > set(s) MUST NOT be outstanding simultaneously. If this > constraint is violated during execution, then the standard > fault bpws:conflictingRequest MUST be thrown by a conforming > implementation. Note that this is semantically different from > the bpws:conflictingReceive, because it is possible to create > the conflictingRequest by consecutively receiving the same > request on a specific partner link for a particular portType, > operation and correlation set(s). For the purposes of this > constraint, an onMessage clause in a pick is equivalent to a > receive (see Pick). > > Action - drop this text from paragraph (paragraph 15 already > explains bpws:conflictingRequest correctly). The text > starting with "Moreover, ..." remains. > > ---------------- > (2) Section 10.4 - paragraph 12 - wrong text: > If a reply activity is being carried out during the execution > of a business process instance and no synchronous request is > outstanding for the specified partnerLink, portType, > operation and correlation set(s), then the standard fault > bpws:invalidReply MUST be thrown by a conforming implementation. > > Action - drop this paragraph completely (paragraph 16 already > explains it correctly using bpws:missingRequest). > > ---------------- > (3) Appendix A. - wrong text (table row explaining > conflictingRequest): Thrown when more than one synchronous > inbound request on the same partner link for a particular > port type, operation and correlation set(s) are active. > > Action - replace with new text (table row explaining > conflictingRequest): Thrown when more than one synchronous > inbound request on the same partner link, operation and > message exchange are active. > > ---------------- > (4) Appendix A. - wrong text (table row explaining > invalidReply): Thrown when a reply is sent on a partner link, > portType and operation for which the corresponding receive > with the same correlation has not been carried out. > > Action - drop this row completely (bpws:missingRequest is sufficient). > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS > TC that generates this mail. You may a link to this group > and all your TCs in OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr oups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]