Optional Components

After building a basic service provider, you might want to add a couple of useful features, one to support URL string names and the other to access the context through other means than the initial context.
Supporting URL String Names
A useful feature to support is to allow applications to supply URL strings as name arguments to methods invoked on the InitialContext (and its subclasses). This feature is described in the URLs lesson. To support this feature, your service provider must have a URL context factory. This is a class that implements the ObjectFactory interface. Its job is to return a URL context implementation that accepts URL strings of a particular scheme. For example, an LDAP URL context implementation accepts URL strings of the ldap URL scheme. The URL context implementation typically works closely with the main context implementation (the one that accepts non-URL strings).
The Adding URL Support lesson describes how to add support for URLs.
Putting a Handle on Things
Although you might not want to support full federation, a handle (that is, a reference) that can be bound in other naming systems can be useful for a context implementation. This allows the context to be federated at least as a terminal (i.e., leaf) naming system, as well as allows access to the context implementation through means other than the InitialContext. To support this feature, you need to decide on the format and content of the context's reference and define a corresponding object factory that accepts that reference. This object factory implements the ObjectFactory interface.
The Adding Federation Support lesson describes how to add support for this feature.
Putting It All Together
The following picture shows the interactions between the components of a basic service provider and those necessary for URL support and object factory support.

The Big Picture