| The Ground Rules

## Names

> Names are discussed extensively in the What's in a Name? lesson. This section discusses in general how a service provider developer should treat the string and structured name parameters to methods in the `Context` interface and subinterfaces.

> #### String Names

> A string name is a composite name. Even if the context implementation that you are writing won't be supporting federation, following this rule is still a good idea so that users of your provider won't have to treat your provider differently in this respect.

> Following this rule, you would write the overloads in the `Context` interface and subinterfaces that accept a `java.lang.String` name as simple wrappers around the overloads that accept a `Name`. As an example, here is a context implementation's definition of `Context.lookup()`.

> >     Object lookup(String name) throws NamingException {
> >         return lookup(new CompositeName(name));
> >     }

> #### Composite Names

> A structured name is represented by an object that implements the `Name` interface. It can represent either a composite name or a compound name. In either case, the name parameter belongs to the caller and you should not modify it (see the Parameters and Return Values section for details).

> A composite name is represented by an instance of `CompositeName`. If your context implementation does not support federation, then it can treat composite names in one of two ways. The simplest is for the context implementation to throw an `InvalidNameException` when it receives a `CompositeName`. However, this approach is Draconian in that it precludes the application from ever passing in a `CompositeName`, even if the `CompositeName` contains only the components that belong to the context implementation's namespace. A more compromising approach is for the context implementation to accept only `CompositeName`s that contain components that belong to its namespace. In this approach, the implementation extracts the components that belong to its namespace, and for components that do not belong, it throws an `InvalidNameException`.

> If your context implementation supports federation, it should extract the components from the `CompositeName` that belong to its namespace. For components that do not belong, it should resolve its own components and then pass the remaining components to the nns. (More detail about this are given in the Adding Federation Support lesson.) If the implementation receives only components for its namespace, then it should process the requested operation.

> Here is some pseudocode that illustrates the nonfederated case.

> >     Object lookup(Name name) throws NamingException {
> >         if (name instanceof CompositeName) {
> >             {mine, theirs} = splitName(name);
> >     	if (theirs.size() == 0) {
> >                  // Find in internal tables
> >                  return impl.get(mine);
> >             } else {
> >     	     // Don't support federation
> >      	     throw new InvalidNameException(name.toString() +
> >                     " has more components than I can handle");
> >             }
> >         } else {
> >             // Process the compound name
> >             ...
> >         }
> >     }

> #### Compound Names

> A compound name can be represented by any implementation of the `Name` interface except `CompositeName` or one of its subclasses. The easiest, though not the most efficient, way of making a context implementation accept a compound name is to turn it into a composite name.

> Here is an example for mapping a compound name to a single-component composite name.

> >     Object lookup(Name name) throws NamingException {
> >         if (name instanceof CompositeName) {
> >             // Process composite name
> >             ...
> >         } else {
> >             // Process compound name; turn it into single-component CompositeName
> >             return lookup(new CompositeName().add(name.toString()));
> >         }
> >     }

> This is the most general solution. A context implementation typically can do this much more efficiently by using either the preparsed form (`Name` instance) directly or the stringified compound name. For example, an implementation might use the stringified compound name as a key to an internal hash table.

| The Ground Rules