[ Home ] [ Up ] [ Relational Databases ] [ Structured Query Language (SQL) ] [ What is JDBC? ] [ Connecting to Databases ] [ SQL Errors and Warnings ] [ Accessing Databases ] [ Creating and Populating a Database ] [ Transactions ] [ Prepared and Callable Statements ] [ Using Metadata ]

If you wish to implement Enterprise solutions, you have to be able to work with databases, so it's natural that we would like Java to talk to any and all of the major SQL databases available from a number of major vendors.

Java is intended to be portable, and to allow the same program to run anywhere. This includes downloading Java programs (applets, etc.) from various sources, including the web.

When Sun Microsystems decided to add to Java the necessary support for database access, they naturally wanted to be able to access those databases from whatever platform the Java program might be running on. In addition, they wanted to allow Java programmers to be able to write programs that could access any database and still function correctly. This was no mean feat, because database vendors have implemented many different proprietary versions of "standard" SQL, and those versions differed significantly in many ways.

Furthermore, most vendors' databases are implemented as a client/server architecture, where the client might be on a PC or a Mac, and the server (where the actual database is running) might be on a UNIX server, or some such high-powered machine. Clearly, the desire was to allow Java programs to run on any client and access any of the major databases running on whatever server was desired.

One model that already existed was that of Microsoft's ODBC (Open Database Connectivity), which was based on XOpen's model of database access. ODBC provided a standard API, and a standard subset of the SQL language (with escapes for vendor-specific functionality), ODBC introduced the concept of ODBC drivers, which could be plugged into the ODBC framework in a transparent way. ODBC drivers provided the standard API, and hid the details of the vendor's implementation from the user of ODBC.

So, Sun, in collaboration with many database vendors and customers, came up with JDBC (which Sun claims does not stand for Java Database Connectivity!). It does not emulate the exact interface of ODBC because ODBC was designed primarily for C programs, while the desire was that Java's interface to databases would be more object-oriented.

JDBC Drivers

A JDBC driver isolates the JDBC programmer from the implementation details of the vendor's database. It sits between the JDBC client and the database:

and hides the details from the JDBC client program. You can select which JDBC driver you wish to use using the JDBC DriverManager class.

JDBC Driver Types

The types of JDBC driver specified by Sun are:

1. A JDBC-ODBC bridge provides JDBC API access via one or more ODBC drivers. Note that 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. Hence, this kind of driver is generally most appropriate when automatic installation and downloading of a Java technology application is not important. For information on the JDBC-ODBC bridge driver provided by Sun, see JDBC-ODBC Bridge Driver.
2. A native-API partly Java technology-enabled 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.
3. A net-protocol fully Java technology-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. The specific protocol used depends on the vendor. In general, this is the most flexible JDBC API alternative. It is likely that all vendors of this solution will provide products suitable for Intranet use. In order for these products to also support Internet access they must handle the additional requirements for security, access through firewalls, etc., that the Web imposes. Several vendors are adding JDBC technology-based drivers to their existing database middleware products.
4. A native-protocol fully Java-enabled driver converts JDBC calls into the network protcol used by DBMSs directly. This allows a direct call from the client machine to the DBMS server and is a practical solution for Intranet access. Since many of these protocols are proprietary the database vendors themselves will be the primary source for this style of driver. Several database vendors have these in progress.

To find a list of supported drivers, see JDBC Data Access API: Drivers.

JDBC Access from Applets

It is important to note that database access from Java applets is restricted in two ways:

• An unsigned applet cannot use non-Java code, so it is restricted to JDBC driver types 3 or 4.
• An unsigned applet cannot connect to any other node than the one from which it was downloaded, so either the database has to be on that node, or there must be some kind of intermediary program on that node to handle JDBC requests and dispatch them to the appropriate database, wherever it may be.