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);