OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[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]