I know that the following "pull" scenario works, it is a form of polling, and fits into the standard request/response communication of a servlet web application:
1. JavaApplet or Application on the client responds to the user clicking on a JButton. 2. The Applet/Application communicates over the intranet to a specific servlet, MyServlet, sending it the appropriate parameters. 3. MyServlet carries out processes, such as reading or polling the database, for any change of state. 4. MyServlet sends back a binary response to the client Applet/Application.
However, if I have many clients, it may be undersirable for them each to continually poll the server's database to determine if there has been a change of state by using MyServlet.
Can server-side Java objects or Java-related technologies be used to push information to the client's Java application? For instance, some other use-case changes the state of the database, and now the server wants to notify the client Java applications of the change in state.
Solution 1 --------- One way for this to be done is for each client Java application to set up a small, RMI server on the client so that client objects can be remotely called.
Are there any other technologies besides RMI that might be used? Feel free to use buzz words (I would then have to take the buzz word and research what it means, for as of now I am not familiar with web services, for example).
It would not have to be an RMI server, but the client does have to be listening somehow. That means a socket - see java.net.ServerSocket - with a Thread devoted to listening for a connection and handling the data. A more flexible system would be to use a JMS (Java Message Service) server to make these change of state messages available to any client that registers interest in them. This "publish-subscribe" approach can handle clients adding themselves and removing themselves without your database server having to do anything. Bill
Tick check! Okay, I guess that was just an itch. Oh wait! Just a tiny ad: