Using Reflection for Incorporating Fault-Tolerance Techniques Into Distributed Applications

Abstract

As part of the Legion metacomputing project, we have developed a reflective model, the Reflective Graph & Event (RGE) model, for incorporating functionality into applications. In this paper we apply the RGE model to the problem of making applications more robust to failures. RGE encourages system developers to express fault-tolerance algorithms in terms of transformations on the data structures that represent computations — messages and methods — hence enabling the construction of generic and reusable fault-tolerance components. We illustrate the expressive power of RGE by encapsulating the following fault-tolerance techniques into RGE components: two-phase commit distributed checkpointing, passive replication, pessimistic method logging, and forward recovery.

Integrating Fault-Tolerant Techniques into the Design of Critical Systems

“…Regarding fault-tolerant techniques applied at software architectural level also several works can be found [31,32,33,4,34]. In [31] Harrison and Avgeriou studied how several fault-tolerant techniques can be carried out as best-known architectural patterns.…”

A philosophical and technical comparison of Legion and Globus

“…The security layer implements the Legion security model [42,43] for authentication, access control, and data integrity (e.g., mutual authentication and encryption on the wire). The core object layer [29,31,32] addresses method invocation, event processing (including exception and error propagation on a per-object basis [44]), interface discovery, and the management of metadata. Objects can have arbitrary metadata, such as the load on a host object or the parameters that were used to generate a particular data file.…”

“…There are also derived classes that interact with back-end queuing systems, BatchQueueHost, and that require the user to have a local account and run as that user, PCDHost [43,45]. There are similar sets of derived types for vaults and class managers that implement policies (for example, replicated objects for fault tolerance or stateless objects for performance and fault tolerance [26,44]) and interact with different resource classes.…”

“…These include classes for object replication for availability [44], messagelogging classes for accounting or postmortem debugging, firewall proxy servers for securely transiting firewalls, enhanced schedulers [34], databases, called collections, that maintain information on the attributes associated with objects (these are used extensively in scheduling), job proxy managers that "wrap" legacy codes for remote execution [38,40], and so on.…”

From Legion to Avaki: The Persistence of Vision

“…Fault-tolerance remains one of the most significant challenges in Grid systems. We began with a belief that there is no good one-size-fits-all solution to the fault-tolerance problem in Grids [13] [23]. Legion addresses fault-tolerance for limited classes of applications.…”