It happens that any proxy returned through a servant always uses indirect binding if the adapter uses it.
If the caller (the proxy user) and the object adapter share the same registry, everything is fine, but if the caller cannot see the registry, the proxy is left unsable (or bind to an object with the same identity if there is one).
Maybe there is some configuration / design advice to resolve this problem, but i have not been able to find one.
For example, given those slice definitions:
interface MyItf {
void doIt();
};
interface Manager {
MyItf* getMyItf();
};
With those interfaces correctly implemented, consider two networks (A,B) where only two hosts are mutually visible (GwA, GwB). Each gateway runs the Manager servants and bind them to AdparterA and AdapterB object adapters respectively.
Each network uses indirect binding to register its endpoints into an ice registry only accessible inside its network.
Any client application executed inside one of the network (i.e. A) can connect to its Manager and request for a MyItfPrx proxy through the getMyItf() call.
When the MyItfPrx doIt() method is called, the relevant endpoint is resolved and the call succeed.
Now, if we change the configuration file for network B so that the adapter endpoint if forced to bind to a known host/port so that it can be reached from network A, when the myItfB = getMyItf() method is called, the returned proxy only get an indirect endpoint (i.e. like My/Identity @AdapterB).
Any call to myItfB.doIt() method will either succeed or fail depending on the ability for the registry in network A to resolve this proxified string!
This is counter-intuitive as it is expected that the returned proxy is only bound to the servant that was registered in the remote site, independently of the locator run on the client side.
A workaround, only used to illustrate this dramatic behavior, is to change the Manager interface to return the identity of the created proxy instead of the proxy itself, and let the client ask for the proxy given its fully qualified stringified proxy name.
interface Manager {
string getMyItfIdentity();
};
The identity string returned is used in statements like this:
String ident = aManagerPrx.getMyItfIdentity();
ObjectPrx prx = communicator().stringToProxy(ident+":tcp -h GwB -p 10000");
MyItfPrx myItf = MyItfPrxHelper.checkedCast(prx);
In this case "tcp -h GwB -p 10000" is the endpoint where the Manager on network B can be contacted from network A.
I really thing this is a bug, rather than a misconception, because the endpoint for a returned proxy should really not be resolved based on the client locator, but based on the resolved endpoint of the servant that has created it.
Regards