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

Interaction Between State Factories and Service Providers

A service providers acts 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 the rules outlined in this section for storing objects in 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 also interest API users.

Relevant Methods

When accepting objects to be bound into the underlying naming/directory service, the service provider should use the guidelines described in this section. An object can be bound by using one of the following methods:

Minimal Set of Acceptable Types

A service provider should try to support binding and rebinding objects that are or do 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 perform the Serializable check first, then no Reference objects will ever be stored in the reference format (they would all be serialized).

Framework Support

A service provider should use state factories configured with the provider and application. This allows the service provider to be customized to support arbitrary types of objects (for which a corresponding state factory is available).

The JNDI framework provides utility methods that service providers can use to access state factories. A service provider that implements only the Context (in the API reference documentation) interface should use NamingManager.getStateToBind() (in the API reference documentation). A service provider that implements the DirContext (in the API reference documentation) interface should use DirectoryManager.getStateToBind() (in the API reference documentation).

These methods traverse the list of state factories specified in the Context.STATE_FACTORIES(in the API reference documentation) environment property and the provider resource file and try to find a factory that yields a non-null answer. (See the Beyond the Basics (in the Beyond the Basics trail) trail for details about environment properties and the provider resource file.)

Here's an example of how a DirContext implementation might use state factories.

// First, use state factories to do a transformation
DirStateFactory.Result res = DirectoryManager.getStateToBind(
    obj, name, ctx, env, inAttrs);
obj = res.getObject();
Attributes outAttrs = res.getAttributes();

// Check for Referenceable
if (obj instanceof Referenceable) {
    obj = ((Referenceable)obj).getReference();
}

// Store different formats
if (obj instanceof Reference) {
    // Store as ref and add outAttrs
} else if (obj instanceof Serializable) {
    // Serialize and add outAttrs
} else if (obj instanceof DirContext) {
    // Grab attributes and merge with outAttrs
} else {
    ...
}
When the provider gets an object (obj) and attributes (inAttrs) from the client to bind into the directory, it invokes getStateToBind() to get a possibly updated pair of object/attributes. If no state factories return a non-null answer, then getStateToBind() returns the original pair of object and attributes. In either case, the provider stores the results in the underlying directory in a format acceptable to the directory.


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