[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-bp] ebBP 3/15/2005: Comments re: AnyProtocolFailure Update (wd 10)
I don't disagree with what you are saying and as a student enjoyed Prolog (except for the "cut" construct which was tricky sometimes) but I digress. Here is what I think the specification would benefit from Two "tree" diagrams, one with Failure at the Top that would show how Failure is specialized into a branch with BusinessFailure and a branch with AnyProtocolFailure. Under the AnyProtocolFailure, specialize that into various non-overlapping cases. The second would have Success at the top, and show the distinct specializations so that distinct and overlapping forms would be described. (I think there are just 2 branches-- BusinessSuccess and ProtocolSuccess.) Next explain what to do with BPSS instances where conditionGuards are labeled with overlapping status values. Done -----Original Message----- From: David Webber (XML) [mailto:david@drrw.info] Sent: Tuesday, March 15, 2005 9:50 AM To: Dale Moberg; Monica J. Martin Cc: Steve Capell; ebXML BP; Himagiri.Mukkamala@sybase.com Subject: Re: [ebxml-bp] ebBP 3/15/2005: Comments re: AnyProtocolFailure Update (wd 10) Dale, Actually failure is complicated - and being able to recover from it consistently requires knowing what type of failure has occurred. Predicatability is what makes BPSS V2 so powerful and robust. I continue to turn to my work in Prolog - Programming in Logic - and one of the huge strengths of Prolog is its formal enforcement of failure and success conditional handling. That model is theoretically proven to solve a wide array of complex problems more simply - and allow machine based reasoning about outcomes. Having BPSS operate in a similar fashion is all good. Just counter-intuitive at first inspection however for people steeped in procedural logic rather than declarative logic...! Cheers, DW ----- Original Message ----- From: "Dale Moberg" <dmoberg@cyclonecommerce.com> To: "David Webber (XML)" <david@drrw.info>; "Monica J. Martin" <Monica.Martin@Sun.COM> Cc: "Steve Capell" <steve.capell@redwahoo.com>; "ebXML BP" <ebxml-bp@lists.oasis-open.org>; <Himagiri.Mukkamala@sybase.com> Sent: Tuesday, March 15, 2005 11:36 AM Subject: RE: [ebxml-bp] ebBP 3/15/2005: Comments re: AnyProtocolFailure Update (wd 10) I think we inherited all these values from past work, and I know I was not present when it was decided to distinguish all of these statuses. It is a lot to support from a monitoring task point of view. But, I am mainly concerned with transitions (actually conditionGuard checks) where different paths are marked by, for example, Failure, AnyProtocolFailure, and SignalTimeout. If I have a SignalTimeout, do we "take" all three paths? Or just the most specific? Or what?? I think that the Business Failure is linked to a specific event so it would not include AnyProtocolFailure also. (I have not gone back and checked what we have written down in the editors draft ) Dale -----Original Message----- From: David Webber (XML) [mailto:david@drrw.info] Sent: Tuesday, March 15, 2005 9:23 AM To: Monica J. Martin; Dale Moberg Cc: Steve Capell; ebXML BP; Himagiri.Mukkamala@sybase.com Subject: Re: [ebxml-bp] ebBP 3/15/2005: Comments re: AnyProtocolFailure Update (wd 10) I never realized failure was so complicated?!? : -) DW ----- Original Message ----- From: "Monica J. Martin" <Monica.Martin@Sun.COM> To: "Dale Moberg" <dmoberg@cyclonecommerce.com> Cc: "Steve Capell" <steve.capell@redwahoo.com>; "ebXML BP" <ebxml-bp@lists.oasis-open.org>; <Himagiri.Mukkamala@sybase.com> Sent: Tuesday, March 15, 2005 11:16 AM Subject: Re: [ebxml-bp] ebBP 3/15/2005: Comments re: AnyProtocolFailure Update (wd 10) > Dale, I understand your comments. Therefore we need to make some > decisions. We currently these states defined: > > * ProtocolSuccess > * AnyProtocolFailure > * RequestReceiptFailure > * RequestAcceptanceFailure > * ResponseReceiptFailure > * ResponseAcceptanceFailure > * SignalTimeout > * ResponseTimeout > * BusinessSuccess (isPositiveResponse=true or no isPositiveResponse > attribute) > * BusinessFailure(isPositiveResponse=false) > * Success (both protocol and business success) > * Failure (AnyProtocolFailure or BusinessFailure) > > We have a generic Failure (see above). I would think that we could have > a generic Failure and not be able to determine if it was > AnyProtocolFailure or Business Success (but the parties know as they > have additional information in an agreement). However, in order to > support the condition BOTH a Business and technical failure occur, seems > logical that Failure is an 'and.' Otherwise we live with 'and/or' and > let it be defined by the parties. I think the former is clearer but that > is just me. We'll discuss today. Comments welcome. Thanks. > > >Moberg: Wouldn't we say that success has to be success on all fronts (so it is > >"conjunction" of all success flavors) but that a general failure would > >be a disjunction of the specific forms of failure (that is, Failure is > >either ProtocolFailure and/or BusinessFailure and/or ...). Anyway that > >seems plausible to me. > > > > > >....[snippet] > >Isn't Failure actually an AnyProtocolFailure and Business Failure > >combined? This would be consistent with Success which is a Technical > >and Business Success? Trying to ensure correction of any typos or > >copy-paste errors (Section 4.8.3). > >======================================================================= = > >Please note, I am trying to correct if needed a consistency question > >between "Success" and "Failure" enumerated business transaction state on > >the condition guard. I believe all other questions raised during these > >interchanges have been answered. Thanks. Comments, as always, welcome. [end-snippet] > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]