Structural Patterns - Applied Java Patterns - page 121

Pattern Variants
Pattern variants include the following:
Both halves keep a reference to each other and send messages back and forth. In the classic form only the HOPP
on the client side has a reference to the other half. This carries the consequence that communication can only be
initiated by the client side HOPP by calling a method on the remote half. The remote half is able to respond only
once to each call through the value it returns. When it's necessary that both halves can initiate communication,
they both need a reference to the other half.
Smart HOPP (SHOPP). In this implementation, the local part of the HOPP can choose its counterpart from several connection strategies.
This is helpful when, for instance, the application is distributed across a flexible network where machines come and go.
Asymmetric HOPP. In this version of the HOPP, pattern both halves don't need to implement exactly the same interface. The remote
part of the HOPP may provide a new proxy for the other half to use. That new proxy can contain new optimizations, or may even be a
proxy to a different remote object.
Related Patterns
Related patterns include the following:
Mediator (page 77) - The objects that need to be mediated are distributed on multiple address spaces. The
Mediator can use the HOPP to simplify communication.
Proxy, specifically Remote Proxy (page 197) - The HOPP pattern uses the Proxy pattern for transparent
communication between the two halves.
Example
Note:
For a full working example of this code example, with additional supporting classes and/or a RunPattern class,
see “ Half-Object Plus Protocol (HOPP) ” on page 483 of the “ Full Code Examples ” appendix.
A Personal Information Manager should be available everywhere, but its data should only be stored in one place.
This example uses RMI and the HOPP pattern to hold a personal calendar on a server, while making its
information available to remote callers.
The Calendar interface defines all methods that will be available remotely. This interface extends
java.rmi.Remote and all its methods throw java.rmi.RemoteException . In this case, Calendar defines three
methods: getHost , getAppointments , and addAppointment .
Example 3.29 Calendar.java
1. import java.rmi.Remote;
2. import java.rmi.RemoteException;
3. import java.util.Date;
4. import java.util.ArrayList;
5. public interface Calendar extends Remote{
6. public String getHost() throws RemoteException;
7. public ArrayList getAppointments(Date date) throws RemoteException;
8. public void addAppointment(Appointment appointment, Date date) throws RemoteException;
9. }
Calendar is implemented by two classes—the RMI remote object and its stub, or proxy. (See “ Proxy ” on page
197.) The remote object class, CalendarImpl , provides method implementations, while the stub manages
communication to the remote object. The Java RMI compiler ( rmic ) needs to be run on the CalendarImpl to
generate a stub and a skeleton class. The skeleton class is provided for backward compatibility, but, as of Java 1.2,
is no longer necessary.
Example 3.30 CalendarImpl.java
1. import java.rmi.Naming;
2. import java.rmi.server.UnicastRemoteObject;
3. import java.io.File;
4. import java.util.Date;