|
Alex,
I personally find
the text you underlined rather confusing. Do you have a simple example to
visualize what that sentence says?
Thank
you,
Ugo
-----Original Message-----
From:
wsbpel-return-6242-ugo.corda=sun.com@lists.oasis-open.org
[mailto:wsbpel-return-6242-ugo.corda=sun.com@lists.oasis-open.org] On Behalf
Of Alex Yiu
Sent: Monday, February 27, 2006 10:52 PM
To:
Dieter Koenig1
Cc: wsbpel@lists.oasis-open.org; Alex
Yiu
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:
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. 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.
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
|