Why use JNDI for data sources_问答_开发者_运维开发者技术经验分享

Can anyone help explain why JNDI should be a preferred way to expose services such as a database / jms?

The posts I run into all talk ab开发者_C百科out the advantage of not having to load a specific driver manager, benifiting from connection pooling etc. but thats easily achievable by specifying the driver manager in a properties file and using reflection.

Connection pooling can also be achieved by wiring in the right implementation into an application bean via spring or otherwise.

So why would using JNDI be any better?

JNDI really shines when you have to move an application between environments: development to integration to test to production. If you configure each app server to use the same JNDI name, you can have different databases in each environment and not have to change your code. You just pick up the WAR file and drop it in the new environment.

Here are some other assumptions that are crucial to know when judging this answer:

I don't have access to the servers on which the code is deployed at all, except for read-only access to logs.
The person who writes and packages the code is not the same person who configures and manages the server.
Once a WAR file starts on its journey to PROD it cannot be changed again without going back to the beginning. Any testing that's done by QA on the test server must be re-done if the WAR is altered.

Perhaps you don't see this benefit because you're a lone developer who writes code on a local desktop and deploys right to production.

I think the "preferred" mechanism is the one that's preferred by the person doing the admin and configuration. As duffymo pointed out, it's crucial that the configuration be external to your deployable artifact, but otherwise, I'd say anything goes. If your sysadmin prefers using a GUI to configure JDNI entries, cool. If he/she prefers editing properties files with cssh and vi, cool too. If you're responsible for both developing and configuring/deploying your app, then that's pretty much your call. Personally, I like to keep as much implementation as possible inside my artifact, meaning that my data source and drivers live there, too.

If you're asking about technical benefits of JNDI over the alternatives, I'm not sure there are any, but you might want to clarify your question.

The real benefit of JNDI over property files comes when deploying to a clustered environment. Using property files leaves the possibility of some of the server instances having a different value. When using JNDI the same value is pushed out to all of the clustered servers by the domain controller, removing the need to copy the same property file to all of the servers (and probably restarting the server/app).

As mentioned by others JNDI for the most part is used for service location lookup but mainly for DB like resources.

Whats most annoying is that Java's LDAP API is also the JNDI API. When working with LDAP the abstractions are very very confusing. JNDI also has the disadvantage of sometimes being a single point of failure.

You can easily accomplish most of what JNDI does by using Host name aliases. That is make an alias that points MYRESOURCE to 127.0.0.1 in your /etc/hosts (or wherever it is for your env). Then in your App config use MYRESOURCE as the host name (in a jdbc url for example).

Then when you move your app to production just change the production's /etc/hosts file to point MYRESOURCE to the production resource/service (like prod database server).

The above is a way more portable smaller footprint naming directory that will work in other languages (ruby, python). It will also work with things that are not normally done with JNDI like REST services. The only annoying thing is that you will have to update your servers hosts files but this can be automated through SSH scripts.

Another area where JNDI helps:

It abstracts the lookup of resources. Normally the JNDI configuration is stored in an XML file on the application server, but it need not be. The configuration might for example be stored on an LDAP server, to make it easier to maintain centrally.

If the applications you run use JNDI to lookup what they need, you can switch from configuration files to using an LDAP server without modifying the applications. If each applications expects a properties file with a hardcoded name, you are out of luck. Imagine an enterprise with dozens of applications in production - changing them all would be a significant problem.

In other words, JNDI mainly shines for complex deployment scenarios, like:

many application servers (possibly clustered)
many different applications
centralized configuration
different server stages (test, production)

So it might seem overkill at first, but is very useful in theses scenarios. Of course, some benefits apply even for small deployments, such as the standardized configuration of DB connections.