Developing Java Enterprise Applications:What Is JDBC?

Keep It Simple

Combining database access with an application-level API often results in compromises because the natures of the languages (SQL versus Java, for example) are quite different in their design and common use. If a developer has to master and maintain applications that utilize various combinations of these languages, the whole process becomes quite complex. Emphasis on keeping JDBC simple has resulted in an API that works well with the rest of JavaSoft’s Java class libraries. Clearly, the Java philosophy as outlined in Sun’s white paper, “The Java Language Environment: A White Paper,” written by James Gosling and Henry McGilton, has been considered in the design decisions for JDBC. In order to keep JDBC simple, the designers considered the following guidelines:

Keep the common cases simple by providing specific APIs for standard activities such as selecting data using parameters. By providing methods for common cases, application programmers can write and maintain less code.

Leverage the style and benefits of the Java core classes as much as possible. By consciously keeping Java’s strengths in mind while designing JDBC, JavaSoft has created an API that application programmers can easily integrate into their Java projects. This goal is realized in the JDBC 2.0 specification, which is geared toward working with the JavaBeans component model as well as other Java technologies, such as the Java Transaction Services (JTS) discussed in Chapter 22, “Transactions, JTA, and JTS.”

Create methods that map to specific functionality rather than relying on a small API with multiple meanings based on parameter values. Rather than trying to keep the API small, it makes more sense to provide a rich API that addresses most of the database tasks with specific method calls. This approach makes it easier for new JDBC programmers to understand the use of each method. Another approach would have been to create a small API with few methods, each taking several parameters that allowed the programmer to configure the method. For example, an execute method could be used for all types of SQL calls, but it would take a parameter to specify whether the SQL call expected a return result. This would have made it easier for a programmer to learn all of the available methods but harder to learn how to use each method. For this reason, a rich API was chosen. This decision is evident in JDBC 2.0, which has a significantly larger API but methods that are relatively simple to understand and use.

Use strong, static typing wherever possible to provide compile-time checking. As part of the Java philosophy, static typing is used wherever possible so that more errors can be caught at compile time rather than run time. The challenge with JDBC is that because raw SQL can be passed to the database and then interpreted at run time, the programmer must contend with SQL being, by nature, a dynamic language. This means that data types are often determined as the result of a query at run time, so warnings and exceptions must be carefully monitored.

One of the best features of JDBC is that it allows Java programmers to quickly develop database access strategies for their applications. With a very small amount of code, a developer can create a connection to a database, query the database, and update values. JDBC even supports a transaction model so developers can make several database modifications and, if necessary, undo all of them as a single transaction. The next section looks at the architecture of JDBC that provides these services.

JDBC Architecture

The basic architecture of JDBC is quite simple. A class called DriverManager provides a service for managing a set of JDBC drivers. The DriverManager class attempts to load the driver classes referenced in the jdbc.drivers system property. You can load drivers explicitly using Class.forName(). For instance, to load the JDBC-ODBC bridge driver, call the following:

Connection con = null;
Class.forName(“sun.jdbc.odbc.JdbcOdbcDriver”);
con = DriverManager.getConnection(“jdbc:odbc:myDataSource);

Class.forName() loads the driver class. On load, the driver should register itself with the DriverManager. The call DriverManager.getConnection() looks for a registered driver that can handle the data source described by the URL that uses the jdbc: protocol and returns an object from the driver that implements the connection interface. A connection represents a session with the data source and includes methods for executing database operations. It provides information about the data source, called meta-data, which includes information about the data source structure.

The protocol used to specify the data source is in the format jdbc:subprotocol:datasourcename, where datasourcename is, in this case, the name of a registered ODBC data source, such as a Microsoft Access database or an Oracle database. The getConnection() method takes an optional username and password for registration with data sources that require these.

Typical Scenarios

There are several typical scenarios for using JDBC. These scenarios differ based on the location of the database, the driver, the application, and the communication protocols used. The main scenarios are:

• Standalone applications

• Applets communicating with a Web server

• Application and applets communicating with a database through the JDBC/ODBC gateway

• Applications accessing remote resources using mechanisms such as the Java Remote Method Invocation (RMI), discussed in Chapter 13, “Introduction to Java RMI.”

These scenarios can be grouped into two- and three-tier architectures. In a two-tier architecture, the application resides on the same machine as the database driver. The driver can access the database running on a database server. The database driver is responsible for handling the networked communication. Figure 2.1 illustrates a simple two-tier JDBC architecture. In this example, the Java application running on the client machine uses a JDBC driver residing locally. The local driver, in turn, uses a vendor-specific client library for accessing the database remotely, over the network. The Java application accesses this resource transparently, meaning that it never has to deal with network communication issues.

NOTE: The database may reside on the same machine as the application and still be considered a two-tier architecture because the application resides in a separate address space from the database. The driver must still handle the interprocess communication.

Figure 2.1 A two-tier JDBC architecture.

The three-tier architecture involves an application or applet running on one platform and accessing the database driver on another. The database driver can be accessed through a variety of mechanisms:

• An applet may access the driver through a Web server

• An application may access a remote server program that communicates locally with a database driver

• An application may communicate with an application server that accesses the database for you

Figure 2.2 illustrates a three-tier scenario in which an applet on the client Web browser accesses a server application that accesses a database behind the firewall.

By placing all the database access logic in the JDBC driver, the driver vendor handles the issues of communicating with the database and database vendor’s client library. This means you can write applications that function in a two-tier or three-tier environment with few or no changes to your code. The JDBC design allows any Java programmer to access a relational database with little or no extra skill.

Figure 2.2 A three-tier JDBC architecture.

Summary

JDBC is a standard mechanism and API for Java programs to access relational databases and other data sources. JDBC programs can send queries and updates to a data source as well as ask the data source about information regarding the data source itself or the data it contains. In order to make using JDBC simple and efficient, access to specific databases is managed by drivers that implement a common set of Java interfaces. This allows the database connectivity provider, or driver programmer, to use whatever mechanisms needed to create a high-performance database connection while making it easy for programmers to change databases without changing a lot of code. Chapter 3, “Basic JDBC Programming,” looks at the actual JDBC API and builds a simple database application.

Table of Contents