|
Applet Design and Deployment by John B. Moore Micro-Phyla Systems Introduction Applets for database applications are a problem waiting for a solution. Pretty harsh words from someone that designs database applets for clients, but unfortunately for any serious database application of any merit, they are nothing less than a pain. Applets that have bouncing balls or such don't count as serious applications. Despite this somewhat negative statement, applets often are the only solution at a given time or place. As other technologies improve, the need for this less than optimal solution will hopefully fade away, but then maybe not! In this session we will focus on those aspects of database applet design that often result in the greatest hair loss, and that is deployment. The many other aspects of designing the applet will only be discussed within the purview of making this goal easier, more manageable, or even possible. I will not discuss the more common and trivial uses of applets that you see on the web every day, but will focus on more serious applications that require regular services and interaction from the server, either via a database or something as complex as a map server applet. The first two thirds of this paper require laying the ground work for the issues, problems, and "parts" needed to understand how to safely deploy a more complex database applet. Be patient, you will need it all in the end.
Applet Design with Deployment in Mind
Simplicity and Minimal classes Everything MUST go across that wire! Say this to yourself over and over as you design your applet. Make sure your boss/client understands this important fact, and remind them daily. Take into careful consideration the environment in which you intend to deploy this applet. Is it for general public use or Intranet use within a company? What is the connection throughput? What are the features required? What will be the target browser(s) and VM. The bottom line is that whatever you add to this applet will have to be sucked down that wire before your user can even see your applet, and users are a very impatient group of people. Try to avoid using a bit of JBCL, a bit of Swing and a bit of some other Bean components from a third party. Each of these groups of classes will bring their own dependencies that will increase the size of your archive file. Lastly, make sure the component actually works in the real world of browsers. For example, note the difference between Figures 1 and 2 below.
<Figure #1 Layout as it would appear in IDE
<Figure #2 showing problems in Layout from IDE to web browser> Showing the effect of a JBCL listbox component between the IDE viewer and deployment in a browser.
This listboxcontrol works great in the IDE viewer, but fails to function in the browser environment. This same kind of issue can haunt you with layout managers. In the IDE viewer a layout will work just fine. You then deploy the applet, and it can become unusable garbage.
Compatibility to the Lowest JDK Possible See all those neat JavaBeans on the component pallette? Try and ignore as many of them as possible. Most of them are traps that will consume hours of your time trying to get them to work in an applet. Unless you have time to burn, stick very strictly to the AWT components. As you venture into more database components, stick with one vendor to minimize complex dependencies. (A discussion of different JDK and JFC versions will be found below)
Regular Deployment is Part of the Development Cycle Deploy often to an environment that will mimic your target environment. This is the key to avoiding painful disappointments after hours of work. As a rule, I will deploy an application after every significant change to the UI or code. This requires that the design equipment often be extensive (see "Hardware needed for proper testing") Though it is possible to test deployment on a single machine in some cases, it often does not address the real issues you may face in the real world, or it may not even be possible. A personal web server often does not mimic a real web server on such things as security issues as they effect databases. For this paper I tried to get all the demos to work on a single machine. It was nothing less than a nightmare. Often times the same applet would work just fine running off a real web server, but would fail on a local environment.
Security Manager, A Major Roadblock. The Internet depends on security or it would not have grown as fast as it has grown. This is therefore very good. But for many aspects of applet design, and in particular database applet design, it is a roadblock. The Security Manager is responsible for making sure that the visiting applet can do nothing to damage the client's system. Therefore, the Security Manager will place restrictions on the following activities:
The most frustrating part of these restrictions is that they will behave differently on different browsers and between local testing and Internet testing. (Which brings us back to deploy, deploy, deploy while designing.)
Data, Databases and Drivers - The Issues Trying to design a data centric applet is usually complex and time consuming. Not only does the issue of making database connection cause problems, but the overhead of the data aware components creates its own headaches. The basic rules of the "SandBox" are that only connections back to the same server are allowed. Any attempt, intentional or otherwise, to make a local connection or a connection to a different server will throw a security exception. The solution is simple but unrealistic; just run your database server on the same machine as the web server. Since this is generally an untenable solution for most companies, there are fortunately a number of workarounds. One solution is to use a third tier that sits on the server and pretends to be the database connection while the real connection is actually on another machine. This third tier is typically called a "servlet". Another solution is to use a Class 3 driver in which the server for that driver runs on the webserver and talks to the real database that can reside on another machine. Both solutions are basically the same in that they place middleware on the web server to redirect the database calls to the real database.
To Swing or Not to Swing - The Maze of JDK Versions
When struggling to get an applet to work, one of the most common replies to your cries for help will be something about what version of the JDK you are targeting. I'll try and summarize the basic issues you will face as you decide your target JDK level. (Note: The download links for the JDKs will be found at the end of this paper under "References and Resources")
The Basics - JDK 1.0.2 If you are targeting the most universal use of your applet, this is your target JDK level. This will give you success on most any browser out there today. (I did say "MOST" not "ALL") But sadly you will be limited to the most primitive of UI and functionality. For practical purposes a database applet at this level is nearly impossible. This is often referred to as JDK 1.0.x in most discussions of earlier JDKs, where 1.0.2 is considered the final version of this line.
A Practical Compromise - JDK 1.1.x This JDK level (1.1.5 specifically) will work with the latest versions of Netscape and Explorer without any assistance of plugins (which we will get to later) and represents a barely tolerable and practical compromise between function and widespread deployment. The biggest danger here is accidentally using a bean component that needs a significant number of Swing classes, and thereby creating a "mix and match" of JDK versions. In JBuilder2 the JBCL2.0 uses look and feel classes from Swing. The deployment wizard generally does a good job of including the L&F classes, though it is a common error for many. To get full Swing functionality in JDK 1.1.x you need to add JFC 1.1.x (Java Foundation Classes, of which Swing is a significant part. See chart below) You can work around Swing deployment problems by using the swingall.jar file in your deployment, if you don't mind a 15 to 20 minute download before your applet appears. Not a good solution, and it is the typical compromise you will face: function vs. speed. Fortunately, you can use the DataExpress components at this level and it does not add any Swing classes. The NonSwing demos illustrated later in this paper, will demonstrate how much can done in keeping a db applet at this level. To summarize, this line of JDKs is frequently referred to in the literature as JDK 1.1.x: The JDK 1.1.5 is the last version the will run unassisted in a browser. Adding the JFC ( thru beta 3 version ) will require either deploying swingll.jar (as mentioned above) or the Java Plugin 1.1.1 (beta) or with JFC 1.1 the Java Plugin 1.1.2. The following table is derived from several sources: in particular, http://java.sun.com/products/jfc/jaccess-1.2.2/doc/compatibility.html illustrates some of the relationships between different versions.
If you want to use the last version of this line, download JDK 1.1.8. The early versions of the Plugin (1.1.1 and 1.1.2) can help in Intranet environments to maintain a consistent deployment and behavior, and should be considered. This consistency minimizes the need for testing multiple browsers (See the discussion of Plugins below) Currently you can only download the JDK 1.0.2 (basic AWT), JDK 1.1.8 plus JFC 1.1, and the current release Java 2 (JDK 1.2) from the main JavaSoft download page (Link found in Resources at the end of this paper) Browsers support different parts of the Java JDK specifications. The following chart illustrates what is supported by the latest version of Netscape on various platforms. (Note: I was not able to locate a similar chart for MS IExplorer)
(This chart and supporting documentation is found at http://developer.netscape.com/docs/manuals/communicator/javajdk.html)
The Latest and Greatest - Java 2 (JDK 1.2.x) With this version of the JDK we step into the world of mandatory Plugins. You now can use most all of the components on the JBuilder3 palette. But you pay a very high price for this UI heaven. Yes, the latest plugin will allow you to run these applets, but sadly they have also grown into "megabyte monsters" that take a painfully long time to download. For Intranet use, these work quite well and performance is acceptable. For Internet, use you should still restrain yourself and keep your components simple and basic.
Java Plugins
The discussion on JDKs naturally leads to the topic of Plugins and the what where and how of deploying this part of the equation. There are really three versions of the Java Plugin: 1.1.1, 1.1.2 and 1.2.1. The versions 1.1.1 and 1.1.2 are basically the same except for a critical difference. The first version is for the "beta" JFC (1.1 thru beta 3) where the swing components reside in com.sun.java.swing packages. The other (1.1.2) is for the shipping version of the JFC 1.1 classes where the packages where changed to com.sun.javax.swing. As an example of what this means in practical terms, an applet compiled and deployed in JBuilder2 will work using the 1.1.1 plugin, but will throw a verify error in the 1.1.2 plugin unless you separately install the final version of the JFC 1.1. An important note: The link trail to the download page for the 1.1.1 version appears to no longer be active, even though the download page is still in existence (Sun is hiding it because they want you to use the 1.1.2 version) The link to this page is included below in the "Resources" section of this paper.
Installation of the Plugin The Java Plugin must be installed on every client. You can see the problem already, as this is exactly the reason for using applets; to avoid this very issue. Fortunately this can be done "dynamically" from your webpage that embeds your applet. If the HTML code for your "plugin applet" was configured correctly (See HTML Converter below) the web browser will notify the client that they need a plugin, and the install process can be done by each client on a "one time" basis. Netscape and MS IExplorer each handle this differently. IExplorer is by far the best and most user friendly installation. Netscape requires the user to click the download, decide where to download the file, then run the install. Whereas Explore handles it all for you with some basic wizards that require nothing more from the user than to click a few buttons. You, as a developer, can just go to the Java Plugin link provided below and install the plugin directly. The plugin magically becomes available to both Netscape and IExplore
HTML Converter The HTMLConverter is a small utility provided by Sun that converts any applet tag to a Java Plugin tag. This is very handy and allows you to avoid reading and understanding the twenty page document that explains what this utility does for you. Having said that, even if you use the converter, do read the document, as it does help explain what all that stuff it inserts into your html document means and how it works. (See the Java Download Page link in the Resources section for a link to the HTMLConverter.) There are two converters: one for the 1.1.x plugin and one for the 1.2.x plugin. The results are identical with one exception; they each point to a different download page for the client to download the proper plugin. Therefore, make sure you use the correct converter or your clients will be downloading the wrong plugin and nothing will work.
A few Plugin GotCha's Sadly, if you are a developer and find yourself working with both plugins (as I have to) you can not run both at the same time. You will find yourself doing a lot of "uninstall/install". When trying to run the 1.2.x converter, you will find it does not work if you follow Sun's directions to the letter. (Note: Earlier versions of the HTMLConverter used an exe to start the java converter. Apparently Sun decided with the latest version to be a "purist" and only supply the classes and leave you to figure out how to run a java app in Windows) What is missing is a "." (period) in your class path. To solve the problem, edit the classpath setting in your environment to look something like: ClassPath=.;f:\Interclient\interclient.jar;..etc... where the ".;" is added to the beginning of your current classpath assignment. To setup a shortcut to run the 1.2.x HTMLConverter, use the following settings which you should alter to match your specific locations for these files. Target: F:\JBuilder3\java\bin\java.exe HTMLConverter Start In: F:\JavaPlugin12
Deployment Scenarios
Hardware Needed for Proper Testing In general it is easier to deploy an applet on a "real" web server configuration than on a "one machine does everything" configuration. Whenever possible opt for setting up a real server with the same web server software you intend to use in production. If a database enters into the picture, again mimic the real target environment. If it is one of those very rare situations where the webserver and the database server are one and the same, then you can get away with two machines. Otherwise, don't skimp as you will suddenly be faced with issues during deployment that were not completely tested. You may end up with mud on your face. The ideal minimum system is four machines: A web server, a database server, a testing client running a browser, and a dev machine running Jbuilder. The cost of the extra machines will be quickly paid for after it is realized how time consuming it is to switch between each, trying to keep everything straight as to what is really happening and why.
Basic Applet Deployment Steps The basics on deployment can be found in the help files and on information found on the Borland.com website. The following summarizes this information with additional comments from my own experience and others.
1. Add all the files you use for your project using the Add to Project button on the AppBrowser. This includes resource files (such as images or audio), documentation files (.txt or .html), and classes that are referenced using Class.byName or Beans.instantiate. 2. Use the Resource Strings Wizard to move your strings to a resource bundle. This is optional, but makes it easier to localize your applet for a different Locale. 3. Compile the applet. (Make sure you save it first. This does make a difference). I have also noticed that if you have made changes to a class file and an it does not appear to "take", that you will need to exit JBuilder and restart. Recompile one more time before running the Deployment Wizard. This has occurred with changes to driver and URL names. 4. Use the Deployment Wizard to create a Java archive. The .html files should be unselected when you deploy the main zip or jar file. Run the deployment wizard again and only select the html and check "no archive" to move this file to the target location. Important: Including the JBCL image resources in a stand-alone archive is critical for applets that use JBCL controls. Extract the images from the JBuilder archive and add them to yours, preserving their case and location. (Extract them to the root directory, and your zip tool will capture the whole path and case structure for you, removing the root directory name.) 5. Copy the archive created in Step 4, or all the compiled Java, image, and multimedia files used by your applet (or the archive you created in Step 4) to the target server. It is better to send the output of the Deployment Wizard directly to the target directory. 6. Ensure that the HTML applet tags which start your application will work from within the server's directory structure, and that the CODEBASE, CODE and ARCHIVE tags are all assigned correctly. CODEBASE as a parameter to the APPLET tag is really misunderstood. It basically states where /dev/home/myapp/files/web/java would be stored in: /dev/home/myapp/files/web/java/borland/jbcl/control/GridView.class. Note: Your archives do not have to be in the CODEBASE directory if you use a relative directory to point at the archive, one that is relative to the CODEBASE directory. If you just specify the file without any directory, then it does need to be in the CODEBASE directory. CODEBASE set to " ", ".", or "./" means "current directory" relative to the HTML file. If this is what you mean, then you can skip the CODEBASE parameter entirely. (Warning! Different web servers appear to interpret the CODEBASE differently. Test it first.) 7. Copy the HTML files containing the applet tags to the server. Again, you can do this with the Deployment Wizard by only selecting the .html file and checking "no Archive". Then set the output directory to your root web directory. 8. Optional: If users need to have certain Java classes or archives already installed on their machine, you may need to provide a convenient means for them to download those files and add them to their local CLASSPATH.
Local Testing Issues The biggest issue with testing locally is the tendency for your applet to try and load class files via the local Classpath. The only way to avoid this is to remove all classpaths from your environment while testing on a local webserver
A Simple Applet
It is always good to start of with a simple case to illustrate the core steps in deployment. This applet is so simple as to give you a false sense of success. Be forewarned: it gets much harder, but the basic steps will be the same. Up to this point in this paper, the theory and basic preliminary setup information has been provided. Now that knowledge must come to bear on the real struggle of deploying a real applet. Hold on to your seats!
Applet Design Design a very basic applet with two text fields, a button, and associated labels. ONLY use AWT components. Your Applet will look something like shown in Figure 3:
<Figure #3 Screen capture of basic applet>
Code added to the applet to give it some simple functionality to concatenate two strings and place the result in a label.
void btnConcat_actionPerformed(ActionEvent e) {
FinalText.setText(FirstText.getText()+" "+SecondText.getText());
}
The core HTML for that applet.
<APPLET>
CODEBASE="."
CODE="deploy.basic.BasicApplet.class"
NAME="BasicApplet1"
WIDTH="400"
HEIGHT="300"
HSPACE="0"
VSPACE="0"
ALIGN="middle"
ARCHIVE="BasicApplet.zip"
</APPLET>
Deployment The first step in deployment is to follow the basic steps outlined in the previous section. Then attempt to load your html page via a webserver. Using the Personal Web server, your URL might look like;
"http://127.0.0.1/basicapplet.html"
If this returns an error or does not load, then some investigation is required. NoDefClassNotFound is one of the most common errors, and means that either the deployment was incomplete, or some other problem that is being hidden by this error. The next step is to attempt to run your applet in the applet viewer.
The AppletViewer Test Step 1 - Nuke the ClassPath - This requires a minimal classpath be defined in your environment. (This effectively eliminates the classpath. Remember browsers don't have classpaths.)
"set classpath= "
Step2 - Gather the Pieces - The next step is to get the HTML document and the zip or jar file that you deployed into the same directory along with a copy of the appletviewer (found in the \Jbuilder\java\bin directory) Step 3 - Test it - Then run the applet with the following command line at the console commandline from the root HTML directory. Typically, Jbuilder places the HTML document in the "myclasses" subdirectory. Therefore that should be where you test the applet in this example.
"AppletViewer BasicApplet.html"
Step 4 - Don't Panic - If it does not run correctly in this environment, it is then clear that something is being either deployed incorrectly/incompletely, the html codebase is wrong, the applet tag is wrong, you followed the directions wrong, or it simply is not your day (an amazingly common problem). Review all the steps outlined above. Often it is the simplest of things that get missed.
Text Database Applets - Three flavors
There are three ways to design this applet that will affect how it is deployed and the problems that will be faced in attempting to successfully run each in a browser. Part I will be a non-Swing version (or at least as non-swing as we can make it), in which only AWT beans will be used along with the DataExpress beans. Part II will be a hybrid version in which we will explore the JDK version switching (1.1.8) and creating and adding a new library (JFC 1.1.x in this case) and using swingall.jar. Part III will use whatever we want from Java 2 (JDK 1.2.x) on the palette and will require the 1.2.x Java Plugin. (See the discussion on Plugins above.) Each will have it's own headaches and issues, so this gives a great opportunity to explore each set of issues with a fairly simple demo.
Text Database Applet, Part I AWT Version
Applet Design The basic approach in this first version is to stick very strictly with AWT components. Using panels, textfields, labels, and buttons from the AWT palette, the layout will look like Figure 4.
<Figure#4 Basic Layout of AWT components>
Making AWT db-Aware The basic task here is to make these basic components db aware. For expediency I have created two methods to handle this chore: setFields() and browseRecord(..). If doing this for a larger project, it would be better in the long run to subclass these components. The DataExpress beans, TextDataFile and TableDataSet are used. Since our focus is on the deployment, I leave it to you to study the provided code for how this was wired to the edit fields.
Deployment From the deployment angle none of what has been used in this demonstration will cause problems running in a browser that supports JDK 1.1.5. The basic steps outlined above should suffice. On the up side, this version deploys quite easily following all the steps outlined above. I noticed that on the Personal Web Server, that for some strange reason, the web server wanted to see the IISSamples directory as the location for the Textdb.txt file. I could find nothing to explain this anomaly. The lesson here is that if at first it does not succeed, move it somewhere else. Logic does not always prevail in the world of applets. On the down side, a lot of code had to be written to handle what the JBCL or dbSwing handles for you natively. In addition, the UI is primitive and you will more than likely spend a lot of time explaining, for example, to your user/customers why that particular request for a dropdown picklist cannot be provided.
Text Database Applet, Part II JDK 1.1x Version
Applet Design An applet is designed with two elements: a navigator and a gridcontrol. Using the instructions given in the Jbuilder help, create a text file and schema file. (There is a small demo application in the subdirectory "exportdata", included in the files for this paper). Don't get creative and add anything else, as even this very simple design will be a challenge to run. Figure 5 shows the very basic layout used.
<Figure #5 Basic Layout of Applet>
No additional code beyond the code needed to load the text database, was added to this design so as to keep the issues as simple as possible.
Deployment The problems faced with even this simple design are many. First the navigator has images on each button, and if you "really" want them you will have to work for them. The Deployment Wizard doesn't pick up the images needed by the JBCL control. What you can do is to look at jbcl3.0.jar, find the images, extract them, and put them in your JAR file with the same directory and file names as found in jbcl3.0.jar. NavigatorControl uses getResource() to load the images. Unfortunately, getResource() is broken in Netscape's Java 1.1 VM, so even then, depending on your VM, it may not work. For purposes of this demo, we will check the property that turns these buttons to Text Only. In the IDE, a standard path to this file will work just fine, but unfortunately over the web, this is a show stopper. Therefore, we have to enhance how the applet uploads the text database because direct loading of the file is not possible. The needed code is as follows:
try {
urlFile = new URL(this.getDocumentBase(),textdbstr + ".txt");
urlSchema = new URL(this.getDocumentBase(),textdbstr + ".schema");
isFile=urlFile.openStream();
isSchema = urlSchema.openStream();
}
catch(Exception ex){
System.out.println("Error on OpenStream ");
ex.printStackTrace();
}
try {
textDataFile1.load(tableDataSet1, isFile, isSchema);
textDataFile1.setFileName(textdbstr+".txt");
}
catch (java.io.IOException exio) {
System.out.println("Error on IO of Textfile");
exio.printStackTrace();
}
catch (com.borland.dx.dataset.DataSetException dbex) {
System.out.println("Error on DatasetLoad");
dbex.printStackTrace();
}
Next, the grid control and the navigator now have inheritance dependencies to Swing; in particular the LookandFeel classes. Find the "commented" lines for the static intializer of the UIManager. Uncomment the LookandFeel you desire. This will insure that the Deployment Wizard will see the dependencies and include the proper swing classes in your archive. The code will be as follows: static {
try {
//UIManager.setLookAndFeel(new
javax.swing.plaf.metal.MetalLookAndFeel());
//UIManager.setLookAndFeel(new
com.sun.java.swing.plaf.motif.MotifLookAndFeel());
//UIManager.setLookAndFeel(newcom.sun.java.swing.plaf.windows.
WindowsLookAndFeel());
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
}
catch (Exception e) {}
}
Lastly, will be the issue of using the proper JDK version and insuring that all of these changes get deployed correctly. First things first: the correct JDK and JFC need to be installed. JDK Switching Now we begin the fun part-switching to the correct JDK and JFC. Following are the basic steps needed to switch the JDK to a version so that the applet will run in a browser that supports the 1.1.5 JDK.
Compiling Once you have installed the alternate version of the JDK and JFC library, re-compile your project. Then run the Deployment Wizard and on the second page turn off the javax selection. On your HTML page, archive tag, add your applet jar file along with the swingall.jar. Make sure you have no spaces between anything so it looks like:
ARCHIVE=yourapplet.jar,swingall.jar
My version of Netscape (4.6) crashed more often if I left the spaces in the above archive. It still may crash a few times, so expect it. The last step is to test your applet. All of the basic steps outlined above still apply, so don't miss a step. Once you are ready to test it, type in the URL of your applet web page, and then go have lunch. It should be loaded by the time you get back. Other Notes Obviously, if you really need to use this applet, the download time over a modem is prohibitive and time will need to be spent trimming down the swingall.jar. I did not explore this further, so I leave that pain and anguish to you. If this is an Intranet system, the download will not be as bad, and you can deploy the swingall.jar file to all of the client machines. But then, if you need to do this, why are you using applets??? On occasion the error "cannot create dependency" has occurred in the above process. You can ignore it. Another option is to have a copy of JBuilder2 around for developing applets at this level. The swing is not so tightly involved in this version, and personally, I had better luck creating tighter and smaller downloads.
Text Database Applet, Part III Java 2 (JDK 1.2) Version This final version would require the latest version of the JavaPlugin (1.2.x). Review the notes on plugins and download and install this version. Design Change nothing from the previous applet. Just point it back to the JDK 1.2 in Projects|Properties.
Deployment Don't bother. It won't work, even with the correct plugin. Why? You will get one or both of the following errors.
# Verifier error
javax/swing/SwingUtilities.doPrivilaged(
Ljava/lang/Runable:)V:
Cannot find class java/security/PrivilegedAction
This error means that one of the classes needed something in the core Java classes that was not there. Core Java classes are either on the client as part of the browser or part of the delivered JRE. Hence, if they can't be found, those are the only two areas you can change. Sadly, the plugin is the only choice for the browser. If you can get past this one, you will get..
Opening
http://www.somewhere.com/com/borland/jbcl/
control/ResTable_en_US.class
java.lang.ClassFormatError: com/borland/jbcl/
control/ResTable_en_US (Bad magic number)
Normally a ResTable class error is just informational and will not crash your applet. Unfortunately, as of this writing there is a bug in the the JavaPlugin 1.2. What should happen when resources are requested, is that Java searches from the most specific to the lest specific. In this case having not found this resource by language and country, it will then look for it by country. If not found, the most generic version which is Res.class is loaded. At this point, it should just merrily go on with the rest of the applet. The current 1.2 plugin is not doing this, and crashes with a ClassFormatError. The "Bad magic number" error is apparently bogus. (This refers to the first series of bytes in a .class file that the verifier checks. It spells out CAFEBABE, and if not present the verifier will deny the class.) If and when this gets fixed, this applet should work just fine (fingers are crossed).
Database Applet
The problem with the text database is that it is a textfile that can not be updated or changed from the applet (due to security restrictions of writing files back to a server). One solution to this would be to run a servlet on the server to write the file for you. But if you going to all that trouble maybe you need to use a real database. This next applet will use Interbase and Interclient to create such an applet.
Design Keeping to the pattern of a very simple design for these demos, the exact same design is used for this applet as was used for the first Text Database applet. Also, for simplicity of deployment, and so we can focus only on the issues of getting Interbase and Interclient talking properly, we will also stick strictly to AWT beans.
Deployment The only tricky part of deploying this applet was making sure that the URL to the database made sense from the perspective of the applet. It was tested both to the local Interbase and to a full Interbase installation on a website. The local installation required the URL:
dbLocal.setConnection(new com.borland.dx.sql.dataset.ConnectionDescriptor( "jdbc:interbase://127.0.0.1/d:\\ibdata\\employee.gdb","SYSDBA", "masterkey", false, "interbase.interclient.Driver"));
The remote connection that worked from any client on a real webserver was:
dbRemote.setConnection(new
com.borland.dx.sql.dataset.ConnectionDescriptor("jdbc:interbase:
//www.microps.com/e:\\ibdata\\employee.gdb","sysdba", "masterkey",
false, "interbase.interclient.Driver"));
Generally, when testing, it is a good idea to keep the loading of the applet and the loading of the data as separate events. To this end, the queryDataSet was opened in a button after the entire applet was finished loading. After the issues of the database loading correctly are resolved, it is easy to delete the button and switch the query to open on instantiation. Though it was not the case with Interclient, many database drivers are not seen properly by the deployment wizard. The error "no suitable driver found" can be frustrating. To solve this, remove the driver part of the ConnectionDescriptor and add a separate instantiation of the driver as follows.
interbase.interclient.Driver driver = new
interbase.interclient.Driver()
dbRemote.setConnection(newcom.borland.dx.sql.dataset.
ConnectionDescriptor("jdbc:interbase://www.microps.com
/e:\\ibdata\\employee.gdb","sysdba", "masterkey", false, ""));
Leave the driver parameter blank in the connection descriptor. The last issue that may bring things to a halt is firewalls. Drivers like InterClient make socket connections through a specific port. For Interbase and Interclient you will find the following lines in Windows services file:
gds_db 3050/tcp # InterBase Server interserver 3060/tcp # InterBase InterServer
The access to this port in the communication of the applet with your server must be available. Map Server Applet Design Unlike strict database applets, serving maps to a client is considerably easier. Some data is exchanged but is kept very simple and streamed as text and parsed and loaded into list and choice boxes. Since there is no input besides selection of choices and simple strings only AWT components could be used. Of all the applets used in this paper this, one is the most complex, but ironically was the easiest to deploy with respect to Java. The map server for this applet was ArcView Internet Map Server (AV IMS) from ESRI, and was designed for The Omega Group Inc. as part of their CrimeView application software. The basic design was broken into two components: the embedded applet housed the map, and related tools for manipulation of that map. All of this functionality was provided by AV IMS's MapCafe (Figure 6).
<Figure#6 - Layout of GIS Applet>
The second component was provided by dialog boxes that allowed the user to do analysis within selected parameters and retrieve maps based on those selections. One such dialog box is illustrated in Figure 7.
<Figure #7 - Dialog entry from Applet>
Deployment Deployment of this application required the coordination of the AV IMS map server ArcView and the web server. AV IMS was run on its own machine, and connected to the web server via a dll web extension provided by ESRI in the IMS package. The applet also communicates back to IMS via this web server extension. Deployment of all three pieces involves configuring each connection and running separate tests for each of those connections. From the applet side, it involved talking to the ISAPI dll via the HTTP protocol. Because this is such a basic and common protocol, the only issue was insuring the syntax of the communication was consistent and that the dll was functioning properly. The down side was that all the communications had to be coded with extensive parsing routines, both in and back. Fortunately, Java contains many helpful methods that made these tasks quick and easy to develop.
Final Thoughts Hopefully I have sobered you enough, that the real issues and the difficulty that will be encountered in database applet development is clearly apparent. It is not for the faint of heart, or the easily frustrated. As new technology comes on line, it will hopefully become less and less necessary to subject oneself to this trial. One bright light I see is the new AppServer recently released by Inprise. I see this as a solution to "applet applications" where the clients are known and controlled. If you must walk this applet road, you have my sympathy. Email me and I will join you in a good cry, share some suggestions that sometimes work, and the solace of knowing that others share your pain and frustration. Good Luck!
Acknowledgments
This paper would not be a fraction of what it has become, without the advice and council of Richard Wilkman at Borland. Rich is the applet master we go to when times are rough, and the JDK's are confusing, and the Error messages make no sense. I can't thank him enough for his assistance in preparing this paper and presentation.
References and Resource Rich Wilkman's "The Java Curmudgeon" http://we.got.net/~rwilkman/java/index.html
Sun's Applet Page http://java.sun.com/applets/index.html
Java Plugin pages MainPage http://java.sun.com/products/plugin/index.html Plugin1.1.1 http://java.sun.com/products/plugin/1.1.1/plugin-install.html
Java Download Page http://java.sun.com/cgi-bin/download2.cgi
Inprise Tech Documents on Deployment http://www.inprise.com/jbuilder/papers/techdoc/index.html
Applet Security http://java.sun.com/security/codesign/
Jbuilder Technical Papers |
