Related Projects


A container-based mechanism for service fault tolerance


Service-oriented architecture, fault tolerance, grid, web services


Fault tolerant computing accepts that faults are unavoidable. Well understood mechanisms have therefore evolved that anticipate faults but prevent these from leading to system failure. Fault Tolerant Containers are an innovative approach to improving service availability and reliability. These containers encapsulate externally provided services and are configured with a policy which specifies fault tolerance mechanisms to apply to the contained services. The container proxies calls to its services, passing them on to replicas in a pattern determined by the policy. A tool and SDK simplify the creation and deployment of the container and its policy.


Our architecture is an application of fault tolerance policies to a set of services via a service container. The container acts as a proxy to the actual services, i.e. a message en route to a deployed service is intercepted by the container. The actions of the container are transparent to both the client and service provider. The client believes they are contacting one specific service, whilst, in fact their calls may be routed via multiple services to improve overall reliability.


Figure 1: The anatomy of a service container

We apply a fault tolerance policy to each message passing through the service container walls. To enact the policy we pass the message through a model representing the policy. In order for a message to be passed through it must be wrapped in a context. The job of wrapping a message is done by a Listener object. Effectively, a Listener is a Java servlet that is mapped to a given endpoint. The context is passed throughout a policy model from procedure to procedure through connections. The policy model itself consists of an acyclic graph of procedures. Essentially, we are providing nothing more than a mechanism by which actions can be applied to service messages. A procedure implements the actions of the policy model, for example in the case of a redundancy procedure, it clones a service message and concurrently redirects the clones down several connections. There are no limitations on the functionality of the policy model or constituent procedures. This is entirely extensible.

Unlike EJB components, the “contained” services do not actually reside inside the container. This is also what distinguishes our service container from service containers as used in the more generic web server context. In reality, any of these services could be called directly without traversing the container.

Representing Policy Models and Procedures

In practice, the information essential to a policy model is represented in eXtensible Markup Language (XML). This XML model consists of three compulsory elements: a policy element plus one or more procedures and connections. There is a one-to-one mapping between each procedure element in the policy model and a procedure sub-class. Each procedure sub-class must expose an invokable interface. In addition to the invokable interface, each procedure must have a constructor that takes the corresponding XML element from the policy model as an argument.

Deployment Tool

Containers are deployed as Java web applications. The step of creating a WAR file containing enough information to function as a service container is sufficiently complex to require a tool. We have developed such a graphical tool to aid in building and configuring a fault tolerant service container. The tool represents a bridge between the code development and container deployment.

A user of the tool begins by creating a project. A project consists of a collection of jars developed by the user, and series of endpoint representations. The jars must contain the Listener and Procedure classes developed in accordance with the SDK. Each endpoint represents a proxy service to be deployed into the service container. The name of the endpoint, in addition to that of the project, is used to create its eventual URL reference.

Each endpoint maps to precisely one Listener and one policy model. The Listener is selected from a list of candidates within the imported jar files. A policy model is chosen using a file selection dialogue. Once chosen the policy model can be edited rendering the display shown below. Policy models can also be created and edited directly from the main menu or externally using any XML or text editor.

Figure 2: Policy Model in the Deployment Tool

Every policy model is displayed as a directed graph and can be edited graphically by clicking on nodes or edges. Each node represents a map to a procedure and each edge a connection between procedures. A procedure can be edited by right-clicking on it's corresponding node in graph. Every procedure must be given a name and a Java class implementation. A procedure may have optional nested XML. In the edit procedure dialog a list of available procedure Java classes are displayed. The source of procedure classes is the tool itself, for generic classes, and any imported Jar files in the project. The name is immediately reflected in the graph representation. One and only one procedure can be chosen for the root procedure.

Every single procedure requires different XML to be nested. There are no limits placed on what that XML is, provided it is well-formed. No requirements have been lodged for XML schemas or document type descriptors (DTDs) by the tool or architecture. When developing a procedure, the XML required must be known as each procedure must parse its own nested set of XML. The abstract procedure class knows only how to deal with procedure and connection XML tags.

The policy model editor saves the policy model in XML format, embedding custom XML in the appropriate procedure tag. Models will vary in complexity, but the model can remain simple whilst providing complex functionality. There is an obvious tradeoff between the complexity of the procedures and the model within which they reside.

Final deployment is invoked through the main menu. This creates a war file as described earlier and places it wherever the user dictates. Creation of the war file requires the copying of jars and XML model files, the generation of a web application deployment file, and finally an archiving process to create the war. If the war is located correctly, namely the webapps directory within the tomcat server, the service container will be deployed dynamically being immediately ready for use. To use, the client must point at one of the endpoints mapping to each proxy service.


Service negotiation

Service composition

Quality of service modelling



Hall, S., Dobson, G. and Sommerville, I. 2005. A Container-Based Approach to Fault Tolerance in Service-Oriented Architectures.


Glen Dobson (Lancaster)


Page Maintainer: Credits      Project Members Last Modified: 5 August, 2005