Location forwarding


Context

The motivation to support location forwarding for objects is to allow objects to move or forward certain requests to other objects. Moving of objects is very important for the Common Object Services LifeCycle Service. An objet complying to the LifeCycleObject interface, defined by the LifeCycle Service should support the move operation. The move operation allows the client to keep its object reference to the object, but the object is going to be relocated on the same or a different server. Making location forwarding transparent to the client is the most important issue.

Communication between server and client

GIOP defines a message named "LOCATION_FORWARD", which should be used to inform the client stub, that the object has been moved. The message body has to contain an object reference to the new location of the forwarded object.

Server side implementation

Two approaches are possible, one is that the POA replaces the object with a forwarding servant, which knows the new location. This servant will then raise an exception each it time it is called, as supposed to be the actual object. The exception will be a user exception and will be caught in the marshalling code of the server request "IIOP_ServerRequest". The involved methods are "set_exception", "marshall" and "init_reply". "set_exception" will check the user exceptions for the special one, only raised by the forwarding servant and will extract the new location. "init_reply" will then create the proper GIOP Reply message with the message type set to LOCATION_FORWARD. The message is encoded into a CDR (Common Data Representation) stream. The second approach is to use a POA servant locator for the child POA, where the object resides on. The servant locator will be used each time the object will be accessed. Basically two methods, named "preinvoke" and "postinvoke" are called each time before and after the actual upcall to the object. Forwarding using the servant locator works in the following way. The object tells its servant locator that it has moved and supports the servant locator with the new object reference. The object locator then raises a special system exception "forward_request" in "preinvoke" each time the object is called from now on. The exception is then caught by the lowest possible level, when the system exceptions are going to be marshalled. Which is in "TAO_Server_Connection_Handler", the involved methods are "handle_input" and "send_error". "handle_input" checks for errors (involving exceptions) and calls "send_error" to create the proper GIOP Reply containing either the system exception or the location forwarding in case the system exception was the "forward_request" exception.

Client side implementation

The client has to expect the location forwarding GIOP message and should respond to it in setting the IIOP_Profile of its IIOP_Object right. The IIOP_Object is a low level object, to which CORBA::Object has a pointer to. The reply type is determined by "TAO_GIOP_Invocation::invoke" which then calls "TAO_GIOP_Invocation::location_forward". "location_forward" sets the changes the IIOP_Profile of the object. The call is then reissued by "TAO_IIOP_Object::do_static_call".

Conclusion

Changing the IIOP_Profile is transparent to the client. So the client gets no idea, that the object now resides somewhere else. The result of the above mentioned solution is that if an object moves the client will notice it with the next call to the object. If the object moves again, the original location is not bothered at all again. Say if the original location was A, then it moved to B and finally to C. First location A responeded with a GIOP Location Forward to the client, then B gets used and finally after moving the object to C, B will send a GIOP Location Forward and location C gets used. There is "no" concept of a home location. If the object moves very often and old servers die it might be a problem, because clients, which did not call on the object lately will not know where to search. Though in the situation of a home location, there is also the risk that this server might die and the object is not reachable any more.

Optimization

In the case, when the object moves several times, a chain of forwarding servers is created. But this chain might be easily disturbed by just one server failing. A good idea is to give the servant locator more intelligence to tell all the oter/previous servers where the object is now. This will of course increase the communication overhead in the case of a move, but we get a high reliability against dying hosts.
For more details and questions,

Michael Kircher

Irfan Pyarali