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.
They might use other naming methods. A connect identifier can be a

1. database service,
2. network service name, or
3. 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 introduced "Directory Naming" with the release of Oracle9i Database in 2001. It replaced the earlier "Oracle Names" naming method. Here are some of the benefits of "Directory Naming" over "Oracle Names":

1. Standardization: "Directory Naming" utilizes LDAP (Lightweight Directory Access Protocol), which is a standardized protocol for accessing directory services. This standardization ensured better compatibility with various applications and platforms.
2. Scalability: "Directory Naming" leverages directory servers, which can be distributed and scaled to accommodate large and complex network environments. This scalability was not possible with the flat file-based approach of "Oracle Names".
3. Flexibility: "Directory Naming" allows for greater flexibility in defining and managing network resources. It supports hierarchical naming structures and attributes for organizing and identifying network objects.
4. Centralized Management: "Directory Naming" facilitates centralized management of network resources through directory servers. This simplifies administration and improves consistency across the network.
5. Security: "Directory Naming" allows for more robust security features, including authentication, authorization, and access control. This helps to protect sensitive network resources.
6. Integration: "Directory Naming" integrates seamlessly with other directory services and applications, enabling easier collaboration and resource sharing.
7. Performance: In some cases, "Directory Naming" can offer improved performance compared to "Oracle Names", especially for large and complex networks.

Overall, "Directory Naming" provided a significant improvement over "Oracle Names" in terms of standardization, scalability, flexibility, manageability, security, integration, and performance. This is why Oracle has made "Directory Naming" the preferred method for network resource naming in its database products.

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 requested a connection to a remote database the tnsnames.ora file was used to get the information required to make the connection. With Oracle Names, a remote data request was 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 functioned very much like a shared tnsnames.ora file on a network disk. Oracle Names also had 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 allowed for multiple "names servers" to be defined. The diagram below describes the numbered steps with respect to how these redundant Names Servers shared 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.