You are right in you assumption.
For active push-style notification from server to clients, the clients have to be "servers" also.
So in the client app you also need to have a remote interface. The first time the client connects to the server you pass to it a reference to an instance of the remote interface.
This object needs to be exported as a remote RMI object, but it doesn't need to be registered in a registry, since you will directly pass a reference to it to the server who needs to call methods on it.
The server keeps a register of all the clients so it can call back when needed. Typically a Map with the key being a meaningful identifier of the clients and the value being the remote reference to the client.
When the client app is shut down, the client needs to unregister.
And the the server will probably want to have a periodic check of all the clients so it doesn't keep references to dead clients.
Your server interface would look something like that :
public interface Server extends Remote {
void register(Client client) throws RemoteException;
void unregister(Client client) throws RemoteException;
void doSomethingUseful(...) throws RemoteException;
...
}
And your client interface:
public interface ClientCallbackInterface extends Remote {
void ping() throws RemoteException;
void notifyChanges(...) throws RemoteException;
}
And somewhere in your client app startup code :
ClientCallbackInterface client = new ClientImpl();
UnicastRemoteObject.exportObject(client);
Registry registry = LocateRegistry.getRegistry(serverIp, serverRegistryPort);
Server server = (Server) registry.lookup(serviceName);
server.register(client);
It is totally possible to implement it. But not trivial. There are many things you have to take care of :
- You must take care of which can be a problem if there are firewalls involved.
- Could be problems with local OS firewall too, your client app actually must open local incoming ports
- If you try to start several clients on the same machine you will have port conflict, must take care of that too
- Totally not going to work outside of LAN
I did implement a system like this and it works fine. But all that said if I had to do it again I would definitely use something else, probably REST services and WebSockets for the callbacks. It would be much less constraints on the network part, just HTTP needed.
