I have several clients all referencing the same remote object through RMI, and I was wondering if it is possible to send an event to the stub object in all of the clients when one of them runs a remote method on it.
For example, if the remote object "obj" has an "updateValue()" method and client A is running it through the stub object, can the server with the real "obj" send an event telling clients A, B, C etc... that the object was updated?
What you describe is a "push" mechanism, which is not part of RMI. What you can do easily is some sort of "pull" mechanism, where object A,B,C etc polls the server for any new event. But that also is not de-facto part of RMI. You would have to implement an additional method named getNewEvent() that calls the server every X seconds to know if a new event has occured.
You might want to look into an event channel/java messaging service (JMS)--I think that's pretty much what you are talking about. It's a core feature of J2EE but a JMS solution can be used in your system without the rest of J2EE.
JMX has an event API which works remotely -- haven't use it first hand.
If you want to get very fancy, you could startup RMI servers on all client machines and have them pass stubs to the "main" server holding the object in question. That main server can invoke the stubs using a standard listener/model pattern.
Were it me, I'd JMS with a dynamic topic.
RMI is a client-server technology, and a RMI channel can be used to communicate with the remote object(s) on the server, but the server can not call the client back.
Nothing stops you however to have two RMI channels so that both side act as client and server, if you see what I mean.
We did that to send notification to desktop application connected to a central server and it worked fine. The desktop application exports (in RMI parlance) a callback stub, connects to the central server, and register the callback stub on the server. The server can then send notifications to all connected desktop application. Of course, you need to set up the network infrastructure (firewall, etc.) so that bi-directional connections are possible. So yes, I would say it's possible, but requires a bit more effort than a single, uni-directional channel.
I had only a very quick look at this article, but it seems to illustrate the idea (if it's not the case, let me know, I'm sure I can find code snippet for this use case).
Other alternatives include polling or JMS, as mentionned in the other answer.