|
|
Comparison of the LDAP and JNDI Models |
Both the JNDI and LDAP models define a hierarchical namespace in which you name objects. Each object in the namespace may have attributes that can be used to search for the object. At this high level, the two models are similar, so it is not surprising that the JNDI maps well to the LDAP.This section discusses how the LDAP maps to the JNDI. Some topics, such as referrals and schema, are discussed only briefly here and are described in more detail in other lessons in this trail.
Models
You can think of an LDAP entry as a JNDI DirContext. Each LDAP entry contains a name and a set of attributes, as well as an optional set of child entries. For example, the LDAP entry "o=JNDITutorial" may have as its attributes "objectclass" and "o", and it may have as its children "ou=Groups" and "ou=People".
In the JNDI, the LDAP entry "o=JNDITutorial" is represented as a context with the name "o=JNDITutorial" that has two subcontexts, named: "ou=Groups" and "ou=People". An LDAP entry's attributes are represented by the Attributes
Federation
Whereas the LDAP model covers a single namespace, the JNDI model deals with multiple namespaces linked together via federation. The LDAP namespace is but one of many namespaces that can be accessed through the JNDI.Names
As a result of federation, the names that you supply to the JNDI's context methods can span multiple namespaces. These are called composite names. When using the JNDI to access an LDAP service, you should be aware that the forward slash character ("/") in a string name has special meaning to the JNDI. If the LDAP entry's name contains this character, then you need to escape it (using the backslash character ("\")). For example, an LDAP entry with the name "cn=O/R" must be presented as the string "cn=O\\/R" to the JNDI context methods. See the What's in a Name?lesson for details.
LDAP names as they are used in the protocol are always fully qualified names that identify entries that start from the root of the LDAP namespace (as defined by the server). Following are some examples of fully qualified LDAP names.
cn=John Smith, ou=Marketing, o=Some Corporation, c=gb cn=Ted Geisel, ou=People, o=JNDITutorialIn the JNDI, however, names are always relative; that is, you always name an object relative to a context. For example, you can name the entry "cn=Ted Geisel" relative to the context named "ou=People, o=JNDITutorial". Or you can name the entry "cn=Ted Geisel, ou=People" relative to the context named "o=JNDITutorial". Or, you can create an initial context that points at the root of the LDAP server's namespace and name the entry "cn=Ted Geisel, ou=People, o=JNDITutorial".
In the JNDI, you can also use LDAP URLs to name LDAP entries. See the LDAP URL discussion in the Miscellaneous
lesson.
Searches
One of the most important aspects of the LDAP is its search model. You can search for entries in an LDAP server by specifying a search filter. The JNDI's DirContextReferrals
LDAP-style referrals are supported with the ReferralExceptionSchema
The JNDI contains methods in the DirContextControls and Extensions
LDAP v3-style controls and extensions are supported using the javax.naming.ldapJava Objects
Beyond basic LDAP functionality such as accessing LDAP entries and searching the directory, the JNDI also supports the notion of Java objects' being integrated into the directory. Thus you can think of the LDAP directory as a repository for Java objects, that is, as an integral part of the environment in which you develop and deploy your Java applications. This topic is discussed in detail in the Java Objects and the Directorytrail.
|
|
Comparison of the LDAP and JNDI Models |