Grabitatearen bidezko sedimentazio-ganberak

chitectures with respect to their dependability properties [155, 167]. Some approaches based on the idea of design diversity [5] have been developed in the context of the re- liable evolution of component-based distributed systems. Both the Hercules framework [50] and the concept of Multi-Versioning Connectors [145] 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. Both approaches are orthogonal to ours and could be used in conjunction.

Stavridou and Riemenscheneider [167], and Saridakis and Issarny [155] emphasize the formal description of architectures in order to prove they are reliable. By employing these specifications together with refinement laws which guarantee the preservation of the reli- ability property, both approaches intend on producing concrete architectural descriptions which are easily translated to code. None of the two works addresses the problem of incorporating error recovery into existing components.

The concept of iC2C[56] defines a structure for incorporating fault tolerance into component-based systems at the architectural level. It defines an internal protocol fol- lowed by its elements in order to enforce damage confinement [5]. Our work refines the concept of iC2C by introducing elements which are not addressed by its definition, such as the the representation of exception handlers and the enforcement of explicit exception propagation.

The work by Guerra et al.[88] deals with the problem of integrating COTS components in systems with high reliability requirements. It presents a case study where the concept of iC2C is used, together with protective wrappers [88]. The goal of this approach is to make non-reliable COTS components which represent a critical regions of systems reliable. The work by Issarny and Banˆatre [97] describes an extension to existing architecture description languages for specifying architectural-level exceptions (configuration excep- tions). This work differs from ours because it emphasizes fault treatment [5] at the architectural level, by means of architecture reconfiguration. Our work, on the other hand, emphasizes architectural-level error recovery. Furthermore, it defines exceptions which should not be handled by any component in the architecture, that is, exception handlers are defined for the whole architecture and are activated under specific situations. In our approach, a component raises an architectural-level exception because it is unable to handle it, and other components in the architecture or exception handlers attached to enclosing configurations (as shown in Figure 2.4) may try to handle it as well.

2.8

Conclusions and Future Work

According to Sprott [166], there is a general consensus in the industry that software components will bring profound changes to the way software is built. Even now, software

2.8. Conclusions and Future Work 42

systems built out of reusable software components are used in a wide range of applications. Many of these systems have high dependability requirements and, in order to achieve the required levels of dependability, it is necessary to incorporate into them means for coping with software faults.

In this paper, we have presented ALEx, an architectural-level exception handling sys- tem which leverages the construction of fault-tolerant component-based applications. The use of traditional language-based exception handling systems for building fault-tolerant component-based systems presents some challenges which have been discussed in Section 2.3. ALEx addresses these issues by instituting exception handling at the architectu- ral level. We have also briefly described FaTC2, an object-oriented framework for the construction of fault-tolerant component-based systems which implements ALEx.

It is important to note that architectural-level exception handling is not a replacement for language-level exception handling. In our view, exception handling in the language level should be the main technique for achieving fault tolerance internally to components (intra-components). Architectural-level exception handling (inter-components) should be employed when (i) an exception can not be handled by the component which raised it, and some other component in the architecture might be able to handle it, and (ii) mechanisms for error detection and recovery must be introduced in a component in order to make it trustworthy (or more trustworthy), but the component should not be modified or its source code is not available.

Until the present moment, the iC2C has been modeled as a synchronous (request/res- ponse) entity and the implementation of FaTC2 conforms to this model. That means that an iC2C is unable to handle asynchronous notifications and that requests are issued under the assumption that a response will be eventually received. This restriction might be too conservative for some applications, since a large amount of glue code may be necessary if a synchronous iC2C needs to interact with asynchronous components (Section 2.6). Hence, a future work for is the definition of an iC2C for which some of these restrictions are relaxed.

FaTC2 still does not implement all the features defined by ALEx. Some features, such as support for attaching handlers to arbitrary configurations and hierarchical handler search upon the receipt of an exception (Section 2.4.3) have not been implemented yet. Hence, another future work for FaTC2 is the implementation of the remaining features described by the specification of ALEx.

Finally, we believe that the design and implementation of ALEx are independent of the C2 architectural style and the iC2C. Hence, we plan to evaluate our approach on generic layered architectures by means of an implementation which does not rely on the concept of iC2C. In this case, new means for associating exception handlers to components would need to be established, in order to maintain the features described in

2.8. Conclusions and Future Work 43

Section 2.4. Computational Reflection [121] and Aspect-Oriented Programming [106] are good candidates for this task.