Naming and directory services are becoming an important component of network programming. There are a number of both with different protocols and APIs. Unfortunately all of these are vender specific and in the heterogeneous environment, that is, today's network, none of these can provide a simple solution across an organization of any size or complexity. What is needed is a server that can look up generally useful things; such as addresses and employee data, checking phone numbers and e-mail addresses and validate logins for many heterogeneous systems across the enterprise, from a central location, using a standardized open protocol. Thus, with the arrival of LDAP and JNDI, one can have a standard API and an open-standard protocol. JNDI helps client applications to keep the same API while changing directory service providers. As organizations are starting to turn to directory servers to act as a central point of access for information in the organization, and increasingly to LDAP-based servers. Here comes a brief about both naming and directory services and the significance of LDAP has been depicted.

A naming service is a service that provides for the creation of a standard name for a given set of data. This allows adding, changing or deleting the names of the objects. The important point to be noted here is that it provides a unique name for each object or entry that is registered for the service. This process is called naming binding.

Every naming service will have one or more contexts. A context is simply a name that is used to make it easier to manage entries in the naming service and to allow reuse of common names. There are two types of contexts, namely root context and sub-context. A file system is the most common naming and directory service we use daily. One more common example for naming and directory service is the Domain Naming Service (DNS), which is being contacted and used by Web browsers every time to get the IP address for the Fully Qualified Domain Name (FQDN) we supply. A root context is the base name of an entry. For example, a root context is very similar to the root context in a file system and from that, all other directories and files are stored. In Unix OS, the root context is `/'. Under Windows OS, it is generally `C:\'. In DNS, the root contexts are the top-level domains like `com' or `org'. In Java Remote Method Invocation (RMI), a root context would be the base of the class hierarchy. For example, if the class hierarchy is research.QCI.QA, then the root context would be `research'.

A sub-context is a name that adds another level to the root context. There may be more than one sub-context. The sub-context is simply used to help subdivide the namespace either to provide more flexibility in management or to allow several objects to share the same common name. For example, to allow for more than one server to be named www, second-level domains are needed, such as `kuis.kyoto-u.ac.jp' and `ics.nitech.ac.jp'. Thus www.kuis.kyoto-u.ac.jp and www.ics.nitech.ac.jp can share the same common name of www but are considered to be two unique systems on the Internet. The same principle holds good for file systems also. After the sub-contexts, there comes only the name of the object stored in the naming service. In a file system, it is the name of file and in RMI, it is the name of a Java class. In DNS, the name of the particular server comes. Thus naming service is all around us without realizing its significance.

Directory services themselves are not new. Linux and Unix users will be familiar with NIS that Sun invented to provide network-wide account management on Unix flavor machines, allowing a single point of logon and administration for user accounts. Similar centralized administration facilities exist for Novell networks and Microsoft NT domain administration. A directory server at first sight seems much like a database server. They both hold data and let us ask questions which result in data being returned. It often is being felt that directory servers are actually less flexible than databases. But still directory servers are having their own distinct advantages, such as speed, redundancy and standardization of the protocol. Directory servers are blindingly fast at processing searches as they are heavily optimized to solve a very specific problem, that is, fast searching over a network and hence could answer queries, even very complex ones, almost instantaneously. Directory servers are also normally replicated, with two or more servers seamlessly providing service even in the event of a failure of any single server.

A directory service is a naming service that includes meta-data describing the object referenced by that name. This enables to search the directory service on the meta-data to find the object without knowing its name. A directory service will always have a naming service, but naming service need not have a directory service. An example of a directory service in the physical world is a telephone book. A telephone book allows us to look up the telephone number of a person or business very quickly if we know the name of the person or business whom we want to contact. There are a number of directory services already in use on our networks today. One common directory service we use everyday is Domain Naming Service (DNS), which takes a Fully Qualified Domain Name (FQDN) and returns that FQDN's Internet Protocol (IP) address.

Most directory services are better optimized for reading and writing is the least optimal operation. Thus it is not wise to use a directory service to store information that is getting updated often. So directory services are more powerful and useful for things like names, userids and passwords, which are not changing often.

Directory services do not have a common query language such as SQL for relational databases. But there is a standard XML representation for directory data called Directory Services Markup Language (DSML). The purpose is to standardize the representation of all types of directory service data in XML. This has been developed by a consortium of directory service providers. Sun Microsystems is working for a complete DSML service provider for JNDI as DSML is very new and no significant works has been done yet.

