[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 think this is a different diagram relating just to the condition guard status values. It specifies the inclusion relations and the mutually exclusive values. It also relates the events in the diagram to what specific status values are returned. I don't recall seeing this information before. David W. once volunteered to assemble a chart for how status values related to monitored events. In effect, this is that "chart". I agree that there is a connection between the diagram and the status values. This proposal is to be explicit on the relations of values among themselves, and to (some) events that are described by these values. -----Original Message----- From: Jean-Jacques Dubray [mailto:jeanjadu@Attachmate.com] Sent: Tuesday, March 15, 2005 3:53 PM To: David Webber (XML); 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) Don't we have this diagram yet? There is a business transaction diagram detailing all the failures that can happen. Are you looking to enhance that diagram? (that figure was in 1.1) JJ- -----Original Message----- From: David Webber (XML) [mailto:david@drrw.info] Sent: Tuesday, March 15, 2005 9:05 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, +1 - awesome. Thanks, 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 12:01 PM 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]