JDBC stands for Java Database Connectivity. It is a specification and application programming interface (API) of the JavaSoft division of Sun Microsystems Inc. and was implemented to allow developers to program applets or applications in the Jav a language, without having to worry about database-specific code. It was released in May 1996, and helped to standardize the growing selection of a very important class of Java tools that allow database access from Java applications.
Java has been called "the vehicle by which developers will be able to bring dynamic application behavior to the Web" . Users can download applets from either local or remote Web servers for execution inside popular Web browsers such as Netscape Navigat or. Applets run disconnected from the server, just like native applications. Java however, has fallen short of its widely ability to connect to outside resources via a build-in API. The first release of the Java Developers Kit (JDK) in early 1995 had no i ntegrated support for accessing databases. The functionality of Java made it easy to build tools for accessing databases, but there was no prescription about how such drivers ought to function. Several vendors produced good tools for database access but t here were no general guidelines for how database access tools should be written.
JavaSoft responded with the first release of the JDBC specification in May, 1996. The advent of JDBC means an end to those shortcomings mentioned. JDBC provides a vendor-neutral, universal framework for vendors to use in building tools that allow clien ts to access databases. The JDBC specification itself is just a collection of interfaces and abstract classes that each vendor must implement to write a JDBC-compliant driver. JDBC promises to database-enable any Java applet or application. It is included in the java.sql.package, which will be part of the Java Developer’s Kit (JDK) version 1.1.
The JDBC API standard defines a set of Java classes required to perform standard relational database operations such as managing database connections, SQL statements, result sets, and metadata. JDBC specification has structural and conceptual similarit ies with Microsoft’s Open Database Connectivity (ODBC) driver, which Microsoft introduced in the 1980s to bring some conformity to client access to databases. It is based on the X/Open SQL Call Level Interface (CLI), the basis of ODBC. Like ODBC, JDBC giv es Java developers a common API to most relational databases, including client/server databases such as Oracle, Sybase, and Informix. The big difference is that JDBC builds on and reinforces the style and virtues of Java, and is easy to use.
JDBC sends a request to a database server using the appropriate SQL dialect and then processes the results (answer set). Using JDBC, it is easy to send SQL statements to virtually any relational database. It means that with the JDBC API it isn’t necess ary to write one program to access a Sybase database, another program to access an Informix database, another program to access an Oracle database, and so on. A single program using the JDBC API can be written, and the program will be able to send SQL sta tements to the appropriate database.
Furthermore, with an application written in Java programming language, the programmer also doesn’t have to worry about writing different applications to run on different platforms. The combination of Java and JDBC lets a programmer write it once and ru n it anywhere. Developers writing database access client applications for heterogeneous networks like being able to write one application that will run anywhere; that shortens the development process and makes application maintenance much easier than in t he traditional C/C++ world.
Like ODBC, the JDBC API uses a driver manager that simultaneously supports multiple database drivers for various databases. The driver(s) can be downloaded with the applet or exist as native drivers on the client, depending on how the security features of JDBC and Java will be implemented.
JDBC is a low-level interface used to invoke SQL commands, and it was also designed to be a base upon which to build higher-level interfaces and tools. A higher-level interface is user-friendly, and is translated into a low-level interface, such as JDB C. Later on I will mention two kinds of higher-level APIs under development on top of JDBC.
In summary, JDBC makes it possible to do three things:
The mechanism to communicate with database servers exist as standard Java classes. This ensures that the security features of Java remain and that JDBC code integrates cleanly in Java code. The JDBC API is expressed through several abstract Java interf aces that allow to link to any number of databases. The interfaces are:
The JDBC Architecture consists of two layers: the JDBC API, which provides the application-to-JDBC Manager connection, and the JDBC Driver API, which supports the JDBC Manager-to-Driver Connection.
Two models for database access are supported by the JDBC API. They are the two-tier model and the three-tier model. The last one is mentioned more generally as a multitier.
In the two-tier model, a Java applet or application talks directly to the database. This requires a JDBC driver that can communicate with the particular database management system (DBMS) being accessed. SQL statements are delivered to the database, and the results are sent back to the user.
This is referred to as a client/server configuration, in which the user’s machine is the client and the machine housing the database is the server. The database may be located on another machine to which the user is connected via a network.
In the three-tier model, commands are sent to a middle tier of services, which then send SQL statements to the database. The database processes the SQL statements and sends the results back to the middle tier, which then sends them to the user.
This model makes it possible to maintain control over access and the kinds of updates that can be made to corporate data. Another advantage of the middle tier model is that the user can employ an easy-to-use higher-level API which is translated by the middle tier into the appropriate low-level calls. The middle-tier architecture can provide performance advantages.
Database vendors support JDBC through the JDBC driver interface or through the ODBC connection. Each driver must provide implementations of java.sql.Connection, java.sql.Statement, java.sql.PreparedStatement, java.sql.CallableStatement, and java.sql.Re sultSet. They must also implement the java.sql.Driver interface for use by the generic java.sql.DriverManager interface.
JDBC uses a simple class hierarchy for database objects. The classes are contained in the java.sql.* package, which will be included in JDK 1.1. The java.sql.* classes are descriptions of classes and methods that must be written in order to produce a J DBC driver, as mentioned earlier.
Three classes relate to opening a connection to the DBMC: java.sql.DriverManager, java.sql.Connection, and java.sql.DatabaseMetaData. For accessing a database, a java.sql.Connection object has to be obtained directly from the JDBC management layer and the java.sql.DriverManager. The following is an example of the code to obtain a connection:
Connection con = DriverManager.getConnection ("jdbc:odbc:wombat", "login", "password");
The DriverManager uses the URL string as an argument, and the JDBC management layer locates and loads the appropriate driver for the target database to which the applet is attempting to link. The DriverManager does this by querying each driver, locatin g the one that can connect to the URL. The drivers look at the URL to determine if it requires a sub-protocol that the driver supports. Then, the driver connects to the remote database, returning the correct java.sql connection object that is the way by w hich the applet accesses services on the database. The JDBC management layer must know the location of each and every database driver available to it. Each driver must register with the DriverManager using the DriverManager.RegisterDrive method so that th e DriverManager knows that the driver exists and where to find it.
The DatabaseMetaData returns information about the client’s connection and interesting information about the database to which the client has connected.
The java.sql.Statement class is used to compose and execute SQL queries on the DBMS. A query of some sort, either a select statement, or an insert, update or delete statement could be performed after connecting. The results of a query are used to creat e a java.sql.ResultSet. Using the connection obtained in the example above, an example of the code for a Select statement could be:
Statement stmt = con.createStatement();
ResultSet rs = stmt.executeQuery("SELECT a, b, c FROM Table1");
while ( rs.next() ) { int x = getInt("a");
String s = getString("b");
float f = getFloat("c"); }
Stored procedures on a database can also be executed with two subclasses of java.sql.Statement: java.sql.PreparedStatement, and java.sql.CallableStatement.
Finally other JDBC classes are supplied for utility purposes. For example java.sql.Types encapsulates Java types for database use; java.sql.Date, java.sql.Time, and java.sql.TimeStamp; java.sql.Exception, and java.sql.Warning provide for exception hand ling.
JDBC drivers fit into one of the following four categories:
Because many PC-based networks already use ODBC for their C and C++ clients, JavaSoft and Intersolv (a major ODBC driver vendor) worked together to produce a JDBC-ODBC bridge, to make the transition from C/C++ clients to Java clients more appropriate. It was developed in mid-1996. They are preparing for the release of a reference implementation of JDBC that uses the ODBC interface. This is the technology that lets Java Applets use existing ODBC drivers.
In this case, ODBC acts as a mediating layer between the JDBC driver and the vendor client libraries. The bridge driver translates JDBC method calls into ODBC function calls. ODBC binary code, and in many cases database client code, must be loaded on e ach client machine that uses this driver. This kind of driver is most appropriate on a corporate network where client installations are not a major problem.
This kind of driver is a two-tier driver that converts JDBC calls into calls on the client API for Oracle, Sybase, Informix, or other DBMS. As well as with the bridge driver, some binary code must be loaded on each client machine. There is a wide range of variation between vendors in how much of the driver is Java, and how much is C/C++. This driver connects the client to the DBMS by way of the vendor-supplied libraries for the DBMS. By this fact, the need for ODBC and the ODBC-JDBC bridge is not there anymore.
The advantage of using this kind of JDBC driver is that it reduces the complexity of a client application, including development, debugging, and maintenance time. It also provides direct access to the full functionality of the database. The client libr aries are usually written in C or C++, therefore, the JDBC implementation must use a layer of C or C++ in order to make calls to the vendor libraries; their layer of non-Java code requires the use of "native methods" in Java. JDBC drivers that use native methods can’t currently be used in applets for security reasons.
This driver translates JDBC calls into a DBMS-independent net protocol which is then translated to a DBMS protocol by a server. This driver designed for a three-tier environment, work with an intermediate application server, the DBMS-independent net pr otocol, that sits between the client and the DBMS. This net server middleware is able to connect its pure Java clients to many different databases. In general, this is the most flexible JDBC alternative.
This kind of driver converts JDBC calls into the network protocol used by DBMSs directly. This pure-Java drivers make no calls to the client libraries of the DBMS, but rather communicate with the DBMS directly, using its proprietary protocol. This allo ws a direct call from the client machine to the DBMS server and is a practical solution for Intranet access.
In addition to retrieving text data, JDBC provides facilities to access binary large objects (BLOBs). This facility is convenient for moving image, video, and audio information from relational databases into Java applets or applications. JDBC will supp ort advanced database features as well, such as using scalar functions and invoking stored procedures and triggers.
JDBC provides threading, which is important for increasing performance because it allows multiple transactions on database data. Using a three-tier JDBC driver with a robust, pure-Java intermediate server will bring the added advantages of Java'’ threa d support. The client can operate as a multithreaded application and let the intermediate server handle the synchronization and waiting that results from communicating with a single-threaded client library.
JDBC is a low-level API and a base for higher-level APIs. Two higher-level APIs under development are:
1. an embedded SQL for Java. JDBC requires that the SQL statements be passed as Strings to Java methods. An embedded SQL preprocessor allows a programmer to instead mix SQL statements directly with Java: for example, a Java variable can be used in a SQ L statement to receive or provide SQL values. The embedded SQL preprocessor then translates this Java/SQL mix into Java with JDBC calls.
2. a direct mapping of relational database tables to Java classes. This is an object/relational mapping, in which each row of the table becomes an instance of that class, and each column value corresponds to an attribute of that instance. Programmers c an then operate directly on Java objects; the required SQL calls to fetch and store data are automatically generated "beneath the covers". More sophisticated mappings are also provided, for example, where rows of multiple tables are combined in a Java cla ss.
Java, being robust, secure, easy to use, easy to understand, and automatically downloadable on a network, is an excellent language basis for database applications. What was needed was a way for Java applications to talk to a variety of different databa ses. JDBC is the mechanism for doing this.
Clearly, JDBC will enable Java applets to communicate with popular relational databases and thus make Java practical for client/server development. JDBC must still address other complex issues, including handling database security on a public network, database recovery from dropped connections, and performance through a translation layer.
JDBC makes it possible to:
If you want to create Java-enabled client/server applications, JDBC should be at the top of your list for database connectivity solutions.
1. JDBC Guide:Getting Started, Sun Microsystems Inc.
2. The JDBC Database Access API, JavaSoft
4. Weblogic, Choosing a Java Database Connectivity driver, Weblogic Inc.