< Zurück | Inhalt | Weiter >

21.3.1 Naming and Directory System Concepts

Directory services are one of the dark mysteries of modern computing. Why? Because if the people who developed these systems ever let on how simple they actually are, everyone would understand and be able to use them well. Then where would we be?

In practice, a naming system is what we programmers call an associative array, or, when we are feeling less verbose, a simple hash of name/value pairs. That’s it. The core concept isn’t any more complicated than that. The most familiar naming service out there (one that we are sure you use every day) is the Internet Domain Name Service, or DNS. This is a system that maps domain names (like www.somedumbnetwork.net) to IP addresses (like 205.117.29.1). In the world of directory services, such a name/value pair is called a binding.

Of course, the devil is in the details. DNS is implemented by a complex network of name servers that pass requests up and down a distributed hierarchy of name servers. That part can get quite complex, but the core idea is that you have a name (the domain name) and a value (an IP address) that you join


together. DNS can actually bind other information, such multiple alias names for a single canonical name/IP pair, a mail handler name for a domain, and other general purpose data which the DNS administrator can choose to share.

So, naming services are a way to join names and values together.

Before we move on, let’s make sure we understand how general and uni- versal this concept is. A filesystem can be thought of as a naming service. A UNIX filename (like, say, /etc/inittab) can be thought of as a way of linking that name with the data it contains. So the key is the name (/etc/inittab) and the value could be either the data it contains, or perhaps a file handle that, when read, returns the data contained in the file.3

There are some other common features of naming systems that we should point out. They are frequently hierarchical. A domain name such as www.multitool.net actually indicates the host www in the multitool domain within the net domain. The name www.multitool.com is not related in any way with the name www.multitool.net. They are contained in different top- level domains. They do not intersect. Likewise, the name /etc/inittab would be completely unrelated to, say, /tmp/inittab—because inittab is a file in the etc directory, and inittab is a file in the tmp directory. So, most naming systems are hierarchical. They differ in how the levels of the hierarchy are indi- cated, and in how absolute names are constructed from components of the hierarchy, but they share this common concept.

So, that’s naming. Next come directory concepts.

A naming service is good, but what happens if you don’t have the key and you need to go looking? That’s what directories are for. Consider the ls com- mand. Why do you need it? Have you ever run it? Of course you have. Why? Because you often don’t know the exact name of something or where exactly it is in a naming system. You need to be able to look for what you want. That is the “directory” part of naming and directory services. You want something that lets you query and browse the naming system to find what you want.

The ls command will give you the complete contents of a directory, or it will allow you to query a directory by specifying wildcard names. These are ex- amples of browse and query features. We’ll talk more about these concepts in relation to naming and directory systems in general and to JNDI in particular.


image

3. The first case would be a name/value pair, the second case would be a name/reference pair. The distinction is often not important, but it does exist.


Key to directory services is the concept of a context. A context is a set of bindings with a common name, expressed in a common way. In our filesystem example, /etc is a context. A context may contain other contexts that follow the same naming convention. For example, /etc/sysconfig is a context that is a subcontext of /etc. Likewise, multitool.net is a subcontext of the net context.

A context is distinguished by having a naming convention for itself and its subcontexts, and it must have means of creating bindings, removing bindings, and querying or listing bindings.

Since JNDI is designed to operate across multiple naming and directory systems, it is necessary to talk about naming systems and namespaces. A naming system is a connected set of contexts that use the same naming convention. Thus, Internet domain names are a naming system, UNIX filenames are a naming system, and so on. A namespace is a set of names in a naming system. These terms will have significance later when we’ll talk about JNDI.

A naming system binds a name to a value. Directory services bind a direc- tory object to one or more attributes. A naming service could be thought of as a simple case of a directory where “name” and “value” are the attributes of the directory object. A directory can store many more attributes (bindings) for a given name than can a naming service. Directory services also (in general) support the notion of searches and queries.

A directory object represents an object in the computing environment. This might be a server, a printer, a user, a router, whatever. Each object would have a set of attributes that describe the object. A directory is a connected set of directory objects.

In the directories we know about (see Sections 21.3.2.4 and 21.3.2.5 for the limits of our knowledge), directory objects are arranged in a hierarchy, so that they serve as naming contexts as well as directory objects.