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.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment