Previous Table of Contents Next


23.2.5 Accessing Server Object Groups


   The interoperable object group references permit alternative implementation strategies for connecting a client to a server object group. This section illustrates some of these strategies:

   The first of these three options, access directly to a member of a server object group, requires the use of the LOCATION_FORWARD_PERM exception. As object replicas fail and are replaced by new replicas, a stage may be reached at which all of the original replicas, cited in the original interoperable object group reference for the object, are inaccessible. Continued use of the original reference will cause system failure. The LOCATION_FORWARD_PERM exception allows such a reference to be replaced by an updated reference that contains profiles for the new replacement replicas. Thus, the LOCATION_FORWARD_PERM exception is not deprecated when it is used to return an interoperable object group reference. The use of the LOCATION_FORWARD_PERM exception to return a reference that is not an interoperable object group reference continues to be deprecated.

   23.2.5.1 Access via IIOP Directly to the Primary Member

   This strategy may be used to provide access to a fault-tolerant server (server object group) by an unreplicated client or by a client supported by a Fault Tolerance Infrastructure from a vendor different from the vendor that provided the Fault Tolerance Infrastructure for the server. Because the access is directly to the primary member, this strategy may be used only if the server object group has the STATELESS, COLD_PASSIVE, or WARM_PASSIVE Replication Style.

   The client ORB extracts an IIOP profile from the object group reference, preferably the profile containing the TAG_FT_PRIMARY component, and establishes a connection to the endpoint addressed by that profile. If the addressed endpoint is the primary member of the object group, it accepts the connection and processes the request. Otherwise, it replies with a LOCATION_FORWARD_PERM that provides the current object group reference, one profile of which (the one with the TAG_FT_PRIMARY component) contains a profile that addresses the current primary.

   23.2.5.2 Access via IIOP and a Gateway

   This strategy may be used to provide access to a fault-tolerant server (server object group) by an unreplicated client hosted by a non-fault-tolerant ORB and by a client supported by a Fault Tolerance Infrastructure from a vendor different from the vendor that provided the Fault Tolerance Infrastructure for the server.

   The client ORB extracts an IIOP profile from the object group reference and uses that reference to establish a connection to the endpoint addressed by that profile. If that endpoint is a gateway, it accepts the connection and forwards messages to the members of the object group, typically using a (proprietary) multicast group communication protocol.

   The client ORB and the client application object must be unaware of whether the interoperable object group reference addressed a gateway or the primary member.

   23.2.5.3 Access via a Multicast Group Communication Protocol

   Some vendors may choose to use a proprietary multicast group communication protocol within a fault tolerance domain, or even between fault tolerance domains supported by a Fault Tolerance Infrastructure from the same vendor.

   The fault tolerance domain identifier and object group identifier contained in the TAG_FT_GROUP component of the profiles of the object group reference could be used to establish a connection using the proprietary multicast group communication protocol. The details of connection establishment, and recovery from faults during connection establishment, for the multicast group communication protocol are not defined in this specification.

   The use of a proprietary multicast group communication protocol must, however, be invisible to both the client application object and the server application object.