This is the approach of the HOPP pattern—create an object that implements the required remote interfaces and which contains a reference to the original stub of the remote object. The methods that should behave normally (send to the remote object) are forwarded to the stub. Methods that should execute locally are handled by the new class.

The name HOPP comes from the fact that the client to the split object receives one half of the object. That one half also contains the protocol how to communicate with the other half, hence Half-Object Plus Protocol.

Implementation

The HOPP class diagram is shown in Figure 3.9.

Figure 3.9. HOPP class diagram

To implement the HOPP pattern, you need:

HOPP – This interface defines the methods that are available to the client of the HOPP. Both halves of the HOPP object implement this interface.

LocalHOPP – This class implements the HOPP interface. Some of the methods are executed locally; others are

forwarded to the RemoteObjectProxy.

RemoteObjectProxy – This class is a Remote Proxy and forwards all the requests to the other half of the object in the other address space. This proxy encapsulates the protocol that links the two half objects.

RemoteObject – This half of the HOPP contains all the methods to execute remotely.

Client – Client calls methods on the HOPP interface. These method calls are transparent to the client, regardless of whether it is using a Remote Proxy (see “ Proxy ” on page 197), a HOPP, or a local object.

Benefits and Drawbacks

The benefit of this pattern is having one object that resides in two address spaces, without too much overhead. For the clients using one part of the HOPP, it is transparent. The clients do not care whether the object lives in one or more address spaces.

It is even possible to hide the difference completely, so that the client thinks it is using a local object while parts of it are not. You can implement the opposite so that a client thinks it is using a Remote Proxy, while in fact it is using a HOPP that contains a Remote Proxy. This has the benefit that some of the methods that were intended to be invoked remotely are now executed locally.

A very powerful advantage is that this pattern allows tailor-made optimizations. Each half of the HOPP can determine when and how it wishes to communicate with the other half. These communication strategies can improve performance by decreasing the number of calls across a network without the client code on either end being affected.

The drawback to this pattern is that some of the functionality needs to be duplicated. This is necessary because each half should have enough functionality to handle local objects.

130