{'fraction_non_alphanumeric': 0.02756892230576441, 'fraction_numerical': 0.006265664160401002, 'mean_word_length': 5.689944134078212, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Building Dependable Distributed Objects with the AQuA Architecture 1

Providing fault tolerance to distributed applications is an important problem. The flexibility that software can offer makes it a natural choice for implementing a significant portion of the fault tolerance of dependable distributed systems. Furthermore, when the dependability requirements change during the execution of an application, the fault tolerance approach must be adaptive in the sense that the mechanisms used to provide fault tolerance may change at runtime. The AQuA architecture [Cuk98, Cuk99] provides a flexible approach for building dependable, distributed, object-oriented systems that support adaptation needed due to both faults and changes in an application’s dependability requirements. The AQuA architecture is composed of several components: Quality Objects, Proteus, Maestro/Ensemble, and gateways. In order to provide a simple way for application objects to specify the level of dependability they desire, the AQuA architecture uses the Quality Objects (QuO) [Zin97, Loy98] framework to process and invoke dependability requests. QuO allows distributed applications to specify quality of service (QoS) requirements at the application level using the notion of a “contract,” which specifies actions to be taken based on the state of the distributed system and desired application requirements. Proteus [Sab99] provides fault tolerance in AQuA by dynamically managing replicated distributed objects to make them dependable. It does this by configuring the system in response to faults and changes in desired dependability levels. The choice of how to provide fault tolerance involves choosing the types of faults to tolerate (crash failures, value, or time faults), the styles of replication to use (active or passive), the types of voting to use (“pass first,” “leader only,” or majority), the degrees of replication to use, and the location of the replicas on the different hosts, among other factors. Proteus uses Maestro/Ensemble [Hay98, Vay98] as the underlying group communication system that provides reliable multicast, total ordering, and virtual synchrony. Communication between all architecture components is done using gateways, which translate CORBA object invocations into messages that are transmitted via Ensemble, and contain mechanisms to implement a chosen fault tolerance scheme.