Previous | Table of Contents | Next |
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:
• Access via IIOP directly to a member of a server object group.
• Access via IIOP and a gateway.
• Access via a proprietary multicast group communication protocol.
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.