Skip to main content

Group Communication – Distribution and Consistency Services (DCS)

DCS provides a mechanism for communicating information—distribution—among members with a consistent quality of service (QoS). Failure detection mechanisms that support and allow guaranteed QoS are an inherent part of DCS and an integral part of its services. DCS is also referred to as GMS (group membership service) and/or GCS (group communication service).

DCS can support state replication requirements, such as HTTP sessions and stateful beans, as well as the distribution and synchronization of middleware artifacts for performance, scalability, and availability.

DCS and its interfacesDCS and its interfaces

Different applications require different levels of replication guarantees to provide better service, including high availability and scalability. For some components, replicating using an unreliable multicast is sufficient. These components would 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 components might require replication with guaranteed delivery and total order. To continue service, these components would need to have the latest computed state. These two kinds of applications represent two points in the spectrum of replication requirements. Providing a customized replication service for each application requires a major investment.

There are three parts to a DCS component, as shown below: application interface, distribution protocol stack (DPS), and system interface. The application interfaces provide abstractions that allow the exploitation of the row services provided by the DPS. Currently, DCS supports two application interfaces: membership and synchrony, and data replication. 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 exploit existing customer investments in terms of software and hardware, as well as evolving IBM middleware components. Existing investments can range from a JMS component as a transport layer, through cluster platform GCS capabilities, to special hardware like InfiniBand. Exploitation of such investments is supported by the flexible design of the DPS and the system interface.

There are two main versions of DCS—Core DCS and Data DCS (a.k.a. Slave DCS). There is one Core DCS per process (JVM) and it provides membership services among peer processes (JVMs) in a cluster. These processes together form a core group. A cluster may have one or more named core groups. Components within these processes can be members of application groups. Application groups are subsets of the core groups. A Data DCS component can be associated with each member of an application group. Several Data DCS instances can occur per process. Data DCS instances rely on membership information provided by the resource manager and the core group.

The Big PictureThe Big Picture