In this article, we will look at the Web Tier in Java EE. We will look explain and contrast the approaches for building a web tier using Servlets, JavaServer Pages and Custom Tag Libraries. We will go into detail into how to these approaches work with web container managed strategies. This is part of a larger series of articles to help you prepare for the java architect exam. The most recent article looked at ejb application architecture, “Tutorial:Review of EJB Application Architecture for the Java Architect Exam”.

The Beginnings of the Web Tier

In late 1999, Sun Microsystems added a new elements to the collection of Enterprise Java tools. These were JavaServer Pages (JSP) which were built on top of Java servlets and designed to increase the efficiency in which programmers, and allow even non-programmers to create web content. As well as JavaServer Pages, JSP 2.0, we will cover the related JSP Standard Tag Library (JSTL) Version 1.1. It also covers other JEE technologies, such as servlets and JDBC, with focus on how to combine them with JSP in the most efficient way.

The Concept of Model View Controller (MVC)

Designing flexible and maintainable web applications that combine HTML, JSP, and Java and access databases or legacy systems has always been a challenge. A number of insights into the use of JSP, beans, and servlets will provide some common approaches to web application design. The JSP authors designed the JSP specification to allow for JSPs to be flexible. That means that you can implement JSP based web applications in a number of ways including the following:
  • A mixture of HTML and JSP scriptlets - this approach mixes large amounts of Java code with HTML in JSP pages leading to applications that are difficult to maintain and extend
  • Delegating functionality to Java beans - this approach delegates functionality to Java beans moving Java code from JSP pages to beans. This approach is commonly known as the Model 1 architecture
  • Using servlets, JSP pages, and Java beans to implement a Model-View-Controller (MVC) architecture - this approach combines servlets, JSP pages, and Java beans into an MVC architecture that results in extensible and maintainable software due to its ability to encapsulates functionality and reduces the impact of changes.

Below is a figure showing the conceptual MVC approach:

Tutorial:Review of Web Tier Application Architecture for Java Architect Exam-c5-conceptualmvc.jpg
Figure:Conceptual MVC Approach

The Evolution of MVC to Model 2

The Model 2 architecture was first advocated for the 0.91 JSP specification. This architecture separates business objects from JSP pages, as it is essential for most web development projects that the JSP pages and business objects can evolve with minimal dependencies between the two of them. Also Model 2 separates content generation from content presentation. This is shown in the figure below:

Tutorial:Review of Web Tier Application Architecture for Java Architect Exam-c5-mvcarchitecture.jpg
Figure:Model 2 MVC Architecture

The Model 2 architecture works by submitting requests to a servlet that accesses business objects to create content. The content is stored in a Java bean that can be accessed by a JSP page. The JSP page can then subsequently present the content in HTML or another markup language. One of the key elements of the Model 2 architecture is the separation of content generation from presentation. The benefit of this design is that by separating Java code for use in content generation and JSP pages for use in content presentation, developers and web page authors could focus on their areas of competence without requiring the learning of any new language. In fact, the Model 2 architecture is a modified MVC implementation since the model does not fire events to its views. This modification was adapted to web applications because they only display one view of their model at a time.

Key Benefits of MVC

The MVC architecture has long been the foundation used for applications that were built using object oriented languages. One of the key aspects of object-oriented development is identifying abstractions and encapsulating them in classes. It is by encapsulating abstractions in classes that allows for loose coupling between objects. Loose coupling reduces dependencies and increases flexibility and reuse.

The three general abstractions that MVC encapsulates are present in most graphical applications. These are models, views, and controllers. By encapsulating what other architectures link together, MVC applications are made much more flexible and reusable than their traditional counterparts.

Web Applications and their Servlet Contexts

Java web applications consists of combination of several different types of resources:
  • JSP pages
  • servlets
  • applets
  • static HTML pages
  • custom tag libraries
  • other Java class files

Servlet 2.5 compliant containers support a standard means to package all these resources and a web application deployment descriptor containing information about how all the resources fit together. All of these resources are arranged in a well-defined hierarchy within an archive file called a WAR file. All compliant containers provide tools for creating and installing a WAR file or provide a special directory where a WAR file is automatically picked up such as the deploy directory in JBoss. Web containers can also support web applications deployed directly in the filesystem using the same directory and file structure as the one defined for the WAR file.

For the container, each web application is represented by a servlet context that has an associated unique URI path prefix called the context path. For example, a retail application can be associated with the context path /retail or a support application could have the context path /support. The context path allows the servlet container to distinguish between the different applications it serves with dispatch requests like /retail/report?month=Jan to the retails application and /support/app to the customer support application.

