Tech and Media Labs
This site uses cookies to improve the user experience.




Java Web Application Technologies

Jakob Jenkov
Last update: 2014-05-24

This trail is an introduction to Java web application architectures and technologies. It is not meant as a detailed description, but rather as an overview of the various choices available. The detailed descriptions are located in their own tutorials (for the topics where I have tutorials available).

Applets

Applets were Java's first web technology. An Applet is a small Java program that is downloaded from a web server and executed in the browser. Just like a Flash movie or an ActiveX component. Applets were given much interest in the media in the beginning, but never really took off as a web application GUI platform. Today Applets is an "old" technology, which is being replaced in the future by the more modern RIA (Rich Internet Application) technology JavaFX.

Applets could run entirely client side in the browser, or connect back to the server it was downloaded from to send and receive data.

Servlets

Servlets were Java's first server side web technology. It was meant as an alternative to the early web technology "CGI scripts". CGI Scripts were programs that were executed on the web server when a request arrived which was to be handled by that CGI script. Thus, a CGI script process was to be started and finished whenever a request arrived at the web server for a CGI script. Starting a new process is rather slow, and can be memory intensive. Therefore Sun came up with Sevlets. A CGI script could be written in many languages, e.g. Perl or C.

A Servlet is an ordinary Java class that implements a special Servlet interface. This class is then deployed in a Servlet container. The servlet container is connected to a web server. When an HTTP request arrives at the web server which should be handled by a servlet, the web server forwards the request to the servlet container. The servlet container then forwards the request to the servlet that is to handle the request.

Since the servlet container is running all the time, so are the servlets. In other words, when a request arrives for a given servlet, that servlet is already loaded into memory, and ready to process the request. No starting up of CGI scripts or Java processes.

Today most servlet containers comes with builtin web servers, so you do not often make the distinction between a Java web server and a Java servlet container. Examples of Java web servers with servlet containers are:

Tomcat Jetty

Personally I prefer Jetty because it is small and easy to work with. It also starts and stops very quickly. Quick restarts can be handy during development.

JSP

JSP is short for Java Server Pages. JSP was a reaction to the complaints that embedding HTML inside Servlets (Java code) was a bad idea. If the layout across a site needed to be changed, you would have to do so in the Java code. This wasn't always that easy to do, since HTML generating code was interleaved with domain logic code. JSP was also a reaction to the then new web technologies ASP (Active Server Pages) from Microsoft, and PHP, which were / are both technologies similar to JSP.

In JSP the roles are reversed. In a JSP you write you HTML as you would in a standard HTML page. Then you can insert "scriplets" (little pieces of Java code) inside the HTML. For instance, you can repeat a piece of HTML, or choose between two pieces of HTML.

Here is a small servlet and JSP example to better illustrate the difference:

public void service(ServletRequest request, ServletResponse response){
    PrintWriter writer = ((HttpServletResponse) response)).getWriter();

    writer.write("<html>");
    writer.write("<body>");
    writer.write("<table>");

    for(int i=0; i<10; i++){
       writer.write("<tr><td>");
       writer.write("" + i);
       writer.write("</td></tr>");
    }

    writer.write("</table>");
    writer.write("</body>");
    writer.write("</html>");
}
<html>
<body>
<table>
    <%
        for(int i=0; i<10; i++){
            %><tr><td><%=i%></td></tr><%
        }
    %>
</table>
</body>
</html>

As you can see, the JSP example is much shorter than the Servlet example, and it is much easier to get an overview of the HTML. However, this is not always the case. If you are working with an application with much domain logic, and little HTML, a servlet will perhaps be easier to use. If you have a lot of HTML and only a little logic here and there, JSP would probably be better suited for the task.

Model 2 Architecture

JSP do make it easier to weave a little code into your HTML. However, it does not cleanly separate the view (HTML) from the controls (domain logic). If the amount of Java code needed inside the JSP pages increases, the JSP's will soon look like spaghetti, much like a Servlet with a lot of HTML generating code may. Neither Servlets nor JSP was the perfect solution.

