What is the purpose of JNDI

Question

How can you realize the usage of JNDI , with an example if possible?

Sankey

You can check a personal blog post for use cases: tshikatshikaaa.blogspot.com/2013/01/… – Moral

@JVerstry +1 for pointing to an article that talks about related LDAP, JCA and CCI. – Sankey

Check out this SO thread – Preferable

Answer 1

JNDI is the Java Naming and Directory Interface. It's used to separate the concerns of the application developer and the application deployer. When you're writing an application which relies on a database, you shouldn't need to worry about the user name or password for connecting to that database. JNDI allows the developer to give a name to a database, and rely on the deployer to map that name to an actual instance of the database.

For example, if you're writing code that runs in a Java EE container, you can write this to get hold of the data source with JNDI name "Database":

DataSource dataSource = null;
try
{
    Context context = new InitialContext();
    dataSource = (DataSource) context.lookup("Database");
}
catch (NamingException e)
{
    // Couldn't find the data source: give up
}

Note there's nothing here about the database driver, or the user name, or the password. That is configured inside the container.

JNDI is not restricted to databases (JDBC); all sorts of services can be given names. For more details, you should check out Oracle's tutorial.

Cheese

So with this example in picture, how is JNDI different from placing Database names in a config xml file or a property file and then reading it from there? – Sankey

Firstly, you'd have to store the password in plain text in your config file. Secondly, if you have several apps pointing to the same database and something about the database config changes, you have to update the config in multiple places. – Cheese

well, how does JNDI help here? – Sankey

Only one place to make the changes, and the container manages keeping the settings secure for you. – Cheese

this should contain all you need to know about JNDI, whether in a J2EE context or a JavaSE context. javaworld.com/javaworld/jw-04-2002/jw-0419-jndi.html – Frication

And, if the database server changes, your app doesn't have to be affected, because the JNDI name remains unchanged. – Girvin

@SimonNickerson Hi!. I am learning about JNDI. This is a good answer, but if you notice the question "How can you realize the usage of JNDI?" then it looks unfinished. You described realization from the developer's perspective. How about the deployer's perspective? – Horst

@Horst Ignoring the deployer's perspective is the goal here. JNDI is a general interface to any number of different naming services such as LDAP or others. So the Java programmer does not know or care about the details of the server managed by the deployer. The Java programmer just assumes that some naming service will be provided at runtime. JNDI is the mediator at runtime to match the Java app to its needed object from some naming service server managed by the app deployer. Enabling the Java programmer to not know or care about the deployer's perspective is the entire point of JNDI. – Symptom

Answer 2

JNDI is a very powerful mechanism for both organizing configuration information and discovering and listening to services via using the EventContext. In JNDI you can lookup and listen to any object (not just DataSources), assuming your JNDI service provider supports it.

Of course, the only issue is actually having a JNDI service provider; the great thing about this is that it surprisingly easy to roll your own. After all you can encode any Java instance into XML using the JavaBeans XMLEncoder and XMLDecoder: you don't need to rely on running within an application server!

So what is the difference between this an having configuration files? Well, it can be much cleaner because all of your applications can get their configuration from the same place. If they need to share configuration information (e.g. database locations) then this can be defined once in JNDI. Suppose you moved database servers: you don't need to remember the gazillion config files with the location in it. You just go to the one place: JNDI.

Wongawonga

This is by far the most rounded clarification - Thank you oxbow_lakes! Btw, would you have code pointers where any Java instance have been encoded as you suggest? – Alecto

Answer 3

JNDI is an API used to access the directory and naming services (i.e. the means by which names are associated with objects). The association of a name with an object is called a binding.

A basic example of a naming service is DNS which maps machine names to IP addresses.

Using JNDI, applications can store and retrieve named Java objects of any type.

Within the context of java this can be used in configuration files where you don't want to hard-code environment specific variables.

Spring Example:

Spring context file

<bean id="WSClientConfig" class="com.example.BaseClientConfigImpl">
<property name="protocol">
    <jee:jndi-lookup jndi-name="java:comp/env/protocol" />
</property>
<property name="endpoint">
    <jee:jndi-lookup jndi-name="java:comp/env/endpoint" />
</property>
<property name="requestPath">
<jee:jndi-lookup jndi-name="java:comp/env/requestPath" />    
</property>

Tomcat context file

<Environment name="protocol" type="java.lang.String" value="https://"/>
<Environment name="endpoint" type="java.lang.String" value="172.0.0.1"/>
<Environment name="requestPath" type="java.lang.String" value="/path/to/service"/>

Lelandleler

Answer 4

JNDI allows the simplification of a resource construct into just a name. So, it's many details group into 1 for convenience/security/etc. (aka abstraction layer)

to realize: set up a properties list that corresponds to the predefined fields in the Jndi Context Interface. (these properties specify the settings for the jndi execution; but *not the search name)

Properties props = new Properties();
//field Context.INITIAL_CONTEXT_FACTORY => property name java.naming.factory.initial
    //field Context.PROVIDER_URL => property name java.naming.provider.url
props.load(new FileInputStream("*properties file*")); //prop file in this case

Context ctx = new InitialContext(props);
    Object o = ctx.lookup("*name of resource*");

ideally, a specialized function would exist to maintain a LDAP directory, DNS, etc, at your organization (so a unified single mapping set services all, reducing discrepancies)

List of JNDI Service Providers: https://www.ibm.com/support/knowledgecenter/en/SSVSD8_8.4.1/com.ibm.websphere.dtx.adapjndi.doc/concepts/c_jndi_JNDI_Service_Providers_.htm

Criminate