Thank you, Alex, now
it makes more sense to me.
> However, if
operation1 is a request-response MEP operation, then conflictingRequest fault
will be thrown.
That depends, of
course, on the time the reply occurs with respect to the various receive's. (If
the reply occurs before the second receive, there would be no
exception immediately after the second receive, etc.)
Ugo
Hi Ugo,
Those text has
been a part of BPEL spec (since BPEL 1.1?) ... (used to be in "Execution
Extension" section)
Anyhow ... here is an example: (psuedo syntax for
lazy typing) ---------------------------------
<sequence>
<receive partnerLink1 operation1 CS1 />
... <receive
partnerLink1 operation1 CS1
/>
... <receive
partnerLink1 operation1 CS1
/> ...
</sequence> ---------------------------------
With this
sequence of <receive>, conflictingReceive will not get triggered at all.
Because, there is no more than one receive operation on same PL, operation
and CS active at the same time.
However, if operation1 is a
request-response MEP operation, then conflictingRequest fault will be thrown.
On the other hand, if operation1 is an one-way MEP operation, then fault
may not be thrown at all.
This example illustrate my interpretation on
that sentence.
Given Ugo's question, I think it is worthwhile to keep
that sentence and highlight the differences of these two
faults.
Thanks!
Regards, Alex Yiu
Ugo
Corda wrote:
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
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
|