XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
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.
 
 
 
 
 
 


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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS