The service providers act as the go-between for the application and the directory when the application stores or retrieves Java objects from the directory. When you write a service provider, you need to perform this go-between role by following these rules for storing and reading objects from the directory.
The following detailed description is intended for developers writing service providers. The insight it offers into the go-between role of service providers might interest some API users.
Storing an Object into the DirectoryA service provider should try to support binding and rebinding objects that are one of the following:
It should check whether an object is in these four categories in the order listed because this order is most likely to capture the intent of the client. For example, a Reference is Serializable, so if you performed the Serializable check first, no Reference objects would ever be stored in the reference format (that is, they would all be serialized).
- Are instances of Reference
- Implement the Referenceable interface
- Implement the java.io.Serializable interface
- Implement the DirContext interface
In addition, to support Java Remote Method Invocation (RMI) programs, a service provider may also support the binding of java.rmi.Remote objects. If a service provider supports binding java.rmi.Remote objects, it should check for java.rmi.Remote before java.io.Serializable.
Reading an Object from the DirectoryWhen returning objects to the JNDI client application, the service provider needs to use object factories to ensure that what the client sees are Java objects rather than raw directory data. Specifically, when returning an object for one of the methods
Which object factories are invoked by the NamingManager depends on the object read from the directory. If the object is a reference, the object factory class name from the reference is used to load and instantiate the factory. If the object is a URL, then the corresponding URL context factory is tried. Otherwise, the list of object factories specified in the Context.OBJECT_FACTORIES environment property is used. This property should contain a list factory class names separated by colons (':') . This list of factories is tried in turn until one produces a non-null answer or throws an exception. If there is no success in finding a non-null answer, NamingManager.getObjectInstance() returns the object given to it by the provider.
In the reference example the object factory FruitFactory was selected to create an instance of Fruit. FruitFactory was identified in the reference. In the attributes example , the client programs (lookup, list, and search) have to set the Context.OBJECT_FACTORIES environment property to "DrinkFactory" so that NamingManager will load and instantiate DrinkFactory to create an instance of Drink. In the serialization example , no object factory was needed (nor found) so that the serialized object (an instance of java.awt.Button) is returned unchanged by the NamingManager. In the remote example , the "rmi" URL context factory turned the "rmi" URL stored in the directory into an RMI stub found in the RMI registry. The rest of this lesson describes the object factories FruitFactory and DrinkFactory.
FederationAs explained in the Other Uses section of this lesson, object factories also play a role in federation. How a service provider uses object factories to support federation is described in the Building a Service Provider trail.