|< Day Day Up >|| |
Before you can enter any objects into a directory, you must first define what kind of objects the directory will accept. This is much like the design of an object-oriented database. We begin the process by declaring the object classes the directory should accept. In our example we will have an object class called "organization" corresponding to the whole enterprise, a number of objects called "organizational unit," and objects of the object class "person." (Forgive me for calling a person an object, but let us agree to accept this point of view in the context of this discussion.)
You do not have to invent these object classes by yourself. There are a number of predefined standard object classes from which you can choose. The names of these object classes are standardized too, most of them being derived from the original X.500 protocol. You will learn more about this in Chapter 3, which discusses the models standing behind LDAP.
The directory will also contain a number of entries, with each of the entries corresponding to an object in the real world. Each class is characterized by a number of "attributes." For example, a person has a name, surname, phone number, and so on. The attributes are made up of an attribute name and one or more attribute values. The attribute names, like the class names, are standard, most of them being inherited from the X.500 protocol.
To refer unambiguously to an object, a special attribute called a "distinguished name" is used. There are no particular rules of how to build this distinguished name; the only important thing is that this name be unique within the namespace. Chapter 3 discusses the distinguished name in detail.
To define the data structures for the directory, you must first define a schema. A schema comprises object classes accepted by the implementation and governs how these object classes should interact. Chapter 3 discusses this issue in greater depth. For now, it is sufficient to know that the directory server has a number of schema files that contain the description of the object classes the directory can contain. This description is nothing but a list of attributes the entries can contain, together with a specification of the type and properties of these attributes. The schema also contains a specification for making comparisons between the values of these attributes. For example, the name or surname is not case sensitive, so if you are searching for King, KING, or king, you will find the entry. Similarly, consider the attribute "telephone number." There are several ways to write a phone number. The directory should ensure that you find the number:
even if you typed in:
0 100 203 440
This behavior is important not only for queries, but also for the ordering of values. Again, we will learn more about this in Chapter 3.
Every LDAP implementation is shipped with ready-to-use schema files. Both object classes and attributes are fixed in standards distributed in the form of requests for comments (RFCs), but you can extend these standards to fit your particular requirements. That is enough theory for now. Let us move on to the praxis.
|< Day Day Up >|| |