Next in thread →
Next in month →
Fw: [wsbpel-spec-edit] [Fwd: Re: [wsbpel] Issue - 221 - Proposal vor Vote]
221 is one of the ones Dieter took today.
Regards, Diane
IBM Emerging Internet Software Standards
(919)254-7221 or 8-444-7221, Mobile: 919-624-5123, Fax 845-491-5709
----- Forwarded by Diane
Jordan/Raleigh/IBM on 02/22/2006 04:25 PM -----
Alex Yiu <>
02/22/2006 02:37 PM
To
bpel spec <>
cc
Alex Yiu <>,
"'Dieter Koenig1'" <>, Danny van
der Rijn <>
Subject
[wsbpel-spec-edit] [Fwd: Re: [wsbpel]
Issue - 221 - Proposal vor Vote]
Hi members in Editor Group,
Have we assigned this issue (Issue 221) to an editor yet?
If so, I would like to remind that the following updated text would be
the finalized proposal, if nobody oppose (so far it seems to me that both
Danny and Dieter are OK with it).
Thanks!
Regards,
Alex Yiu
[P.S.: I looked up online "vor" is "forward"
in German ... It may be time for us to practice some German ....
;-) ]
-------- Original Message --------
Subject:
Re: [wsbpel] Issue - 221 - Proposal vor Vote
Date:
Wed, 15 Feb 2006 21:29:11 -0800
From:
Danny van der Rijn <>
To:
Alex Yiu <>
CC:
Dieter Koenig1 <>,
References:
<>
<>
<>
<>
<>
<>
<>
My original intention was that there would be one missingReply per open
IMA. Then fault data could be supplied in an implementation-specific
way so that something interesting could be done in the handler. However,
it is just as easy to have the fault data be a repeating element, so I'm
fine with your interpretation. Provided everyone else agrees (not
a small proviso...) I think we might be done with this.
Thanks as always for your diligence, patience, and precision,
Danny
Alex Yiu wrote:
Hi Danny,
[a]
Danny wrote:
Sort of. It's not really new semantics. Just
clarifying how missingReply gets generated. missingReply gets generated
if, when the check is made, ANY outstanding request's partnerLink or messageExchange
is out of scope, and it has not had a missingReply generated and handled.
...
The "sort of" wordings makes me think about those scenario few
more times. :-)
To make sure there is no more misunderstanding, I will try to confirm the
semantics with you a number of examples.
[b]
Danny wrote on Feb 13:
(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).
I will try to do one more try to come up with clearer wordings on (1) and
(2).
For (2), if my guess on your intended logic is right, I would prefer something
based on your wordings. I think that your wording capture on your own intention
better.
[c]
Clarification with examples:
Example #1:
-----------------------
<scope name="a">
<FH>
<catch faultName="foo:BarFault"
>
... activity-B ...
</catch>
<catch faultName="missingReply"
>
... activity-R ...
</catch>
</FH>
<flow>
<sequence name="branch1">
<throw faultName="foo:BarFault"
/>
</sequence>
<sequence name="branch2">
<receive operation="opA"
... />
<!-- Assuming fault "foo:BarFault"
happens
when branch2 executes up to here. -->
</reply>
</sequence>
</flow>
</scope>
-----------------------
Question: will a missingReply fault be generated
before the execution of fault handler for "foo:BarFault".
If my interpretation and memory is right, the answer is NO. Hence,
I would like to add one extra phrase to point (1):
(1) If the contained activity and the event handlers of the scope have
completed without
any unhandled fault 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.
One single bpws:missingReply fault may encompass
more than one missing
replies.
If activity-B contains a matching reply, then of course
NO missingReply fault will be generated. If activity-B does NOT contain
a matching reply, then a missingReply fault will be generated by point
(2).
If activity-B contains another receive (say <receive
operation="opB" ... /> ) without a matching reply, then a
(single) missingReply fault will be generated to cover the missing reply
situation of both operation ("opA" and "opB").
Example #2:
-----------------------
<scope name="a">
<FH>
<catch faultName="missingReply"
>
... activity-R ...
</catch>
</FH>
<sequence>
<receive operation="opA"
... />
</sequence>
</scope>
-----------------------
In this example, a missReply fault is generated at the end of the sequence.
And the correspoding catch construct will be used to handle that fault:
If activity-R contains a match <reply>, no further
missingReply fault will be generated.
If activity-R does NOT contain a match <reply>,
no further missingReply fault will be generated also. [That is how I interprete
Danny's wording of "other than ..." on point (2)]
If activity-R contains another <receive> (say operation="A"),
a new missingReply fault will be generated at the end of fault handler.
If activity-R contains another <receive> (say operation="A")
but it also trigger another fault (say "foo:XyzFault"), a missingReply
fault will NOT be generated at the end of fault handler.
If the above is the right intepretation, I would suggest to reword point
(2) based on Danny's text as:
(2) If a fault handler has completed without
any unhandled fault then a check for missing replies
MUST be made. If any missing reply
is detected then a new bpws:missingReply is thrown to the parent
scope (similar to throwing or rethrowing other faults from a fault handler).
However, if the fault handler is handling
a bpws:missingReply fault and all detected missing replies are already
encompassed by the existing bpws:missingReply fault, the new fault will
NOT be generated and thrown. Similar to the case above, the newly thrown
missingReply fault may encompass more than one missing replies.
Does the above wording express our intended semantics in a simple and clear
way?
Also, the Primer team can consider parts of the above example as some candidate
material.
Thanks!
Regards,
Alex Yiu
Danny van der Rijn wrote:
comments inline.
Alex Yiu wrote:
Hi,
First of all, sorry for joining this conversation a bit ... I may not have
the full context.
Most of it is below in the email thread. I'm not going to repeat
most of it here, but you may find the conversation on the thread interesting.
Or it may put you to sleep.
However ... I want to clarify your true intended semantics ... It seems
to me that you are implying when multiple fault (currenlty) happens within
a scope:
one fault is the winner
and the matching fault handler got called
NEW semantics you are implying: all other "loser"
fault will be kept somewhere and if one of the old "loser"
faults is a missingReply fault. We will throw that fault???
Sort of. It's not really new semantics. Just clarifying how
missingReply gets generated. missingReply gets generated if, when
the check is made, ANY outstanding request's partnerLink or messageExchange
is out of scope, and it has not had a missingReply generated and handled.
My point is that the request is still outstanding, and it doesn't matter
when it went out of scope - it's still outstanding; there's still
someone waiting on the other end for an answer, who is completely unaware
of the process' internal scope design.
If you really mean the above semantics, I would vote "no" on
this tweak. Because:
it is a big change to the fault handling model. NOT just
for missingReply
Again, it's not about the handling, it's about the generation. What
makes missingReply interesting is 1) There's someone on the other end waiting,
and 2) The fault is generated by scope cleanup, not by execution of any
particular activity, expression evaluation, etc.
If we go for this model, why "missingReply"
is so special here? How about other standard fault? e.g. conflictingRequest
and etc ... ?
See above.
These two factors make feel me quite uncomfortable.
In DK's wording, it said: "If a new bpws:missingReply is detected"
....
If "new" does not mean a new fault caused by execution of a fault
handler, what does that "new" mean?
See above, but the ambiguity of what "new" means is why I suggested
new wording. I'm glad I did, because as you can see, we both interpreted
it differently. I *think* that DK meant the interpretation that I
did, since it came after seeming agreement to my arguments, but maybe it
didn't. In either case, yours is a new voice, and needs to be satisfied
with any final wording.
Regards,
Alex Yiu
Danny van der Rijn wrote:
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:
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
<
To
>
Dieter Koenig1/Germany/IBM@IBMDE
cc
13.02.2006 19:48
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"
<>
To
01.02.2006 15:57
<>
, "Danny van der
Rijn"
<>
,
<>
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:]
Sent: Tuesday, January 31, 2006 6:32 PM
To: 'Danny van der Rijn';
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:]
Sent: Tuesday, January 31, 2006 7:03 PM
To:
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:]
Sent: Tuesday, January 31, 2006 1:04 PM
To:
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:]
Sent: Monday, January 30, 2006 7:35 PM
To: Alexandre Alves
Cc:
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:]
Sent: Monday, January 30, 2006 10:10 AM
To:
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
<
To
>
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
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
Next in thread →
Next in month →