Are your Web services exceptions naked or covered?

Building a reliable SOA requires rigorous Web services exception handling and testing techniques

By Mamoon Yunus and Rizwan Mallal, JavaWorld.com, 12/20/06

Web services—the foundation of service-oriented architecture (SOA)—are self-contained, modular applications that one can describe, publish, locate, and invoke over a network. Web services operate at a level of abstraction similar to the Internet. They are agnostic to operating system, hardware platform, communication protocol, or programming language and have blurred the boundaries between network devices, security products, applications, and other IT assets within an enterprise. Almost every IT asset now advertises its interface as a Web Services Description Language (WSDL) interface ready for SOAP/XML messaging. Using SOAP for system-to-system messaging and WSDL for interface description, IT professionals now have unprecedented flexibility in integrating IT assets across internal and external corporate domains. It is this flexibility of distributed computing provided by Web services that makes exception handling complex within a service-oriented architecture. In this article, we will explore exception handling and testing techniques, and their impact on Web services-based SOA.

Web services exceptions

An exception is shorthand for "exceptional event," defined as follows by the Java Tutorial: An exception is an event, which occurs during the execution of a program that disrupts the normal flow of the program's instructions.

Exceptions can happen when an error occurs in a method or a Web services operation. The error can be caused by program flaws or a lack of system resources. Typical problems include:

User input errors, where a user inadvertently types incorrect characters
Physical limitations, where a disk fills up or runs out of available memory
Device errors, where the hardware doesn't behave as expected, such as an unenabled portable USB key
Network errors, where an application server tries to connect to a remote database using Java Database Connectivity

The calling program or consumer must be notified that an error occurred in the invoked method or producer. This is where sophisticated, programmatic exception handling comes into play, with exceptions bubbled to the calling programs to enable recovery from the exception. Typically, an astute programmer anticipates exceptions and programmatically handles them; however, not all exceptions can be anticipated, and not all exceptions are recoverable. If an exception handler is not found, the runtime system can terminate and act unreliably.

Programming platforms such as Java and .Net have extensive and sophisticated exception handling capabilities. Developers can construct a rich set of error handling patterns using conditional if-then-else constructs and try-catch-finally blocks. Using such exception handling patterns, developers can reduce the risk of drastic program crashes or abrupt, unanticipated program termination and add robustness to an application.

Within a Web services-based distributed architecture, exception handling must address additional requirements. Exceptions now have to be communicated independent of operating systems, programming languages, and applications. The exceptions must 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 must occur 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 details of internal IT assets to the consumer or leaking sensitive corporate information in stack traces.

1 | 2 | 3 | Next >