Apart from DNS, there are a number of directory services, such as Novell Directory Services (NDS), Network Information Services (NIS/NIS+), Windows NT Domains and Active Directory Services (ADS) available at the moment. These directory services supply more functionalities than that DNS gives. Each one also allows to store information about users (userid, passwords, names, etc.), user groups for access control, and computers, such as Ethernet and IP addresses. NDS and ADS provide additional functions, such as the location of network printers, software and so on, than either NIS or NT domains. As there are many kinds of directory services and we have so many computers on our networks, some larger problems have erupted. There are classified into two main issues. First one is to keep track of users and the second one is keep track of network resources, such as computing systems and printers.

Consider this situation. An user can have an access to a Novell system, which uses NDS, for file and print sharing and can have an account in a Windows-based machine for running some other applications, and finally an account on an Unix machine for e-mail and Web page publications. Unfortunately these systems use different directory services and hence there can be no interactions among these systems. This means that users have to have different user accounts (user id and password) for each system. Sometimes there may be accounts of people who had left the organizations or institutions. As these accounts are open and accessible remotely, they can be exploited by the former organizational member or by someone who hacks that account and hence a security hole can be created. This situation is very problematic and troublesome for the networks administrators, who have been assigned to track the users and resources available in the network.

In addition to this, there is one more issue that makes it very difficult for the traditional application developer to interact with several different directory services is that every directory service has its own particular protocol.

The grand solution for all those quoted issues was intended to be a directory service designed by the International Telecommunication Union (ITU) called X.500. This was to be a universal solution for directory services, with multiple servers around the world collaborating to provide different branches of a universal directory tree. Unfortunately there came a couple of big problems. X.500 was designed to use OSI protocols, which were one of those great networking protocols that never happened. This was largely because TCP/IP was already well established, supported on a wide variety of machines and was decisively the protocol of the Internet.

Having realized the significance of having a standard protocol that use TCP/IP protocol, researchers at the university of Michigan developed Lightweight Directory Access Protocol (LDAP) in the early 1990s. Since then, it becomes the most popular directory protocol. The latest version is LDAP v3, which provides new additional features, such as for referrals, which allow servers to return referrals to other servers, for security using the Simple Authentication and Security Layer (SASL), Unicode support and extensibility. LDAP specifies how clients should access data on the server. Nowadays there are servers specifically built for LDAP, such as openLDAP or iPlanet Directory Server. However, LDAP can become an interface to any type of data store. Because of this feature, almost all the popular directory services (NIS, NDS, Active Directory and Windows NT Domains) now have an LDAP interface of some type.

There are primarily three applications. They are access control, white pages services and distributed computing Directory.

Access control deals with controlling access to system and its resources. Today's applications dictate who can use them; this can range from allowing anyone who can click on the application's icon to start it up, to allowing only a person who matches a particular retinal scan, a biometric technology. Access control can be further subdivided into two parts: authentication and authorization.

Authentication is determining who the person using a piece of software is. This is being achieved nowadays when a user supplies a username and a password and the username is compared with the person's record in a database. If the password supplied is the same as the one stored in the database, then the real identity of the person gets verified. But the biggest problem with this kind of authentication is that passwords can be easily extracted while in transit over the Internet or one can easily access the database containing passwords unauthorizedly. In today's networked world, password protection assumes a greater significance during its transit over the network. LDAP has the capability to support a wide range of authentication services, including password, digital certificates and the Simple Authentication and Security Layer (SASL) protocol.

Authorization is to determine the resources and the applications for the one, who is authenticated, is allowed to do. There are specified, fine-tuned authorization policies towards filtering access to the systems. LDAP supports to design sophisticated authorization policies.

White pages services are services that enable someone to look up users based on attributes contained in their entries. That is, we can look up one's email address, gets the telephone number of his office, and other details. This sort of services is called white pages because this type of information is similar to the type of information one can find in the white pages of US telephone books. LDAP to a major extent supports these types of services. E-mail packages, such as Netscape Messenger or Microsoft Outlook, have an LDAP client that provides most of the white pages services. For example, one enters an electronic purchase order request for some widgets from a commercial company. The purchasing application supplied by the company has a business rule that says after a person enters a purchasing order, it must be sent to the person, who authorizes the purchase order, for their group. So the application looks up in the LDAP directory to find out who authorizer is for the ordering person's group, and sends them an e-mail notification using the authorizer's LDAP email attribute.

Distributed Computing Directory : Distributed network programming has set to become one of the fastest growing segments of server-side programming. This is where an application uses code that actually resides separately from the running application. The code can be either in a separate JVM in the same machine or in a JVM on a different physical machine located in a remote location. This type of programming is mainly used for reusing existing legacy code or to reduce heavy load of processing in a single machine and towards improving application performance. There are a number of architectures available for supporting distributed programming.

