Building a commercial-quality Web application in Java

A small company explains what it learned while developing
software to support Netscape's AppFoundry program

If you wonder how well Java holds up as a development language for commercial-quality apps, you'll likely want to hear about our recent experience. As a participant in the Netscape AppFoundry program -- which was unveiled September 9, see the Netscape press release, for details -- our company, DTAI, created a business application designed to let intranet users view and update dynamic company organization charts via a Web browser. We created this full-blown application exclusively in Java, and in the process learned quite a bit about the strengths and limitations of the language. What follows is an account of our project and the lessons we learned.

DTAI's interactive Org Chart application is unique among the AppFoundry applications in that it is the only one developed exclusively in Java. Most of the other AppFoundry applications were developed primarily in HTML and JavaScript. DTAI chose Java because of the need for a high-degree of interactivity and graphics, including drag-and-drop capabilities, and drill-down navigation of complex organizational diagrams.

Our assignment

DTAI got involved with the AppFoundry project early and secured an assignment. Our task: develop a Company Org Chart application exclusively with Java and JavaScript, and use LiveWire Pro where possible. See the sidebar "

Working with Netscape

" for complete background on the project and its parameters.

Challenges

The AppFoundry schedule was aggressive, to say the least. For most, development began in mid June. The first Alpha delivery was scheduled for mid-July, and the final product was due in mid-August. Moreover, developers were asked to take advantage of the

new features

in Netscape's most recent releases and

beta

software. These products inevitably were not proven and often inadequately documented.

DTAI spent much of the first two or three weeks trying to find out what new products like LiveWire Pro and Netscape Enterprise Server would do for us. Initially, we had decided to save the Org Chart data files to a relational database running on the server. LiveWire Pro provides solutions to help you write server-side JavaScript to connect to a database. We had to scrap this initial design, however, when we learned that LiveWire Pro did not support a Java-to-database connection directly. (JavaSoft's JDBC should eventually solve this sort of problem. (See the May 1996 JavaWorld article "Integrating Databases with Java via JDBC" for details.)

After examining our database requirements, we determined that the database for the Org Chart would be simple enough to implement using an ad-hoc, flat-file solution. We decided to write a Java-based database server for the Org Chart. We developed a Java application that would listen for Socket connections from clients (Java applets running in a browser), and then respond to requests to read and write records within a file resident on the Web server's file system. (We used the generic client-server classes I wrote about in the September 1996 JavaWorld article, "Generic client-server classes.") This worked pretty well. We used Java's file IO classes and, for the most part, the application was portable to multiple operating systems, including Unix, Windows 95, and NT.

Executing the server

The database server application should be running constantly -- like an HTTP server, for example -- but this kind of operation usually requires that system files be modified to start the application at boot-up. And if the application dies unexpectedly, it typically requires intervention by the system administrator. This seemed like too much hassle for such a simple application, so we took a different approach:

  • First, the applet would attempt to connect to the database server, assuming the server was already running.
  • If the server was not already running, the applet would attempt to load a CGI program on the server, using a Java URL and the openStream function to cause the program to be executed.
  • The CGI program would set up the environment and then execute the server.
  • The applet would then attempt to connect to the server, trying once per second until some maximum number of attempts is reached. (The connection usually succeeds within one attempt.)

One trick to this was that the CGI program had to finish executing, or the URL connection in the browser would not complete and the application would hang. The solution for Unix was to start the Java database server application in a background process. No problem.

Enter Windows NT

We had another requirement. We had to support server solutions for both Unix (initially Solaris) and Windows NT. The biggest hurdle related to the NT port that we had to overcome was in "backgrounding" the database process. With Unix, we took for granted the fact that background processes and foreground processes are handled identically by the operating system. Windows NT, however, does not treat background processes as "first class citizens." There are no tools for backgrounding a process. No simple shell symbols, or function calls. We dug out the Advanced Windows textbooks and put together a small program (included with the Org Chart distribution) that takes a command line with arguments and executes that command in a new process "without a console" (that is, in the background).

It worked, but still had the downside that there are no tools included with the standard Windows NT distribution to locate and/or kill the process if necessary. The Windows NT Resource Kit (sold separately) supplies some Unix equivalents to "ps" to find the process, and "kill" to terminate it. Not nearly as good as their Unix counterparts, but they do the job. Third-party vendors also supply Unix commands and shells for NT. Rebooting the system also works. :-)

The CGI program also had to be rewritten for NT. In fact, we never could get Netscape Enterprise Server to execute a ".CGI" file using the PERL.EXE program. And Perl is not as portable as some people claim. Many of the functions that I had used in the Unix version (including "fork" and "exec" of course) simply were not implemented in the Win32 version. That's one of the reasons I believe Java still has a good chance to replace Perl as the language of choice for CGI programming (not to mention the fact that Perl script is completely incomprehensible).

Netscape server-side Java

