Adding high availability features to server applications using aspect oriented programming

Software fault tolerance (FT) techniques are designed to allow a system to tolerate software faults that remain in the system after its development. An important class of software fault tolerance techniques utilizes independently developed but functionally equivalent software variants (often called versions). Independent design and implementation of variants is aimed at reducing the probability that more variants contain the same error(s), since the variants will act as redundant components masking or replacing each other in case of an error is activated on a given input. Recovery blocks (RB) [1] and N-version programming (NVP) [2] are well-known software FT schemes. They are used in critical applications ranging from embedded control systems to availabilityor security-critical server applications in carrier grade products. • The RB scheme implements a passive redundancy approach. It contains at least two variants of the same functionality, an acceptance test and an executive. Receiving a request, the executive establishes a checkpoint by saving the state of the application, then executes the primary variant and invokes the acceptance test on the result of the variant. If the result is acceptable then this will form the output of the FT scheme. In case of a failure reported by the acceptance check, recovery (restoration of state) is performed, and the next variant is invoked. Variants are called in this way until a valid result is found. If no variant can provide acceptable result then a failure is reported. • The NVP scheme implements an active redundancy approach. It contains at least three variants for the same functionality, a voter and an executive. The executive invokes all the variants in a parallel way forwarding to them the input data, then collects the output results and forwards them to the voter. If a majority result exists then it will be the result of the NVP scheme, otherwise a failure is reported. Accordingly, the majority of faultfree variants mask the output of an erroneous one. There are several extra requirements towards the software that is to be used as a variant in an FT scheme. The communication with the environment, the use of global variables, the implementation of error handling etc. are restricted since all input and output shall be strictly controlled by the executive as presented above. Accordingly, variants shall be implemented by taking specific rules into account. If a service implemented by an existing software (called in the following as legacy software) is to be transformed to a fault tolerant one then a natural idea is to use the existing software implementation (or parts of it) as a variant in the FT scheme. (Besides this, another variant(s) have to be implemented as well. ) Unfortunately, legacy software typically does not satisfy the requirements mentioned above, thus re-design or modification become necessary. These modifications usually mix up the concerns of the original functionality (business logic) and fault tolerance, as source code snippets for error detection, fault handling and redundancy management have to be modified or inserted into the original code. When transforming an existing service to a fault tolerant one, we face the following challenges: • Establishing rules to form a variant and modifying the legacy software to satisfy these rules. To do this, a technique was needed that allows performing these modifications in such a way that is easy to review, verify and change if necessary. Direct modification of the source code was not feasible from this point of view, as clear separation of the original business logic and the FT extensions was needed. • Elaborating the core logic of the FT scheme in such a way that is easy to re-use if another service is to be transformed to a fault tolerant one. There are several approaches that aim at separating functional and non-functional (e.g. fault tolerance) aspects. Library calls to pre-defined mechanisms [3], reflection [4], and meta-object protocols [5] are mature and well-tried techniques that address the separation of func-