They are OMG's CORBA, Microsoft's DCOM and Java's both RMI and EJB. These use a registry service that a client application uses to locate the distributed code. DCOM uses Windows registry, CORBA uses Naming Service and RMI uses registry service. But these services do not provide a mechanism to search their registry to discover what objects are available for use. With JNDI and LDAP, one can provide indirect references to these services. For example, one can an entry with a name of `Real Time Stock Quote Service' that has an attribute that contains the actual network location of the RMI or CORBA object.

This type of services provides a lot of advantages such as flexibility to applications and comprehensibility of code. For instance, if there is a need for moving a particular distributed object to a new server, all we have to do is just change its location in LDAP directory, instead of having to make the changes in all of the applications accessing this object. Thus all of the clients will update their locations automatically the next time they reference the object as they will look up the LDAP server for its location before accessing the object.

As LDAP can also store other descriptive attributes in an entry, we can store better descriptions of an object in the directory to build a white pages for objects. For instance, we can add details such as the development language used for the object, the name of the developer and comments about the object etc.

One can also use LDAP to store configuration information about an application. This is particularly helpful if the same user accesses the same application but on different machines and it would be helpful to provide the same configuration information regardless of the machine being used.

The data in an LDAP directory store is organized in a tree, called a Directory Information Tree (DIT). Each leaf in the DIT is called an entry. The first entry in the DIT is called the root entry. An entry is composed of a Distinguished Name (DN) and any number of attribute/value pairs. The DN is the name of an entry and must be unique. It is like the unique key of a relational database table. A DN shows the relation of the entry to the rest of the DIT just like the full path name of a file shows the relation of a particular file on our hard drive to the rest of the files on our system. A path to a file normally reads left-to-right when reading from root to file, whereas a DN reads right-to-left when reading from root to entry. Here comes an example of a DN

uid=peter. ou=people, o=kuis.kyoto-u.ac.jp

The leftmost part of a DN is called a Relative Distinguished Name (RDN) and is made up of an attribute/value that is in the entry. The RDN in the above example is uid=peter. LDAP attributes often use mnemonics as their names like the LDAP attribute cn stands for common name, uid for userid, mail for e-mail address for example, cn=peter chelliah and uid=peterIndia, mail=peter@kuis.kyoto-u.ac.jp.

Attributes are referred to in name/value pairs and the attribute values can contain either binary or text data. Any attribute can have one or more values if defined by the schema, which is the rules that defines the objectclasses and attributes in the LDAP server. For example, a user can have more than one phone number, so they could have more than one value for their phone attribute. Attributes also have matching rules, which tell the server how it should consider whether a particular entry is a match or not for a given query. For example, Case Sensitive String (CSS) is a matching rule which means that attribute can match if value of the query equals the attribute's value, including the case. Similarly there are many more matching rules, such as Case Insensitive String, Telephone etc.

Objectclass is a special attribute. This attribute is similar to a table in a relational database. An objectclass defines which attributes can be used in a given entry in the directory. It separates attributes into two types, required, which means attributes that must be present in the entry, and allowed , which means optional attributes. The definitions of attributes, attribute matching rules and the relationship between object classes and attributes are defined in the server's schema.

LDAP Data Interchange Format (LDIF) is the most common way to show LDAP data in human readable format. Here is an example of LDAP entry represented in LDIF.

dn:uid=peterIndia, ou=people, o=kuis.kyoto-u.ac.jp
cn: peter chelliah
sn: chelliah
givenname: pethuru
objectclass:top
objectclass:person
ou: Research
ou: People
l: Kyoto
postalCode: Matsuo-Bldg. 2F, Iseya-cho, Kawaramachi marutamachi
pinNumber: 602-0873
mail: peter@kuis.kyoto-u.ac.jp
telephonenumber: 81 75 257 0066
facsimiletelephonenumber: 81 75 257 0062
roomnumber:202

There are a number of standard operations that can be performed on a LDAP server. They are searching the server, adding a new entry, modify an entry, and delete an entry. Here is how LDAP can be a significant factor for Java RMI.

It is very easy compared with other paradigms to develop distributed Java applications using Java RMI. The inherent problem with RMI clients is that it is not possible with the present setup of RMI to update the location of RMI server objects dynamically. An RMI location is specified using an RMI URL like rmi://localhost/

Click for an overview of Java Naming and Directory Interface

Click for LDAP Links

---