OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

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


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]