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. How it does this depends on whether its participation in the name's resolution is as an intermediate naming system or a terminal naming system.
An intermediate naming system is a naming system that is involved only in the resolution of the composite name. It is responsible for passing on the operation to its target context. The terminal (or target) naming system is the system that contains the context in which the operation is carried out. In other words, the terminal naming system is the system 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 performing 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(), then the service provider would invoke list(), using its components from the composite name, as if it was not in a federation and then return the results of list() to the caller.
By contrast, processing for an intermediate naming system is much more interesting. The provider's job is to determine the reference to the next naming system, or nns, when given its components from the composite name. This reference is called the next naming system pointer, or nns pointer. In the previous example, the LDAP provider must determine the nns pointer for the LDAP name "cn=homedir,cn=Jon Ruiz,ou=People".
Retrieving NNS Pointers
A service provider can support retrieval of the nns pointer in either of two ways. One way is to use an explicitly named nns pointer, also called a junction. The second way is via an implicit nns pointer.
Junctions
A junction is a binding of a name to an nns pointer; in the previous example, "cn=homedir,cn=Jon Ruiz,ou=People" is a junction. This name is bound to a reference to a file system context. If you perform a Context.lookup() on the name, then you will get back not an LDAP entry but a Context instance for a directory (/tmp) in the file system.
A context may have an unlimited number of junctions. Moreover, a junction is usually indistinguishable from other normal (nonjunction) names in the context, although this depends on the naming policy of the underlying naming system.
Implicit NNS Pointers
A service provider also can support retrieval of the nns pointer 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. Then the name "corp.wiz.com/" will 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 an nns pointer. It can be determined statically or dynamically.
Static Implicit NNS Pointers. A static implicit nns pointer is constructed by using data found in the current naming system. For example, suppose that 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.
Dynamic Implicit NNS Pointers. 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 a composite name's components in the current naming system does not indicate any nns information. The only conclusion that the service provider can draw is that resolution was completed in the current naming system and should proceed to the next naming system.
For example, suppose that 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, and "part1/abc" names an entry in 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 a dynamic implicit nns pointer, the JNDI defines a special Reference called an nns reference. This reference has an address type "nns" and an address content 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