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] Re: ebBP 2/22/2005: Any Protocol Failure Question: section 4.6.8.1 and 4.8.3


No schema changes for that issue IMO. 

It seems to me to be a matter or explaining (or illustrating) under what
the conditions the status values would be true, what the point is in
using one kind of failure in your descriptions rather than another, and
so on. In other words, it is explanation of the meaning of the terms and
illustration of their usage that might need more expansion. I personally
think it is probably OK for 2.0; wait for further input from modelers or
implementers.

Dale Moberg


-----Original Message-----
From: Monica J. Martin [mailto:Monica.Martin@Sun.COM] 
Sent: Thursday, March 10, 2005 2:23 PM
To: Dale Moberg
Cc: Yunker, John; ebXML BP; himagiri@sybase.com; steve.c >> Steve Capell
Subject: Re: [ebxml-bp] Re: ebBP 2/22/2005: Any Protocol Failure
Question: section 4.6.8.1 and 4.8.3


>Moberg: I am not certain how the group has explained the use of these
status
>values, because a given event can be evidence for several status
values.
>I have assumed that RAE and AAE are technical failures. It seems
>reasonable that GeneralException would be a technical failure also.
When
>an event occurs that makes multiple flavors of failure occur, and there
>are distinct transitions defined that vary for those different status
>values, I think the specification leaves it open exactly what a
>monitoring application would require to verify that behavior was as the
>BPSS instance specified. It is a case where the implementation is
>expected to do something reasonable (after all, a failure has occurred
>so in general it will be necessary to note the failures that have been
>detected...)  If a NOF business message failed to be sent after an
>exception, it would just be another protocol failure (choreography
>violation) for that session. I think it would still be worth reporting
>in a monitoring tool.
>  
>
mm2:  Given that response, do we make any schema changes to the proposed

text I provided in last email? And, which is Failure:

    * Business or Technical Failure
    * Business and Technical Failure

See wd 10 2/23/2005 Section 4.8.3.

Thanks.

>mm1: Thanks John, I'll take these comments for revisions in the General

>Exception text proposed. I have a question for Dale and Hima though. 
>Hima, any concerns?
>Dale, do we need to make any changes to the schema in line with 
>associating AnyProtocolFailure with GeneralExceptionType? Updated text 
>is provided at the end of this email.  I have one final question, 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). Thanks.
>  
>




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