RE: [Requirements] Non-requirement for MEPs

> -----Original Message-----
> From: Burdett, David [mailto:david.burdett@commerceone.com]
> Sent: Wednesday, March 19, 2003 3:07 PM
> To: 'Assaf Arkin '; 'Patil, Sanjaykumar '
> Cc: 'public-ws-chor@w3.org '
> Subject: RE: [Requirements] Non-requirement for MEPs
>
>
>  >>>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. <<<
>
> Is this a reason for defining: the semantics of the message, and the
> representation of the message over the wire separately?

The representation of the message over the wire is important for
communication, but has nothing to do with choreography. The representation
is protocol dependent, but you don't want to write a choreography in support
of one and only one protocol.

Going back to the use case I provided, the choreography is one and the same
regardless of which protocol you use. Between the supplier service and
customer service you may use SOAP over HTTP, or SOAP + WS-RM over HTTP +
JMS. Between the proxy service and supplier service you may use SOAP over
HTTP, or DIME over HTTP, or DIME over UDP, etc. You have a lot of different
choices for moving the message around, and different over-the-wire encoding
depending on how you encode it (SOAP, DIME, etc), which transport you use
(HTTP, UDP, etc) and what headers you may or may not need (with or w/o
WS-RM). But the choreography is all the same.

So the choreography must be expressed in very abstract terms. Ideally using
WSDL abstract operation definitions. If you do that you:

a) express the choreography in very abstract terms not specific to any
protocol
b) leverage technologies that already support this form of abstraction (WS
stack, XML Schema, etc)
c) allow multiple different protocols to specify over-the-wire messages
(SOAP, DIME, HTTP, IP multicast, JMS, etc)
d) benefit from a framework for allowing the service to specify one or more
protocol bindings, and allows protocol bindings to be reused by multiple
services (WSDL service definition)

arkin


>
> David
>
> -----Original Message-----
> From: Assaf Arkin
> To: Patil, Sanjaykumar
> Cc: public-ws-chor@w3.org
> Sent: 3/19/2003 11:57 AM
> 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 Thursday, 20 March 2003 15:06:07 UTC