How to architect push notifications to a Swing client from JAX-WS on GlassFish?

Question

I have a widely distributed java swing application that is a web service client from a JAX WebService EJB on a Glassfish 3.1.2 server.

I want to be able to distribute a String notification to all users that stays active until they have read it. The notifications only need to exist within the Swing client.

I have created a superuser web portal to enter the String data and save it to a database.

My question is:

1. What is the best technology to (push)distribute this data String Notification to my clients?
2. How should I arcitect the database to know if the notification has been viewed? (So I can stop showing the "New Notification" on the client)

Or if there is a reference to a guide that would work wonderfully, I couldn't find one.

My Ideas:

• Have the client call a webservice every 10 minutes to check if there are any new notifications
• For the database create a notification table and notifications seen. Link my users table to notifications seen table. Notifications seen is very basic with just 3 columns: NotificationID, UserID, TimeSeen.

Answer 1

One way of simulating push notifications is long polling. This technique is called Comet or Reverse AJAX. While it's more common in REST based services, it can be just as easily accomplished in JAX-WS.

For JAX-WS you will want to investigate:

• asynchronous web service invocation
• JAX-WS client APIs ... Using the JAX-WS asynchronous programming model

Have the client call a webservice every 10 minutes to check if there are any new notifications

Instead with long polling, you make the initial client connection right away. But instead of the server responding immediately, it hangs onto the connection (asynchronously). Then when a notification needs to be pushed, it responds back on the existing connection.

With this technique, as soon as information is available on the server, it will be "pushed" to the client.

For the database create a notification table and notifications seen. Link my users table to notifications seen table. Notifications seen is very basic with just 3 columns: NotificationID, UserID, TimeSeen.

Sounds good. Expose it as a JAX-WS service. When the client receives the message, have them invoke it with the NotificationID.

Something like:

NotificationService svc = ...;
UserId userId = ...;

AsyncHandler<Notification> handler = new AsyncHandler<Notification>()
{
    public void handleResponse (Response<Notification> response)
    {
       Notification notification = response.get();

       // update swing gui

       NotificationID notificationId = notifcation.getId();

       svc.markNotificationAsSeen(userId, notificationId);

       // continue polling forever (or put in some logic to stop)
       svc.getNotificationAsync(userId, this);
    }
};

Future<?> invocation = svc.getNotificationAsync(userId, handler);

Answer 2

If 10 minutes is often enough, and you know for sure your users can wait that much, stick with polling the server every 10 minutes.

If you need (almost) real time notifications, check out JMS (and especially topics). HornetQ is one of the implementations, and easy to use if you are using JBoss.

Answer 3

I would recommend going with a Message Queue server. Like someone suggested HornetQ or ActiveMQ which you can embed on your server if you wish.