The latter part of the URI path is used within the selected context to determine the manner in which to process the request by comparing it to the path-mapping rules defined by the application's deployment descriptor. These rules can be defined in such a way that all requests starting with /report are sent to one servlet and requests starting with /store are sent to another. Another mapping rule could have one servlet that handles all requests with paths ending with a specific file extension, such as .jsp. This type of mapping rule is used for handling all JSP page requests.

Each context is self-contained and is not aware of other applications running within the same web container. References used between the servlets and JSP pages in an application are generally relative to the context path. They are referred to as context-relative paths. The use of context-relative paths within the application permits a web application to be deployed using any context path.

The last thing to note about the servlet context is that it can hold objects that are shared across all components in the application. The types of objects it tends to hold are resources such as database connections, connectors to other legacy systems or shared resources required by multiple servlets and JSP pages. Special considerations need to be factored in for the servlet context in web applications distributed over multiple servers.

Web Container Functionality

All servlets are under the control of a servlet container. It serves as the connection between a web server and the servlets by providing the runtime environment for all the servlets on the server as well as being responsible for loading and invoking those servlets when requests arrive. The container loads an instance of the servlet class in a thread when it receives the first request for the servlet, allows it to initialize itself, and then delegates the request to the servlet for processing by handing off the request and response objects and calling the relevant HTTP method (i.e. doGet, doPost, etc). All subsequent requests are then handled by the same servlet until the server is shut down. On shutdown, the container allows the servlet to release resources and save its state before completing shutdown.

There are a wide variety of types of servlet containers. There are some containers that are called add-ons, or plug-ins which are used to add servlet support to web servers without native servlet support such as Apache and IIS. These servlet types can run in the same operating-system process as the web server or in a separate process. Other containers are standalone servers and include web server functionality to provide full support for HTTP as well as the servlet runtime environment. Servlet container can also be embedded in other servers such as for climate-control systems in order to offer a web-based interface to the system. When a container is bundled as part of an application server it can then distribute the execution of servlets over multiple hosts allowing the server to balance the load evenly over all containers. There are even servers that can provide failover capabilities in case a host crashes.

Irrespective of the type, the servlet container is responsible for mapping an incoming request to the servlet that has been registered to handle the resource identified by the URI and to pass the request and response objects to that servlet. When the servlet has processed the request and returned a response, it's the container's responsibility to convert the response created by the servlet into an HTTP response message and return it to the client. This is shown in the figure below:

Tutorial:Review of Web Tier Application Architecture for Java Architect Exam-c5-requestdispatching.jpg
Figure:Request Dispatching

The web container is analogous to the EJB container. It provides an environment in which web components can execute in an efficient manner. The concept of containers is one of the biggest advantages of the JEE platform in that is shields the developer from the inner workings of components in the platform, leaving them to focus on using the JEE platform to implement the required business logic for their application. Web containers provide the services such as threading, transactions, configuration and security management that is required by presentation and control components such as JSPs, JSF components, Servlets, filters, web event listeners, as well as plain old Java classes (POJOs). Without this web applications would be impossible.

Web Tier Components - Servlets

A Servlet is a server-side component designed to extend the ability of servers hosting applications to handle inbound service requests from remote clients by means of a request response programming model. The general responsibilities of a servlet are the following:
  1. Read all data sent by the user usually entered in a form on a Web page, but possibly coming from a Java applet or a custom HTTP client program.
  2. Find any other information about the request that is embedded within the HTTP request including details about browser capabilities, cookies, the host name of the requesting client, etc.
  3. Generate the results through processes such as interrogating a database, invoking a Web service or RPC call, invoking a legacy application, or directly computing the response.
  4. Format the results inside a document in the appropriate markup languages. In many cases, this will involve embedding the information within an HTML page.
  5. Set the appropriate HTTP response parameters so that the browser knows what type of document is being returned (e.g., HTML) as well as setting cookies and caching parameters among other possible tasks.
  6. Return the document to the client, possibly in text format (HTML), binary format (GIF images), or even in a compressed format like gzip layered on top of some other underlying format.

