Alex -
I don't think that that captures the intent. It's not just faults
*caused* by the fault handler, it's also *any other* fault than the one
that triggered the fault handler. So if you missed 2 replies, for
instance, this clause would be invoked.
Alex Yiu wrote:
Hi Dieter and Danny,
I am OK with rewording in (1).
For (2), Dieter:
(2) If a fault handler has
completed then a check for missing replies
MUST
be made. The fault handler may have
processed any fault, including a
different bpws:missingReply. If a new bpws:missingReply is detected
then it
is thrown to the parent scope (similar to throwing or rethrowing other
faults from a fault handler).
"processed"?
Do you mean: "trigger" / "cause"?
How about:
(2) If a fault handler has completed then a check for missing replies
MUST
be made. The execution of fault handler
may cause a new fault, including a
different bpws:missingReply. If a new bpws:missingReply is detected
then it
is thrown to the parent scope (similar to throwing or rethrowing other
faults from a fault handler).
Does it sound more precise?
Thanks!
Regards,
Alex Yiu
Danny van der Rijn wrote:
I'm fine with your new wording.
Danny
Dieter Koenig1 wrote:
Re: [wsbpel] Issue - 221 - Proposal vor Vote
Hi Danny, I am ok with (1). In (2), the fault
handler may have processed a
different missingReply or any other fault; so I slightly reworded (2) -
let
me know if that is acceptable.
(1) If the contained activity and the event handlers of the scope have
completed then a check for missing replies MUST be made. If one is
detected
then a bpws:missingReply is thrown. The scope itself can catch it as
this
is still inside of the scope. Note that it is possible for a scope to
detect missing replies for embedded scopes that failed to throw a
missingReply because another fault took precedence.
(2) If a fault handler has completed then a check for missing replies
MUST
be made. The fault handler may have processed any fault, including a
different bpws:missingReply. If a new bpws:missingReply is detected
then it
is thrown to the parent scope (similar to throwing or rethrowing other
faults from a fault handler).
When we are finished with this text, we should also create a
corresponding
action item for the editing team.
Kind Regards
DK
Danny van
der
Rijn
<dannyv@tibco.com
To
> Dieter
Koenig1/Germany/IBM@IBMDE
cc
13.02.2006 19:48 wsbpel@lists.oasis-open.org
Subject
Re: [wsbpel] Issue - 221 -
Proposal
vor
Vote
I would suggest:
(1) If the contained activity and the event handlers of the scope
have completed then a check for missing replies MUST be made. If
one
is
detected then a bpws:missingReply is thrown. The scope itself can
catch it as this is still inside of the scope. Note that it
is
possible for a scope to detect missing replies for embedded scopes
that failed to throw a missingReply because another fault took
precedence.
(2) If a fault handler has completed then a check
for missing replies MUST be made. If any missing reply other than the
exact
one that
caused a missingReply fault to be thrown initially is detected then a
bpws:missingReply is thrown to the parent scope (similar to throwing or
rethrowing other faults from a fault handler).
Dieter Koenig1 wrote:
Just to make sure this one does not get lost: do we have any
suggested
wording for 221 different from the resolution in
http://lists.oasis-open.org/archives/wsbpel/200601/msg00074.html?
Kind Regards
DK
"Alexandre Alves"
<aalves@bea.com>
To 01.02.2006 15:57
<chris.keller@active-endpoints.com>
, "Danny van der
Rijn"
<dannyv@tibco.com>
,
<wsbpel@lists.oasis-open.org>
cc
Subject RE: [wsbpel] Issue - 221
-
Proposal vor
Vote
Hi Chris, Danny,
I generally agree with Danny, now that I understood his example, I
think
the user would find it strange that a 'throw foo' is executed,
causing a
'missingReply' to be raised… I understand we do swallow faults,
but
missingReply in particular seems like an extreme case as it is
being
activated by a 'throw' (which terminated the scope).
Rgds,
From: Chris Keller [mailto:chris.keller@active-endpoints.com]
Sent: Tuesday, January 31, 2006 6:32 PM
To: 'Danny van der Rijn'; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue - 221 - Proposal vor Vote
Hi Danny,
I think at the parent scope point the fault should and would have
been
swallowed. So given an option of having a parent throw the
missingReply,
after handling some other fault, I’d leave things as they are. Of
course
that is just my opinion. I’m am still open to my other stated
options if
you or others care to consider them J.
- Chris
From: Danny van der Rijn [mailto:dannyv@tibco.com]
Sent: Tuesday, January 31, 2006 7:03 PM
To: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 221 - Proposal vor Vote
But now you're losing the other fault, which can't ever be
"regenerated"
like a missingReply can. This isn't what I was suggesting. I was
suggesting that we leave Dieter's semantic alone for when a
different
fault
is thrown (i.e. it takes precedence). I was merely pointing out
that
there's still a missingReply, and it can be detected later.
Chris Keller wrote:
Hi Danny,
I think I would prefer a wording more like “if a fault handler
completes
normally or abnormally (i.e. itself faults, throws or rethrows) a
missingReply is thrown if an open IMA is present. This happens
regardless
of whether there was an attempt to throw or rethrow another
fault”.
I
think we can make this happen by describing the scope state
diagram
in such
a way that the check for the open IMA happens before the throw or
rethrow
of any other fault. All this is a mouthful and needs cleaning up,
but my
reasoning is that it is nicer if the point of the throw is the
scope
causing the missingReply under all circumstances. One use case
that
comes
to mind is exception handling procedures that allow manual
intervention,
something that is outside the scope of the spec, but could be a
useful
feature of a product.
- Chris
From: Danny van der Rijn [mailto:dannyv@tibco.com]
Sent: Tuesday, January 31, 2006 1:04 PM
To: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 221 - Proposal vor Vote
Chris -
I see missingReply as somewhat of a special case because it isn't
triggered
anywhere near any web service activity, yet it's a web-service
fault. I
understand that there's no fault stack, yet on the other hand,
this
fault
is triggered by a stack unwind of sorts, when something on the
lexical
stack goes out of scope. All that would have to be done is a
small
wording
change to achieve the behavior I'm talking about. Saying that
when a
scope
completes, a missingReply is thrown if an open IMA is contained
within
whose partnerLink or messageExchange definition is contained in
the
scope
*or a scope that is nested within*
Danny
Chris Keller wrote:
Hi Danny,
Although what has been proposed may not be perfect it is
consistent
with
BPEL fault behavior in general. BPEL doesn’t maintain a stack of
faults,
so if more than one fault is generated at any given point then
only
one
fault is propagated to the fault handling. However the point you
bring up
is a good one. In that if you have a standard fault queued at the
same
time as a user defined fault, should we choose the standard fault
in
preference to the user defined fault? This may be logical given
that
the
standard fault when using the exit option is much more severe and
typically
standard faults are not easily recoverable from as they are
modeling
errors. If we applied that prioritization to your example then
Scope
B
would throw missingReply in preference to bar. It would have no
effect on
fault foo as the scope is still active during that processing.
Any
thoughts on this treatment? Alternatively we could specifically
call
out
missingReply and have it be thrown in preference to another fault
when
completing a fault handler. - Chris
From: Danny van der Rijn [mailto:dannyv@tibco.com]
Sent: Monday, January 30, 2006 7:35 PM
To: Alexandre Alves
Cc: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 221 - Proposal vor Vote
Alexandre -
I see you're interpreting things differently than I am. I can see
both
interpretations.
You interpret that missingReply is "thrown and lost". I interpret
that it
was never thrown. "The throwing was lost."
In any case, I would point out that to any external observer,
(like
the one
who opened the IMA), no reply of any kind has happened, so the
IMA is
still
open.
As far as the process goes, the activity's scope may be lost,
which
brings
up interesting issues, but nevertheless, the activity has never
been
replied to.
Danny
Alexandre Alves wrote:
Hi Danny,
You seem to bring up an important point, but I am having problems
understanding your example.
When scope B completes (with fault foo), then the IMA goes out of
scope and
hence a missing reply fault is thrown and lost. Why would the IMA
still be
open in scope A? When the (first) missing reply is raised it
signifies the
closing of the IMA… What did I miss from your example?
Rgds
From: Danny van der Rijn [mailto:dannyv@tibco.com]
Sent: Monday, January 30, 2006 10:10 AM
To: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 221 - Proposal vor Vote
I don't think that your intention for (2) is clear in the
language.
Something along the lines of:
(2) If a fault handler has completed then a check
for missing replies MUST be made. If any missing reply other than
the
exact
one that
caused a missingReply fault to be thrown initially is detected
then a
bpws:missingReply is thrown to the parent scope (similar to
throwing
or
rethrowing other faults from a fault handler).
As for (1), I am troubled that a fault that is serious enough to
exit
the
engine could be lost so easily. But let's deal with a specific
case:
Scope A catch bar empty Scope B catch
foo throw bar sequence receive
(create
open IMA) throw foo
Scope B receives a message, creating an open IMA, and then throws
foo. Its
fault handler catches foo, and throws bar, thus losing the
missingReply
fault. Scope A catches bar, and suppresses it. When "catch bar"
completes, the IMA is still open. Does Scope A throw a
missingReply? Or
is the fact that B ":lost" it mean that it's lost forever? I
would
vote
for the former (A throwing), but the text isn't clear to me as to
what
happens.
Danny
Dieter Koenig1 wrote:
If more than one fault is thrown then only one is handled by a
fault
handler, either in the same or in an enclosing scope. All other
faults are
lost. This rule applies to bpws:missingReply as well.
In (2), the check allows to throw bpws:missingReply to an
enclosing
scope
after a different fault has been handled in the scope that
completes
unsuccessfully. The "different fault" may be a different
"instance"
of a
bpws:missingReply fault as well.
Do you still see an issue w.r.t this behavior, or can you suggest
better
language for 221 that would not trouble you :-) ?
Kind Regards
DK Danny van der Rijn <
dannyv@tibco.com
To > wsbpel@lists.oasis-open.org
cc 25.01.2006
22:35
Subject Re: [wsbpel] Issue - 221
-
Proposal vor Vote
I had sent this question to the irc during the meeting before I
had
to
go. Don't know if it got discussed or not.
point (2) - why is this only "(for a different fault)"?
more specifically:
- if there is more than one IMA that caused the fault to be
thrown,
and
there is still at least one open (but less than before) at the
end of
the <catch missingReply>, what happens?
- if the <catch missingReply> opens a new IMA that it
doesn't close
before it's done, what happens?
the inconsistent nature of dealing with these, especially since
they
can
exitOnStandardFault, truly troubles me.
Danny
Dieter Koenig1 wrote: Two additional changes to the 221
resolution (friendly amendments): (A) First sentence: Drop
"during termination of a scope, " (B) Appendix A
(missingReply
standard fault): Result: (A) Add to the end of 14.4:
-------- The standard fault bpws:missingReply can also be
detected if one or more receive operations using a
partner
link or message exchange defined in
the scope remain open. (1) If the contained activity and
the event handlers of the scope have completed then a
check
for missing replies MUST be made. If one is
detected then a bpws:missingReply is thrown. The scope itself
can catch it as this is still inside of the scope.
(2)
If a fault handler (for a different fault) has completed then a
check for missing replies MUST be made. If one is detected
then
a bpws:missingReply is thrown to the parent scope (similar to
throwing or rethrowing other faults from a fault
handler). (3) If a fault handler itself throws or rethrows a
different fault to the parent scope then no check for
missing replies is made, so a bpws:missingReply is
potentially
lost (similar to a case where multiple faults have been
detected and only one gets propagated). (4) If the
termination
handler is executed then no check for missing replies is
made,
so a bpws:missingReply is potentially lost (like any
other fault thrown in the termination handler).
-------- (B) Change Appendix A (missingReply standard fault)
from: -------- Thrown when a receive has been executed,
and the process instance
reaches the end of its execution without a corresponding
reply
having been executed. -------- To: --------
Thrown when a receive has been executed, and the process instance
or a scope reaches the end of its execution without a
corresponding reply
having been executed. -------- Kind Regards
DK ----- Forwarded by Dieter Koenig1/Germany/IBM on
25.01.2006
17:39 ----- Dieter
Koenig1/Germany/I BM
To
wsbpel@lists.oasis-open.org
19.01.2006 17:58
cc
Subject [wsbpel]
Issue -
221 - Proposal
vor Vote The last
paragraph of section 14.4. "Web Service Operations" (starting
with "The fourth extension ...") introduces the standard
fault "bpws:missingReply". Add the following text to the
end of the paragraph: -------- The standard fault
bpws:missingReply can also be detected during termination of
a
scope, if one or more receive operations using a partner
link or message exchange defined in the scope remain open.
(1)
If the contained activity and the event handlers of the scope
have completed then a check for missing replies MUST be
made. If
one is
detected then a bpws:missingReply is thrown. The scope itself
can catch it as this is still inside of the scope.
(2)
If a fault handler (for a different fault) has completed then a
check for missing replies MUST be made. If one is detected
then
a bpws:missingReply is thrown to the parent scope (similar to
throwing or rethrowing other faults from a fault
handler). (3) If a fault handler itself throws or rethrows a
different fault to the parent scope then no check for
missing replies is made, so a bpws:missingReply is
potentially
lost (similar to a case where multiple faults have been
detected and only one gets propagated). (4) If the
termination
handler is executed then no check for missing replies is
made,
so a bpws:missingReply is potentially lost (like any
other fault thrown in the termination handler).
-------- Kind Regards DK
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
|