OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsbpel] Issue - 221 - Proposal vor Vote


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]