Hi Danny,
I hope you have also read the email that I forwarded from a Satish's
email.
If you want to remove "missingReply" fault, do you mean the
process/scope instance will never know there is an error at all? Only
the invoker of this faulty process will see the missing reply or
timeout?
If that is the case, that sounds weired to me.
BPEL Engine is a container, while BPEL process is an instance managed
by that container. It is a common practice the container notify the
instance or even trigger some corrective action, if the instance
misbehave. (e.g. If a dangling transaction occurs, a transaction aware
container will signal this situation and may choose to close the
transaction (commit or rollback) on behalf of component.)
For variant-[A], it is consistent with existing modelling. As Chris
pointed out in his 7-step description, we are merely adding step (5) to
existing model in order to do checkpoint of missingReply in a scope
lifecycle.
Thanks!
Regards,
Alex Yiu
Danny van der Rijn wrote:
I would like to point out that currently, there is no missingReply
fault thrown on scope exit. All the spec has is the requirement that
missingReply is thrown if the process finishes with an open receive.
(Which makes no sense. Which is why issue 221 exists.)
This entire 123 to 221 discussion is based on a suggestion that Yaron
made (in the 221 thread), that missingReply be thrown as soon as it is
known that there will be no reply. Now that we are examining it, I'm
wondering whether we should just remove missingReply altogether, as I
believe that neither of the 2 options that Alex described (and thanks
for doing that, Alex) seem to work out in my head - A is completely
inconsistent with other fault behavior, and B is not very useful.
Danny
Alex Yiu wrote:
Chris,
Thank you very much for going through my viewpoints in such a detailed
fashion!
Selling an idea of this multi-facet semantic is never easy. :-) ...
But, I feel that we are converging.
I also think your 7-step description is a good way to depict a
lifecycle of a scope instance in case of "normal completion". That is,
no fault happens during step (3) to step (5).
If a fault happens during step (3) to step (5), the following steps for
fault handling will take place:
F1 - marks scope as faulted
F2 - matches and selects a fault handler (it can be the default one)
and uninstall other fault handlers and termination handler
F3 - executes the activity of the selected fault handler (A fault may
be thrown to the parent during this step. If so, step F4 will not be
reached).
F4 - validates that message exchanges have closed (A missingReply fault
may be thrown to the parent during this step) [ same logic as in step
(5) ]
[No source links will be fired after F4. Instead, DPE may be triggered.]
F4 is what we are discussing. One thing to point out is: F4 is needed
no matter whether we have step (5) in the previous 7-step description.
[A new open IMA can be created during the execution of the fault
handler.]
Thanks!
Regards,
Alex Yiu
Chris Keller wrote:
Thanks for
the descriptions Alex. I’m
not completely sold, but let me describe in another way what you are
suggesting. Essentially it is declaring that scopes have the following
lifecycle
(where all but step 5 is what we do today):
1 - Scope
initialization (variables, partnerLinks,
etc)
2 - Scope
schedules event handlers
3 - Scope
executes Activity
4 – Scope
waits for event handlers
to complete
5 – Scope
validates that message
exchanges have completed (no outstanding replies for locally declared
partnerLinks or messageExchange receives)
6 – Scope
completes
7 – Scope
source links execute…
We already
do wait for event handlers to
finish before the scope completes so checking that partnerLinks are
completed
prior to “completing” seems ok. I don’t think we have a case
where a fault handler actually waits or checks for anything prior to
completing
but now we are saying it would execute step 5 (it’s actually this point
that I am not sure about). If we do that then like any other fault
generated by a fault handler it would be thrown to the parent scope.
- Chris
From: Alex
Yiu [mailto:]
Sent: Tuesday,
December 13, 2005
6:10 PM
To: Alex Yiu
Cc: Danny van der
Rijn; ;
'Yuzo Fujishima';
'ws bpel tc'; Alex Yiu
Subject: Re:
[wsbpel]
Issue 221 -
discussion carried over from Issue 123
Hi, all,
[discussion carried over from Issue 123]
Ok ... let me summarize again on where to throw missingReply fault (to
make
sure everyone is on the same page)
I believe that there are 2 variant of suggestions on the table:
Variant [A]:
(which
I
am prefering)
It has two checkpoints:
checkpoint [A1]: S2 (at the end of normal execution) => S2
checkpoint [A2]: S2 (at the end of fault handler) => S1
[** A typical fault propagation flow would be:
At the
end of normal execution, a missingReply is thrown by S2 to S2.
Then, a
fault handler (including the default one) will be triggered, if the
missingReply fault is NOT handled (aka default), the fault will be
propagated to S1. ** ]
Variant [B]:
It has only one checkpoint.
checkpoint [B1]: S2 (at the end of normal execution or fault handler)
=> S1
(You guys can think of [B1] is the morphed combination of [A1]+[A2]
plus
modification.)
Concerns I have on Variant [B] are:
It
seems to me that S2 does not receive any fault signal in the case of at
the end of normal execution. What is the state of S2? Is S2
considered normally completed and up for compensation? Or, is it
faulted?
If S2
is considered normally completed, that is very strange. A scope with an
open-unfinished receive and a missing reply should not be considered
completed by itself.
If S2
is considered faulted, a fault signal should be sent to S2 first (which
may in turn propagate to S1, as depicted above).
Say, if
we go for this variant [b]:
<onEvent>
scenario: S2 belongs to an <onEvent> construct. Now, one of
<onEvent> S2 instances throws this missingReply fault directly to
S1. What can S1 do? Perform the compensation on S2? But, remember we
can only do group compensation of all S2 instances? Can someone justify
why previous successfully completed S2 need to be affected?
Also, you guys can also think of scopes as components in a business
process.
Component S1 makes use of component S2. If component S2 forgot to send
a reply
(or make any other system-level mistake e.g. forgot to close some
system
resources), it should be S2 considered at fault or faulted. If S2 can
clean up
its own mess, S2 should handle it first. If S2 cannot handle, then it
will be
S1's turn to handle it.
I hope I point out concerns that I have on Variant [B] more precisely
this
time.
I also hope Variant [A] seems a better solution to you guys now.
Thanks!
Regards,
Alex Yiu
Alex Yiu wrote:
Hi all,
I am OK with moving this part of discussion to Issue 221 also, because
I also
want to pass Issue 123 resolution in a timely fashion and the decision
on where
to throw missingReplying is taking some discussion time than expected.
Thanks!
Regards,
Alex Yiu
Danny van der Rijn wrote:
I agree with Yuzo and Chris.
I still think,
though, that we should save this discussion for 221. 123 only deals
with
messageExchange, while 221 holds for any of the 3 values.
Chris Keller wrote:
I
support Yuzo’s position completely. A missing
reply at the completion of S2 should be thrown to S1. The fact that we
are saying that the missingReply is thrown is when the partnerLink or
messageExchange goes out of scope says it all. How does it go out of
scope, it goes out of scope because the scope completed. After
completion
we can’t come back into ourselves to catch a fault. All that said
I’d rather not have this delay 123. I’m ok with leaving the
text as it stands in the 123 proposal and solving the question of which
scope
catches the fault in issue 221.
- Chris
From: Alex
Yiu [mailto:]
Sent: Monday,
December
12, 2005
11:50 PM
To: Yuzo Fujishima
Cc: Danny van der
Rijn; Chris
Keller; 'ws bpel tc'; Alex Yiu
Subject: Re:
[wsbpel]
Issue 123 -
Proposal for vote
Hi Yuzo,
Thanks for following this discussion thread. Really appreicate it ...
:-)
[a]
The main motivations behind "S2-to-S2" for missingReply fault are:
==> Finer-grain reply / compensation
If the
fault is thrown to S1 instead of S2, S1 cannot do anything to fix the
missing reply situation. Because, one of resources (partnerLink or
messageExchange) used in the open IMA is already out of scope (S2) and
S1 has no access those out-of-scope resources anymore.
The
missingReply situation may be caused by the situation where some other
faults happened and the enclosed scope (S2) does not handle those fault
properly. (Please see more analysis of
"programming-error-vs-runtime-error" below.) ... In the
<onEvent> or parallel <forEach> situation, assuming there
are 5 instances created and 4 of them got executed successfully without
any missingReply situation. But, one of them ran into this missingReply
situation. If we throw the fault to S1 and if we want to every
compensate the work of S2, all 5 of them need to be compensated. We
cannot compensate just the faulty instance by itself. On the other
hand, if we throw to S2, we can do a partial compensation in its fault
handler.
[b]
About "Reason 1" : "programming-error-vs-runtime-error"
consideration:
I agree with you this is more likely a programming error, not a true
runtime
error. That is why Dieter introduced this exit-on-standard-fault
facility to
allow people to stop process in case of this programming error.
With or without using this exit-on-standard-fault facility, as a
complete
specification, we need to specify snapshot state of the process - i.e.,
what
scopes are faulted and not, when the "exit" takes place.
If you think of the <onEvent> example described above, S1 should
not be
faulted, when the "exit" happens. Similarly, the previous 4 instance
of "S2" should not be faulted either. Only the true missingReply
scope should be faulted.
I also agree with you that people should not rely on catching this
missingReply
fault to do any complicated business logic. At most, people should just
log the
fault and attempt doing the partial compensation, as described above.
(This
applies to most of standard fault catchers).
I am just promoting scope-modularity. Definitely, not promoting any
weired
coding style. If you want, I think we can add a caution statement along
the
intention of the passed resolution of Issue 192 (Dieter's
exitOnStandardFault
proposal) to spec to state that: "If people do not set
exitOnStandardFault
to true, it is a good practice to restrict logic of any standard fault
fault
handler to some minimalistic repair work (e.g. error logging and
partial
compensation)."
Actually, the same wisdom applies to most of conventional programming
language.
E.g. in Java, if one got an IOException, SQLException, or Security
permission
related Exception, there are only few things that a Java application
programmer
can do / should do (similar to above).
[c]
About "Reason 2: When to judge if a reply is missing":
Yuzo wrote:
we should expect a fault
handler to send a reply.
Yes, I totally agree with you
here. :-)
Our intended behavior are actually very similar. :-) ... I guess the
related text in my previous email writeup is muddled. Sorry for the
not-organized enough text.
Let me add some clarification and refinement here:
==================================
There are two
checkpoints to decide whether a bpws:missingReply fault needs to be
thrown in a
scope (S2):
After the normal
execution of the scope (S2) is finished but before the scope is
considered completed and the fault handlers of the scope (S2) are
uninstalled, if no fault has been thrown to the scope (S2) during the
normal execution.
After the execution of
a fault handler of the scope (S2) is finished, if a fault has been
thrown to scope (S2) during the normal execution of the scope (S2), and
that fault triggers the fault handler of the scope (S2), and no fault
has been thrown by execution of the fault handler
The bpws:missingReply fault
thrown by missingReply
checkpoint logic in
the case #1 will be caught by a fault handler at the
scope (S2)
which matches bpws:missingReply fault, if there is one.
If the triggered fault handler (either
by bpws:missingReply fault or other kinds of fault) does
not
generate proper replies to
any open IMAs, a missingReply fault MUST be thrown. This is the case
#2 checkpoint
logic.
Important
Notes:
In case #2,
there is NO an infinite loop situation, because any faults triggered or
thrown by a fault handler (e.g. <rethrow> activity) will NOT be
caught by any fault handler of the same scope (S2) and they can only be
caught by its ancestor scopes (e.g. S1).
If a fault is thrown
either during the normal execution of the scope (S2), checkpoint logic
of case #1 will not be executed. That implies, if such a fault happens
and the scope (S2) does not have a matching fault handler, this fault
will be propagated to the parent scope (S1) and it will overshadow
overall missingReply logic.
If a fault is thrown
or rethrown during the execution of a fault handler of the scope (S2),
checkpoint logic of case #2 will not be executed. That implies, if such
a fault happens, this fault will overshadow missingReply logic of case
#2.
Here is a fragment of process definition that illustrates the
relationship of
scope S1 and S2 described above:
------------------
<scope
name="S1">
...
<scope
name="S2">
...
<partnerLinks>
<partnerLink name="pl1" ... />
</partnerLinks>
...
<sequence>
<receive partnerLink="pl1" ... />
<!-- receive without reply -->
</sequence>
</scope>
...
</scope>
------------------
Note: The bpws:missingReply fault is thrown by scope S2 to scope S2
itself.
==================================
[I highlighted the clarification changes in GREEN.]
To summarsize, we agree more than disagree. :-) ....
Case #2 is where the fault is thrown by S2 to S1.
I am merely adding one more differentiated checkpoint (case #1) to
allow the
fault thrown by S2 to S2 to achieve the semantics of scope-modularity
and
finer-grain repair and compensation. (IMHO, that is very important for
<onEvent> cases).
I hope I have explain my intended behavior better this time. :-)
More thoughts on this topic ... ? :-)
Thanks!
Regards,
Alex Yiu
Yuzo Fujishima wrote:
Alex,
Alex Yiu wrote:
Hi Danny and Chris,
Please see inline.
...
*Q1*: /have the process'
faultHandlers been
uninstalled?/
Answer: As I mentioned in the my previous email: (please see the
example)
http://lists.oasis-open.org/archives/wsbpel/200512/msg00050.html
I prefer the direction of which: the fault is thrown by scope S2 to
scope S2.
I am not a big fan of this "S2 to S2" semantics for
the following reasons:
Reason 1: Credibility of the use case.
I am not convinced that there are (many) cases where
scope S2 fails to reply without throwing a fault (except
missingReply). If S2 does, it should be a programming
error rather than a runtime error.
More likely are, in my opinion, the cases where
scope S2 fails to reply due to some fault.
For such cases,
S2 should define a fault handler to catch the fault and
send a reply there.
Not catching the cause fault and instead waiting for the
missingReply to occur doesn't seem to be a good programming
practice. The language should not promote that.
Reason 2: When to judge if a reply is missing.
A missingReply should be thrown only after the whole execution
of the scope S2, including the fault handlers, completed
without sending a reply. (As explained in the example for Reason 1,
we should expect a fault handler to send a reply.)
Then the natural destination of the missingReply fault should be
the parent of S2, i.e., S1.
Yuzo Fujishima
NEC Corporation
