Bi-direction remoting after client connects to server

[ge0ffrey]

Is the following possible using Spring's remoting support?

The client A connects to the server S using remoting (RMI, burlan, hessian, ...) and registers itself (so the connection stays open).
The client B also connects to server S the same way.
Can the server S send a message to the client A telling him that B registered?

This without A having to poll or A having to set up it's own server (which won't work as A and B have a firewall blocking incoming connections).

Over basic RMI this works: the connection stays open and A registers itself on S so S has a reference to A to call him.

[oliverhutchison]

Yes and no.

Yes. This will work just fine for RMI with or without Spring.

No. This does not work for the HTTP, Hessian or Burlap remoting protocols as these only support a simple request/response - they have no support for callacks.

Ollie

[ge0ffrey]

Without Spring I see no problem, but with Spring I don't understand how to tell Spring that my TheCallBack should be proxied (instead of a serialized pojo):

CLIENT:
TheService theService = (TheService) applicationContext.getBean("theService");
TheCallBack theCallBack = new TheCallBackImpl();
theService.registerTheCallBack(theCallBack); // doesn't work


SERVER:

public void registerTheCallBack(TheCallBack theCallBack) {
this.theCallBack = theCallBack;
theCallBack.callBack();
}

[oliverhutchison]

Does TheCallBack implement java.rmi.Remote?

[ge0ffrey]

No, it doesn't.

Should it?
TheService doesn't either because Spring does that for me.

Instead of doing:
TheCallBack theCallBack = new TheCallBackImpl();
Can I ask Spring to give me a TheCallBack, which should be proxyable (like with RmiServiceExporter), but doesn't open a RMI server and doesn't bind that proxy in that server (unlike RmiServiceExporter).

So is there an RmiServiceExporter that doesn't start up a RMI server?

[oliverhutchison]

Spring uses something of a hack to get POJO remoting over RMI working and there is no support for POJO call backs.

So basically - if you want call backs you're going to have to do it the standard RMI way.

Ollie

[Jeff Moszuti]

Yes, you can get client B to notify client A when client B registers using Spring. RmiServiceExport only starts up a RMI server if it is unable to find one.

So in client A you will have to get Spring to bind your callback object to the registry like you did with your Service, then lookup the callback object so that you can pass it as a parameter to your method 'registerTheCallBack'.

When you lookup the callback object, Spring will return the 'remote stub' to you (which you then pass to the service). The service can then invoke a method on the callback 'remote stub' that is executed on client A.

There is one caveat, for this to work, the 'remote stub' (RmiProxyFactoryBean) needs to be serializable. I'll raise a bug in Jira for the Spring team to look at.

[ge0ffrey]

There might be a second caveat:
Client A must be able to open a dummy RMI server on a port,
because RmiServiceExport can not be told not to start an RMI server (and just only make a proxy).

Why a dummy?
Because client A will give the server it's remote stub and the server will talk back through the same connection.

Why do I like this behaviour?
Because client A and B are behind firewalls and any RMI server they manage to put up are unreachable.

Why is it a problem that RmiServiceExport starts of an RMI server (if none is online)?
Because the user might not have the right to start up anything on a port

[chelu]

I attach a working example to the old Jira issue https://jira.springsource.org/browse/SPR-982

The code that I'm using is on
http://sourceforge.net/p/jdal/code/c.../remoting/rmi/

Export the client callback with provided RmiServiceExporter and pass the object returned by RmiServiceExporter.getRemoteService() to the remote server.

If you don't want that client bind to the registy, set the DummyRegistry as registry on RmiServiceExporter.

Cheers