About Database Adapters

About Sun Adapter for JDBC/ODBC

This topic provides information about Sun Adapter for JDBC/ODBC.

About Java Database Connectivity (JDBC)

Java Database Connectivity (JDBC) is an implementation of the Java programming language that dictates how databases communicate with each other. Through a standardized application programming interface (API), connectivity from database management systems (DBMS) to a wide range of SQL databases is accomplished. By deploying database drivers laced with JDBC technology, it is possible to connect to any database -- even in a heterogeneous environment -- and access tables, tabular data, flat files and more. When using JDBC, Java programmers have the ability to request connections to a database, send queries to the database using SQL statements, and receive results for advanced processing.

JDBC Drivers

To connect with individual databases, JDBC requires drivers for each database. Those drivers come in four varieties. Driver types 1 and 2 are typically intended for programmers that write applications. Driver types 3 and 4 are typically used by database and middleware vendors. The various driver types are described in the following sections:

Type I: JDBC-ODBC Bridge

This combination provides JDBC access via ODBC drivers. ODBC binary code--and in many cases, database client code--must be loaded on each client machine that uses a JDBC-ODBC Bridge. A product called SequeLink from Data Direct Technologies provides a driver that supports some ODBC drivers (for example Microsoft Access).

Type one drivers provide JDBC access via one or more Open Database Connectivity (ODBC) drivers. ODBC, which predates JDBC, is widely used by developers to connect to databases in a non-Java environment.

Pros: A good approach for learning JDBC. May be useful for companies that already have ODBC drivers installed on each client machine— typically the case for Windows-based machines running productivity applications. May be the only way to gain access to some low-end desktop databases.

Cons: Not for large-scale applications. Performance suffers because there’s some overhead associated with the translation work to go from JDBC to ODBC. Doesn’t support all the features of Java. User is limited by the functionality of the underlying ODBC driver.

Type One Driver

A JDBC/ODBC bridge provides JDBC API access through one or more ODBC drivers. Some ODBC native code and in many cases native database client code must be loaded on each client machine that uses this type of driver.

The advantage for using this type of driver is that it allows access to almost any database since the database ODBC drivers are readily available.

Disadvantages for using this type of driver include the following:

Type II: Partial Java driver

This type of driver converts JDBC calls into calls on the client API for Oracle, Sybase, Informix, DB2, or other DBMS. Note that, like the bridge driver, this style of driver requires that some binary code be loaded on each client machine.

This type of driver converts the calls that a developer writes to the JDBC application programming interface into calls that connect to the client machine’s application programming interface for a specific database, such as IBM, Informix, Oracle or Sybase.

Pros: Performance is better than that of Type 1, in part because the Type 2 driver contains compiled code that’s optimized for the back-end database server’s operating system.

Cons: User needs to make sure the JDBC driver of the database vendor is loaded onto each client machine. Must have compiled code for every operating system that the application will run on. Best use is for controlled environments, such as an intranet.

Type Two Driver

A native-API partly Java technology-enabled driver converts JDBC calls into calls on the client API for DBMSs. Like the bridge driver, this style of driver requires that some binary code be loaded on each client machine. An example of this type of driver is the Oracle Thick Driver, which is also called OCI.

Advantages for using this type of driver include the following:

Disadvantages for using this type of driver include the following:

Pure Java driver for database middleware

This style of driver translates JDBC calls into the middleware vendor’s protocol, which is then translated to a DBMS protocol by a middleware server. The middleware provides connectivity to many different databases.

This driver translates JDBC calls into the middleware vendor’s protocol, which is then converted to a database-specific protocol by the middleware server software.

Pros: Better performance than Types 1 and 2. Can be used when a company has multiple databases and wants to use a single JDBC driver to connect to all of them. Server-based, so no need for JDBC driver code on client machine. For performance reasons, the back-end server component is optimized for the operating system on which the database is running.

Cons: Needs some database-specific code on the middleware server. If the middleware must run on different platforms, a Type 4 driver might be more effective.

Type Three Driver

A net-protocol fully Java-enabled driver translates JDBC API calls into a DBMS-independent net protocol which is then translated to a DBMS protocol by a server. This net server middleware is able to connect all of its Java technology-based clients to many different databases. Many mainframe legacy non-relational databases use this kind of driver.

Advantages for using this type of driver include the following:

The disadvantage for using this type of driver is that it requires a separate JDBC middleware server to translate specific native-connectivity interface.

Type Four Driver: Direct-to-database pure Java driver

This style of driver converts JDBC calls into a network protocol that sends the converted packets--in a proprietary format--to be used directly by DBMSs, thus allowing a direct call from the client machine to the DBMS server and providing a practical solution for intranet access. This type of driver has become very popular recently and is supported by most database software vendors. All JDBC drivers from Data Direct Technologies (driver vendor) are Type 4 drivers.

Pros: Better performance than Types 1 and 2. No need to install special software on client or server.

Cons: Not optimized for server operating system, so the driver can’t take advantage of operating system features. (The driver is optimized for the database and can take advantage of the database vendor’s functionality.) User needs a different driver for each different database.

A native-protocol fully Java technology-enabled driver converts JDBC technology calls into the network protocol used by DBMSs directly. This allows a direct call from the client machine to the DBMS server.

Advantages for using this type of driver include the following:

The disadvantage for using this type of driver is that each database will require a driver

About the JDBC/ODBC Adapter

The JDBC/ODBC Adapter enables the Sun Java CAPS ESB system to exchange data with external databases. Sun Java CAPS ESB contains many database Adapters. You should use those Adapters to interface with the databases they support. The JDBC/ODBC Adapter should only be used when you have a driver or a database that is not supported by those Adapters.

The JDBC/ODBC Adapter uses Java Collaborations to interact with one or more external databases. By using a Java Collaboration Service it is possible for Sun Java CAPS ESB components such as Adapters to connect to external databases and execute business rules.