Top 25 Java Naming And Directory Interface (JNDI) Interview Questions You Must Prepare 19.Mar.2024

  • A large no. Of machines can have a common list of login users.
  • Reading accesses and responsiveness is fast.
  • LDAP can be used to cluster when failover occurs.

Netscape's API is LDAP-specific. It is used for low-level access to LDAP directories. It exposes details about the protocol that applications typically do not need to know. 

HotJava Views 1.1 is using JNDI to access LDAP.

Enterprise APIs such as 

  1. Enterprise JavaBe
  2. Java Message Service
  3. JDBC 2.0

make use of JNDI to for their naming and directory needs.

RMI over IIOP applications can use JNDI to access the CORBA (COS) naming service.

Naming services map objects with names. It maps a reference to an object by a user friendly name. For example a machine maps its ip address. The association of an object with a name is called ‘binding’. Examples : Domain Naming Service, File systems.

All naming operations are relative to a context. The InitalContext implements the Context interface and provides an entry point for the resolution of names.

JNDI provides a standard API for interacting with naming and directory services using a service provider interface (SPI), which is analogous to JDBC driver. To connect to an LDAP server, you must obtain a reference to an object that implements the DirContext. In most applications, this is done by using an InitialDirContext object that takes a Hashtable as an argument: 

Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL, "ldap://localhost:387");
env.put(Context.SECURITY_AUTHENTICATION, "simple");
env.put(Context.SECURITY_PRINCIPAL, "cn=Directory Manager");
env.put(Context.SECURITY_CREDENTIALS, "myPassword");
DirContext ctx = new InitialDirContext(env); 

JNDI is also used to lookup resources like a database or a message queue. With JNDI you get a uniform way to access directory services.

java:comp/env/ejb/MyBean: This is a logical reference, which will be used in your code.

ejb/MyBean: This is a physical reference where an object will be mapped to in a JNDI tree.

The logical reference (or alias) java:comp/env/ejb/MyBean is the recommended approach because you cannot guarantee that the physical JNDI location ejb/MyBean you specify in your code will be available. Your code will break if the physical location is changed. The deployer will not be able to modify your code. Logical references solve this problem by binding the logical name to the physical name in the application server. The logical names will be declared in the deployment descriptors (web.xml and/or ejb-jar.xml) as follows and these will be mapped to physical JNDI locations in the application server specific deployment descriptors. To look up a JDBC resource from either Web (web.xml) or EJB (ejb-jar.xml) tier, the deployment descriptor should have the following entry: 

<resource-ref>
<description>The DataSource</description>
<res-ref-name>jdbc/MyDataSource</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref> 

To use it: 

Context ctx = new InitialContext();

Object ref = ctx.lookup(java:comp/env/jdbc/MyDataSource); 

To look up EJBs from another EJB or a Web module, the deployment descriptor should have the following entry: 

<ejb-ref>
<description>myBean</description>
<ejb-ref-name>ejb/MyBean</ejb-ref-name>
<ejb-ref-type>Entity</ejb-ref-type>
<ejb-link>Region</ejb-link>
<home>com.MyBeanHome</home>
<remote>com.MyBean</remote>
</ejb-ref> 

To use it: 

Context ctx = new InitialContext();
Object ref = ctx.lookup(java:comp/env/ejb/MyBean); 

  • At the time of creation of the databases, the existing LDAP will receive the database server instance and the database information is provided to the LDAP directory after the creation of the databases.
  • The catalog information for the server can be retrieved for the directory of LDAP, at the time of the client’s connection to the database.
  • The catalogue information need not be stored locally on each machine for the clients.
  • The LDAP directory will be searched by the client applications for the needed information in order to connect to the database.

To centralize the information storage the enterprises uses LDAP. The information is of user names, passwords, email addresses, printers, determination of database access. Multiple database management is reduced by centralizing the information.

XFN is X/Open Federated Naming, a C-based standard for accessing multiple, possibly federated naming and directory services.

A programmer familiar with XFN will find it easy to use JNDI. 

At the time of this writing, IBM, Novell, Sun, and WebLogic have produced service providers for JNDI.

A Java CORBA application can use JNDI to access to the CORBA (COS) name service, as well as other naming and directory services.

It offers the application one interface for accessing all these naming and directory services. 

Using JNDI also paves the way for Java CORBA applications to use a distributed enterprise-level service like LDAP to store object references.

JNDI provides an excellent object-oriented abstraction of directory and naming. 

Developers using JNDI can produce queries that use LDAP or other access protocols to retrieve results; however, they are not limited to LDAP nor do they have to develop their applications wired to LDAP. JNDI supports the key capabilities in LDAP v3.

Lightweight Directory Access Protocol Developed by the University of Michigan.

It is a protocol for locating organizations, individuals, and other resources such as files and devices in a network, whether on the public Internet or on a corporate intranet.

JNDI stands for Java Naming and Directory Interface. It provides a generic interface to LDAP (Lightweight Directory Access Protocol) and other directory services like NDS, DNS (Domain Name System) etc. It provides a me for an application to locate components that exist in a name space according to certain attributes.

A J2EE application component uses JNDI interfaces to look up and reference system-provided and user-defined objects in a component environment. JNDI is not specific to a particular naming or directory service. It can be used to access many different kinds of systems including file systems. The JNDI API enables applications to look up objects such as DataSources, EJBs, MailSessions, JMS connection factories and destinations (Topics/Queues) by name.

