Java Database Connectivity or more popularly JDBC, acts as a translator between Java applications and the native language of a database. The database is the server, feeding information to the client on every SQL request. The client, on the other hand is the application written in Java, which is firing the SQL request to the database server. Now, this flow of information must follow a certain model to systematically transact the information. Let’s see how the JDBC driver paves the way into the application design consideration of database programming in Java.
JDBC drivers fit into four distinct categories. Each has a specific purpose and properties of its own. They are elaborated as follows.
Type 1 or JDBC-ODBC Bridge Plus ODBC Driver
ODBC driver is a database vendor independent driver and can be used to connect multiple databases. JDBC driver leverages its versatility and speaks with ODBC, which in turn speaks with the underlying database. This means, once JDBC passes the request off to the ODBC driver, it is the responsibility of the ODBC driver to communicate with the database. As obvious, JDBC driver has no knowledge of the actual database it is communicating with. It is advantageous in the situation where no native JDBC database driver is available. But this advantage is also its drawback, it adds another layer of complexity and can make the process of isolating bugs difficult in our program.
Fig1: JDBC-ODBC Bridge Architecture
If we write a standalone application we can simply load the JDBC-ODBC bridge and install the ODBC driver on the client machine. But if we are building a network application where our client counterpart seeks to access the local files, the standard security will not allow access to the locally installed native libraries needed to complete the database connection. For these situations JDBC-ODBC driver is not a viable solution.
Type 2 or Native API Partly Java Driver
These drivers are absolutely vendor specific. That means each database we opt to connect must have a separate driver, because they use native API libraries to communicate with the database. The native API is supported by CLI (Call Level Interface) libraries. On JDBC request, actual communication is established by this library. The driver simply translates the JDBC request to the native method call to CLI. After the request is served, the result is translated back in the reverse order, native format to JDBC and ultimately to the client application. Native library adds cohesiveness and inflexibility, but makes it faster than JDBC-ODBC bridge, because JDBC directly interacts with the native routines; there is no broker or middle layer here for the communication to go through.
Fig2: Native API Partly Java Driver Architecture
Type 2 drivers are always recommended over Type 1 drivers. All major database vendors ship their database with Type 2 native drivers. Like Type 1, Type 2 is also not a very viable alternative for network applications either.
Type 3 or JDBC Network All Java Driver
This is a three-tier driver, which involves a third server that acts in between the client and the database server. This driver combines the feature of Type 1 and Type 2. In Type 1 we need to load the ODBC driver locally on the client and in Type 2, the native libraries (CLI) are located on the client. In Type 3, CLI libraries are located on the remote server, the JDBC driver is divided into two parts. One part is downloaded to the client and the second part of JDBC, located in the server, communicates with CLI which in turn communicates with the database. Thus, communication from client to server is all Java to Java through a network protocol interface. Unlike Type 4 ‘All Java’ has a different connotation here – the JDBC driver at the client side translates the client request into a driver specific network protocol, which then sends the request to the listener process on the server. The remote server process acts as a proxy for the client. The listener process hands over the request to the CLI to get a response from the database. This shift of responsibility has some specific advantages.
- Client no longer needs to bother about database specific protocols
- Client no longer needs to download a portion of the driver that communicates with the database native libraries
- Security issues are no longer a concern as found in Type 1 and Type 2 drivers.
Fig3: JDBC Network All Java Driver Architecture
However, the main problem with Type 3 drivers is in the use of non-standard network protocol, which is bound to the database vendor. Using one vendor’s driver on the client and another vendor’s driver on the server will not work. Also, there is a compatibility issue due to the difference of versions as well. But still, the advantage of this driver far outweighs Type 1 and Type 2 drivers. This driver is appropriate and absolutely suitable for network application unless we can find the Type 4 drivers.
Type 4 or Native Protocol All Java Driver
This is absolutely a pure breed of Java driver. With no CLI, communication is pretty straightforward. JDBC completely handles the communication responsibility with no in between translation necessary. Eliminating the major disadvantages of its legacy, this driver greatly simplifies database access. However, Type 4 driver requires native database protocol to be rewritten especially in the case of already existing databases, so they be may be unavailable or may take a bit longer to develop than other types of drivers.
Fig4: JDBC Native Protocol All Java Driver Architecture
Inherently, client-server model is at least two-tier. In the case of JDBC programming, the database application is the client and the DBMS is the server. Two-tier applications are mostly standalone, where the client interface is either GUI or CUI. Type 1 and Type 2 drivers are suitable for creating two-tiered JDBC applications. Some advantage of creating two-tiered JDBC applications are.
- Simple to implement
- Eliminates considerable overhead by maintaining a persistence connection
- Works faster
Three or more tiered applications are in vogue now due to the demand of online JDBC applications. This model separates the database server from the web/application server. Client requests are routed through a proxy server. This not only creates a clean and secure environment but also minimizes ripple effect of changes made in any other tier in the scenario.
The choice of the type of driver plays a crucial role. But to start JDBC programming, it doesn’t make much difference what underlying JDBC driver is used. Java code written for database programming is all the same for every driver unless a very low level, database specific operation is involved. However, the choice becomes crucial in view of performance, compatibility, driver availability and the programming model to be used.