[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 244 - Proposal for Vote
Hi Dieter, +1 in general. With a minor amendment on item (1): There are text to compare conflictingRequest and conflictingReceive in paragraph 10 in Section 10.4, which still help users to understand the nature of conflictingRequest fault. How about merging that useful and correct part to paragraph 15, which explains bpws:conflictingRequest:
Thanks! Regards, Alex Yiu Dieter Koenig1 wrote: 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_workgroups.php |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]