Building dependable distributed systems from commercial off-the-shelf components is of growing practical importance. For both cost and production reasons, there is interest in approaches and architectures that facilitate building such systems. The AQuA architecture is one such approach; its goal is to provide adaptive fault tolerance to CORBA applications by replicating objects. The AQuA architecture allows application programmers to request desired levels of dependability during applications' runtimes. It provides fault tolerance mechanisms to ensure that a CORBA client can always obtain reliable services, even if the CORBA server object that provides the desired services suffers from crash failures and value faults. AQuA includes a replicated dependability manager that provides dependability management by configuring the system in response to applications' requests and changes in system resources due to faults. It uses Maestro/Ensemble to provide group communication services. It contains a gateway to intercept standard CORBA IIOP messages to allow any standard CORBA application to use AQuA. It provides different types of replication schemes to forward messages reliably to the remote replicated objects. All of the replication schemes ensure strong, data consistency among replicas. This paper describes the AQuA architecture and presents, in detail, the active replication pass-first scheme. In addition, the interface to the dependability manager and the design of the dependability manager replication are also described. Finally, we describe performance measurements that were conducted for the active replication pass-first scheme, and we present results from our study of fault detection, recovery, and blocking times.

Middleware is a class of software systems above the operating system which is becoming widely used for programming distributed systems. Voting is a fundamental operation when distributed systems involve replicated components. However support for voting in middleware is very limited. The paper describes issues involved with supporting voting, and more general data fusion, in middleware. We describe the Voting Virtual Machine (VVM) architecture, which can be embedded in different middleware substrates such as .NET and CORBA. We also describe its companion Voting Definition Language (VDL), which allows for portable description of voting algorithms. The VVM and VDL, together with the external VVM voting manager provide for voting transparency and adaptive voting. Finally, we describe how the simple "byte-by-byte" value comparison schemes used in other voting middleware as well as in byzantine fault tolerant multicast systems do not work in the face of the heterogeneity inherent in distributed systems.

The Quality Objects (QuO) middleware is a set of extensions to standard distributed object computing middleware that is used to control and adapt the quality of service in a number of distributed application environments, from wide-area to embedded distributed applications. This paper compares and contrasts the characteristics of key use cases and the variations in QuO implementations that have emerged to support them. We present these variations in the context of several actual applications being developed using the QuO middleware.

As networks and the use of communications within applications continue to grow and find more uses, so too does the demand for more control and manageability of various "system properties" through middleware. An important component supporting an integrated property architecture is the concept of an object gateway, which is a quality-of-service (QoS)-aware element transparently inserted at the transport layer between clients and objects to provide managed communication behavior for the particular property being supported. In this paper, we introduce the concept of a QoS-oriented gateway to integrate a variety of QoS enforcement and implementation mechanisms controlling the underlying distributed interactions. We discuss the functions performed by such a component in achieving the desired overall end-to-end QoS, and the design considerations underlying our current implementation. We conclude with experiences to date with two variations of the gateway: one controlling managed latency and throughput using bandwidth allocation, and one controlling dependability through the coordination of object replicas.

Dependable distributed systems are difficult to build. This is particularly true if they have dependability requirements that change during the execution of an application, and are built with commercial off-the-shelf hardware. In that case, fault tolerance must be achieved using middleware software, and mechanisms must be provided to communicate the dependability requirements of a distributed application to the system and to adapt the system's configuration to try to achieve the desired dependability. The AQuA architecture allows distributed applications to request a desired level of availability using the Quality Objects (QuO) framework and includes a dependability manager that attempts to meet requested availability levels by configuring the system in response to outside requests and changes in system resources due to faults. The AQuA architecture uses the QuO runtime to process and invoke availability requests, the Proteus dependability manager to configure the system in response to faults and availability requests, and the Ensemble protocol stack to provide group communication services. Furthermore, a CORBA interface is provided to application objects using the AQuA gateway. The gateway provides a mechanism to translate between process-level communication, as supported by Ensemble, and IIOP messages, understood by Object Request Brokers. Both active and passive replication are supported, and the replication type to use is chosen based on the performance and dependability requirements of particular distributed applications.

Trends in networking and distributed computing are creating a new generation of applications that must adapt as the environment within which they execute changes. Examples of adaptation include switching protocols to overcome a security exposure or failure mode seen only in certain settings, changing data rates to accommodate a slow link, or adapting the behavior of a high level application to match the set of participants using the application. We describe the Ensemble system, a tool for building adaptive distributed programs. © 1998 John Wiley & Sons, Ltd.

The Horus system supports a communication architecture that treats protocols as instances of an abstract data type.This approach encourages developers to partition complex protocols into simple microprotocols, each of which is implemented by a protocol layer.Protocol layers can be stacked on top of each other in a variety of ways, at run-time.First, we describe the classes of protocols that can be supported this way.Next, we present the Horus object model that we designed for this technology, and the interface between the layers that makes it all work.We then present an example layer that implements a group membership protocol.Next, we show how, given a set of required properties, an appropriate stack can be constructed.We look at an example stack of protocols, which provides fault-tolerant, totally ordered communication between a group of processes.The work contributes a standard framework for protocol development and experimentation, provides a high performance implementation of the virtual synchrony model, and introduces a methodology for increasing the robustness of the protocol development process.