Although the vast majority of all Servlets implemented are designed to respond to HTTP/HTTPS GET and POST requests, the Servlet model is designed to accommodate any protocol that is predicated around a request/response model. Any developer wanting to create a servlet must implement the javax.servlet.Servlet interface or the javax.servlet.HttpServlet interface for HTTP Servlets. The service method contains the routing logic that forwards the inbound request to the appropriate handler. As we mentioned in the previous section, servlets are hosted by a web container. Each server instance is allocated to its own thread for execution. This use of multiple threads allows for web applications to easily scale except in circumstances where the developer explicitly chooses to use the SingleThreadedModel tagging interface. The figure below shows the servlet lifecycle.

Tutorial:Review of Web Tier Application Architecture for Java Architect Exam-c5-servletlifecycle.jpg
Figure:Servlet Lifecycle

The container controls the life cycle of a servlet. When a request is mapped to a servlet, the container will perform the following steps.
  1. If an instance of the servlet does not exist, the web container
    • Loads the servlet class.
    • Creates an instance of the servlet class.
    • Initializes the servlet instance by calling the init method.
  2. Invokes the service method, passing request and response objects.
  3. If the container needs to remove the servlet, it finalizes the servlet by calling the servlet’s destroy method.

It is possible to monitor and react to events in a servlet’s life cycle by defining listener objects whose methods get invoked when life-cycle events occur. You must define and specify a listener class in order to use these listener objects for this purpose. We will discuss listeners in a later section.

Web Tier Components - Filters

A filter is a server-side component that runs on the server before the servlet or JSP page with which it is associated. It is attached to one or more servlets or JSP pages and interrogates the request information that is being sent to these resources and then can do one or more of the following:
  • Invoke the resource (i.e., the servlet or JSP page) in the normal manner.
  • Invoke the resource after modifying the request information.
  • Invoke the resource and then modify the response before returning it to the client.
  • Prevent the resource from being invoked and redirect to a different resource along with returning a particular status code, or generate replacement output.

This capability provides several important benefits. The first benefit is that it allows you to encapsulate common behavior in a modular and reusable manner. You could create a single compression filter that can used for 30 different servlets or JSP pages that need to compress content in order to decrease download time.
The second benefit is that it allows you to separate high-level access decisions from presentation code. This benefit is very useful for JSPs where you are looking to only use it for presentation and not business logic. You could create an access restriction filter that blocks access to certain sites without needing to modify any individual page where the restriction would apply.

The third and final benefit is that filters allows you to apply wholesale changes to a wide range of different resources in large volumes. For example, you could create a string replacement filter to replace the company name but not any other data in the resource in all of the appropriate sections.

Web Tier Components - Listeners

Listeners allow an application to react to specified events. Since Servlet 2.3 specification, you can handle not only session attribute binding events that are triggered when an object was added or removed from a session, you can also handle events related to these other application lifecycle events:
  • Servlet context listeners. These listeners are notified when the servlet context (i.e., the Web application) is initialized and destroyed.
  • Servlet context attribute listeners. These listeners are notified when attributes are added to, removed from, or replaced in the servlet context.
  • Session listeners. These listeners are notified when session objects are created, invalidated, or timed out.
  • Session migration listeners. These listeners are notified when the session objects are serialized and deserialized by the container. Usually, the serialization and deserialization of session objects occurs when the container migrates the session objects from one machine to another.
  • Session object binding listeners. These listeners are notified when the implementing object is added or removed from the session object.
  • Request listeners. These listeners are notified when request objects are initialized and destroyed.
  • Request attribute listeners. These listeners are notified when attributes are added to, removed from, or replaced in any request.

All of these new types of listeners follow the standard Java event model in that the listener class will implement one or more of the listener interfaces that define methods that correspond to events. The listener class will be registered with the container when the application starts and then container calls the event methods at the appropriate times.
In the listing below is a session event listener used for tracking the number of active sessions for an application:

Java Code: Session counter listener
package com.acme.jsp.servlets;
import javax.servlet.*; 
import javax.servlet.http.*; 
public class SessionCounterListener implements HttpSessionListener { 
    private static final String COUNTER_ATTR = "session_counter";
    public void sessionCreated(HttpSessionEvent hse) { 
        int[] counter = getCounter(hse); 
    public void sessionDestroyed(HttpSessionEvent hse) { 
        int[] counter = getCounter(hse); 
    private int[] getCounter(HttpSessionEvent hse) { 
        HttpSession session = hse.getSession(  ); 
        ServletContext context = session.getServletContext(  ); 
        int[] counter = (int[]) context.getAttribute(COUNTER_ATTR); 
        if (counter == null) { 
            counter = new int[1]; 
            context.setAttribute(COUNTER_ATTR, counter); 
        return counter; 
Now, for every new session, the sessionCreated( ) method increments a counter maintained as a servlet context attribute. And when a session ends, the counter is decremented by the sessionDestroyed( ) method. One could also combine this listener with a filter to reject new users if a maximum session threshold is reached in order to ensure optimal performance or some other attribute for the application.

Web Tier Components - JavaServer Pages (JSP)

JSP is a Java technology for web application development derived from the success of servlet technology. Servlets are useful in a number of areas, but they are generally reserved for programmers. JavaServer Pages are HTML pages with embedded mark-up that gets evaluated at runtime by the web container to generate complete HTML pages. These HTML pages are then sent to the client for rendering to the end user. The key elements of JSP technology are JSTL (Java Standard Tag Library) and the Unified Expression Language (EL), which both of which have matured over the lifetime of the JSP specification. The main purpose of these elements is basically to enforce a workable MVC model that separates presentation logic from business logic in Java EE. The figure below shows a JSP page. It is simply a regular web page with JSP elements for generating the parts that differ for each request:

Tutorial:Review of Web Tier Application Architecture for Java Architect Exam-c5-jsppage.jpg
Figure:JSP Page Consisting of Template Text and JSP Elements

Note that outside of the JSP elements in the pages, everything else is just template text. Template text is text of any type (i.e. HTML, WML, XML, or even plain text). JSP has no dependency on HTML so it can be used with any markup language. The template text is always passed straight through to the browser when a JSP page request is processed and then merged with dynamic content generated by the JSP elements before being sent as the result to the browser. The lifecycle for a JSP is a bit more complicated than that for a servlet. That is because the likelihood of it being changed during it’s lifetime is significantly higher so it will often need to be recompiled into a special servlet before being load and an instance of it being created. This is shown in the figure below:

Tutorial:Review of Web Tier Application Architecture for Java Architect Exam-c5-jsplifecycle.jpg
Figure:JSP Lifecycle

Web Tier Components - Java Standard Tag Library (JSTL)

JavaServer Pages Standard Tag Library (JSTL) is one of the most important additions to JSP since its inception. JSP has normally been programmed using scriptlet code written in Java and inserted along with the HTML for the Web page. JSTL replaces these scriptlet code with reusable tags that are similar to those that make up HTML. It is a set of tag libraries that forms part of the JSP specification. Before the introduction of the JSTL, open source communities such as Apache, commercial companies, and indeed individual software teams built their own tag libraries. The JSTL replace these numerous tag libraries with standard tag libraries to the most commonly used functions for which tag libraries are used. This allowed developers and architects to effectively delegate control and enhanced presentation logic tags to the specification writers and instead focus instead on application logic. The JSTL is the most obvious example of open standards adding tangible value to developers as the JSP specification extends out to area where standardization was obviously required.

Web Tier Technologies - Unified Expression Language (EL)

The Expression Language (EL) was introduced with the JSP 2.0 specification. JavaServer Faces also has its own version of EL that was introduced in version 1.1 of the specification. The two versions were unified in JEE 5 as a logical attempt to simplify the overall platform. Basically EL provides developers with the ability to eliminate Java scriptlets completely from JSP pages. There are two key constructs for EL expressions. These are:
  • ${expr} - $ indicates that the expr is evaluated immediately
  • #{expr}. - # indicates to the container that evaluation should be deferred.

The container also uses a number of implicit objects available for an executing EL snippet such as requestScope, sessionScope, etc. Access to these implicit objects further improves the ability of EL to replace custom Java snippets in JSP. Although custom Java snippets are not on their own a very bad thing, the mixing of presentation with business logic violates one of the core tenets of the MVC design pattern.

Web Tier Technologies - Session Management

The Servlet specification provides an elegant way to allow a client-server conversation to manage session state over the stateless HTTP protocol. This is done via the web container which provides access to a map called the HttpSession, where developers can manage any data that needs to be stored in order to process a client’s request. This object must not be abused since storing large objects, such as the collections of search results, is to cause performance and scalability problems.

Web Tier Components - JavaServer Faces (JSF)

JavaServer Faces is a server-side user interface component framework for Java-based web applications. It has become a useful method for constructing web UIs. It has two main components:
  • An API for representing UI components and managing their state such as handling events, validation, data conversion, defining page navigation, supporting internationalization and accessibility. It also provides the means to extend any one of these features.
  • Two JavaServer Pages (JSP) custom tag libraries that can be used for adding JSF UI components to a JSP page and for wiring these component to server-side objects.

The programming model and tag libraries allow for rapid building and maintenance of web applications with server-side user interfaces. Among the things you can do are:
  • Drop components on a page by adding component tags
  • Wire component-generated events to server-side application code
  • Bind UI components on a page linking it to server-side data
  • Construct UIs using reusable and extensible components
  • Manage UI state beyond the life of server requests

User interfaces created with JavaServer Faces technology are server based but renders back to the client. A JSP page can also be a JavaServer Faces page when the JSP page includes JavaServer Faces tags. It will provide the user interface components by using custom tags defined by JavaServer Faces technology. The user interface for the web application controls the objects referenced in the JSP page. The objects include:
  • The UI component objects mapped to the tags on the JSP page
  • All event listeners, validators, and converters registered with the components
  • JavaBeans components encapsulating the data and application-specific functionality of the components

A figure demonstrating JavaServer Faces interaction between the browser and the server are shown in the figure below:

Tutorial:Review of Web Tier Application Architecture for Java Architect Exam-c5-jsfinteraction.jpg
Figure:JSF Interaction Between the Browser and Server

JSF is designed to be easy to use by developers to stop thinking in terms of HTTP requests and responses and focus instead on UI development in terms of user and system-generated events. The JSF components are reusable and as such improve developer productivity, software quality, and system maintainability. It can be easily integrated into a number IDEs such as Eclipse, Netbeans, and IntelliJ.

Templating Frameworks

There are a number of templating frameworks that leverage the Servlet container to build out a simpler, more efficient way of including dynamic content in HTML fragments, such as Velocity and FreeMarker. These frameworks show how simple web development can and should be. Irrespective of the ease of development and use of these frameworks, the mandated way to build presentation logic in the JEE platform is either using JSP or JSF.

Benefits of Web Frameworks

Web frameworks fill the nice between the JSP/Servlet/JSF specification and what an architect requires in order to build a high-quality web application with a rich user interface. For web UIs, the definition of a good web framework is one that provides the architect and developer with core features such as action handlers, client and server-side validation, proper management of transactions, integration of security, session state management and build a maintainable and understandable web UI. The mainstream web frameworks have been so successful that many architects have decided not to use EJBs in their applications. They have done this because EJBs in the Java EE platform provide features that are not required except when business requirements dictate it. For those who choose not to specify or use a web framework in Part II of the exam, you will need to justify your decision. Note that most non-trivial Java projects are using a web framework in order to impose standard practices on the development team, to produce maintainable code, and to avoid re-inventing the wheel on every new development.

Best Practices

In this section, we provide best practices for each of the various components of the Java EE web tier stack. You can use almost any component to address any presentation/flow control/business logic problem, but the nature of JSPs, Servlets, JSF, and other web components means that they are better-suited to these specific scenarios.

Standard Use of JSPs and Servlets

JSPs are used to handle the presentation of data to the end user. They contain no business logic. Best practice is to minimize or eliminate entirely all Java code from JSPs and to use EL, JSTL or custom/third-party tags instead. This guideline tends to reinforce the role of JSPs for providing the view in MVC.

Standard Use of JSF

The standard uses for JSF are the same as for JSP. As an architect, you must choose between either JSP with JSTL and a good MVC framework, or use JSF. They both perform the same function and are not mutually exclusive. One can mix JSF UI components with JSTL in a hybrid solution. This is because JSF has matured to the point where it is used more and more in web and enterprise applications, although many architects continue to prefer JSP with JSTL and EL.

Web-Centric Design

There is a significant proportion of all Java EE applications in existence today are deployed only in a web container avoiding the use of EJBs. These types of Java EE applications are called web-centric.

As a JEE architect, you can stipulate that EJBs not be used in the design of an application, but it is important that you clearly understand why that decision is mandated as well as the impact of this decision on your developers since they will need to implement the business logic. The exam will test you on this concept by presenting you with a number of scenarios. Those scenarios with a strong messaging, transaction, or security management component would tend to be candidates for an EJB-centric implementation. Scenarios where the ease of development is essential, or an existing application is already web-centric, or where transactions are not a key aspect of the application because it will do primarily reads from a database are candidates for web-centric applications.

Some of the really obvious reasons for not using EJB is standard Create, Read, Update, and Delete (CRUD) applications built using Struts to organize and control the presentation and business logic tiers, and Hibernate plus a DAO access layer to implement the persistence tier. As long as there are no asynchronous messaging requirements or JMS queues or topics to access, and the web container can provide the functionality needed for aspects such as concurrency control, security, and session management, then the best practice is to adopt a web-centric approach.

In an scenario where an organization has invested significantly over the years in transactional systems based on mainframe technology, ensuring system reliability and security are paramount. It is critical that issues related to data corruption from edge conditions such as the lost update or optimistic locking occur. If this type of system is in an unknown state due to a technology failure, the system will need to be back up and running within 10 minutes in order to avoid a service-level agreement (SLA) breach as well as notifying the relevant regulatory authorities and the completion of a full system audit. It is clear in this scenario, that a solution architect would be remiss to recommend a web-centric solution on the JEE platform in order to meet these non-functional requirements.

That is because it is the majority of the aspects of the EJB framework lend themselves very well to this type of deployment. If an architect chose only a web framework, they will force themselves to replicate in code the reliability and availability characteristics that already exist in the core Java EE platform. This is not an efficient use of time on the project and results in increasing the risk of the project with an implementation that will probably be costlier to maintain over its lifecycle.

EJB-Centric Design

The business requirements that we mentioned previously translates into nonfunctional requirements (NFRs) focusing on system correctness, reliability, and security. In this scenario, assuming that the organization’s systems can be accessed by a non-EJB solution, as we mentioned, it is possible to achieve, with significant effort, a solution that will meet the NFRs using only a web-centric solution. But this will require you to commit your team to write entire modules of custom code to provide features that you get out of the box from an EJB container. Also, this will likely require you to leverage vendor-specific libraries/mechanisms in order to implement these modules. This could potentially limit the portability of your solution going forward. As an architect, there is no one correct answer, it is more of a question of weighing the tradeoffs of going down a web-centric path compared to an EJB-centric path. The role of the architect in this is to examine the possible solutions and select the best solution, taking into account the context in which the set of business requirements exists.

Evaluation of Architectural Choices

From the two preceding sections you can derive that irrespective of whether one chooses a web-centric or EJB-centric architecture, there is never a right or wrong answer in relation to what is the best architecture in a particular situation. The decision to select one over the other is should be based on an objective review of the facts relating to a specific project. The relevance of the different aspects that one should consider are outlined below:
  • Transaction requirements—if this is a critical aspect of the application, your choice should be weighted towards using EJBs
  • Security requirements— if this is a critical aspect of the application, your choice should be weighted towards using EJBs
  • Messaging requirements—if your application requires asynchronous messaging, then you should again consider EJBs or more specifically message-driven beans (MDBs).
  • Performance
  • Ease of development.
  • Scalability.
  • Existing team skills or existing project implementation.

Of the last four aspects, only scalability would be weighted possibly towards the use of EJBs. The other three are equally true of web-centric solutions as they are of EJB-centric solutions. In fact, the primary focus for EJB 3.0 has been to improve drastically the ease of development. The general consensus on EJBs is that it is as easy to develop with them as it is with most of the lightweight inversion of control frameworks that came along to address the shortcomings of EJBs. Note that you can use these frameworks in conjunction with a web-centric application to give you many if not all of the same features that you would find in a EJB-centric solution. At the end of the day, the architects choice will ultimately be driven by both the business and non-functional requirements as well as the stated preferences of the organization. .

AJAX and Cometd

We should mention that the exam also contains material on Asynchronous JavaScript and XML, or AJAX. Architects need to understand the benefits of AJAX as they relate to providing a richer end-user experience and how the JEE 5 platform allows server-side components to service AJAX requests from browsers. This comprises a key aspect of the appeal of JSF since it provides AJAX functionality out of the box. Note also in the future, there will be more questions related to an extension of AJAX into what is known as cometd (HTTP continuations). This is another means of enhancing the end-user experience for browser-based applications and the implementation of this technology within Java EE will soon be reflected in the questions posed.


  • Presentation tier technologies remain a key element of the JEE 5 platform.
  • Part II of the exam is more concerned with the candidate displaying in-depth understanding of the business requirements and selecting a presentation technology that meets those requirements.
  • JSF has grown from the presentation tier that is a significant element of the JEE platform.
  • You will need to understand which is the best UI technologies to use in the JEE platform within the context of a series of scenarios for the exam. The scenario provides all the information required to select the correct technology/combination of technologies to use from the multiple choice answers provided.
  • As a JEE architect, one of your key skills is the ability to analyze application requirements and choose the best combination of JEE technologies on the web tier to meet those requirements, while not over-engineering the solution.

OK. That’s it for the web tier.