A Logging JavaSpace Proxy

One main benefit of a logging system is that it lets us see how
clients use the space without having to insert debug/logging
statements into the client code. To automate this process without
touching our client code, we will use a simple yet powerful idea.

We know that all space-based systems load a proxy at runtime to
support the remote calls on the JavaSpaces API. Using this knowledge,
we can easily build new proxies that hide the logging operations from
the client, but still look like the standard JavaSpace proxy.

So in our system, the Jini proxy for our logging system will
implement the JavaSpaces interface. However, instead of calling the
backend of the JavaSpace directly, the proxy will collect the
information we need and then forward the JavaSpaces API calls onto
another proxy that uses the backend JavaSpaces server.

To avoid confusion, throughout this article we will call the proxy
that produces logging information the logging proxy. The
standard proxy that calls into the space backend is called the
delegate proxy, and the combination of delegate proxy
and the backend space will naturally be called the delegate
space.

Figure 1 shows the general structure for building the logging
proxies and using the delegate space.

Figure 1. A Logging JavaSpace Proxy Architecture.

The interface to the logging proxy, LoggingSpace,
extends JavaSpace:

import net.jini.space.JavaSpace
public interface LoggingSpace extends JavaSpace {
// no additional methods to those in the JavaSpace interface
}

LoggingSpace has exactly the same methods as
the JavaSpace interface. By declaring a
LoggingSpace as a subinterface of
JavaSpace, it can be used wherever a
JavaSpace is called for. But because it is a
subinterface, we can use a type-based lookup in the Jini lookup service
to find a JavaSpace proxy that also does logging.

Now that we have established a general structure for the logging
proxy, let's consider how we will record and structure the logging
information.