As a reaction to this someone (I can't remember who) suggested a new web application architecture, called "Model 2". In a model 2 architecture a Servlet first processes the request and executes all necessary domain logic. When the servlet is done, it attaches any necessary data to the request attributes, and forwards the request to a JSP (or other view technology). The JSP then renders the HTML that is to be send back to the browser. This provides a clearer separation of domain logic and HTML generation.

One of the earliest and most popular Model 2 architecture web frameworks is Struts

The biggest problem with the model 2 architecture is the hard separation of domain logic (controls) an HTML generation (views). Sometimes you need several smaller components to each process their part of the request and generate their part of the final HTML page sent back to the browser. In a strict model 2 architecture this can be a bit hard to do. Once the domain logic (control) is done executing, the request is then forwarded to a view (JSP). This view can again include other, minor controls inside it, and each of these controls may forward the request to a view too.

The problem with this model is the interleaving of control logic and view logic. The execution becomes something like:

control --> view
            --> control --> view
            --> control --> view
                            --> control --> view

Let's say that the last control in the example above encounters an error, and wants to abort the whole request handling. A normal way of doing so would be to sent back a 500 HTTP error to the browser. However, since the view generation is already well underway, the last component may not be able to alter the response headers! Nor can it send an HTTP redirect header back. If an exception is thrown in the last control, the browser will get back half a page, and no error message.

Component Based Architecture

Component based architectures are inspired by the desktop component libraries found in Swing, AWT, and other window toolkits. They can also be thought of as a refinement of the model 2 architecture.

In a component based web application you will have components matching the various components on the pages. For instance, a page with a form will have form components corresponding to the form fields. The component based web framework will try to fill the values from the form fields into the form components, so it is done for you automatically. A bit like a form field in a Swing app. This is how Apache Wicket works.

Personally I am not too crazy about having too many components on the server side. It isn't always much easier to copy the values out of form field components, than out from the HTTP request object. I prefer access to the raw HTTP request. In fact, when working with RIA frontends like Flex, JavaFX or Silverlight, which communicate with the server side via HTTP/XML or HTTP/SOAP, server side components matching request parameters can actually be more in the way, than of benefit to you.

Some component based web framework architectures also avoid the model 2 control-view-control interleaving problem by splitting the 1-pass request handling of the model 2 architecture into a 2 pass request handlng process. This is illustrated below:

component.control
    --> component.control
    --> component.control
    --> component.control
            --> component.control
component.view
    --> component.view
    --> component.view
    --> component.view
            --> component.view

First all components in the hierarchy executes their control logic (domain logic). If any of the components throw an exception at this point, the whole request can be aborted and a 50X HTTP response be send back to the browser, or an error page displayed etc. Any component in the hierarchy can also issue an HTTP redirect response, if desired.

Second all components in the hierarchy executes their view logic. The view logic typically generates either HTML or XML. When generating HTML the view logic is often implemented by forwarding the request to a JSP which generates that components part of the total HTML. The view logic of a parent component (e.g. a JSP) often has markers specifying where in the generated HTML / XML, each child's HTML / XML should be included.

Another advantage of component based architectures over strict Model 2 architectures is that each component in a component based architecture knows its child components (if it has any). That means, that a parent component can disable (avoid calling) one or more of its child components, if the request should not be processed by that child. Additionally, a component may add new children at request processing time, if necessary. For instance, a component may decide based on the request to add either a ChildA or ChildB, and then pass on the request processing afterwards to the component added.

In a model 2 architecture a control does not know its children. Only the views knows where to include children. To disable a child control + view would be harder. It would require sending a disable signal to the child control + view, possible via a request attribute. Adding new components is very hard too. You would have to modify the view at runtime. However, views are very often JSP's, and they are not too easy to modify at runtime.

Examples of component based web frameworks are:

JSF (Java Server Faces)
Butterfly Web UI
Wicket
Tapestry

JSF

JSF is short for Java Server Faces. JSF is a component based web framework developed by Sun. JSF is an alternative to JSP.


JavaFX

JavaFX is a RIA (Rich Internet Application) technology developed by Sun, inspired by Adobe Flex. A RIA application works like an Applet. It is a small program that is downloaded and executed in the users browser. RIA technologies are often much better geared towards communicating with the server side, than traditional Applet's were. They are typically also much easier to layout.

Adobe Flex

Adobe Flex was one of the first RIA technologies to emerge. Flex is a GUI framework for creating RIA applications in Flash. A Flex application is compiled into a Flash file which can then be included in your HTML page. Flex is very easy to layout using MXML - an XML format which resembles HTML a lot.

Though Flex isn't Java I have included it because it is very easy to integrate a Flex RIA application with a Java server side. Flex can call a Java server side via either RMI, SOAP or simple HTTP/XML. I prefer the HTTP/XML mechanism, as it is very simple to develop and debug. In addition, Flex has been out a lot longer than JavaFX, and is thus (at the time of writing) more mature.

Jakob Jenkov




Copyright  Jenkov Aps
Close TOC