Advertisement

Logging Service Interface

With this design in mind, we must first develop the interface for the remote logging service. This is actually quite simple—we just need a logOperation() method that takes a SpaceOperation parameter in the same way we did in Part I in the LocalLoggingProxy. However, in this instance, we define the method in a Remote interface so that later on, when we write the new proxy, it will delegate calls to the remote logging service.

import java.rmi.Remote;

public interface SpaceLogger extends Remote {

    public void logOperation(SpaceOperation op)
        throws RemoteException;
} 

Logging Strategies

Earlier we mentioned that we could use various strategies to store the SpaceOperation data, and for this example we would use a simple CSV file implementation. However, as other strategies exist, it makes sense to define an extra local interface LoggingStrategy to make changing strategies easier in the future.

In our design, we will use delegation to forward the logOperation() request from the SpaceLogger implementation to the appropriate LoggingStrategy. Not only does this simplify writing the SpaceLogger implementation, but it also lets us dynamically load the desired strategy when we start an instance of the logging service.

Here is our interface for LoggingStrategy, which is non-remote, but also defines a logOperation() method:

interface LoggingStrategy {
    public void logOperation(SpaceOperation op);
} 

Figure 2's UML diagram shows the relationship between the SpaceLogger and the LoggingStrategy interfaces. The diagram also shows how the SpaceLoggerImpl class (which we will develop next) delegates to one LoggingStrategy implementation.

Figure 2. The SpaceLogger uses a LoggingStrategy.

With the logging service's class model under our belts, we can finally start to get our hands dirty and write some real code!