The Java Naming and directory interface (the Java naming and directory Interface,jndi) is a set of APIs that access the naming and directory services in Java applications. The naming service links names to objects so that readers can access them by name. A directory service is a naming service in which objects have names as well as attributes.
Naming or directory services enables readers to centrally store shared information, which is important in network applications because it makes such applications more coordinated and easier to manage. For example, you can store printer settings in a directory service for use with printer-related applications.
After learning about the basics of Jndi, this chapter explains the Jndi in detail in a code example so that the reader can understand and use Jndi. 1. What is Jndi
In an enterprise, a naming service provides a way for readers ' applications to locate objects on the network. A naming service ties objects and names together, and can find the object by the name they specify.
Jndi is a Java naming and directory interface and is an application programming interface (API) that provides naming services for Java applications. It provides developers with a common, unified interface for finding and accessing various naming and directory services, similar to JDBC being built on an abstraction layer. To use Jndi, you must have more than JDK version 1.3 installed.
Jndi contains a large number of naming and directory services that use a common interface to access different kinds of services, and can connect to multiple naming or directory services at the same time and establish logical associations. 1.1 Name Service
A naming service is a service that provides the ability to create a standard name for a given dataset. It allows you to associate a name with a Java object or resource without having to point out the physical ID of the object or resource. This is similar to the dictionary structure (or the map structure of Java), in which the keys map to values. For example, the Domain Name service (domains naming Service,dns) on the internet is to provide a naming service that maps domain names to IP addresses, when you open a Web site, you typically enter a name in the browser, find the appropriate IP address through DNS, and then open it.
All Internet traffic uses TCP, UDP, or IP protocols. The IP address consists of 4 bytes of 32-bit binary digits, which, compared to names, are easier to remember than numbers, but for computers it is better at handling numbers.
In fact, all naming services provide the basic function of DNS, that is, a system to the naming service registration, the naming service provides a value to another map. Then another system accesses the naming service to get the mapping information. This kind of interaction is very important for distributed enterprise-level application.
In Java, the basic name operation is contained in the context interface. 1.2 Directory Services
The directory service is a special type of database that, in contrast to relational database management systems such as SQL Server, Access, and Oracle, constructs a directory service to handle behavior-based transactions and uses a relational information model. The directory service further extends the concept of naming services to provide a hierarchical repository of information, in addition to a one-to-one relationship, as well as a hierarchical structure of messages. In the case of directory services, this hierarchy is often used to optimize search operations, and can also be distributed as a reality or replicated across networks.
A directory service usually has a name service (but a name service does not have to have a directory service). If the phone book is a typical directory service, usually first in the phone book to find the relevant names, and then find the person's phone number.
Each directory service can store information about user names, user passwords, user groups (such as information about access control), Ethernet addresses, IP addresses, and so on. The information and operations that it supports will vary depending on the directory service that you are using. Unfortunately, there are different protocols for accessing different directory services, so readers need to know more than one API.
This is the origin of Jndi, like JDBC, where jndi acts as a generic API for different name and directory services, or as a front-end, and then uses different back-end adapters to connect to the actual service. Figure 6-1 shows how Jndi and LDAP work together to provide a perfect solution for customers.
Here, the use of JNDI to complete communication with the LDAP server, for developers they are only concerned about a special protocol (LDAP) and an API (JNDI), and the developers to their own protocols to provide the LDAP interface. In fact, for these popular directory services, there are products that allow developers to communicate with these directory services through LDAP.
Jndi is a complete component of the Java EE technology. It supports ways to access different, new, and existing services through a single approach. This support allows any service provider to execute a JNDI framework insertion through a standard service provider Interface (SPI) contract. In addition, Jndi allows Java applications on the WebLogic server to access a standardized approach to external directory services, such as LDAP, by inserting the appropriate service providers.
The basic directory service operation is contained in the DirContext interface. Introduction to 1.3 LDAP
Lightweight Directory Access Protocol (Lightweight Directory Access PROTOCOL,LDAP) was developed as a standard directory protocol in the early the 1990s. It is currently the most popular directory protocol, and vendor and platform-Independent.
LDAP can be traced back to the X.500 protocol, and the X.500 protocol was originally developed based on the OSI network protocol. The 3rd version of the LDAP protocol is defined in RFC2251 and is already very mature, and its newest additions include the LDAP XML specification, called the Directory Service Markup Language.
The Java language uses the LDAP API, such as the Netscape Directory server, to use LDAP directly or through Jndi. Jndi is the standard API in J2SE and is a generic API that does not have to be bound to LDAP.
LDAP defines how the customer should access data in the server, and it does not specify how the data should be stored on the server. In most cases, developers only need to deal with a directory service designed specifically for LDAP, or an LDAP front-end for an existing directory service. LDAP can be the front end of any data storage type. The most popular directory service today is NIS, NDS, Active directory, and so on, with some sort of LDAP front-end.
LDAP and relational databases are two different levels of concept, the latter is the storage mode (the same level as the grid database, object database), the former is the storage schema and access protocol. LDAP is a storage concept higher than the abstraction level of relational databases, which is the same level as the query language SQL of relational databases. The most basic form of LDAP is a standard way to connect to the database, which is optimized for read queries. So it can quickly get the results of the query, but in other areas, such as update operations, etc. are much slower.
In another sense, LDAP is the storage that implements the specified data structure, which is a special kind of database. But it's important to understand that LDAP is different from the general database. LDAP is optimized for queries, and LDAP has a much better read performance than write performance. The LDAP server is also used to process queries and update LDAP directories. In other words, the LDAP directory is also a type of database, but not a relational database. It is particularly noteworthy that LDAP is typically used as a hierarchal database rather than as a relational database.
1. LDAP data
In LDAP, data is organized in the form of a tree called the Directory Information Tree (information Tree,dit directory). The first "leaf" in the DIT is called an entry (entry), and the first entry is called the root entry (root entry).
An entry is made up of a distinguished name DN (distinguished name) and any attribute/value pair. A DN is the name of an entry, and it must be unique, similar to the unique keyword of a relational database. The DN also indicates the relationship between the entry and other parts of the DIT tree, similar to the way in which a file's full path name indicates the relationship between a particular file on the hard disk and other files in the system. When a file is read from the root, the file path on the read system is read from left to right, but the DN is read from right to left when the DN is read from the root directory. Such as:
UID = Jordan,ou = Nba,o = American
Represents a user who defines a group of American in the Organization for the NBA's users Jordan. The leftmost part of one of the DN names is called the Relative distinguished name RDN (relative distinguished name), which consists of an attribute/value within an entry, such as the preceding UID = Jordan is RDN and the rear is optional.
LDAP typically uses shorthand mnemonics to represent its name, and commonly used LDAP attributes and their definitions as shown in table 6-1.
LDAP attributes and their definitions
LDAP properties |
Defined |
O |
Organization: Organization |
OUs |
Organization Unit: Organizational units |
|
|
Continued form
LDAP properties |
Defined |
Uid |
Userid: User ID |
cn |
Common Name: Common names |
sn |
Name |
givenname |
First Name |
Dn |
Distinguished Name: Distinguished names |
Mail |
e-mail address: email addresses |
|
|
One of these properties can have one or more values, such as a user can have more than one mail.
2. Functions of LDAP
So far, we have introduced the LDAP itinerary Registration section, in fact LDAP also includes many other uses, in general LDAP functions include remote service registration, access control, Yellow Pages server and configuration data.
(1) Remote server Registration
This is what is involved in using LDAP in this chapter, which has been discussed earlier. LDAP allows a remote server to register its availability, and then allows the client to obtain the registration information and use the server. In some cases, such as RMI, this may mean that the serializable objects are saved in LDAP, and the saved objects can be retrieved thereafter. This is similar to the use of rmiregistry, but it can search for LDAP, but Rmiregistry does not, and when the Rmiregistry is stopped and restarted, the previously registered object is invalid and all objects must be re-register.
(2) Access control
Many enterprise applications control the users who access their services. This may be as simple as a Web application login page, or it may be as complex as using a digital signature. Whichever method is used, the information to be examined needs to be saved somewhere, and one option is to save that information in LDAP. For example, users can be guaranteed to be in LDAP.
(3) Yellow Pages server
The Yellow Pages server function is similar to the phone directory, so called Yellow Pages. It provides an information search feature that enables LDAP to search for information based on the property content of the entry. For user names, computers, printers, and so on, you can use LDAP to store this information for all employees in the company, and then search for users with a specific name and retrieve their user IDs.
(4) Configuration data
LDAP can act as a resource center for configuration information, which is used when the application is running. This is similar to using a property file in a Java application, but it is not just a property file for each application, but rather a single repository center that can be used to access and maintain. Shared database names used by some specific applications can be saved to LDAP. Therefore, if the database name changes, there is only one place to maintain for all applications that need to migrate to the new database.
3. Using LDAP
To use LDAP, you need to complete the following 4 steps.
(1) Connecting to the LDAP server
To use LDAP, you must first obtain a connection to the LDAP. To complete the LDAP connection, you need to know which host is running LDAP and which port to connect to, which is similar to having the phone line plugged into the wall's phone hole before you can make a phone call.
(2) Bind to LDAP server
For LDAP, there are usually at least two ways to bind (log on) to an LDAP server, anonymous (LDAP3 version), or as a specific user. Bindings are similar to calling a friend by using a telephone line set up by the telephone company. Anonymous logins can only access some of the public data. If your application is logged on as a specific user, you can access both public data and all the data that is accessible to that user. Setting accessible data for a user is determined by the access control list of the LDAP server (Access controls List,acl). ACLs control which users can read, write, or modify any data associated with the ACL. Different properties within an entry can be associated with multiple different ACLs. As a result, different users can see different data items, in addition to certain properties that can be associated with multiple ACLs, such as an ACL can provide read permission to a user group, but another ACL can provide write permissions to another user group.
(3) Perform any required operations on the LDAP server
These operations mainly include searching servers, adding new entries, modifying entries, deleting entries, and so on.
(4) Releasing the connection to the LDAP server
When an application connects to LDAP and completes its related work, the application should close the connection to free system resources. 2. Use Jndi 2.1 Jndi service provider
Jndi cannot be used without service providers. A service provider is a collection of Java classes that enables developers to communicate with directory services in a manner similar to how the JDBC driver communicates with the database. Service providers that can be used for Jndi must implement the context interface or the extended interface Directory-context of the context.
When using Jndi, the reader only needs to know about Jndi, and the service provider is concerned with the details of the actual network protocol, encoding/decoding value, and so on.
When you download the SDK Software Development Kit, you download some of sun's existing service providers. These service providers include LDAP, NIS, COS (CORBA Object Services), RMI registration, and file system providers. such as: Hashtableobj.put (context.initial_context_factory, "com.sun.jndi.ldap.ldapctx-fatory") means using the Sun LDAP Service provider. Of course, if you want to use the IBM service provider, you can use Com.ibm.jndi.LDAPCtxFatory instead of com.sun.jndi.ldap.ldapCtxFatory. 2.2 Jndi Packages
The JNDI includes 5 packages.
· Javax.naming: Primarily for naming operations, it contains classes and interfaces for naming services that define the context interface and the InitialContext class;
· Javax.naming.directory: Mainly for directory operations, it defines the DirContext interface and Initialdir-context class;
· Javax.naming.event: Request event notification in a named directory server;
· JAVAX.NAMING.LDAP: Provide LDAP support;
· JAVAX.NAMING.SPI: Allows dynamic insertion of different implementations, providing developers and implementations for different naming directory service vendors so that applications can access related services through Jndi. 2.3 Common Jndi operations
The common Jndi operations are as follows:
· void bind (String Sname,object object), binding: The process of associating a name with an object.
· void Rebind (String sname,object object), rebind: Used to rebind an object with an already existing name. Generally use rebind () instead of bind (), because the rebind () does not appear when there is a duplicate name, and bind () reports an exception.
· void Unbind (String sname), freeing: Used to release objects from the directory.
· void Lookup (String Sname,object object), finding: Returns an object that is the total of a catalog.
· void rename (String soldname,string snewname), renaming: The name used to modify the binding of an object name.
· Namingenumeration listbindings (String sname), listing: Returns a list of the names of the properties specified by the binding in a particular context, returning the name, class, and object itself, for applications that need to actually manipulate the object. The specific use is as follows:
Get a reference to the initial directory environment
Context cntxt = new InitialContext ();
Returns a list of the names of the attributes specified by the binding in a specific context
Namingenumeration namenumlist = ctxt.listbinding ("Cntxtname");
Loop list all names, classes, and objects
while (Namenumlist.hasmore ()) {
Binding BND = (Binding) namenumlist.next ();
String sobjname = Bnd.getname ();
String sclassname = Bnd.getclassname ();
Get the Object
Someobject objlocal = (someobject) bnd.getobject ();
}
· The Namingenumeration list (string sname) is similar to Listbindings (string sname), except that it returns a series of Name/class mappings, mainly for context browsing applications. 2.4 Jndi Operation Steps
Use Jndi to access the naming service or directory service, as follows:
(1) Establish a hash table (hashtable) that contains the attributes that define the Jndi service that you want to use, the LDAP server IP address that you want to connect to, and the port that you are working on.
(2) Add any information related to authentication as a user login to the hash table.
(3) Create the initial context object. If you access the naming service, you use the InitialContext class, and if you access the directory service, you use the InitialDirContext class.
(4) Perform the desired action (such as adding a new entry or search entry) using the context object that you just obtained.
(5) Close the context object after completing the operation. 2.5 The type of object the Jndi allows to store
The biggest feature of Jndi is the ability to use LDAP to store objects that need to be shared between different applications or left behind for backup. Jndi allows the following kinds of Java-related object types to be stored in the LDAP server.
(1) Serialization of Java objects. This is the ability to store and retrieve a serialized Java object. This means that the Java object to be stored must implement the Referenceable or Serializable interface class, otherwise the object cannot be stored.
(2) A standard LDAP directory entry. It provides the ability to manipulate standard catalog data. Standard catalog data has a smaller amount of data and can be shared among different languages. Keeping catalog data independent of programming languages is important for large businesses that are developing in several different languages.
(3) A pointer to the RMI Java object. RMI is used for distributed computing, and through RMI, a Java application can call a remote class method as Local. We can store a reference to an available RMI class on the developer's LDAP server without having to maintain the registration of the methods available on every computer that has an RMI client application installed. 2.6 Jndi Storage Query serialized Java Objects
The primary goal of Jndi is to read/write Java objects on the network. Here's a concrete example to see how to use Jndi. First, we will explain how to save the serialized Java Object Data in LDAP, and then use an example to illustrate how to query and invoke the saved object data.
1. Save data
Saving data in LDAP means adding a usage entry to the LDAP server, which is to bind the entry to the server. Let's start with a basic class and then use Jndi in another class to bind the base class to the server.
4 Example 6-1 saves data in LDAP.
(1) Basic classes to be bound
package Jndi;
import java.io.serializable;
Public class persons implements Serializable {
String Name = "";
String age = "";
Public persons () {
}
constructor, which is used to assign a value to a variable
Public Persons (String namepara,string age) {
Name = Namepara;
Age = age;
}
Value to return the variable name
Public String GetName () {
return Name;
}
Value used to return the variable age
Public String Getage () {
return Age;
}
}