With a
J2EE app server, would I be correct to use JMS if I want to notify a group of clients when data on the server has been changed?
For example, 10
Java application clients (or
applet clients) simultaneously connect to the app server using EJB and get a view of the current data. If the data is changed by another client, it would be nice to send a message directly to all the clients, notifying them of the change so they can get refreshed data. This keeps the client from needing to continuously contact the server over and over again to see if the data has changed.
So let's say a Session Bean performed the data-changing operation on the client's behalf. It would then create a new message and send it to the app server for a message topic. All the clients would be message consumers who listen to the app server to receive messages of this type. So there's no Message-Driven bean here, right? I'm just using the messaging services of the app server?
Isn't the client, as an asynchronous message consumer, still continuously (or periodically, depending on frequency) contacting the server to check for messages? Would having a high number of clients then have a heavy burden on the server? Would it be better for the client to somehow send a reference to itself via RMI so an EJB on the server can directly contact the clients who are "logged in?" How would you store this list of Remote objects?
Thanks for any tips.
(I deleted my message from the distributed java forum and posted here.)