| The Big Picture

## 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