Structural Patterns - Applied Java Patterns - page 119

Half-Object Plus Protocol (HOPP)
Pattern Properties
Type: Structural
Level: Component
Purpose
To provide a single entity that lives in two or more address spaces.
Introduction
A distributed Java application spreads objects over different address spaces—multiple Java Virtual Machines. For
some technologies like RMI, remote objects can invoke methods on objects that actually reside on another JVM,
allowing you to distribute state and behavior. Regardless of the technology used, objects in different JVMs need
to communicate with each other in order for a distributed application to function. If they can't, what we have is a
failure to communicate.
Suppose you have machine A and machine B, each with a JVM running. An object in JVM A needs object B's
stub (see “ Proxy ” on page 197) to call methods on an object in JVM B. It can get it through several means. Once
A has the stub, A can call methods on the stub and those method calls will be forwarded to B.
The downside is that all method calls on the stub will be forwarded across the network, which isn't always
desirable. Sometimes you want the stub to execute some of the invoked methods locally, without going to the
remote object.
This is an example of an object that exists in two or more address spaces. The proxy (the local representation of a
remote object) is considered to be part of the remote object. By executing methods locally and in the remote JVM,
an object executes behavior in multiple address spaces. This is what the HOPP pattern accomplishes for you.
Applicability
Use the HOPP pattern when:
An object has to be in two different address spaces and cannot be split.
Part of the functionality should execute remotely but some methods need to be invoked locally.
Optimizations, such as caching, or the combining of multiple requests into a single network transaction, need to
be applied in a way that is transparent to the caller.
Description
Distributed applications are hard to write. One of the problems encountered is that a single entity (object) needs to
be in several address spaces. This might be because the object needs to access multiple physical devices on
different machines or simply because the object cannot be split in a logical way.
To split an object in half and have the two halves communicate remotely can be accomplished by executing rmic
with the -keep or -keepgenerated option. This saves the source code of the stub. Next, edit the source so that
certain methods are handled by the stub and not forwarded to the remote object. When you compile the changed
source you have your own customized version of the stub.
Unfortunately, this limits your further use of rmic because each time you use rmic on the remote object, you will
have to do the manual editing again. And again. And again.
The solution is to split the object in half and provide communication between the two halves. Implement each
half so that it can interact with the objects in its address space. The protocol is responsible for synchronizing the
two halves and sending information back and forth.