If we wish to make a version of FileClassifier available across the network, there are a number of possibilities. The client will be asking for an instance of a class, and generally will not care too much about the details of this instance. It will want an object that belongs to the FileClassifier class or one of its subclasses and will not usually care which of these it gets, as long as it contains the method getMIMEType() .
Services will have particular implementations and will upload these to the service locators. The uploaded service will be of a specific class and may have associated entries.
There are several options that the client could use in trying to locate a suitable service:
- This is the silly option: push the entire implementation up to the lookup service and make the client ask for it by its class. Then the client might just as well create the classifier as a local object, because it has all the information needed! This doesn't lend itself to flexibility with new unknown services coming along, because the client already has to know the details. So this option is not feasible .
- Let the client ask for a superclass of the service. This is better, as it allows new implementations of a service to just be implemented as new subclasses. It is not ideal, as classes have implementation code, and if this changes over time, there is a maintenance issue with the possibility of version "skew." This can be used for Jini; it just isn't the best way.
- Separate the interface completely from the implementation. Make the interface available to the client, and upload the implementation to the lookup service. Then, when the client asks for an instance object that implements the interface, it will get an object for this interface, which implements the interface in some way or other. The client generally will not care how the object does this. This will reduce maintenance: if the client is coded just in terms of the interface, then it will not need recompilation even if the implementation changes. Note that these words will translate straight into Java terms; the client knows about a Java interface , whereas the service provider deals in terms of a Java class that implements the interface .
The ideal mechanism in the Jini world is to specify services by interfaces and have all clients know this interface. Then each service can be an implementation of this interface. This is simple in Java terms, simple in specification terms, and simple for maintenance. This is not the complete set of choices for the service, but it is enough to allow a service to be specified and to get on with building the client.
One possibility for service implementation is looked at later in this chapter, and the next chapter is devoted to the full range of possibilities.