File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes EJB and other Java EE Technologies and the fly likes JMS or RMI to notify client of data change Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "JMS or RMI to notify client of data change" Watch "JMS or RMI to notify client of data change" New topic

JMS or RMI to notify client of data change

Perry Board

Joined: May 03, 2003
Posts: 29
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.)
C. Nimo
Ranch Hand

Joined: Mar 23, 2004
Posts: 82

when you're using JMS, you have to make sure that all your clients have a JMS client installed as well, so they communicate with your JMS server. I don't find it that difficult, but sometimes you just can't have that on remote machines.
still, using JMS, i think your implementation will be a lot easier. I mean - your clients query the server for information. so, let's say you have a method called queryMyServer() on each of the clients.
using JMS, your EJBs just don't care about the clients - what you do is use a topic, that all clients listen to. then, when you update your data, just put a message on this topic, telling all clients you got some new info for them.
the clients will have a listener on this topic, and in its onMessage() method - just call queryMyServer() and you're good as gold, since the clients will query the server when they can, and you still have the control (inside your server) of load and distribution of data. additionally, a client may decide it doesn't need your data, so that's good as well - less hussle and expensive RMI on your side.
you might also want to just send the changed data on your JMS message straight away to the client, and let the JMS provider worry about it gettting safely to the destination.
Perry Board

Joined: May 03, 2003
Posts: 29
Thanks for the reply. I'll read up a bit more on JMS.
I agree. Here's the link:
subject: JMS or RMI to notify client of data change
It's not a secret anymore!