RMI client side callbacks

Question

Hi all,
I have an RMI server and a number of clients that run on different machines. What I need to do is, implement the "observer" pattern. i.e.
in my case, not only the clients call the server, but also the server
must notify the registered clients when its state changes.
For that purpose, I suppose, that my clients must also be RMI servers.
My first question is, is that true what I suppose? Is there any other
way to implement asynchron client side callbacks with RMI?
My second question is, if it must be done so (clients are also RMI servers), how can I implement this? Server needs client interface jar
file, ans client needs server interface jar file at compile time.
(Important: I do not use any HTTP server from which I can load _Stub
classes at runtime)
I don't like this architecture at all and therefore think that there
may be better solutions. One solution may be to poll the state of the
server from the clients periodically, so that there is no need for
callbacks. But that is also not the perfect solution for me.
Can someone suggest anything else?
Any idea will be greatly appreciated!
Thank you

Answer 1

Hello guvener
Some time ago, I did exactly what you are thinking about. Here was the strategy.
1. There was a server program, sitting (obviously) on the server machine, where rmiserver was running. The server class had only a single public method for the calling routines to call.
2. That public method took, as a parameter, a transaction request. One possible transaction was, "Here is a message for another client." Another possible transaction was, "Listen out for a message for me." For example, a client would call the server with the "listen" transaction or with a "here's a message" transaction.
3. When the calling method requested a "listen" transaction, the server would enter a "wait" state until it received a message for that particular client.
4. To prevent blocking, there were three specific strategies:
(a) The client would call the server with a "listen" transaction in a separate thread.
(b) There was a "cancel" transaction that would allow a client to cancel its "listen" transaction with the server.
(c) There was a "close-down" transaction that would allow the server to tell the clients their "listen" transactions had been cancelled, as it was closing down.
This requires thorough and careful planning. However, once the classes are correctly planned, this strategy is elegant and simple and leads to only a small amount of coding. It's also flexible, without any restrictions on how many transactions a client could request at a time.
Do be careful to synchronize where applicable!
I hope this helps.