JDBC Architecture

JDBC is designed using a two-tier approach. It's a unified and standard API used by all J2EE applications and components to access databases through a provider-specific driver. Such clean separation of application logic and database-specific environment helps an enterprise application to be portable and reusable across multiple databases.

Figure 9.1 illustrates the layered approach of the JDBC architecture. An application client uses a unified JDBC API to access one or many databases, even in a heterogeneous environment. Many of the database products provide JDBC drivers, including Oracle, SQLServer, DB2, Sybase, PointBase, Cloudscape, Hypersonic, Postgres, and mySQL.

It's possible that clients and components across all the J2EE tiers can access the database through the JDBC API (see Figure 9.2). However, it's recommended in practice that JDBC connections should be near to the data source itself. This implies that components in the EJB-tier are encouraged to use the JDBC to connect to databases. This not only enhances the security aspect of your enterprise applications, but it also increases their portability. Moreover, EJBs provide built-in mechanisms for transaction control, and placing JDBC calls in well-designed EJBs frees you from programming local transactions using JDBC or distributed transactions. Transactions will be covered in detail in Day 16.

At a minimum, JDBC assumes that all underlying database vendors support the SQL-2 database access language. Since its original inception in 1997, the JDBC specification has focused on these issues:

• Offers vendor-neutral access to common functionality that most database server vendors must implement in order to be JDBC-compliant.

• Supports advanced SQL data types (part of SQL3), such as Blobs (Binary Large Object), Clobs (Character Large Object), and arrays and their mappings, to native Java objects.

• Provides implicit support for database reliability, availability, and scalability. The Standard Extension API describes advanced support features, such as enhancement of database performance and JNDI support.

Choosing the Right JDBC Driver

Different types of JDBC drivers are available for a J2EE application's use. Two-tier drivers provide direct access to databases from a Java application. Two-tier drivers are vendor specific. Three-tier drivers provide access to databases through the middle tier, which enables you to manage database resources centrally through the application server. Three-tier JDBC drivers are vendor neutral, and make it easier to integrate off-the-shelf components to your DBMS environment and to write more portable code. Moreover, they help you to develop scalable, reliable, and available J2EE applications.

JDBC Driver Types

JDBC drivers are commonly identified by type. The following list provides a brief description of each driver type, which will help you choose a JDBC driver type that fits your application requirements:

• Type 1: Uses ODBC as the primary interface to the database. The client makes JDBC calls that are converted to ODBC by the JDBC-ODBC Bridge, which is also required on the client tier.

• Type 2: Uses a native database library as an interface to the database. The client makes JDBC calls that are converted to the native code through a JDBC-native driver. The native library is a proprietary API, such as OCI (Oracle Client Interface). This driver type is normally used for high-performance and large transaction volume requirements.

• Type 3: This is a multitier, vendor-neutral driver. No driver is required at the client tier. Clients make JDBC calls through the network (RMI calls) to the JDBC driver that resides in the middle tier (application server tier).

• Type 4: This is an all-Java driver. Clients make JDBC calls directly to the database. Because it's a native Java driver, it performs according to the underlying Java Virtual Machine (JVM). It's the most frequently used JDBC driver type.

Figure 9.3 depicts these drivers in a multi-tier approach.