I've actually implemented this for our application.
Our client code required server callbacks, but we could not bind our client's objects to an RMI registry.
I created an interface INonBindingRemoter
with method: public Object remote(Object target, Class targetInterface) throws RemotingException;
The returned Object is a serializable instance of targetInteface which contains a reference to a Remote object. The Remote object is resident on the client, but is not bound to a RMI Registry. targetInterface invocations are delegated to the Remote object which in turn delegates calls to the target object residing on the client. The returned object is suitable for as a callback argument when passed to a remote method on a remoted server object.
My implementation of INonBindingRemoter is not particularly clean, but is functional.
It involved the creation of a NonBindingRMIServiceExporter, a perversion of Spring's RmiServiceExporter.
NonBindingRMIServiceExporter calls to UnicastRemoteObject.exportObject(...), but does not bind the object to a RMI registry.
I also had to use a custom class 'LookupFreeRmiProxyFactoryBean' in place of Spring's RmiProxyFactoryBean, to subvert the typical stub lookup process. Some of the messiness in my implementation surrounds that fact that setServiceUrl on LookupFreeRmiProxyFactoryBean must be given a garbage value, because a RMI lookup is not actually performed.
I don't really plan on supplying code here - though if developers in spring core want to see what i've done to poach any ideas, I can arrange it.
Typical usage is as follows:
My POJI: ICallback
My POJO: Callback implements ICallback
ICallback c1 = new Callback();
INonBindingRemoter test = new NonBindingRemoter();
ICallback proxy = (ICallback)test.remoteProperty(c1, ICallback.class);
IService1 s1... //get handle to remoted server service