Databases & Java (JDBC) - Online Article

Java is a platform independent programming language. In order to access a database with Java you need to use a platform-independent method. This is easy to accomplish, but might be quite cumbersome. Usually, you'd have to create a server program that speaks to the database of your choice and then your Java programs would need to interact with your server.

If you want to abandon your platform independence, you can always write native code to access your data. This would involve C or C++ programming in UNIX or Windows 95/NT. Without the proper tools, this can be a real headache.

So what does a programmer do when he needs data access from Java? There are several ways to get data to your application. These database access services include:

     
  • Access via Web Server. The client requests data and a CGI program talks to the database and returns the formatted data to the Java program.
  •  
  • Proprietary Server. The proprietary server knows how to talk to databases. Your Java program makes requests of this server, which in turn fulfills your requests.
  •  
  • Network Access. Network access, through the use of a class library, interacts with networked database servers. These database servers are capable of responding to direct queries from your Java program.
  •  
  • Direct Access. A direct access is also a class library that allows you to manipulate local databases. Those are databases that are on the same machine your Java program is running on.

The latest arrival onto the database scene is Sun Microsystem's own Java Database Connectivity, or JDBC. JDBC is big news and I'll get into that in a bit. But for now, let's take a closer look at these other data access options.

Access via Web Server

To access data via CGI scripts, the applet or application requests data from an HTTP server just like any other Web document. However, encoded in the CGI parameters is the database query that is to be executed. Once the HTTP server receives the request, it passes the parameters to the proper CGI program. The CGI program then performs the database query on the program's behalf.

Because this is a three step process, response time is not fantastic. But if the HTTP server is on the same machine as the application and the database, response times are better.

This option is useful for specific types of databases that cannot be moved or can only live on certain types of environments.

Of note is Oracle's WebServer product, which can access Oracle databases directly without going through a CGI program. Using the WebServer, you can embed database requests right in your HTMLpages. Once these pages are received by the Oracle WebServer, they are parsed, and recreated on-the-fly. The recreated pages include, for instance, data from an Oracle database. This seamlessintegration removes the need for a separate CGI program to access data. This is a lot faster and is a complete database solution.

Web Server Database Solutions

Here are some CGI/HTTP database access solutions available for Java:

Access via Proprietary Server

Another Java database option is going with a proprietary server. In this access mode, a non-Web server listens for service requests. Once one is received, it will perform a database query on the client's behalf and return the results to the client.

Proprietary Server Access Solutions

Here are some proprietary server database access solutions available for Java:

Network Access

Network access database solutions for Java are the best. These provide platform independence because the actual network connection and requesting is done in Java.

Network Access Solutions

Here are some network database access solutions available for Java:

Direct Access

Direct access is probably the fastest method of database access, however it is the least portable. You could possibly lose any platform independence you've gained by using Java in the first place. However, if you don't care about independence, this method of database access is by far the best performance-wise.

Direct Access Solutions

Here are some direct database access solutions available for Java:

JDBC

In an effort to set an independent database standard API for Java, Sun Microsystems developed Java Database Connectivity, or JDBC. JDBC offers a generic SQL database access mechanism that provides a consistent interface to a variety of RDBMSs. This consistent interface is achieved through the use of "plug-in" database connectivity modules, or drivers. If a database vendor wishes to have JDBC support, he or she must provide the driver for each platform that the database and Java run on.

To gain a wider acceptance of JDBC, Sun based JDBC's framework on ODBC. As you discovered earlier in this article, ODBC has widespread support on a variety of platforms. Basing JDBC on ODBC will allow vendors to bring JDBC drivers to market much faster than developing a completely new connectivity solution.

JDBC was announced in March of 1996. It was released for a 90 day public review that ended June 8, 1996. As a result of user input, the final JDBC v1.0 specification was released soon after.

The remainder of this section will cover enough information about JDBC for you to know what it is about and how to use it effectively. This is by no means a complete overview of JDBC.

JDBC Goals

Few software packages are designed without goals in mind. JDBC is one that, because of its many goals, drove the development of the API. These goals, in conjunction with early reviewer feedback, have finalized the JDBC class library into a solid framework for building database applications in Java.

The goals that were set for JDBC are important. They will give you some insight as to why certain classes and functionalities behave the way they do. The eight design goals for JDBC are asfollows:

     
  1. SQL Level API
     
    The designers felt that their main goal was to define a SQL interface for Java. Although not the lowest database interface level possible, it is at a low enough level for higher-level tools and APIs to be created. Conversely, it is at a high enough level for application programmers to use it confidently. Attaining this goal allows for future tool vendors to "generate" JDBC code and to hide many of JDBC's complexities from the end user.
  2.  
  3. SQL Conformance
     
    SQL syntax varies as you move from database vendor to database vendor. In an effort to support a wide variety of vendors, JDBC will allow any query statement to be passed through it to the underlying database driver. This allows the connectivity module to handle non-standard functionality in a manner that is suitable for its users.
  4.  
  5. JDBC must be implementable on top of common database interfaces
     
    The JDBC SQL API must "sit" on top of other common SQL level APIs. This goal allows JDBC to use existing ODBC level drivers by the use of a software interface. This interface would translate JDBC calls to ODBC and vice versa.
  6.  
  7. Provide a Java interface that is consistent with the rest  of the Java system
     
    Because of Java's acceptance in the user community thus far, the designers feel that they should not stray from the current design of the core Java system.
  8.  
  9. Keep it simple
     
    This goal probably appears in all software design goal listings. JDBC is no exception. Sun felt that the design of JDBC should be very simple, allowing for only one method of completing a task per mechanism. Allowing duplicate functionality only serves to confuse the users of the API.
  10.  
  11. Use strong, static typing wherever possible
     
    Strong typing allows for more error checking to be done at compile time; also, less errors appear at runtime.
  12.  
  13. Keep the common cases simple
     
    Because more often than not, the usual SQL calls used by the programmer are simple SELECT's, INSERT's, DELETE's and UPDATE's, these queries should be simple to perform with JDBC. However, more complex SQL statements should also be possible.
  14.  
  15. Use multiple methods to express multiple functionality
     
    There are two schools of thought on functionality. One is to provide a single entry point into an API. The programmer must then use a variety of control parameters to achieve the desiredresult. The second is to provide multiple points of entry into the API. This second school of thought was the goal of JDBC. This goal is similar to the way that the Java system was designed.

JDBC Overview

JDBC is divided into two parts: The JDBC API, and the JDBC Driver API. The JDBC API is the programmer's API. This half is where you will spend most of your time coding. The JDBC Driver API is for driver writers and database vendors to create connectivity modules for their database software. Figure 6.7 shows the complete JDBC API class hierarchy.

The JDBC API consists of many classes and interfaces. This structure makes the API a semi-abstract set of functionality. In order for JDBC to be of any use, a database vendor must fill in the blanks.

Four of these blanks will be the center of any database programming that you do with the JDBC API. These four classes are:

     
  • DriverManager - This class is responsible for managing all the available database drivers. The DriverManager class retrieves the list of available classes for drivers from the system property called jdbc.drivers. Each of the found drivers is loaded.
  •  
  • Connection - This interface defines a session between an application and a database.
  •  
  • Statement - This interface is used to issue a single SQL statement through a Connection. It owns only one ResultSet. Therefore, multiple concurrent SQL statements must be done through multiple Statements. Issuing a SQL statement while processing the ResultSet of a previous Statement will result in the overwriting of the results.
  •  
  • ResultSet - This interface provides access to the data returned from the execution of a Statement.

This short overview is only a small portion of the JDBC API. There is support for other database features such as cursors and stored procedures.

JDBC Vendor Support

Many database vendors have already pledged support of JDBC. The following is a list of vendors who plan on supporting JDBC. This list is from the JDBC Web site as of June, 1996.

Most big database vendors are on this list. If your database vendor is not on this list, fear not. There will be a JDBC-ODBC bridge driver from Sun. If your database vendor has ODBC support, then you will be in the clear.

About the Author:

No further information.




Comments

No comment yet. Be the first to post a comment.