52.

  

MIMEType

The MIMEType class is known to the client and to any file-classifier service. The MIMEType class file can be expected to be known to the JVMs of all clients and services. That is, this class file needs to be in the CLASSPATH of every file-classifier service and of every client that wants to use a file-classifier service.

The getMIMEType() method will return an object from the file-classifier service. There are implementation possibilities that can affect this object:

• If the service runs in the client's JVM, then nothing special needs to be done.
• If the service is implemented remotely and runs in a separate JVM, then the MIMEType object must be serialized for transport to the client's JVM. For this to be possible, it must implement the Serializable interface. Note that while the class files are accessible to both client and service, the instance data of the MIMEType object needs to be serializable to move the object from one machine to the other.

There can be differences in the object depending on the implementation. If it implements Serializable , it can be used in both the remote and local cases, but if it doesn't, it can only be used in the local case.

Making decisions about interfaces based on future implementation concerns is traditionally rated as poor design. In particular, the philosophy behind remote procedure calls is that they should hide the network as much as possible and make the calls behave as though they were local calls. With this philosophy, there is no need to make a distinction between local and remote calls at design time. However, a document from Sun, "A Note on Distributed Computing" by Jim Waldo and others, argues that this is wrong, particularly in the case of distributed objects. The basis of their argument is that the network brings in a host of other factors, in particular that of partial failure. That is, part of the network, itself, may fail, or a component on the network may fail without all of the network or all of the components failing. If other components do not make allowance for this possible (or maybe even likely) behavior, then the system as a whole will not be robust and could be brought down by the failure of a single component.

According to this document, it is important to determine whether the objects could be running remotely and to adjust interfaces and classes accordingly at the design stage. This lets you to take into account possible extra failure modes of methods , and in this case, an extra requirement on the object. This important paper is reprinted in the Jini specification book from Sun ( The Jini Specification by Ken Arnold and others) and is also at http://www.sun.com/research/techrep/1994/abstract_29.html .

These considerations lead to an interface that adds the Serializable interface to the original version of the MIMEType class, as objects of this class could be sent across the network.

 package common; import java.io.Serializable; /**  * MIMEType.java  */ public class MIMEType implements Serializable {     /**      * A MIME type is made up of 2 parts      * contentType/subtype      */        protected String contentType;     protected String subtype;     public MIMEType(String type) {         int slash = type.indexOf('/');         contentType = type.substring(0, slash1);         subtype = type.substring(slash+1, type.length());     }     public MIMEType(String contentType, String subtype) {         this.contentType = contentType;         this.subtype = subtype;     }     public String toString() {         return contentType + "/" + subtype;     } } // MIMEType 

FileClassifier Interface

Changes have to be made to the file-classifier interface, as well. First, interfaces cannot have static methods, so we will have to turn the getMIMEType() method into a public instance method.

In addition, all methods are defined to throw a java.rmi.RemoteException . This type of exception is used throughout Java (not just by the RMI component) to mean "a network error has occurred." This could be a lost connection, a missing server, a class not downloadable, etc. There is a little subtlety here, related to the java.rmi.Remote class: the methods of Remote must all throw a RemoteException , but a class is not required to be Remote if its methods throw RemoteExceptions . If all the methods of a class throw RemoteException , it does not mean the class implements or extends Remote . It only means that an implementation may be implemented as a remote (distributed) object, and that an implementation might also use the RMI Remote interface.

There are some very fine points to this, which you can skip if you want. Basically, though, you can't go wrong if every method of a Jini interface throws RemoteException and the interface does not extend Remote . In fact, prior to JDK 1.2.2, making the interface extend Remote would force each implementation of the interface to actually be a remote object. At JDK 1.2.2, however, the semantics of Remote were changed a little, and this requirement was relaxed . From JDK 1.2.2 onwards, an interface can extend Remote without implementation consequences. At least, that is almost the case: "unusual" ways of implementing RMI, such as over IIOP (IIOP is the transport protocol for CORBA, and RMI can use this), have not yet caught up to this. So for maximum flexibility, just throw RemoteException from each method and don't extend Remote .

Doing so gives the following interface:

 package common; /**  * FileClassifier.java  */ public interface FileClassifier {     public MIMEType getMIMEType(String fileName)         throws java.rmi.RemoteException; } // FileClasssifier 

Why does this interface throw a java.rmi.RemoteException in the getMIMEType() method? Well, an interface is supposed to be above all possible implementations and should never change. The implementation discussed later in this chapter does not throw such an exception. However, other implementations in other sections use a Remote implementation, and this will require that the method throws a java.rmi.RemoteException . Since it is not possible to just add a new exception in a subclass or interface implementation, the possibility must be added in the interface specification.