3. Notification Solutions

The simplest solution is a "timed page refresh". Using HTML META tags in the header of the HTML document, the page is automatically reloaded every N seconds. If in the meantime something has changed on the server we get the new content, otherwise we get the same stuff. But how large should we make the refresh interval ?

Since we are seasoned Java developers building serious applications, we often use "server-side callbacks". Here a server objects calls back a Java applet client using RMI or CORBA.

In this solution an applet is a client from a messaging middleware server that pushes messages over a TCP/IP connection (java.net.Socket) or using connectionless UDP messages (java.net.DatagramSocket), the latter possibly even with multicast (java.net.MulticastSocket). You could use a messaging product such as iBus (SoftWired), MQSeries (IBM) or WebLogic Events (BEA) or develop your own custom messaging with java.io.ObjectStream's over sockets.

Each of the above solutions has its advantages/disadvantages in complexity, security, performance, scalability, browser Java compatibility and restrictions like firewalls. The most optimal solution strongly depends on what your application is supposed to do. For example, when users require a direct interaction with the state such as in a shared whiteboard, server side-callbacks or messaging can be a powerful technique.

But we are still within a browser and unless the applet constitutes the entire client application, it is hard to integrate updates coming from the server with the HTML content. How can we alter this content from within the applet when it gets the callback or message ? One solution is to refresh the page by calling AppletContext.showDocument(URL) within the callback method.

Since HTML is meant for layout, wouldn't it be nice to be able to directly alter parts of the HTML content with incremental data coming from the server ? This would be an ideal scheme for web-applications where content on the server is dynamically changing and the required user-to-server interaction is minimal, e.g. driven by HTML FORMs.

In addition to the above solutions I have developed a technique that is lightweight, thin on the client, requires no applets or plug-ins, directly integrates with scripting/HTML, uses standard HTTP connections and can be deployed (in theory!) in any Java servlet-server. It is certainly not meant to replace the above solutions. My intention is to add another option to your toolbox. You as Java architects/developers should determine the trade-offs and choose what is best for your particular application.