Impact of Exception Handling Patterns on Web Services

Discussions

J2EE patterns: Impact of Exception Handling Patterns on Web Services

  1. Below are excerpts & references to articles that I have come aross addressing Exception Handling in a Web Services context. I am interested in views on exception handling patterns in a web services-based SOA. ------ Within a web services-based distributed architecture, exception handling has to address the following additional requirements:
    • Exceptions now have to be communicated independent of operating systems, programming languages and applications.
    • The exceptions have to be presented to the consumer such that they are readily interpreted and if the exception is recoverable, the consumer can seamlessly respond to the exception thrown by a web services producer that may be located anywhere within or external to the corporate IT boundaries.
    • The communication of such exceptions has to be done with corporate security in mind as well. If exceptions are not handled rigorously, carefully and deliberately, a producer web service runs the risk of exposing internal IT assets details to the consumer or leaking sensitive corporate information in stack traces.
    Web Services exception handling has a significant impact on the quality and reliability of a corporate Service Oriented Architecture. Some items to consider:
    • Web services developers have to carefully add exception handling to their methods to ensure that the method handles exceptions elegantly.
    • Web services developers have a further responsibility to anticipate and test exceptions that may be getting caught by the container. Letting the container be the catch-all for exceptions is dangerous since it takes information flow control away from the developer and in the hands of the container.
    • In large SOA deployments that have a little bit of everything from .NET, Java, or LAMP and all kinds of containers, it is recommended that information control for SOAP-based exception handling is centralized. This ensures that externally facing web services do not leak component details and compromise a corporation’s strategic Service Oriented Architecture initiative.
    Bottom-line: For externally facing web services exposed to a large number of public consumers, only recoverable exceptions should be communicated. All other exceptions should be controlled, cleansed or suppressed. ------ References: 1. Are your Web services exceptions naked or covered? 2. The Java Tutorial: Exceptions
  2. In other words don't return the phrase "Houston, we have a problem!"(true story ,i've seen this..) in your webservce calls on a globally caught an exception!;..this will only annoy the users of your service! :)
  3. Recoverable Exceptions[ Go to top ]

    In my experience, cases in which an exception is recoverable are rare. As a matter in fact, the only one I can think of righ now is a "busy signal" (i.e. HTTP 503). IMHO, all other "recoverable" exceptions should be business responses instead. "Logic by exception" sounds like "trial and error programming" to me. I try not to do it.