Previous | Next | Trail Map | Java Objects and the Directory | Object Factories

Role of Service Providers

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 Directory

A 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).

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

Reading an Object from the Directory

When 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 the service provider should invoke the method NamingManager.getObjectInstance() (in the API reference documentation) using information it read from the directory. NamingManager.getObjectInstance() interacts with the object factories in an attempt to produce a Java object representing the information in the directory.

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 (in the API reference documentation) 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 (in the Java Objects and the Directory trail)the object factory FruitFactory was selected to create an instance of Fruit. FruitFactory was identified in the reference. In the attributes example (in the Java Objects and the Directory trail), 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 (in the Java Objects and the Directory trail), 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 (in the Java Objects and the Directory trail), 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.


As 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 (in the Building a Service Provider trail) trail.

Previous | Next | Trail Map | Java Objects and the Directory | Object Factories