Computer Science

Different applications require different levels of replication guarantees in order to provide better service (e.g., high availability, scalability). For some applications it is sufficient to replicate using unreliable multicast technology. These applications will be able to continue service (e.g., on another machine) with some previous copy of the state (order, timing or synchronization are not important). Other applications might require replication with guaranteed delivery and total order. To continue service, these components will need to have the latest computed state. These two kinds of applications represent two points in the spectrum of replication and synchronization requirements. Providing a new customized replication service to each application is costly. The innovative technology developed for DCS promotes a modular approach that allows applications with varied replication requirements to effectively use DCS. Applications can instantiate and dynamically configure a DCS component to fit their needs.

Figure 1 DCS and its interfaces

There are three parts to a DCS component (see Figure 1): application interface, distribution protocol stack (DPS) and system interface. The application interfaces provide abstractions that allow the exploitation of the raw services provided by the DPS. It supports two application interfaces: membership and synchrony service (MSS) and data replication service (DRS). These interfaces can be used by a resource manager component and an object replication abstraction component correspondingly. The DPS is based on our versatile replication infrastructure (VRI) and is configurable with respect to its delivery guarantees. DCS components should be able to make use of existing client investments in software and hardware. Existing investments can range from a Java Message Service (JMS) component such as a transport layer, through cluster platform Group Communication Services (GCS) capabilities, to special fast interconnects like InfiniBand. The flexible design of the DPS and the system interface allow the investments to be optimized.

The failure of DPS products to gain wide acceptance is attributed mainly to the complexity of their interfaces and their associated learning curve. There is a definite need for a higher level abstraction to improve the usability of DPS.

There are two main versions of DCS: Core DCS and Data DCS. There is one Core DCS per process and it provides membership services among peer processes. These processes together form a Core Group. A process may be a member in one or more named Core Groups. Applications running on these processes can be members of application groups. Application groups are subsets of a particular named core group. A Data DCS component can be associated with each member of an application group. There can be several Data DCS instances per process. Data DCS instances rely on membership information provided by the Core Group they are associated with.