Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
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.
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:
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.
|Forum migration complete By Athen|
|Forum migration update By Athen|