On The Fly Remote method generation
Hi,
We have a design where in a module can be executed remotely as well as locally. The remote implementation of the module uses RMI.
The Issue that we are facing is as follows. We want the client code to remain unchanged even if the implementation is switched. Hence, the base interface which declares the methods that this module can be used for should not implement any of RMI specific interfaces (Remote), nor should the functions declare throwing RemoteException.
However, if this is not done then RMI would not let be bind the module as an RMI service :(.
Hence, my question is - is there a way to wrap / export an existing class / class method such that it will exhibit as a Remote implementation at runtime. If there is any such way, then I could declare my normal (non-RMI specific) interface and while binding the object I could wrap it / export it to Remote. I got this idea from the UnicastRemoteObject.export() function.
Currently, the approach we had to take was declare two interfaces - one for local access and other for remote access. These two interfaces are abstracted by providing an accessors, which internally handles the details of Remote / Local module usage.
Any help, or pointers to it would be greatly appreciated.
Thanks a lot.
# 2
Or you can declare all your methods to throw IOException which is the base class of RemoteException but doesn't include every exception class in the entire JDK.
You can't get rid of the requirement to declare RemoteException altogether, and you shouldn't want to. Remote calls can fail in mysterious ways and somebody needs to know about them.
Or you could write a proxy class for the client that presents the desired client-side interface and calls the remote methods itself, handling all the remote conditions internally, if that is possible given your application semantics.
ejpa at 2007-7-29 16:51:57 >
# 4
Thanks ejp.
Currently, we have a hierarchy of accessor classes which the client uses to access the module's functions. The accessor can be either RemoteAccessor or LocalAcessor. The RemoteAccessor implements the module's RemoteProvider interface while the LocalAccessor implements the module's LocalProvider interface.
The RemoteProvider interface exposes all the functions of the LocalProvider interface and adds the RemoteException to the functions. The RemoteAccessor now implements all these functions, and catches RemoteException, wraps it with a module specific exception and throws this new exception.
So I suppose that the kind of proxy you are mentioning is what we are using right now - maybe there is a more elegant solution to implementing the proxy. I'm also having a look at cajo's TransparentItemProxy.
But the issue that I think exists over here is that, we have to maintain two interfaces - RemoteProvider and LocalProvider, which seems to be an overkill and a maintenance problem as well, because each time a new method is to be added, the dev needs to ensure that it is added in both these interfaces - in Local without RemoteException and in Remote with RemoteException :(.
You have any other suggestions here?
Thanks a lot.
