| Previous | Table of Contents | Next |
Regardless of the architecture and functionality changes to both client programs and database servers, ODBC continues to be one of the primary means of getting data to and from client programs in a client/server environment. The benefit is that security comes with ODBC’s popularity, because any data access method replacing ODBC will need to fully address the migration path off ODBC, or suffer failure and nonacceptance. It is also true that new functionality delivered by database vendors, such as the new functionality in Oracle8, will be—and is—accessible through ODBC. Although ODBC has some minor limitations, its greatest weaknesses are attributable to client/server development in general. The greatest of these is the support and configuration of individual PCs. All in all, ODBC is the primary data access method of the semitechnical user and will probably continue to be so for some time.
In effectively using JDBC, its purpose and architecture need to be examined. The following section introduces the purpose of JDBC and offers a brief synopsis of its architecture and evolution.
Java Database Connectivity (JDBC) is the industry-accepted standard Application Programming Interface (API) that enables developers using the Java development language to access data in many different formats and locations. As its name implies, Java Database Connectivity (JDBC) is similar to ODBC, because its design goals and general architecture are the same. They both access data, regardless of format or location, through a single interface. Although most access through JDBC is via SQL, there is nothing that limits JDBC from using query languages other than SQL to access data sources, as long as the data resulting from the query is returned in a format that complies with the JDBC specification.
In the summer of 1996, shortly after the Java Development Kit V1.0 specification came out, the JDBC kit was also produced by Sun. As of JDK 1.1, JDBC was a part of the specification and JDBC drivers were available for most major databases. This gave Java a true universality, because it could run on any platform, and with JDBC, could access most data sources through a non–vendor-specific interface. Currently, there are more than 30 companies making JDBC drivers to access most data sources that are available in the market today, including drivers to access ODBC data sources through JDBC. To get more information on JDBC drivers, visit www.javasoft.com.
Shortly after JDK 1.0.2 was released, Oracle made the JDBC drivers for Oracle7 available free of charge. In addition to the initial JDBC drivers, Oracle also produced two related products that greatly enhanced JDBC options for use in Internet/intranet applications: JDBC Thin and SQLJ. All the Oracle JDBC-related products currently support JDK 1.0.2 and JDK 1.1+. In addition, both Oracle7 and Oracle8 databases are supported, except the JDBC Thin driver, which supports only Oracle 7.2 or later (including Oracle8).
Although the Oracle JDBC drivers are what you would expect (JDBC functionality plus support for Oracle-specific functionality), the SQLJ and JDBC Thin products are different enough to warrant additional discussion.
JDBC Thin is one of the most exciting products for enabling “Thin Client” computing to come along to date, due to its ability to connect Java client programs to Oracle databases without having Net8 installed on the client. To achieve this, the JDBC Thin driver is written completely in Java and establishes a direct connection to the Oracle database server via a lightweight, Java sockets implementation of Oracle’s Net8 protocol. The only requirement is that the client machine support TCP/IP, which any machine that is Internet/intranet-enabled does by default.
SQLJ is another addition to the Oracle precompliers such as Pro*C for C, Pro*COBOL for COBOL, and Pro*Fortran for FORTRAN. Perhaps a better name for SQLJ might have been Pro*Java. As in other Oracle precompliers, SQLJ enables a developer to embed SQLJ statements directly into the Java code without having to know JDBC. The SQLJ program is run against the Java code and translates the SQLJ clauses into Java classes, which make the database requests via JDBC. The Java type system then assures that the SQLJ-generated classes are called with correct numbers and types of arguments. At this point, the Java code is ready to be complied with the Java compiler and run as a Java program or applet. The benefits to using SQLJ are that it performs data type checking by making the Java program call the generated classes.
Oracle precompilers are tremendously helpful in languages where the alternative to the precompiler is coding to the OCI (Oracle Call Interface—Oracle’s database API). SQLJ also has the benefit of checking the SQL at compile time, which eliminates finding any SQL errors when the Java code is run.
In defense of JDBC (which is the alternative to SQLJ in Java), the coding of SQL is not any more complicated than SQLJ, and no generated code needs to be examined when debugging code. (SQLJ generates separate Java classes to handle the SQL calls.) Additionally, in environments where multiple database vendors are used, it is probably more cost effective to have developers using a common interface such as JDBC as their data access language.
There are two major components in JDBC. The first is the JDBC API, which defined the API for Java programmers accessing the database. The second was the JDBC driver API, which defined the common interface that database vendors needed to write device drivers for so that Java could access their databases.
The following section will enable developers to understand the JDBC setup and configuration process.
For JDBC and SQLJ, there are two basic steps for installing JDBC for Oracle8; for JDBC Thin, only the second step is necessary.
The JDBC drivers for Oracle can be downloaded from the Oracle Web site free. After downloading the file, double-click on the file to unZip it and read the readme.txt file located in the directory in which you have unZipped the file. It will guide you through installing the software via Oracle’s Installer.
| Previous | Table of Contents | Next |