Netscape is starting to support Java as a CGI alternative. Netscape Enterprise Server supports Java plug-in applications, known as Netscape Server Applets. We took a look at this technology as another potential solution to the Java-based database application, running it directly within the server. We had no problems running the simple example Java server applets, but when we tried configuring our database application as a server applet, the HTTP daemon on Windows NT crashed. Additional perusal of some of the Netscape-based newsgroups on Java confirmed that others had similar problems configuring complex Java applications as server applets. This feature sounds promising, but probably has a way to go before it is ready for prime time.

Write once, run anyhow

As required, our final version of the Org Chart ran successfully on Windows NT and Solaris servers, and Windows 95 clients. Unfortunately (and this is probably not news to most Java enthusiasts), the AWT components don't behave identically on all platforms. Worse yet, some implementations of the Java Virtual Machine (JVM) and/or the Java library are more robust than others. Windows 95 is now my platform of choice for Java development because it gets the most attention by Java tool developers. Under Windows 95, I can develop and test with a high degree of confidence that my Java application is going to run as designed.

The Org Chart application makes extensive use of the Java library. It pushes the envelope of Java implementations. Although it runs flawlessly (at least from what I have seen) on Windows 95, as a standalone application, or within Netscape 3.0, it can have problems on other platforms. The Org Chart uses pop-up dialog windows for viewing and entering employee information, for instance. The applet works fairly well under HP and Solaris, but Motif-based Java implementations like these still have poor implementations of the Dialog window object, causing distracting screen flashes, and window navigation problems. Netscape reported that the applet portion of the Org Chart would not even run under MacOS, and ran incredibly slowly on a Silicon Graphics machine (a machine not usually associated with the phrase "a snail's pace").

Here is a word of caution: Inconsistencies in the graphical user interface implementations will be problematic if you don't test your applet on all platforms. For instance, in Windows 95 and NT, the AWT button always has a gray background. In one example, we set the background color of the panel encompassing several buttons to black. We left the foreground color black (the default) because black contrasts well with the gray button backgrounds. On Unix, however, the buttons inherit the background color from the parent panel, making the text unreadable in this scenario.

I can't promise that there are no bugs, but the Org Chart applet does not appear to use any questionable features or techniques. I'm convinced that there are not enough "large" Java applications out there yet to stretch the testing procedures for current JVM and Java library implementations. Hopefully, more applets like ours, with source code if possible, will start to be made available to Netscape, Microsoft, Sun, and others so that we can eventually stop coding workarounds to their bugs. Org Chart can run as a standalone application, as well as an applet. This should be encouraging to PDA and Network Computer developers, as a strong implementation of the JVM should have no problem running the Org Chart.

Netscape promises to address the JVM failures, and I am told that they will be looking at the Org Chart applet to see what needs to be done to get it to run correctly on all platforms. We will also be looking for workarounds for the time being. I have submitted a number of bug reports to Netscape. If these kinds of bugs irritate you as much as they do me, I encourage you to submit your own report. I imagine that Netscape is more likely to respond to reports that come in quantity.

The delivery

DTAI made every deadline despite the problems. Some of the other developers had a more difficult time, having taken the path of JavaScript and LiveWire Pro. As we evaluated this option ourselves, in the early phases of the project, we noticed that the beta software that was available for the JavaScript/LiveWire Pro implementation had a number of "undocumented features". For this reason, among others, Netscape actually slipped the launch date of AppFoundry by a few weeks. This gave Netscape the chance to help the developers, and probably fix some of their own problems. As a side benefit to DTAI, the schedule slip gave us the chance to add some features of our own, making the Org Chart GUI more intuitive, the display more configurable, and the included examples more visually appealing.

The final version for AppFoundry was delivered mid-August and is now available from the Netscape AppFoundry Web site for download. Java developers may want to download the software just to take advantage of the numerous example classes.

Conclusion

DTAI is committed to Web technology for the corporate intranet, because we believe that it is the future. Open standards, like HTML and Java in particular, promote ingenuity and technological advances. Think about it. If it is not necessary to mandate the Intel PC in the office because software is based on architecture-neutral standards, someone is going to invent a completely new computing solution that can still perform to the levels required in the corporate office.

AppFoundry was a great opportunity for DTAI. It pushed us to expand our knowledge of Java and the tools available. And it also pushed us to develop some of our own tools, which already have been of use on a number of other Java projects.

As I continue to stretch my Java implementations to the limits, I am often frustrated to find classes not implemented, and functions that don't work as advertised. But that doesn't stop me from using the language, or from chosing a Java solution to as many projects as I can. For the most part, the language and the libraries were well thought out, with the goal of making my programming tasks easier. I have used a number of languages over the years, including BASIC, Fortran, Pascal, C, and C++ for significant software tasks. I think I am about five to ten times more productive programming with Java rather than my previous language of choice, C++. There is no doubt in my mind that Java will become the language of choice in the near future, and that kind of demand is obviously going to cause improvements to come rapidly.

Related:
1 2 Page 1