![]() |
|||
![]() ![]() |
![]() |
![]()
|
![]() |
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:
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 systems 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 IndependentIn 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 JavaOne 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.
|
![]() |
|