RE: [ebxml-bp] ebBP 3/15/2005: Comments re: AnyProtocolFailure Update (wd 10)

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

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