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


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




  


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