1.Who should use JNDI?

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.

2.Can I use JNDI now?

Yes, Sun Microsystems has released JNDI as a Java Standard Extension. Sun Microsystems has also released service providers that plug in seamlessly behind JNDI for a number of naming and directory services: LDAP, NIS, CORBA (COS) Naming, and files. These and service providers produced by other vendors are available for download.

3.Who will provide implementations of JNDI?

At the time of this writing, IBM, Novell, Sun, and WebLogic have produced service providers for JNDI. We maintain a listing of publicly available service providers.

4.What protocols does JNDI provide an interface to?

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.

5.How does JNDI relate to LDAP?

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.

6.How does JNDI relate to Netscape's Java LDAP API?

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.

7.How does JNDI relate to OMG's CORBA standards for naming?

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.

8.How does JNDI relate to Microsoft's ADSI?

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 JavaBeans components, bind them into the directory, and look them back up without having to do any translation or deal with data representation issues

9.What is XFN and how does this relate to JNDI?

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.

10.What about security?

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.

11.What is JNDI ? And what are the typical uses within a J2EE application ?

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 means 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:

12.Explain the difference between the look up of "java:comp/env/ejb/MyBean" and "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:

13.What is a JNDI InitialContext ?

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

14.What is an LDAP server ? And what is it used for in an enterprise environment ?

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.

15.Why use LDAP when you can do the same with relational database (RDBMS) ?

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

16.where does JNDI fit into this LDAP ?

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:

17.What protocols does JNDI provide an interface to?

JNDI itself is independent of any specific directory access protocol. Individual service providers determine the protocols to support. JNDI supports popular protocols, such as LDAP (Light weight Directory Access Protocol) , NDS(Netscape Directory Service), DNS(Domain Naming Service), and NIS(Network Information Service), supplied by different vendors

18.What is Context and InitialContext?

A context represents a set of bindings within a naming service. A Context object provides the methods for binding names to objects and unbinding names from objects, for renaming objects, and for listing the bindings. JNDI performs all naming operations relative to a context.
The JNDI specification defines an InitialContext class. This class is instantiated with properties that define the type of naming service in use (such as provider URL, security, ID and password to use when connecting).

19.What’s the difference between JNDI lookup(), list(), listBindings(), and search()?

lookup() attempts to find the specified object in the given context. I.e., it looks for a single, specific object and either finds it in the current context or it fails.

list() attempts to return an enumeration of all of the NameClassPair’s of all of the objects in the current context. I.e., it’s a listing of all of the objects in the current context but only returns the object’s name and the name of the class to which the object belongs.

listBindings() attempts to return an enumeration of the Binding’s of all of the objects in the current context. I.e., it’s a listing of all of the objects in the current context with the object’s name, its class name, and a reference to the object itself.

search() attempts to return an enumeration of all of the objects matching a given set of search criteria. It can search across multiple contexts (or not). It can return whatever attributes of the objects that you desire. Etc. It’s by far the most complex and powerful of these options but is also the most expensive.

20.Components of JNDI?

Naming Interface- The naming interface organizes information hierarchically and maps human-friendly names to addresses or objects that are machine-friendly. It allows access to named objects through multiple namespaces.

Directory Interface- JNDI includes a directory service interface that provides access to directory objects, which can contain attributes, thereby providing attribute-based searching and schema support

Service Provider Interface- JNDI comes with the SPI, which supports the protocols provided by third parties.