The Objects can be loaded into the JNDI tree using a J2EE application server's administration console. To load an object in a JNDI tree, choose a name under which you want the object to appear in a JNDI tree. J2EE deployment descriptors indicate the placement of J2EE components in a JNDI tree. The parameters you have to define for JNDI service are as follows:

  • The name service provider class name (WsnInitialContext for WebSphere application server).

    Hashtable env = new Hashtable();

    env.put(Context.INITIAL_CONTEXT_FACTORY,"com.ibm.websphere.naming.WsnInitialContextFactory"); 

  • The provider URL :
  • The name service hostname.
  • The name service port number. 

env.put(Context.PROVIDER_URL, " iiop://localhost:1050");
Context ctx = new InitialContext(env); 

The Java ADSI package allows Java programs to access Active Directory based on the COM model.

Although it can be used to access other directories, it is a Windows-centric solution. 

JNDI offers Java applications, regardless of whether they're running on Windows or accessing Active Directory, to access directories using the Java object model. 

For example, you can manipulate objects such as AWT and JavaBe components, bind them into the directory, and look them back up without having to do any trlation or deal with data representation issues.

LDAP stands for Lightweight Directory Access Protocol. This is an extensible open network protocol standard that provides access to distributed directory services. LDAP is an Internet standard for directory services that run on TCP/IP. Under OpenLDAP and related servers, there are two servers slapd, the LDAP daemon where the queries are sent to and slurpd, the replication daemon where data from one server is pushed to one or more slave servers. By having multiple servers hosting the same data, you can increase reliability, scalability, and availability.

  • It defines the operations one may perform like search, add, delete, modify, change name
  • It defines how operations and data are conveyed.

LDAP has the potential to consolidate all the existing application specific information like user, company phone and e-mail lists. This me that the change made on an LDAP server will take effect on every directory service based application that uses this piece of user information. The variety of information about a new user can be added through a single interface which will be made available to Unix account, NT account, e-mail server, Web Server, Job specific news groups etc.

When the user leaves his account can be disabled to all the services in a single operation. So LDAP is most useful to provide "white pages" (e.g. names, phone numbers, roles etc) and "yellow pages (e.g. location of printers, application servers etc) like services. Typically in a J2EE application environment it will be used to authenticate and authorize users.

Different directories have different ways of dealing with security. 

JNDI allows for applications to work in conjunction with directory-specific security systems. In the future, JNDI-based applications will be able to take advantage of any single sign-on mechanism developed for the Java platform.

Searching for files and directories done by providing Directory services. A directory service is a set of names. The user and resource information and machine addresses are summarized by directory service. For example, for a given user name, the service returns the attributes of the user such as telephone no, email address etc. A directory service use the databases that specialized and hierarchical in design.

Searching for files and directories done by providing Directory services. A directory service is a set of names. The user and resource information and machine addresses are summarized by directory service. For example, for a given user name, the service returns the attributes of the user such as telephone no, email address etc. A directory service use the databases that specialized and hierarchical in design.

JNDI itself is independent of any specific directory access protocol. Individual service providers determine the protocols to support.

There will be provider implementations for popular protocols, such as LDAP, NDS, DNS, and NIS(YP), supplied by different vendors. 

Any Java application that needs to access information about users, machines, networks, and services. User information includes security credentials, phone numbers, electronic and postal mail addresses, and application preferences. Machine information includes network addresses, machine configurations, etc. In addition, any Java application that needs to either export objects or access objects exported by other applications and services. Examples include printers, calendars, and networked file systems.

JNDI is a generic directory API for Java programs. It is analogous to the java.io.File class for accessing files. 

There might be some administrative programs that need to manipulate a file at the protocol level (such as NFS), but typically all Java applications use the File class to access to file system. 

Similarly, most Java programs should use JNDI to access directories. 

Applications that need to manipulate directory content at the protocol level may choose to use Netscape's API.

In general LDAP servers and RDBMS are designed to provide different types of services. LDAP is an open standard access mechanism, so an RDBMS can talk LDAP. However the servers, which are built on LDAP, are optimized for read access so likely to be much faster than RDBMS in providing read access. So in a nutshell, LDAP is more useful when the information is often searched but rarely modified. (Another difference is that RDBMS systems store information in rows of tables whereas LDAP uses object oriented hierarchies of entries.) . Key LDAP Terms:

  • DIT: Directory Information Tree. Hierarchical structure of entries, those make up a directory.
  • DN: Distinguished Name. This uniquely identifies an entry in the directory. A DN is made up of relative DNs of the entry and each of entry's parent entries up to the root of the tree. DN is read from right to left and commas separate these names. For example 'cn=Peter Smith, o=ACME, c=AUS'.
  • objectClass: An objectClass is a formal definition of a specific kind of objects that can be stored in the directory. An ObjectClass is a distinct, named set of attributes that represent something concrete such as a user, a computer, or an application.
  • LDAP URL: This is a string that specifies the location of an LDAP resource. An LDAP URL consists of a server host and a port, search scope, baseDN, filter, attributes and extensions.
  • LDAP schema: defines rules that specify the types of objects that a directory may contain and the required optional attributes that entries of different types should have.
  • Filters: In LDAP the basic way to retrieve data is done with filters. There is a wide variety of operators that can be used as follows: & (and), | (or), ! (not), ~= (approx equal), >= (greater than or equal), <= (less than or equal), * (any) etc.