Have you ever wondered what the difference between a JDBC and a JNDI connection is? If you’re familiar with at least one of these, it’s likely that you’re familiar with JDBC (but probably not JNDI).

JDBC connections come up often in the Oracle world (for good reason). It’s a standard model/framework for designing drivers that interact with relational databases. As it pertains to us in the Hyperion, Dodeca (and even Drillbridge!) world is that we often define connections in terms of specifying JDBC parameters. This typically means a driver class name (like com.mysql.jdbc.Driver for a MySQL driver), a JDBC URL (a URL specifying a server and optionally a database/schema and other parameters), and credentials (username/password). So if you’ve poked around in your infrastructure much at all, there’s a good chance that you’ve come across a JDBC connection.

You may have even come across something called JNDI and even vaguely known it was sort of an alternate way to configure a connection but never really had to bother with it. I’ll spare you the acronym details, but think of JNDI as a way of organizing database connections (and other objects actually, but we don’t need to worry about that at the moment) such that instead of our app/system having to know the server name and credentials, it just asks “Hello, can I have the resource that was defined for me with name XYZ?”

For the application in question, the net result is much the same: a database connection is gained and the database operations are executed as normal. Consider the following diagram that compares these two ways of organizing the database resources, as it pertains to a connection we might want to make from an application such as Dodeca:

JDBC vs. JNDI connections (as it pertains to Dodeca data sources)

In the first, and most common scenario, we have a Dodeca servlet (yellow) sitting inside of a Java Application server (Tomcat in this case). Dodeca talks to its repository and asks for the details for a defined SQL (JDBC) connection (the red star, representing the connection details stored in the repository along with everything else). Given those credentials, Dodeca (the app) then makes a connection to that particular database (the red cylinder) and does whatever with it (executes a SQL query such as SELECT or INSERT). Again, this is the typical configuration scenario.

The nuance to keep in mind here is that at some point in time, the connection details, meaning the JDBC parameters such as driver class, URL, username, and password, had been specified and entered in to the app (Dodeca) and stored in it’s repository.

But what if, for some policy/organizational/legal/technical reason, the powers that be at a given organization decided they didn’t want to have these configuration details in the repository? Maybe it’s due to separation of duties, SOX compliance, or some other reason. But they might say, “You know what? We’ll define the connection for your system and you can grab a connection via its name, but won’t have access to the username/password?”. This would be an organizational situation where JNDI could be appropriate.

With JNDI, the configuration details for the database are now stored in the container itself (as noted by the red star in the green application server/container). So now, the app (Dodeca) would ask it’s parent container “Hey, can I have the connection named XYZ?” and then connect to the proper database (red cylinder) without having to know the driver, URL, username, or password.

In this case, the connection in Dodeca (or whatever the end system is) is now defined differently (and a bit more simply) as in the following:

Configuring a SQL connection in Dodeca using JNDI

Note the “DataSource” parameter with the JNDI resource name – and node that the JDBC section is empty, along with the Security section. Each container, be it Tomcat, WebLogic, or whatever, has its own way for defining JNDI resources, but in Tomcat, it might look like the following:

Configuring JNDI connection in Tomcat

The preceding is a screenshot from a configuration file for Tomcat that defines resources. The entire Resource tag is used to define the connection by giving it a name, specifying some parameters, the driver class, and any pertinent configuration details.

As I mentioned, at the end of the day, the end result is much the same: the application gets a connection to a database one way or another and operations are executed as normal. I find that the reason for using a JNDI connection is typically less technical than organizational. Specifying resources this way can also be useful if you want to let the target app use the same configuration between development/QA/environments, although given the way that Dodeca organizes connections, it isn’t an issue.