Matt Payne asks:How are you handling exceptions in web services? [...] We have a developer wrapping exceptions in a custom coded "Axis fault" and I think it smells funny to have the server side business logic refer to the web service implementation. [...]Your nose knows, Matt. If what you want is wrapped exceptions, you should use RMI...As for how to deal with implementation-level exceptions from a web services specification perspective, there are the two starting points:
The W3C SOAP 1.1 note says: The SOAP Fault element is used to carry error and/or status information within a SOAP message. (SOAP 1.2 provides a little more on faults.)
The WS-I Basic Profile is explicit about error-handling only in so far as specifying that a SOAP Fault in the context of HTTP should be returned with a 500 Internal Server Error HTTP response code. (The guidelines for 4xx response codes are also worth a look.)
In other words, you're on your own.As little as I like the "business internet" metaphor, I think that (well-designed) user-facing web applications are one starting point for thinking about how to handle exceptions in the course of web services interactions. For example:
User-facing web application version: If you submit some goofy data as an address or log-in with an incorrect set of credentials, you'll get an error message that you can read in your browser.
Web service version: If you send an otherwise well-formed SOAP message with some goofy (from a semantic perspective) data or bad credentials, you'll receive a SOAP fault that the service architect designed for this purpose.
The circumstance where unexpected things go wrong is more interesting, and it's a good idea
2000
to get comfortable with the idea that things can fail sometimes:
User-facing web application version: If something goes awry on the server side, you'll receive either an error page or some kind of internal error information like a stack trace. The fact that the internal error information is returned as an HTTP response is a bit of a red herring: the important thing is that it occurs as an out of band (i.e., outside the scope of the application) communication.
Web service version: This is up to your judgment and the use case for the service, but my version of how to handle this is by a failure at the protocol level. That is, if you can't communicate with the target application, the communications should fail, e.g., an HTTP failure without a SOAP fault should be generated.
If you think about unexpected exceptions within the service implementation on the same level as other non-service-level failures (e.g., server on fire, no network connectivity, etc.), I claim that this will guide you to the correct set of decisions.
Previous Topic
