[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 244 - Proposal for Vote
Ok, with today's updates, the proposal for 244 is now as follows: (1) Section 10.4 - paragraph 10 - remove 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 10 (the sentence "Moreover ..." remains ---------------- (1a) Section 10.4 - paragraph 15 - old text (with two occurences of "incomplete"): If there should ever be multiple simultaneous incomplete inbound message 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 inbound message activities subsequent to the execution of the successful incomplete receive. Action - replace the above with new text (incomplete->open and a new note): If there should ever be multiple simultaneous open inbound message 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 inbound message activities subsequent to the execution of the successful open receive. Note that bpws:conflictingRequest 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), while conflictingReceive fault is not triggered. ---------------- (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 inbound message activity on the same partner link, operation and message exchange is open. ---------------- (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).
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]