Half Object Plus Protocol was published in volume 1 of Pattern Languages Of Program Design by Gerard Meszaros. Its synopsis is:
Divide an object which needs to be accessed from more than one address space into two interdependent half-objects (one in each address space) with a protocol between them. In each address space, implement whatever functionality is required to interact efficiently with the other objects in that address space. (This may result in duplicated functionality, i.e., implemented in both address spaces.) Define the protocol between the two half-objects so that it co-ordinates the activities of the two half-objects and carries the essential information that needs to be passed between the address spaces.
Patterns which solve the same problem include Remote Proxy (which delegates all requests back to a single site) and Caching Proxy (which caches the results of some requests to reduce delays and network traffic.) Remote Procedure Call solves the same problem in a different way; it exposes the fact that the target object is in a different address space to the client, which results in client software which "knows" about the distributed nature of the application.
The pattern includes figures that show flow of control traces that make the distinction between the various alternatives clear. The following link will retrieve the text of the pattern, but not the figures.
Figures
FIGURE 1 Where should the distribution boundary be?
For an instance of this pattern see IBM's Ultra Lightweight Client (www.software.ibm.com 
) -- Thomas Maeder
They've also (just now) done one of these for their Visual Age for Java environment. It's aimed at reducing the hideous bloat of Java applications and applets (particularly with full GUIs). See www.software.ibm.com . -- Richard Emerson
The problem with caching is how to invalidate the cache. Data ages; machines go down. The framework for ensuring cache consistency can be very complex.
I'm convinced that there's a pattern language here. Let's hack at it at Hopp Pattern Language.
See original on c2.com