15.6 Object Location

   The GIOP is defined to support object migration and location services without dictating the existence of specific ORB architectures or features. The protocol features are based on the following observations:

   A given transport address does not necessarily correspond to any specific ORB architectural component (such as an object adapter, object server process, Inter-ORB bridge, and so forth). It merely implies the existence of some agent with which a connection may be opened, and to which requests may be sent.

   The “agent? (owner of the server side of a connection) may have one of the following roles with respect to a particular object reference:

• The agent may be able to accept object requests directly for the object and return replies. The agent may or may not own the actual object implementation; it may be an Inter-ORB bridge that transforms the request and passes it on to another process or ORB. From GIOP’s perspective, it is only important that requests can be sent directly to the agent.

• The agent may not be able to accept direct requests for any objects, but acts instead as a location service. Any Request messages sent to the agent would result in either exceptions or replies with LOCATION_FORWARD status, providing new addresses to which requests may be sent. Such agents would also respond to LocateRequest messages with appropriate LocateReply messages.

• The agent may directly respond to some requests (for certain objects) and provide forwarding locations for other objects.

• The agent may directly respond to requests for a particular object at one point in time, and provide a forwarding location at a later time (perhaps during the same connection).

   Agents are not required to implement location forwarding mechanisms. An agent can be implemented with the policy that a connection either supports direct access to an object, or returns exceptions. Such an ORB (or inter-ORB bridge) always return LocateReply messages with either OBJECT_HERE or UNKNOWN_OBJECT status, and never OBJECT_FORWARD status.

   Clients must, however, be able to accept and process Reply messages with LOCATION_FORWARD status, since any ORB may choose to implement a location service. Whether a client chooses to send LocateRequest messages is at the discretion of the client. For example, if the client routinely expected to see LOCATION_FORWARD replies when using the address in an object reference, it might always send LocateRequest messages to objects for which it has no recorded forwarding address. If a client sends LocateRequest messages, it should be prepared to accept LocateReply messages.

   A client shall not make any assumptions about the longevity of object addresses returned by LOCATION_FORWARD (OBJECT_FORWARD) mechanisms. Once a connection based on location-forwarding information is closed, a client can attempt to reuse the forwarding information it has, but, if that fails, it shall restart the location process using the original address specified in the initial object reference.

   For GIOP version 1.2 and 1.3, the usage of LOCATION_FORWARD_PERM (OBJECT_FORWARD_PERM) behaves like the usage of LOCATION_FORWARD (OBJECT_FORWARD), but when used by the server it also provides an indication to the client that it may replace the old IOR with the new IOR. When using LOCATION_FORWARD_PERM (OBJECT_FORWARD_PERM), both the old IOR and the new IOR are valid, but the new IOR is preferred for future use.

   Note – Usage of LOCATION_FORWARD_PERM and OBJECT_FORWARD_PERM is now deprecated, due to problems it causes with the semantics of the Object::hash operation. LOCATION_FORWARD_PERM and OBJECT_FORWARD_PERM features could be removed from some future GIOP versions if solutions to these problems are not provided.

   Even after performing successful invocations using an address, a client should be prepared to be forwarded. The only object address that a client should expect to continue working reliably is the one in the initial object reference. If an invocation using that address returns UNKNOWN_OBJECT, the object should be deemed nonexistent.

   In general, the implementation of location forwarding mechanisms is at the discretion of ORBs, available to be used for optimization and to support flexible object location and migration behaviors.