51.

  

Marshalling Factories

There may be many factories for a service, and each of them will generate a different user interface. These factories and their user interfaces will be different for each service. The standard factory interfaces will probably be known to both clients and services, but the actual implementations of these will only be known to services (or maybe to third-party vendors who add a user interface to a service).

If a client receives a ServiceItem containing entries with many factory implementation objects, it will need to download the class files for all of these as it instantiates the Entry objects. There is a strong chance that each factory will be bundled into a jar file that also contains the user interface objects themselves , so if the entries directly contain the factories, then the client will need to download a set of class files before it even goes about the business of deciding which of the possible user interfaces it wants to select.

This downloading may take time on a slow connection, such as a wireless or home network link. It may also cost memory, which may be scarce in small devices such as PDAs. Therefore, it is advantageous to hide the actual factory classes until the client has decided that it does in fact want a particular class. Then, of course, it will have to download all of the class files needed by that factory.

In order to hide the factories, they are wrapped in a MarshalledObject . This keeps a representation of the factory and also a reference to its codebase , so that when it is unwrapped, the necessary classes can be located and downloaded. Clients should have the class files for MarshalledObject , because this class is part of the Java core . By putting a factory object into entries in this form, no attempt is made to download the actual classes required by the factory until it is unmarshalled.

The decision as to whether or not to unmarshall a class can be made on a separate piece of information, such as a set of Strings that hold the names of the factory class (and all of its superclasses and interfaces). This level of indirection is a bit of a nuisance, but not too bad:

 if (typeNames.contains("net.jini.lookup.ui.factory.JFrameFactory") {     factory = (JFrameFactory) marshalledObject.get();     .... } 

A client that does not want to use a JFrameFactory will just not perform the preceding Boolean test. It will not call the unmarshalling get() method and will not attempt the coercion to JFrameFactory . This will avoid downloading classes that are not wanted. This indirection does place a responsibility on service-side programmers to ensure that the coercion will be correct. In effect, this is a maneuver to circumvent the type-safe model of Java purely for optimization purposes.

There is one final wrinkle when loading the class files for a factory: a running JVM may have many class loaders. When loading the files for a factory, you want to make sure that the class loader is one that will actually download the class files across the network as required. The class loader associated with the service itself will be the most appropriate loader for this.