Re: [xml-dev] Handling Multiple Service Responses

["Pete Cordell" <petexmldev@codalogic.com>]

I'm not sure if this is helpful or not, but things like HTTP group response
codes into classes.

For example, responses 100-199 are provisional, 200-299 are successful,
300-399 are redirection (I think), 400-499 are failures to do with the
requested resource (again - I think), 500-599 I think are server errors,
600-699 ???? etc.

The point is that while you can get detailed error information, the
error handling for each class of error can be generic to the class and not
specific to each individual error code.

In XML you might do something like:
    <error><class>Critical</class><code>errr...</code></error>

Actually, SOAP error codes are similar, e.g.: Client.Authentication

Anyway, HTH,

Pete Cordell
Codalogic
Visit http://www.codalogic.com/lmx/ for XML C++ data binding
----- Original Message ----- 
From: "Fraser Goffin" <goffinf@googlemail.com>
To: <xml-dev@lists.xml.org>
Sent: Monday, January 21, 2008 11:06 PM
Subject: [xml-dev] Handling Multiple Service Responses


> Hi,
>
> I am seeking some opinions about how others handle this situation :-
>
> A service exposes an operation (lets assume it is implemented as a web
> service using SOAP).
>
> A request is sent to the service and the service may respond with :-
>
> a. A payload representing the expected successful outcome to the request
> b. One of a NUMBER of unsuccessful response types (note: I am not
> necessarily saying these are errors per se)
> c. A SOAP Fault indicating some sort of technical failure in calling the
> service
>
> It is (b) that I am uncertain about.
>
> (i) I want to make it easy for the calling client to discern whether they
> have a success response, or a non success repsonse (the technical error is
> easy).
>
> (ii) The calling client may need to take different actions based on which
> one of the many different UNsuccessful response messages is returned.
>
> For (i) I thought that, rather than returning a different message
> structure
> for each different response type (b) I would model this as a common
> 'business response' structure which [say] includes a business response
> code
> that the caller can use to identify which of the 'published' non success
> outcomes has actually occurred (I am assuming here that these type of
> responses don't include any useful data other than the response code that
> the client needs).
>
> This would have the advantage that the client only needs to understand 3
> types of response for this operation, the success response, the non
> success
> response and the SOAP Fault (rather than 'n' non-success responses)
>
> I considered just using 2 response types, success and SOAP Fault, but I
> think it might be better to reserve SOAP Faults to non business messages
> that we don't really want a caller to have to be concerned with (other
> than
> the fact that the invocation failed).
>
> I have to say I'm pretty uncertain about this... on the one hand I feel
> like
> creating specific message types for all possible responses that the
> service
> *could* return, but on the other, this seems like it might just make life
> more difficult for the caller ?? The determination of what is a
> business 'error' *may* be in the context of the caller even where the
> service asserts an error (i.e. the caller may choose to consume and
> continue).
>
> Has anyone else faced this predicament or do you have a view about the
> 'straw man' approach outlined above or a better alternative ?
>
> Cheers
>
> Fraser.
>