RE: [Requirements] Non-requirement for MEPs

Agreed. One generic system error is probably enough at the choreography
level (it helps increase the level of coupling. Good thing). - Edwin

> -----Original Message-----
> From: public-ws-chor-request@w3.org 
> [mailto:public-ws-chor-request@w3.org] On Behalf Of Assaf Arkin
> Sent: Wednesday, March 19, 2003 11:58 AM
> To: Patil, Sanjaykumar
> Cc: public-ws-chor@w3.org
> Subject: RE: [Requirements] Non-requirement for MEPs
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: public-ws-chor-request@w3.org 
> > [mailto:public-ws-chor-request@w3.org]On Behalf Of Patil, 
> Sanjaykumar
> > Sent: Wednesday, March 19, 2003 10:20 AM
> > To: Assaf Arkin
> > Cc: public-ws-chor@w3.org
> > Subject: RE: [Requirements] Non-requirement for MEPs
> >
> >
> >
> >
> > >> <Assaf>
> > >> I'm not sure there is much value in identifying specific
> > faults, I think
> > >> some coarse distinction will suffice.
> >
> > >> For example, the seller may send a message that the buyer
> > cannot validate.
> > >> The buyer can send back some fault. But the seller may
> > validate the message
> > >> on its side before sending it, determine the fault without
> > having to receive
> > >> it from the buyer. The seller may find that it's
> > implementation is wrong and
> > >> it cannot proceed. It's able to fix the implementation but
> > that may take
> > >> longer than the transaction timeout. So suffice that the 
> seller can 
> > >> say 'oops, something went wrong, let's decide to cancel the 
> > >> transaction'. I don't think there's need to delve into the what 
> > >> went wrong in
> > much detail,
> > >> coarse grain would work fine for all the scenarios I've seen. 
> > >> </Asaaf>
> >
> > Even to say that "oops, something went wrong, let's decide 
> to cancel 
> > the transaction", you need to know the exact type of the 
> error. That 
> > is, if you wanted to define the behavior of the system to 
> cancel the 
> > transaction for certain types of errors, you are already 
> assuming that 
> > you can identify the types of errors. Isn't specifying the 
> type of the 
> > error already getting into defining details of the error message!
> 
> But I can do that in a very generic way.
> 
> It's possible that a message has a well formed error, 
> validation error, attachment corrupt error, mandatory header 
> not supported error, or decryption failure error. At the 
> choreography level do I care which of these errors prevented 
> the message from being processed? Or can I just forumlate the 
> behavior in terms of a very generic error (like error = SOAP server
> fault) ignoring the details?
> 
> This is different from business errors, which may have more 
> specific effect on the flow, errors like:
> 
> - The product is not available, please update your catalog
> - The quoted price is no longer accepted, please obtain a new quote
> - Cannot possibly ship by this date, alternative date provided
> 
> You would want to clearly define these errors and use 
> suitable messages. Usually these are messages, not 
> specifically faults (in the WSDL term). Even if you decide to 
> use faults, you can still define these faults precisely using 
> WSDL and address them specifically using a fault handler.
> 
> The issue here - as I understood from reading Edwin's e-mail 
> - is that the faults listed above (invalid, unsupported 
> header, etc) are not well defined. For the implementation 
> this is an issue, but for the choreography I have yet to see 
> a use case that distinguishes between failure due to invalid 
> vs failure due to malformed. I do see a difference between 
> these generic "server faults" and other type of errors, but 
> the other type of errors can be well defined by creating 
> specific message definitions for them.
> 
> arkin
> 
> 
> > Once we support certain types of errors,  we may also have 
> to augment 
> > the error message definitions with the exact information of 
> the error 
> > instance. For example, a content-validation-failed error 
> message can 
> > include the details of which element in which document was the 
> > culprit.
> >
> > Yes, a coarse grained error type is useful in its own merit and we 
> > could include such a category to account for unidentified errors. 
> > However, for those functionalities that will be directly 
> supported by 
> > the choreography specification, we need to clearly support the 
> > relevant error messages also.
> >
> >
> > Sanjay Patil
> > Distinguished Engineer
> > sanjay.patil@iona.com
> > -------------------------------------------------------
> > IONA Technologies
> > 2350 Mission College Blvd. Suite 650
> > Santa Clara, CA 95054
> > Tel: (408) 350 9619
> > Fax: (408) 350 9501
> > -------------------------------------------------------
> > Making Software Work Together TM
> 
>

Received on Wednesday, 19 March 2003 15:32:59 UTC