would it be consistent with your proposal to word (b) : any receive
which, if executed, would cause the overall state to become illegal.
Alex Yiu wrote:
Hi, all,
After thinking about the situation mentioned by Yuzo more, I would like
to mention a few points:
- I can see the "conflictReceive" fault conditon in the terms of
matching receive-reply is quite different from in terms of
"conflictReceive" fault condition in terms of the maintaining the
uniqueness of partnerLink, operation, CS in the existing spec text.
Hence, I would agree with Yuzo's previoius suggestiont to use "conflictRequest"
in the context of Issue 123 to avoid further confusion.
- Regarding to whether we can enforce that fault "MUST be thrown
within the BPEL process on all the conflicting receive activities", I
would agree with with Yuzo again. The "conflictRequest" fault
can be detected only at runtime. By the time when the second duplicated
receive is executed, the first receive is finished already. It just
needs a reply activity to complete the request-reply pattern.
It can be confusing to users, if we fault the flow/thread which has
executed the <receive> activity. Moreover, it is possible to have
a <receive> activity in one flow and its matched <reply>
activity in the other flow. (Though this is a very minority design
pattern.)
Therefore, I suggest two minor changes in this proposal:
(a) "conflictReceive" => "conflictRequest"
(b) "all the conflicting
receive activities" => "the conflicting receive activities
subsequent to the execution of the first incomplete receive."
I know the wordings in (b) is kind of clumsy. If someone find a more
elegant way to express the same semantics, please feel free to re-word
it. :-)
Thanks!
Regards,
Alex Yiu
Here is the updated version of the proposal according to my suggestion:
-----------------------------------------------------
A reply activity is associated with a receive activity based on the
tuple - partnerLink, operation, and messageExchange. The value defined
in messageExchange is scoped to the combination of partnerLink and
operation. That is, it is legal to use the same messageExchange value
in multiple simultaneously incomplete receive activities so long as the
combination of partnerLink and operation on the receives are all
different from each other. An incomplete receive describes the state of
a BPEL process from the point that a request/response receive activity
starts execution until its associated reply begins execution.
If there should ever be multiple simultaneous incomplete receive
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
receive activities subsequent to the execution of the first
incomplete receive.
If a reply activity cannot be associated with an incomplete
receive
activity by matching the tuples and this error situation is not caught
during static analysis, then bpws:missingRequest fault MUST be thrown
within the BPEL process on the reply activity. Because
conflicting requests should have been rejected at the time
<receive> is executed, there cannot be more than one
corresponding <receive> at the time <reply> is executed.
If the messageExchange attribute is not specified on a receive then its
value is taken to be empty. For matching purposes two empty
messageExchange values on receives with the same partnerLink and
operation values are said to match. Empty value does not match with
other non-empty values.
(Please note: there are existing text paragraphs in the spec, which
enforces
that no
more than one <receive>s are waiting for a message associated
with the same partner link, port type, operation, and correlation sets.
This constraint still exists and will not be affected by the proposal
of Issue 123. This proposal simply add one more constraint to receive,
when <reply> are needed to be associated with <receive>.)
-----------------------------------------------------
Yaron Y. Goland wrote:
I thought
about that but I must admit that I prefer requiring a fault to be
thrown on both activities. My reasoning is that BPEL is a truly
parallel environment and defining who is 'first' can be somewhere
between difficult to impossible. So by requiring that all incomplete
receives throw faults we make the engine's behavior more easily
predictable.
Just a thought,
Yaron
Yuzo Fujishima wrote:
Hi,
I don't understand how the following will be enforced:
> If there should ever be multiple simultaneous incomplete receive
> activities which have the same partnerLink, operation and
> messageExchange tuple then the *bpws:conflictingReceive* fault
MUST be
> thrown _within the BPEL process_ on all the conflicting receive
activities.
By the time the second of the conflicting receive activities is
executed,
the first one could have received a message and completed. How could
a fault be thrown for the first one?
Example:
1. Receive activity A starts.
2. A message is delivered to A. A completes. Note that
A is still incomplete because no reply has been sent yet.
3. The control reaches receive activity B.
It turns out that B is conflicting with A.
4. B throws a fault.
But what must/can be done for A, which has been completed
already?
We might want to modify the rule such that the second
and later conflicting receives throw a fault while the
first one survives.
Yuzo Fujishima
NEC Corporation
Alex Yiu wrote:
Hi, all,
Here is the draft proposal for Issue 123. It is based on Yaron's text
sent out few days ago.
It contains a terminology change: (i) from "usage" to "messageExchange"
(as some people agree with the general idea of this proposal but don't
like the terminology) and (ii) from "triple" to "tuple" (that is my
personal preference).
Bernd and Yuzo had some further input and clarification requests, which
I have incorporated. They are marked with underline here.
-----------------------------------------------------
A reply activity is associated with a receive activity based on the
tuple - partnerLink, operation, and messageExchange. The value defined
in messageExchange is scoped to the combination of partnerLink and
operation. That is, it is legal to use the same messageExchange value
in multiple simultaneously incomplete receive activities so long as the
combination of partnerLink and operation on the receives are all
different from each other. An incomplete receive describes the state of
a BPEL process from the point that a request/response receive activity
starts execution until its associated reply begins execution.
If there should ever be multiple simultaneous incomplete receive
activities which have the same partnerLink, operation and
messageExchange tuple then the *bpws:conflictingReceive* fault MUST be
thrown _within the BPEL process_ on all the conflicting receive
activities.
_If a reply activity cannot be associated with an incomplete receive
activity by matching the tuples and this error situation is not caught
during static analysis, then bpws:missingRequest fault MUST be thrown
within the BPEL process on the reply activity._ _Because conflicting
requests should have been rejected at the time <receive> is
executed, there cannot be more than one corresponding <receive>
at the time <reply> is executed._
If the messageExchange attribute is not specified on a receive then its
value is taken to be empty. For matching purposes two empty
messageExchange values on receives with the same partnerLink and
operation values are said to match. _Empty value does not match with
other non-empty values. _
(Please note: there are existing text paragraphs in the spec, which
enforces that no more than one <receive>s are waiting for a
message associated with the same partner link, port type, operation,
and correlation sets. This constraint still exists and will not be
affected by the proposal of Issue 123. This proposal simply add one
more constraint to receive, when <reply> are needed to be
associated with <receive>.)
-----------------------------------------------------
Thanks!
Regards,
Alex Yiu
To unsubscribe from this mailing list (and be removed from the roster
of the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
To unsubscribe from this mailing list (and be removed from the roster
of the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
|