Dunzon of Wahid Sadik: Why would you use JNDI?

Basic Stuff

JNDI = Jave Naming and Directory Interface.
Example of similar services are: DNS, Sun NIS and NIS+, COS (for CORBA), LDAP (decedent from DAP, which ran over X.500) etc.
Taking example of DNS, we can locate a server's real location (IP) using its domain name.
JNDI enables large java application look up resources (e.g. database location, JMS server location etc.).

JNDI in a stand-alone Java application

Let's we have a 2000-class Java application.
Think about passing different resoucres to different classes. When you do that, you also have to take care of initializing, managing, scheduling, load balancing etc. issuse.
Resources we are talking about can be database connection, logging interface, configurations files, etc.
In the bootstrap of the application, we can launch a JNDI instance and plug these necessary resources against different names.
Codes, elsewhere in the application, can run a JNDI context to get a handle to JNDI, and then simply loopup objects using pre-agreed names.
Now, JNDI has different service providers, enabling access to FS,

JNDI in a stand-alone Java application

Now Consider a Java application that doesn't run the JNDI service.
No problem, just know where is the JNDI service is running, and then do how you were doing before.

JNDI Service Providers

JNDI wants to offers one-stop solution for different lookup services. So, it need service providers to do that. See one of the links for full list of SP (Service Provider).
The service providers act as JNDI service.

Examples of JNDI SP are:

JNDI Rationale

I've copy/pasted stuff from the links given in the end.

As surprising as it may seem, the notion of a card catalog is quite handy in the world of computing, as well. In computing, we call it a naming service, which associates names with the locations of services and with information. It provides computer programs with a single location where they can find the resources they need. In the way, programs don't waste time by performing the electronic equivalent of walking up and down the aisles, and don't require that the locations be hard-coded into their logic, either.
Finding resources is of particular importance in large-scale enterprise environments, where the applications you build may depend on services provided by applications written by other groups in other departments. A well-designed naming infrastructure makes such projects possible -- and the lack of one makes them impossible. In fact, many business-process re-engineering efforts begin with the design and implementation of a robust, enterprise-wide naming and directory infrastructure.

Links:

Dunzon of Wahid Sadik