Previous | Next | Trail Map | Building a Service Provider | Adding Federation Support

Creating a Federation

You create a federation in either of two ways:

In the former way, you explicitly bind the reference of one naming system into a context in another naming system. For example, you might record reference information about the local departmental LDAP naming system into a DNS system such that applications can subsequently resolve a composite name that contains the DNS name and the LDAP name. In the latter way, you have the federation be created dynamically as the resolution of a composite name proceeds. For example, a file system contains different types of files. Some of those files might be ZIP formatted. You can create a federation by using a composite name that contains the filename and its entry within the ZIP file. In this way, the federation is created dynamically with no external assistance and can be as varied as the types of files and their corresponding service providers.

An explicit binding consists of a name and a reference. Depending on the naming system in which the reference is bound, the actual reference might take different forms. For example, a departmental LDAP naming system might be bound into the DNS via a DNS SRV record that contains the LDAP servers' IP addresses and DNs. Or, the JNDI reference of an application naming system might be bound in an LDAP naming system. Also, a naming system might be represented differently in different superior naming systems. For example, the same naming system might be bound by using different data in the DNS and in the LDAP. Regardless of its storage format, a reference is eventually represented programmatically by a Reference(in the API reference documentation). The Java Objects and the Directory (in the Java Objects and the Directory trail) lesson describes how a Reference can be transformed to and from its actual representation.

From a service provider developer's perspective, it is a good idea to define a reference for the context implementation. This encourages users of the provider to use a consistent reference when referring to contexts in the implementation and when binding contexts from the implementation into foreign naming systems.

Reference

A context's reference should contain the data required to create a Context instance. If the context represents state on a naming or directory server, then its reference should at a minimum contain information on how to contact the server and how to identify its state within the server. Sometimes this task is complicated by the fact that access to the server might be controlled and require authentication. You are advised not to place security-sensitive information such as passwords in a reference. Rather, the reference should be generic and the context's authentication information ignored.

If the service provider already has a URL context implementation and a factory for the context implementation, then you can leverage that when designing the context's reference. For example, you can simply make the reference contain the URL(s) of the context. This not only makes access to the context more consistent, but also significantly simplifies the implementation of the corresponding object factory.

Object Factory

Once you have defined the format of the reference for your context implementation, you can write an object factory for it. Thus applications will be able to access your context implementation via references instead of names.

Following is an example of an object factory written to use the URL context factory of the same context implementation. For example, suppose that your context implementation supports the foo URL scheme and has the URL context factory tut.foo.fooURLContextFactory. The corresponding object factory FooCtxFactory might look as follows.

public class FooCtxFactory implements ObjectFactory {
    public FooCtxFactory() {
    }

    public Object getObjectInstance(Object ref, Name name, Context nameCtx,
	Hashtable env) throws Exception {

	if ((ref instanceof Reference) &&
	    myClassName.equals(((Reference)ref).getFactoryClassName())) {
	    
	    // Create a URL context factory
	    ObjectFactory factory = new tut.foo.fooURLContextFactory();

	    // Extract the URL(s) from the Reference
	    String[] urls = getURLs((Reference)ref);

	    // Ask the URL context factory to process the URL(s)
	    return factory.getObjectInstance(urls, name, nameCtx, env);
	}

	// This is not meant for this factory
	return null;
    }
}
getURLs() is a utility that extracts the URL strings from the reference's addresses.

Referenceable

A symmetric relationship is not needed for binding the context. Simply because you can look up a context from a foreign naming system does not necessarily mean that you can programmatically bind (the reference of) the same context into that foreign naming system. The binding could have been added administratively through tools specific for that foreign naming server.

Nevertheless, you can plan for programmatic binding support by making your context implementation referenceable. To do this, make the implementation implement the Referenceable(in the API reference documentation) interface. Also, provide an implementation for getReference()(in the API reference documentation). This method should return a reference that can be fed back into the provider's object factory.

Adding Federation Support: End of Lesson

What's next? Now you can:


Previous | Next | Trail Map | Building a Service Provider | Adding Federation Support