| Previous | Table of Contents | Next |
23.1.3.1 Replication and Object Groups
To render an object fault-tolerant, several replicas of the object are created and managed as an object group. While each
individual replica of an object has its own object reference, an additional interoperable object group reference (IOGR) is
introduced for the object group as a whole. It is this object group reference that the replicated server publishes for use
by the client objects. The client objects invoke methods on the server object group, and the members of the server object
group execute the methods and return their responses to the clients, just like a conventional object. Because of the object
group abstraction, the client objects are not aware that the server objects are replicated (replication transparency) and
are not aware of faults in the server replicas or of recovery from faults (failure transparency).
23.1.3.2 Fault Tolerance Domains
Many applications that need fault tolerance are quite large and complex. Managing such an application as a single entity is
inappropriate. Consequently, this specification defines fault tolerance domains
, as illustrated in Figure 23-1. Each fault tolerance
domain typically contains several hosts and many object groups, and a single host may support several fault tolerance domains.
Existing security policies and mechanisms can be maintained by ensuring that a fault tolerance domain is entirely contained
within a single security domain. All of the objects groups within a fault tolerance domain are created and managed by a single
Replication Manager, but they can invoke and can be invoked by objects within other fault tolerance domains. The concept of
fault tolerance domains allows applications to scale to arbitrary sizes, by allowing a smaller number of objects to be managed
by each Replication Manager.
ORB withoutsupport forfault tolerance
Host 6
E1Host 1 Host 3 D2 New York
A
BCHost 5 Fault Tolerance 2 1 Domain
Figure 23-1 Fault tolerance domains are shown lightly shaded, hosts are shown darkly shaded, and members of an object group
are shown unshaded. The members of object group B are denoted B1, B2 and B3, and similarly for object groups C, D and E.
23.1.3.3 Fault Tolerance Properties
Each object group has an associated set of fault tolerance properties. Examples of such properties are the ReplicationStyle
(COLD_PASSIVE, WARM_PASSIVE, ACTIVE, etc.), InitialNumberReplicas, MinimumNumberReplicas, etc. It is possible to define fault
tolerance properties that apply to all object groups within a fault tolerance domain or to all object groups of a specific
type. It is also possible to set the properties of an object group when it is created, and to change the properties dynamically
after the object group is created.
23.1.3.4 Strong Replica Consistency
Strong replica consistency requires that the states of the members of an object group remain consistent (identical) as methods
are invoked on the object group and as faults occur. More specifically, for the ACTIVE ReplicationStyle, Strong Replica Consistency
means that, at the end of each method invocation on the object group, all of the members of the object group have the same
state. For the COLD_PASSIVE and WARM_PASSIVE ReplicationStyles, it means that, at the end of each state transfer, all of the
members of the object group have the same state. Strong Replica Consistency requires Strong Group Membership, as well as Uniqueness
of the Primary for passive replication. Strong Group Membership means that, for each method invocation on an object group,
the Fault Tolerance Infrastructures on all hosts have the same view of the membership of the object group. Uniqueness of the
Primary for passive replication means that one and only one member of the object group executes the methods invoked on the
object group.