Java Reference
In-Depth Information
clients. A server usually sends information about all its changes to clients, and the client has to be able to be
contacted by the server, which might not be an easy task because of the client application or a firewall.
Pattern Variants
The most common variation in implementing a Successive Update strategy involves choosing an update approach
that is a combination of both client pull and server push. Depending on an application's requirements, an
application can rely on client pull for routine events, but use server push for time-critical notifications.
Applications that mix the two update strategies typically define time-critical notifications:
Notifications that could potentially cause an application error, such as deleting a customer record.
Normal events, such as those that cannot result in an error or loss of data, like creating a new customer.
For server push, the server module can transmit its notifications to explicitly defined clients, provided that the list
of clients is relatively short and the information is not large. As the number of supported clients grows, the server
can quickly become overwhelmed with such an approach, although not as quickly as when being polled by all the
clients. For notification of many clients, broadcasting information is often preferable. In this case, the server
sends its message to one or more servers, which retransmit to clients that have registered themselves as interested
participants. This approach is used in the Web and multicasting technologies, and reduces the load on the
originating server.
Related Patterns
Related patterns include the following:
Observer (page 94) - Clients often use the Observer pattern to register with the server for a server push solution.
Callback (page 238) - Successive update might use the Callback pattern for server push.
Mediator (page 77) - In server push solutions, the server often acts as a Mediator, sending updates to interested
clients as the updates are received.
Example
Note:
For a full working example of this code example, with additional supporting classes and/or a
RunPattern
class,
The example code shows a simple client pull solution for the Personal Information Manager. Clients use the
server to centralize information about tasks they are working on. Each client stays up-to-date by periodically
requesting updates from the server.
In the sample code, the
PullClient
class retrieves a task for a client. Its responsibility is to locate the RMI server
so that it can request tasks on a regular basis.
Example 4.20
PullClient.java
1. import java.net.MalformedURLException;
2. import java.rmi.Naming;
3. import java.rmi.NotBoundException;
4. import java.rmi.RemoteException;
5. import java.util.Date;
6. public class PullClient{
7. private static final String UPDATE_SERVER_SERVICE_NAME = "updateServer";
8. private static final String UPDATE_SERVER_MACHINE_NAME = "localhost";
9. private ClientPullServer updateServer;
10. private ClientPullRequester requester;
11. private Task updatedTask;
12. private String clientName;
13.
14. public PullClient(String newClientName){
15. clientName = newClientName;
16. try{
