| Before answering this question, let's briefly talk about what a directory service really is. A directory is simply something that you use in order to look up and find information. In the physical world, you probably use directories every day. A very common example of a directory is your telephone book. If you need your friend's phone number, you look up his or her entry in the phone book, and there you will find the phone number to use. Another common directory is the building directory that you may encounter when you enter the lobby of a large building. How else would you know which floor to visit? Electronic directories sometimes serve purposes that are similar to those served by physical directories. An email directory, for example, may let you use a fellow employee's name in order to look up his email address. Directories can also serve other purposes. They can be used to find out what servers are on your network, and they can be used to find network printers that are available to you. The Oracle data dictionary tables that hold user information can even be thought of as a directory. Using a separate directory for each different email system, fileserver, database server, or whatever quickly leads to a high maintenance burden . As employees come and go, you'll find yourself needing to make the same changes in multiple directories. Consequently, there's been a great deal of interest over the years in developing a common directory technology that can be used across many different applications. Years ago, a common directory technology known as X.500 was developed by the International Standards Organization (ISO). Unfortunately, X.500 directories are not easy to implement, and accessing an X.500 directory from a client is not easy either. LDAP was designed to remedy these problems. It's a lightweight protocol, originally developed at the University of Michigan, that runs over TCP/IP and allows you to access either an LDAP-compliant directory service or an X.500 directory service. 6.1.1 Entries, Attributes, and Object Classes LDAP directories are based on the concept of an entry . An LDAP directory contains entries for one or more classes of objects. Each object class has a set of attributes associated with it. Each directory entry is associated with one or more classes, and contains values for the attributes of those classes. Figure 6.1 illustrates this concept. Figure 6.1. LDAP directory entries contain values for one or more attributes  As you can see from Figure 6.1, possible attributes for an employee directory include phone number and email address. Attributes for a directory of net service names would need to include such things as a hostname, a protocol, a port number, and a service name. 6.1.2 Directory Hierarchies LDAP directories are organized in a hierarchical format. This is actually one of the big differences between a directory and a relational database. Figure 6.2 illustrates the LDAP hierarchy that you would use to define net service names using a domain-naming scheme. In this case, the domain is gennick.org . Figure 6.2. LDAP directory hierarchy for net service names in the gennick.org domain  Two net service names are illustrated in this figure. One name is luke.gennick.org , and the other is nick.gennick.org. This type of diagram is commonly used to illustrate LDAP directory structures. You'll see it often as you work with LDAP. To make sense of a diagram like this, it helps to understand both the hierarchical nature of a directory and the concept of a distinguished name. 6.1.2.1 Hierarchical versus relational If you're an old-timer, you may recall that databases weren't always relational. In fact, hierarchical databases were quite common before relational databases came along. One of the key differences between the two types lies in how you access the data. With a hierarchical database, you have to work your way from the top of the hierarchy down to the element that you want to retrieveyou can't access a child without first accessing the parent. With a relational database, you can easily access rows in a child table without first accessing the parent data. A physical phone book can be thought of as hierarchical. When you look up someone's phone number, you start by taking the first letter of that person's last name. To look up Jonathan Gennick, for example, you begin by taking the letter G. Then you find the corresponding section of the phone book; in this case, you want the section for names beginning with G. Then you look in that section for entries with a last name of Gennick. Having found those, you next look for the entry with a first name of Jonathan. After finding that entry, you can retrieve his phone number. Because phone books are hierarchical, you have to follow one access path . You would have a difficult time indeed trying to do a reverse lookup of the name that corresponded to a given phone number, because phone directories aren't organized by phone number. Like phone books, LDAP directories are hierarchical in nature. They can be stored in a relational database, but that doesn't negate the hierarchical aspects involved. With LDAP, the identity of each entry is bound up in the hierarchy. 6.1.2.2 Distinguished names LDAP directory entries have names based on their position in the directory hierarchy. Figure 6.2 shows the hierarchy for two net service names: nick and luke . The names nick and luke are considered relative names . A relative name is one that is only unique at a given level of a directory tree. In this case, the relative names nick and luke are only unique with respect to the parent entry named OracleContext. It's entirely possible for nick and luke to appear elsewhere in the same directory. Distinguished names are used to uniquely identify a specific directory entry. A distinguished name is the concatenation of all relative names leading from the entry of interest back up to the directory root. Commas are used to separate each relative name. The common notation used is to preface the distinguished name with dn:, and then to enclose the whole string in parentheses. Thus, the distinguished names for nick and luke , as shown in Figure 6.2, are as follows : (dn: cn=nick, cn=OracleContext, dc=gennick, dc=org) (dn: cn=luke, cn=OracleContext, dc=gennick, dc=org) For those of you used to separating name components with periods (such as with nick.gennick.org ), this notation will take a bit of getting used to. 6.1.3 Uses for LDAP One of the great things about LDAP is that you can create your own object classes and attributes. This allows you to use LDAP directories for a wide variety of creative purposes. Oracle currently supports LDAP for the following uses: -
Global users -
Global roles -
Net service names Global users and global roles are defined in an LDAP directory service and can be managed centrally. A user can then change his password once, for example, and have that change apply to all databases across the board. Similarly, net service names may also be defined and managed separately. Oracle's clear goal is to take all the bits and pieces of information that DBAs usually need to replicate for each database, and allow those to be managed centrally . LDAP is the core technology supporting this effort, and it will play an increasingly important role in your Oracle environment. 6.1.4 Oracle Internet Directory The Oracle Internet Directory (OID) is one among several competing brands of LDAP directory servers. It's by no means the only LDAP directory that you can use with an Oracle database. In fact, Oracle currently supports the following directory products: -
Oracle Internet Directory -
Microsoft Active Directory -
Novell Directory Services The OID is, of course, Oracle's preferred solution. It's a Version 3 compliant LDAP server that uses the Oracle database as a repository for directory entries. By using the Oracle database as a repository, you gain advantages in terms of scalability and reliability. The OID should be as scalable as the database itself, and Oracle claims the potential to support hundreds of millions of entries with one OID server. The OID also benefits from Oracle's high availability and replication features. Through the use of multi-master replication, you can keep two or more directory servers in sync with one another. If one server goes down, the others remain available, allowing directory administration and lookup activity to continue unabated. | 
