The Current Naming System

Regardless of whether a service provider supports strong or weak separation, once it has determined the components of the composite name that it should process, it needs to process them. The way it processes the components depends on whether its participation in the resolution of this composite name is as an intermediate or terminal naming system.
Intermediate naming systems are those that are only involved in resolution of the composite name. They are responsible for passing the operation onto its target context. The terminal (or target) naming system is the one that contains the context in which the operation is carried out. In other words, the terminal naming system is that named by the tail component(s) of a composite name. In the following sample composite name:
cn=homedir,cn=Jon Ruiz,ou=People/tutorial/report.txt
The LDAP directory is an intermediate naming system and is responsible for resolving the name cn=homedir,cn=Jon Ruiz,ou=People. The Unix file system is the terminal or target naming system and is responsible for perform the requested context operation on the name tutorial/report.txt.
Processing for a terminal naming system is not very interesting: the provider merely carries out the requested context operation. For example, if the context method invoked was Context.list(), the service provider would invoke list() using its components from the composite name, as if it was not in a federation, and return the results of list() to the caller.
Processing for an intermediate naming system is much more interesting. The job of a provider for an intermediate naming system is to determine the reference to the next naming system, or nns, given its components from the composite name. This reference is called the next naming system pointer, or nns pointer. In the above example, the LDAP provider must determine the nns pointer for the LDAP name cn=homedir,cn=Jon Ruiz,ou=People.
Junctions
There are two ways by which a service provider can support retrieval of the nns pointer. One way is to use an explicitly named nns pointer, also called a junction. A junction is a name that is bound to a nns pointer. cn=homedir,cn=Jon Ruiz,ou=People in the above example is a junction. This name is bound to a reference to a file system context. If you perform a Context.lookup()on the name, instead of getting back an LDAP entry, you will get back a Context instance for a directory (/tmp) in the file system. There is no limit to the numbers of junctions you can have in a context. Moreover, depending on the naming policy of the underlying naming system, a junction is usually indistinguishable from other normal (nonjunction) names in the context.

Implicit Next Naming System Pointers: Static and Dynamic
Another way for a service provider to support retrieval of the nns pointer is via an implicit nns pointer. An implicit nns pointer is named by using the composite name component separator (/). Suppose the name corp.wiz.com names an object in the current naming system, the name corp.wiz.com/ will then name its nns pointer. An implicit nns pointer is used when a naming system's native entries cannot or should not be used directly to hold a nns pointer.
An implicit nns pointer can be determined statically or dynamically. A static implicit nns pointer is constructed by using data found in the current naming system. For example, suppose you store nns pointers in the DNS by using TXT records. When the DNS provider processes the name, corp.wiz.com/, it will use the data in the TXT record of the corp.wiz.com entry to construct the nns pointer.
An implicit nns pointer can also be determined dynamically, based on the types and content of the objects bound in the current naming system. This is useful when the result of resolving the components of a composite name in the current naming system does not indicate any nns information. The only conclusion that the service provider can draw is that resolution has completed in the current naming system and should proceed to the next naming system.
For example, suppose the composite name lib/xyz.zip/part1/abc consists of two parts: lib/xyz.zip and part1/abc. lib/xyz.zip names a file in the ZIP format while part1/abc names an entry within the ZIP file. The resolution of lib/xyz.zip results in a file object and does not indicate which nns to use for continuing the operation on part1/abc.
To support dynamic implicit nns pointer, the JNDI defines a special Reference called an nns reference. This reference has an address type nns and an address contents that is the resolved object. In the ZIP file example, the resolved object is the ZIP file itself and the file system service provider would construct an nns reference as follows:
Reference ref = new Reference("java.io.File",
    new RefAddr("nns" {
	public Object getContent() {
	    return theFile;
	}
    }));

Federation