I'm looking into changing the exception handling strategy used by our web services. Currently they expose exceptions that we think the client can realistically use as normal java exceptions. However, some SOAP client platforms such as .NET do not properly deal with this (for example, the .NET SOAP client doesn't allow more than one detail message in the fault element, making it impossible to pass stracktraces).
Now, is there a best practice when it comes to communicating faults from web services? I've read in a couple of places it's better to write small domain objects that can hold the return data as well as optional fault information. This seems a bit like bypassing the fault issues altogether which seems less than desirable. Note that an important requirement is compatibility with .NET's faulty SOAP implementation.
R van Vliet
posted 9 years ago
Nobody any ideas on this? I'm still struggling with it.
Another issue is how to do web service versioning nicely (i.e. if you have an updated web service with changed calls, do you put the version number in the web service name or the namespace, etc.).
Humans and their filthy friendship brings nothing but trouble. My only solace is this tiny ad: