Brought to you by EarthWeb
ITKnowledge Logo Login Graphic Click to go to the Oscars.
Click to go to the Oscars.
ITKnowledge
Search this book:
 
Search the site:
 
EXPERT SEARCH ----- nav

EarthWeb Direct

EarthWeb Direct

EarthWeb sites: other sites

Previous Table of Contents Next


Stand-alone Applications

Stand-alone Java applications are considered trustworthy. They have full access to the local file system as does any other application. They are allowed to call native libraries and open network connections to any host.

There should be, however, one restriction. As with applets, if an untrusted sun.sql.Driver class is dynamically loaded from a remote networked source, then use that driver only with code loaded from that source.

JDBC and Untrusted Applets

JDBC follows the standard applet security model, which imposes fairly onerous restrictions for untrusted applets. In particular, JDBC uses these rules:

  It assumes that normal unsigned applets are untrustworthy.
  It does not allow applets to access to local database data such as registry or configuration files.
  If a downloaded JDBC Driver registers itself with the JDBC DriverManager, then JDBC will only use that driver to satisfy connection requests from code that has been loaded from the same source as the driver.
  It does not allow an untrusted applet to open a database connection to a server that is not the server it was downloaded from.
  JDBC does not make any automatic nor implicit use of local credentials when making connections to remote database servers.

JDBC does not encrypt the data it sends over the Internet. Indeed, JDBC is not a network protocol nor a database protocol. If connection encryption is necessary, choose a database that supports encryption in its protocol. In this case, this specific database management system’s JDBC driver will encrypt/decrypt the data as necessary.

Firewalls

Firewalls protect intranets. They simply filter incoming and outgoing connections with regard to their IP addresses and/or TCP/IP ports. A simple example is the firewall that only allows WWW, Usenet News, and e-mail to be used. It stops all packets running on ports other than 80, 119, and 25, respectively.

Actually, all connection attempts make their requests to these well-known ports. Once the connection is established, it shifts to another free port. JDBC and JDBC drivers use TCP/IP ports to communicate with database servers. The only thing to do when a firewall is present is to allow data to transit on the port used by your database protocol. The database administrator has a good idea of which port(s) are used by the database management system. So, the operation simply consists of opening an adequate door on the firewall machine.

One Hundred Percent Database Independent

In some cases, it is useful to write code that is 100 percent independent of the underlying database. Such a requirement is mandatory for programmers who develop CASE tools, data import/export utilities, or DBMS administration tools in Java.

Fortunately, JDBC is inherently 100 percent database independent. All DBMS-specific features are provided through JDBC drivers that have enough database knowledge to handle these features. The JDBC metadata interfaces are sufficiently complete to build database-independent code in Java.

In the case of applets, the name of the JDBC driver and the database URL string are passed as parameters for maximum flexibility. The only thing to change when switching from one DBMS to another is the HTML file that contains these applet parameter tags. Listing 9-1 is an example:

Listing 9-1: Passing parameters to an applet.

...
..-.
<applet code=myApplet width=500 height=600>
<param name=driver value=connect.sybase.SybaseDriver>
<param name=connection
value='jdbc:sybase://dbms.mydomain.com:8192/demodb;user=guest;
password=guest'>
...
...

The applet must parse its parameters to discover the driver to load and the database URL to use. The driver code (Java classes) does not have to be present on the client; it can reside on the server side and downloads dynamically upon execution of the applet. The code to fetch parameters from an applet, shown in Listing 9-2, is quite simple:

Listing 9-2: Getting parameters from an applet.

...
...
String driver;
String url;
Connection conn;
driver = getParameter("driver");
if (driver != null)
Class.forName(driver).newInstance();
url = getParameter("connection");
if (url != null)
conn = DriverManager.getConnection(url);
...
...

One Hundred Percent Java or Non-100 Percent Java

One hundred percent Java-based applications or applets may run on all-Java network devices such as the Sun Microsystems, Inc.’s JavaStation. Such devices are the first wave of a seismic shift in the computer industry.

JDBC is, fortunately, all-Java. Programs and applets developed with JDBC are portable, but some JDBC drivers are not portable. Indeed, all those using local native libraries are not portable, although they may be available for a variety of platforms. Furthermore, they have to be installed on a client machine before an application can use them. They cannot be downloaded automatically from the network.

The problem is that there are only a few all-Java JDBC drivers available. Others will appear quickly, but what can we do today, for example, to use JDBC within applets to connect to a poorly supported database?

The best solution is to use a middle tier. Many JDBC endorsees now develop and sell three-tier bridges to place in front of common enterprise class database management systems. Many developers offer evaluation copies, making it is easy to experiment and determine which is the right solution for your project. Another solution is to code the middle tier yourself. It is doable using Java RMI. A simple working example is provided later.


Previous Table of Contents Next
HomeAbout UsSearchSubscribeAdvertising InfoContact UsFAQs
Use of this site is subject to certain Terms & Conditions.
Copyright (c) 1996-1999 EarthWeb Inc. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.