Typical Uses of JDBC

You can make design choices between options that offer different qualities and drawbacks based on the targeted user community. To help you evaluate the pros and cons of each choice, this section and the section “ODBC versus Specific Drivers as a Subprotocol,” later in this chapter, explore different scenarios and show what is the best solution to address their problems.

Applets

You can use JDBC from within applications as well as from applets. Java’s initial fame was its use of applets downloaded from the Internet. Although the types of application are virtually unrestricted, there are still a few matters to consider for applets.

The differences between applets and traditional applications can be summarized as follows:

• A distrusted applet cannot access local files or open arbitrary network connections to remote hosts without using a browser proprietary security manager interface to request such access. An application accesses the local file system according to the permissions granted the user.

• A distrusted applet cannot easily rely on specific facilities provided or located in the underlying operating system, such as a local Registry, to locate a database. Applications often rely on such facilities; for example, Open Database Connectivity (ODBC) uses an .ini file or the Registry, and most proprietary APIs use specific properties files. Using property files is common for Java applications.

• Using applets, response times to download the necessary classes and JDBC driver may be arbitrary when traffic peaks arise on the Internet. In addition, using non-Type 4 drivers necessitates the local installation of native libraries. For this reason, using a full Java Type 4 driver from within an applet is the most appropriate choice.

• Making applets available on the Internet provides no way to estimate the maximum number of simultaneous database connections that may be established at the same time.

• Applets may be restricted to using the HTTP protocol via a Web proxy to communicate with a database server. This is especially the case when a firewall is in place and allows only HTTP traffic to go in and out through a Web proxy. In such cases, it is preferable to let the applet communicate with a server-side component such as a servlet using HTTP and to execute all databases access from within this servlet.

As Figure 5-4 shows, an applet is highly dependent on components that aren’t present in the traditional fat-client scenario. Communication channels are used for both the download of classes and for query data and result set transmission.

Figure 5-4: An applet communicating with a server.

These differences aren’t necessarily serious drawbacks. Indeed, it is neither necessary nor preferable for applets to look in local files to find out about a database’s server name, IP address, and so on. Complicated connection information may be provided, using parameters passed to the applet from within the HTML page, so the users won’t have to handle long and cryptic URLs to open the JDBC connection. This kind of information can be pushed to the client.

Applets in three-tier architectures

Another approach to using JDBC from within applets is the three-tier architecture, in which a server actually uses JDBC to perform the calls to the database. This approach solves a number of the applet’s common problems. Eventually, the applet makes a connection to the middle-tier server and requests or calls an action on a particular object using Remote Method Invocation (RMI), for example. This request triggers a conversation between this middle tier and the database management system. In this case, connection information such as database identification may be excluded from the applet’s code. Figure 5-5 depicts such a three-tiered architecture.

Figure 5-5: Three-tier design.

Note 

Java 1.1’s RMI provides an HTTP-tunneling feature that enables RMI communication to go through firewalls and Web proxies. (A java-rmi.cgi program is available in the bin subdirectory of the Java 1.1.x distribution.)

Rich-client applications

Java standalone applications are suitable within intranets and are deployable to specific users across the Internet, provided that those users are allowed to make use of distribution products such as Marimba Castanet. These applications run trusted code and are allowed to access the local file system and open network connections to arbitrary hosts, just as normal applications do. Figure 5-6 represents the parts of a standalone application.

Figure 5-6: The parts of a standalone Java application.

Thin-client applications

A final approach that requires only a Web browser on the client side is more and more seen as the most flexible solution. Thin-client applications are made of pure HTML pages or WML pages generated by server-side components. The entire functionality of these applications is provided through the Web interface, while servlets and Java Server Pages (JSPs) integrate with databases and dynamically generate the pages.

In such cases, JDBC runs only on the server side. The type of JDBC driver used in this approach is totally independent from the browser’s platforms. Another advantage is that the database integration logic may serve different types of devices because servlets can easily produce HTML at first and then XML, WML, or Palm Web Clippings without needing to rewrite the entire database access logic.