JDBC Concepts

Java applications using JDBC can use any of the four kinds of JDBC driver types to connect to a database such as Oracle, Sybase, or Microsoft SQL Server. These drivers are supplied by database vendors or by third-party providers. The Java application loads the driver using the DriverManager class of the JDBC API. WebLogic Server 7.0 comes with JDBC drivers for Oracle, Sybase, and the evaluation database PointBase preinstalled. You will be looking at these drivers supplied with WebLogic Server in the section "Configuring Connection Pools in WebLogic Server."

Now you will discover what these four JDBC driver types are and which driver type is best to use in certain configurations or architectures.

Type 1 Drivers

The type 1 driver is based on the two-tier model. This is also called the JDBC-ODBC bridge. Microsoft came out with its ODBC driver in the early 1990s. JavaSoft and Intersolv together first introduced the JDBC-ODBC bridge to facilitate the transition of PC-based C and C++ applications already using ODBC to Java applications.

This kind of driver is generally divided into three distinct layers on the client side. The first layer is the Java application and the JDBC API, the second layer is the JDBC-ODBC bridge, and the third layer is the ODBC driver. Figure 7.2 illustrates the layers of a type 1 JDBC driver.

Figure 7.2. Type 1 JDBC driver.

The JDBC-ODBC bridge communicates with the ODBC driver using the Java Native Interface (JNI) and acts as a translator between the Java application/JDBC API and the ODBC driver. The ODBC driver is the layer that actually interacts with the database to perform the database-specific operations. These drivers are best suited for intranet applications.

Limitations

Type 1 drivers need the ODBC driver, which is tightly coupled to Windows, to be installed on the client, thus making these drivers incompatible with non-Windows browser clients.

Applets generally cannot use type 1 drivers since they cannot load native code. Some browsers can get around this by using plug-ins.

Since this kind of driver possibly requires downloading of software onto the client at runtime, it could cause serious security hazards and can slow down the performance of the system.

Note

It is interesting to note that, as a security measure, applets can communicate only with the Web server from which they were downloaded. However, when the JDBC-ODBC bridge comes into the picture, the scene changes. Since the JDBC driver is not aware of the ODBC configuration, it is not possible for it to detect whether the database is a remote one. Hence, the Java applet using such a JDBC-ODBC bridge can access remote databases.

All the preceding limitations make type 1 drivers not very suitable for the Internet world. However, if they are to be used on an intranet, then the preceding limitations can be overlooked, depending upon your company's internal policies.

Type 2 Drivers

The type 2 driver is also based on the two-tier model. Type 2 drivers are also called native API drivers. This kind of driver, which is very similar to the JDBC-ODBC bridge client architecture, also is divided into three layers on the client side. Here the native C/C++ driver replaces the ODBC driver. Figure 7.3 illustrates the layers of a type 2 JDBC driver.

Figure 7.3. Type 2 JDBC driver.

The Java client application utilizes the JDBC API to converse with the JDBC driver. The JDBC driver contains Java code, which translates the commands into commands understandable by native C/C++ drivers. The native drivers installed on the client interact with the database to perform the various database-related functions. Like type 1 drivers, type 2 JDBC drivers use the JNI to communicate with the native API drivers. These drivers are best suited for intranet applications.

Limitations

A type 2 driver requires a native driver to be installed on the client machine; that is, in order to work, it requires native binary code to be installed and configured.

A type 2 driver uses the JNI, which depends on the Java Virtual Machine (JVM). JVMs are implemented by different vendors, making the driver platform-dependent.

Applets cannot load native code. Hence, these drivers cannot be used with applets. Some browsers can get around this by using plug-ins.

If any DBMS networking is involved, the driver may need software installed to enable this networking. An example of this is the configuration of Net8 to enable Oracle database clients to use the native Oracle Net8 drivers.

Type 3 Drivers

The type 3 driver is based on the three-tier model. This is the most flexible kind of driver. The client side consists of only the Java application using the JDBC API. The architecture here is minimally a three-tier architecture (but it can even be extended to multitier architecture). Figure 7.4 illustrates the type 3 JDBC driver architecture.

Figure 7.4. Type 3 JDBC driver.

The JDBC driver is downloaded onto the client from a middleware server. The JDBC driver converts the client application's JDBC calls into a network protocol. The driver then interacts with a server-side application installed on a middleware server, with which it establishes a connection over the network using a socket connection. This server-side application residing on the middleware server can translate the JDBC client request into the database-specific API.

This driver does not require any installation of client-side software or any native binary code. The client application is no longer limited to accessing a certain database. With a single type 3 JDBC driver installed on the client, a client can get access to multiple databases. Client applications using this driver can be ported onto any platform that supports the JVM. This makes the client application very generic.

Since the middleware server manages all the database connections, concepts such as load management, connection pooling, and multipooling can be implemented. This can result in a system with optimized usage of resources and a high level of performance. Networking options such as HTTP tunneling to pass through firewalls and pass-through servers can be used with type 3 drivers. This makes them most suitable for applications involving use of middleware servers.

The only limitation is that it may be slightly difficult to install and configure a type 3 driver.

Type 4 Drivers

The type 4 driver is based on the two-tier model. This is the simplest of all drivers in terms of the architecture. There is a Java client that uses the JDBC API. The driver on the Java client interacts directly with the database. For this, the driver uses a vendor-specific API. Figure 7.5 illustrates the type 4 JDBC driver architecture.

Figure 7.5. Type 4 JDBC driver.

These drivers are written in pure Java; that is, a driver's entire functionality is implemented as a set of Java classes with no native code included. There is no client installation or configuration involved. Also, since the type 4 JDBC driver is serializable, it becomes possible for servers to download them onto clients without any prior native driver configuration necessary. All this makes the type 4 drivers excellent in terms of performance. The underlying protocol of these drivers must take care of security and networking issues. If this is not done effectively, then the type 4 driver can result in poor performance. Also, these drivers may not be able to pass through firewalls and are most suitable when the application requires access to only one type of a database.