| Previous | Table of Contents | Next |
DCE-CIOP 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, server process, ORB process, locator, etc.). It merely implies the existence of some agent to which requests may be sent.
• Server ORBs are not required to implement location forwarding mechanisms. An ORB can be implemented with the policy that servers either support direct access to an object, or return exceptions. Such a server ORB would always return locate response messages with either LOCATE_OBJECT_HERE or LOCATE_UNKNOWN_OBJECT status, and never LOCATE_LOCATION_FORWARD status. It would also never return invoke response messages with INVOKE_LOCATION_FORWARD status.
• Client ORBs must, however, be able to accept and process invoke response messages with INVOKE_LOCATION_FORWARD status, since any server ORB may choose to implement a location service. Whether a client ORB chooses to send locate request messages is at the discretion of the client.
• Client ORBs that send locate request messages can use the location policy component found in DCE-CIOP IOR profiles to decide whether to send a locate request message before sending an invoke request message. See Section 16.5.6, “Location Policy Component,? on page 16-20. This hint can be safely ignored by a client ORB.
• A client should not make any assumptions about the longevity of addresses returned by location forwarding mechanisms. If a binding handle based on location forwarding information is used successfully, but then fails, subsequent attempts to send requests to the same object should start with the original address specified in the object reference.
• The “agent? (receiver of an RPC) 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 a gateway that transforms the request and passes it on to another process or ORB. From DCE-CIOP’s perspective, it is only important that invoke request messages 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 invoke request messages sent to the agent would result in either exceptions or replies with INVOKE_LOCATION_FORWARD status, providing new addresses to which requests may be sent. Such agents would also respond to locate request messages with appropriate locate response 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.
In general, the use 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.