JNDI stands for Java Naming and Directory Interface. It is an API to providing access to a directory service, that is, a service mapping name (strings) with objects, reference to remote objects or simple data. This is called
binding. The set of bindings is called the context. Applications use the JNDI interface to access resources.
To put it very simply, it is like a hashmap with a String key and Object values representing resources on the web. Often, these resources are organized according to a hierarchy in directory services. Levels are defined with separators (for example ‘.’ for DNS, ‘,’ for LDAP). This is a naming convention. Each context has its naming convention.
SPI stands for Service Provider Interface. In other words, these are APIs for services. JNDI specifies a SPI to implement directory services. Objects stored in directories can have attributes (id and value). CRUD operations can be performed on these attributes. Rather than providing a name, one can also search for objects according to their attributes, if the directory allows it. The information provided by user applications is called a search filter.
What Issues Does JNDI Solve?
Without JNDI, the location or access information of remote resources would have to be hard-coded in applications or made available in a configuration. Maintaining this information is quite tedious and error prone.
If a resources has been relocated on another server, with another IP address, for example, all applications using this resource would have to be updated with this new information. With JNDI, this is not necessary. Only the corresponding resource binding has to be updated. Applications can still access it with its name and the relocation is transparent.
Another common use is when applications are moved from a development environment, to a testing environment and finally to production. At each stage, one may want to use a different database for development, testing and production. In each context, one can make a different binding to each database. The application does not need to be udpated.
What is LDAP?
LDAP stands for Lightweight Directory Application Protocol. It is often used as a directory service in JNDI. Today, companies set LDAP server dedicated to responding to JNDI requests. A common use is to maintain a list of company employees, together with their emails and access credentials to miscellaneous application.
By centralizing this information, each application does not have to store multiple copies of employees information in their own databases, which is easier to maintain and less prone to errors and incoherencies.
What About JCA and CCI?
JCA stands for Java EE Connector Architecture. It is a Java technology helping application servers and their applications connect to other information systems, by providing them with connections to these. JCA defines its own SPI for the connector service. CCI stands for Common Client Interface. It is defined as part of JCA. It is the API user applications use to access JCA connection services.
JCA helps integrating information systems developed separately. Typically, instead of using JDBC to access databases, which is more or less equivalent to hard-coding configurations, a user application can use JCA to connect to these databases (or information systems). The JCA instance can be registered in the JDNI directory and retrieved by the user applications too.
What About Web Applications?
Typically, web applications run in containers called application servers. Web applications can create their own JNDI service to store objects, but they can also retrieve these from the container itself by using their corresponding name. In this case, the resource (often a database) is configured at the container level.