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 object 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 to use a POA servant locator and the other is to use a servant activator.

Client side implementation

The client has to expect the location forwarding GIOP message and should respond to it in setting the Profile of its Object right.

Conclusion

Changing the 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 responded 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 other/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