by Donald Bales, author of Java
Programming with Oracle JDBC
02/20/2002
Using HTTP as the communication protocol and a servlet peer for database queries, you can write a rich-content user interface applet that can dynamically interact with a database, yet remain small enough in size to perform well. In last month's article, "Dynamic Database Access from Client-side JavaScript", we looked at an architecture for utilizing the services of an applet-servlet pair to provide dynamic database access for client-side JavaScript.
There were, however, some drawbacks to this approach, the most important being the fact that this architecture leaves access to the database wide open. You can work around this issue by restricting which database objects can be accessed from the user id used to log into the database from SqlServlet, or by restricting a sub-classed version of SqlServlet to the access of a particular table; however, both of these strategies fall short of allowing you to access confidential data. Another approach is needed. We'll discuss a transparent approach shortly.
A second drawback was browser compatibility. JavaScript compatibility varies wildly from browser to browser. To work around this problem, you can simply abandon HTML and JavaScript use for your client-side GUI, and instead create a rich-content GUI using a lightweight applet. A lightweight applet is an applet designed to display a single screen. It uses HTTP as a protocol to communicate with a database through SqlServlet.
Designing an applet this way greatly reduces the size of the applet, because almost all of the classes it needs to execute already exist on the client as part of a browser's installation. All that needs to be downloaded is your custom applet and the SqlApplet classes. The typical lightweight applet is around 8K in size. Not much bigger than an HTML page embedded with enough JavaScript to produce equivalent functionality. Accordingly, I'll show you how to rewrite SqlServlet and SqlApplet so they can be readily sub-classed to create a specialized SQL servlet or lightweight applet. We'll also cover some strategies for making SqlServlet and SqlApplet secure. Then, we'll finish up with a working example.
In contrast to my previous article, we're now using an applet-servlet-database architecture, minus the HTML and JavaScript, as shown in Figure 1. In this architecture, our dynamic SQL servlet, SqlServlet, receives a SQL statement as a URL parameter, sql, executes the SQL statement, and then returns its results as tab-delimited text. SqlServlet's peer, SqlApplet, parses the tab-delimited data, making it available as a series of rows and columns.
Figure 1. Applet-Servlet-Database Architecture
We have two modifications to make to SqlServlet. The first is to move the dynamic query capability of the servlet to a protected method.
This will allow you to sub-class the servlet in order to create a specialized query servlet. A second modification is to add security to the servlet so that only authorized use of the servlet is possible. Then we have two possible modifications for SqlApplet. The first is to remove its GUI console, and the second is to make its custom public methods protected, to prevent generic use through JavaScript. Let's start from the ground up by tackling SqlServlet first.
Rewriting SqlServlet to Enable Sub-classing
You can re-code SqlServlet so that it is suitable for sub-classing by moving the code that dynamically executes a SQL statement, and returns the results as tab-delimited data, into a protected method, execute(), as I have done in Example 1. In addition, if you wish to disable generic use of SqlServlet, you can code a call to the sendError() method in the beginning of its doGet() method.
