WEB-BASED JAVA APPLICATION IMPLEMENTATION
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.
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.
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!
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.
send feedback to firstname.lastname@example.org