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 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



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