JDBC is a simple wrapper on SQL (Structured Query Language) and database responses (i.e., result sets) into a simple object layer. JDBC has many similarities to another standard application programming interface, Open Database Connectivity (ODBC). JDBC simply defines the interfaces that specific database vendors can implement to access their data. There are a great number of JDBC drivers available, some from the database vendors themselves and some from third parties. All of the drivers fall into one of four categories:

• Type 1 Drivers: These drivers require the presence of ODBC to access the database. A Type 1 driver merely translates the JDBC call to the appropriate ODBC call and translates the return type into the JDBC return types. Because of its reliance on ODBC, this driver requires setup on the machine that is accessing the data.
• Type 2 Drivers: Like Type 1 drivers, these drivers provide no host redirection. However, Type 2 drivers do not use ODBC to get to the database. Instead, they interface to the vendor-specific driver or database API. Typically, they do this by using Java Native Interface (JNI).
• Type 3 Drivers: A Type 3 driver uses an open protocol to communicate with the database. Type 3 drivers do not require any native code on the client, and they provide a level of host redirection. An example of this driver is the RMI-JDBC driver, which uses Remote Method Invocation (RMI) to communicate the calls and gets the result sets from the database.
• Type 4 Drivers: Like Type 3 drivers, these drivers do not require that any code be installed on the client. Unlike the Type 3 drivers, Type 4 drivers use proprietary (vendor-specific) protocols to access the database.

One of the real advantages of using the JDBC API is that you can write your data access code and then change the type of database that you are using without changing the code. Switching the type of database entails loading the appropriate driver and the initialization information, indicating which database to use. Each of the driver vendors (which may or may not be the database vendors) has the responsibility for implementing the interfaces.

Code:

Here is a simple example of loading a driver and running a simple query statement:

Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
Connection conn = DriverManager.getConnection("jdbc:odbc:integrated1", "", "");

Statement s = conn.createStatment();
ResultSet rs = s.executeQuery("Select * from id");

while (rs.next()) {
  System.out.println(rs.getString("class_name") + " = " + rs.getString("next_id"));
}

What to use JDBC for:

1. getting to relational data
2. integrating with existing systems

Although using and implementing APIs is beyond the scope of this document, we will point you to resources that address these topics in detail. For example, there are many valuable articles and Web sites dedicated to JDBC programming. Following are two sites that provide basic information and training on using JDBC.

JDBC Specification -- http://www.javasoft.com/products/jdk/1.2/docs/guide/jdbc/spec/jdbc-spec.frame.html

Tutorial on using JDBC --http://developer.javasoft.com/developer/onlineTraining/jdbc/index.html

Object-Relational Mapping (ODMG Interfaces to Relational Databases)

Many people in the industry recognize that using Java to access relational data introduces an impedance mismatch. While a straight JDBC solution is a good solution for many types of applications, some applications are better suited to a model that does not deal with result sets and raw data. A better solution for these applications employs business objects that represent domain entities and encapsulate the data access and business logic. This encapsulated business-object approach fits well for many distributed and transactional applications. Because most data is stored in a relational database, many companies have produced object-relational mappers to access the data in this object-oriented fashion.

Of course, you can do this object-relational mapping by hand. That is, you can use JDBC to access your database, create your domain-specific business objects, and set the properties on these objects yourself. However, this is often a tricky process that involves much redundant code and the difficult task of managing the cache of objects that have been previously retrieved from the database. Nonetheless, many software products are coded this way.

If you prefer not to do this by hand, object-relational mappers are designed to make your relational database look and feel like an object database. Because these products are all relatively new, there are not any standards for the way the data is accessed or the API's appearance. These products use JDBC to communicate with a database, but they provide an object-based interface and object return types when accessing and storing data. They also track which objects have been changed and need to be stored in your database

Because of the lack of standards, and because these are all third party components, we will not discuss how O/R Mapping APIs work nor provide an example. Rather, this discussion was included to alert you to the fact that this interface does exist, and that Javasoft considers O/R Mapping to be an essential piece of the enterprise Java toolkit.

What to use an o/r mapper for

1. 1.building object based systems
2. 2.dealing with legacy data as smart business objects rather than raw data

For more information:

A sampling of O/R vendors can be accessed at the following links

http://www.javasoft.com
http://www.oop.com
http://www.objectmatter.com
http://www.watershed.com
http://www.thoughtinc.com
http://www.objectpeople.com
http://www.softwaretree.com

Task