Overview of Directory Naming

Most clients needing to perform name lookups in the directory server access the directory server^[1] using anonymous authentication. To perform a lookup, the directory server must allow anonymous authentication. Directory servers usually allow anonymous authentication by default, however, some directory servers, such as earlier releases of Oracle Internet Directory, require directory configuration to allow anonymous access. To look up entries, a client must be able to find the directory server in which that entry resides. Clients locate a directory server in one of two ways:

1. Dynamically using DNS. In this case, the directory server location information is stored and managed in a central domain name server. The client, at request processing time, retrieves this information from DNS.
2. Statically in the directory server usage file, ldap.ora, created by Oracle Internet Directory Configuration Assistant and stored on the client host.

After a directory is found, clients are directed to the realm Oracle Context from the root Oracle Context.
they might use other naming methods. A connect identifier can be a database service, network service name, or network service alias. These can be referred to by their common names (relative name) if the default Oracle Context is where the entity resides. If not, then the connect identifier needs a fully-qualified name or distinguished name.

Oracle Names was a distributed service designed to help simplify the setup and administration of Net8 clients and servers. In Oracle8 Network Topology the propagation of a tnsnames.ora file to hundreds of PC clients was one solution to this problem.
In a non-Oracle Names environment, when a client requests a connection to a remote database the tnsnames.ora file is used to get the information required to make the connection. With Oracle Names, a remote data request is routed to a centralized Names server. The Names server gathers the information and passes the 1) IP address, 2) protocol, 3) port number, and 4) SID name back to the requesting client or server.
In short, Oracle Names functions very much like a shared tnsnames.ora file on a network disk. Oracle Names also has the same shortcoming, because a failure of the Names server will prevent any Windows clients from connecting to Oracle. To address this problem, Oracle Names allows for multiple names servers to be defined. The diagram below describes the numbered steps with respect to how these redundant Names Servers share information.

Oracle Names provided an alternative to "file-based" tnsnames.ora service-name resolution, where service names and addresses were configured and maintained with each individual client. By maintaining the tnsnames.ora information in a central Names server, Oracle Names reduced the work effort associated with maintaining hundreds of tnsnames.ora files on client PCs.
The Names server was an Oracle database where Oracle8 was installed on the server in order for Names to store information.
Oracle Names went one step further and eliminated all maintenance of the tnsnames.ora file. Whenever a server that was registered with Oracle Names added a new database to its listener.ora file, Oracle Names took that information and stored it in the Names server. In this fashion, all tnsnames.ora maintenance was accomplished automatically. As soon as a new database was added to the listener with Net8 Assistant, the Names server obtained the information about the database and made it available to all registered PC clients. The next lesson discusses how Oracle Names resolves requests.

[1]Directory Server: A directory server that is accessed with Lightweight Directory Access Protocol (LDAP). Support of LDAP-compliant directory servers provides a centralized method for managing and configuring a distributed Oracle network. The directory server can replace client-side and server-side localized tnsnames.ora files.