520 DISTRIBUTED OBJECT-BASED SYSTEMS CHAP. 9
9.1.7 Fault Tolerance
CORBA systems have long lacked real support for fault tolerance. In most cases, a failure was simply reported to the client, and the system undertook no further action. For example, if a referenced object could not be reached because its associated server was( temporarily) unavailable, a client was left on its own. In CORBA version 3, fault tolerance is explicitly addressed. The specification of a fault-tolerant CORBA can be found in( OMG, 2000d).
Object Groups
The basic approach for dealing with failures in CORBA is to replicate objects into object groups. Such a group consists of one or more identical copies of the same object. However, an object group can be referenced as if it were a single object. A group offers the same interface as the replicas it contains. In other words, replication is transparent to clients. Different replication strategies are supported, including primary-backup replication, active replication, and quorumbased replication. These strategies have all been discussed in Chap. 6. There are various other properties associated with object groups, the details of which can be found in( OMG, 2000d).
To provide replication and failure transparency as much as possible, object groups should not be distinguishable from normal CORBA objects, unless an application prefers otherwise. An important issue, in this respect, is how object groups are referenced. The approach followed is to use a special kind of IOR, called an Interoperable Object Group Reference( IOGR). The key difference with a normal IOR is that an IOGR contains multiple references to different objects, notably replicas in the same object group. In contrast, an IOR may also contain multiple references, but all of them will refer to the same object, although possibly using a different access protocol.
Whenever a client passes an IOGR to its ORB, that ORB attempts to bind to one of the referenced replicas. In the case of IIOP, the ORB may possibly use additional information it finds in one of the IIOP profiles of the IOGR. Such information can be stored in the Components field we discussed previously. For example, a specific IIOP profile may refer to the primary or a backup of an object group, as shown in Fig. 9-17, by means of the separate tags TAG�PRIMARY and TAG�BACKUP, respectively.
If binding to one of the replicas fails, the client ORB may continue by attempting to bind to another replica, thereby following any policy for next selecting a replica that it suits to best. To the client, the binding procedure is completely transparent; it appears as if the client is binding to a regular CORBA object.