DCS provides a mechanism for communicating information (distribution) among members with a given (consistency) 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 (e.g., HTTP session and stateful beans), as well as the distribution and synchronization of middleware artifacts for performance, scalability, and availability.
Different applications require different levels of replication guarantees in order to provide better service (e.g., high availability and scalability). For some components, it is enough to replicate using unreliable multicast. These components 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 components might require replication with guaranteed delivery and total order. In 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 requirements. Providing a customized replication service for each application requires a major investment.
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 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. There can be several Data DCS instances per process. Data DCS instances rely on membership information provided by the resource manager and the core group.