A Systematic Approach for Structuring Exception Handling in Robust Component-Based Software

This article addresses the systematic incorporation of exception handling into component-based systems. By "component-based", one can infer "object-oriented" since the use of libraries of classes, such ast STL and JCL, can be seen as the use of components, building blocks, while constructing large-scale software systems. Read this article in its entirety to get a sense of how to put exception handling to good use.

2. Related Work

Software fault tolerance at the architectural level is a young research area that has recently gained considerable attention. Some approaches based on the idea of design diversity have been developed in the context of reliable evolution of component-based distributed systems. Hercules framework and Multi-Versioning Connectors are approaches that maintain old and new versions of components working concurrently, in order to guarantee that the expected service is provided, even if there are faults in the new versions. The guidelines described in Section 4.3 for handling exceptions at the architectural level are based on these two approaches.

Other possible approach for building fault-tolerant component-based systems is to employ exception handling at the architectural level, as suggested by some authors in the literature.  The work by Issarny and Banâtre describes an extension to existing architecture description languages for specifying configuration exceptions, which are exceptions raised due to violations of architectural invariants. Guerra et al have proposed an approach for architecting fault-tolerant component-based systems based on a specific architectural style. Castor et al have proposed an EHS addressing specific concerns of componentbased systems, at the architectural level, also focusing on a specific architectural style. These works differ from our present work in the sense that they do not attempt to integrate architectural-level and implementation-level exception handling. Architectural-level exception handling is not a replacement for implementation-level exception handling. The two techniques are complementary and should be employed synergistically in order to achieve best results. To the best of our knowledge, however, no attempts have previously been made to devise a general strategy for structuring component-based systems taking into account both architectural-level and implementation-level exception handling.

There are some works in the literature describing guidelines for structuring exception handling in objectoriented software systems. In general, these works do not focus on CBD and do not try to bridge the gap between architectural-level and implementation-level exception handling. In spite of this, they do provide valuable advice, which has been taken into account for the elaboration of the approach proposed in this paper.

More closely related to DBC, is the work of Shenoy that discusses best practices in EJB exception handling. The main goal of Shenoy's work is faster problem resolution and it is based on the backward error recovery capabilities provided by EJB containers. In contrast, our main goal is a basis for forward error recovery and faulttolerance that is not dependent on any specific component framework.

Vecellio motivates the creation of techniques to assess the reliability of off-the-shelf (OTS) components. The author argues that traditional techniques for assuring the reliability of software systems are not effective for component-based systems. Meyer reinforces these ideas and discusses the concept of trusted components. The author states that the elaboration of extensive techniques for demonstrating the quality of reusable components, together with the construction of a large set of trusted components, has the potential to change the way systems are developed. This viewpoint is complementary to ours.

Also related to our work, in the area of dependability benchmarking, it is possible to estimate the dependability of certain types of OTS components. However, it is still difficult to predict how components built by different organizations will behave together when integrated into a new system.