WEB-BASED JAVA APPLICATION IMPLEMENTATION

Applets vs. Servlets

The usage of the World Wide Web as a deployment platform for business applications has increased dramatically in the last few years. This increase is mostly due to the ease of developing such web sites and the abundance of web developers in the market. This fact will lead many corporations and individuals to strongly consider the advantages and disadvantages of the two main methods of web-based application implementation: Java applets and servlets using HTML forms. This article will weigh each approach and try to determine in which setting each one is appropriate.

The learning curve for HTML forms is not too steep, so it usually doesn't take a user very long to develop his/her first web page (even shorter if a web-authoring application is used). Therefore, forms are ideal for rapidly producing prototypes. Java user interface prototyping, however, can take some time to perfect, so using an IDE with a GUI builder is definitely recommended. (Note: only use an IDE for prototyping because almost all of them prefer to insert proprietary window components whose libraries must be shipped with the software). Developing the GUI in Java does allow more control over the interface, making the application more dynamic, i.e., easier to change components at runtime based on previous input.

When an application needs a connection to a database residing on another machine, a servlet may make the job easier since it can also serve as the middleware between the client and database. Applets are much more difficult to use because of their security restrictions; the most prominent one being that an applet can only make socket connections back to its original machine. One alternative is a signed applet, but the mechanisms for obtaining signatures and ensuring compatibility between browsers is difficult at best.

Browser compatibility is another good topic for discussion. As almost everyone knows, Microsoft's Internet Explorer and Netscape's Communicator browsers are locked head-to-head in an ongoing battle that must acknowledged by anyone developing for the Internet; Each browser has its own nuances that can be just downright annoying at times. One example is that in IE, after submitting a form, the information inside text boxes and the other controls do not show up like they do in Communicator. It doesn't matter whether the application uses servlets or applets, the differences between the browsers will cause many headaches.

One of the most trying tasks when developing with servlets is maintaining the web page history chosen by the user. When the user presses the back button, the program should usually keep track of the information gathered from the previous screens. This can be accomplished by using some form of object persistence such as servlet sessions or cookies. Using one of these methods, a specialized Back button can be placed on the application to make sure the proper previous input is displayed. But the user may still choose to use the browser Back button, circumventing the whole process!

Object persistence and state control are just some of the more integral parts of application development that are crucial when considering which implementation approach best suites a web-based product. While servlets and applets both have their pros and cons, the deciding factor is the sheer complexity of the application. If there aren't that many input screens and the data flow is not too complex, then servlets are an ideal implementation. However, once the amount of information to be gathered grows, and therefore the complexity of the data flow increases as well, then using an applet is probably the better route. That way, developers have more control over how to direct the user's path, as well as easier methods of maintaining object persistence and state. Of course, the end product will become more complex, but that is in direct correlation with the complexity the user requirements specified up front.

Please send feedback to articles@thirdeyeconsulting.com