Java Server Faces in Real-Life Applications

JavaServer Faces (JSF) is the current front-end technology for building web-based applications in the Java Enterprise Edition platform (JavaEE).

In this article, we will talk about the requirements and recommendations that should be taken into consideration for building production-ready JSF applications, including development environment setup and preparation, prototype and design, development and troubleshooting, and performance tuning.

I. Background

In 1998, and in the early stages of Java EE (J2EE), Sun-Microsystems implemented the first support of web-applications as Java Servlets. Servlets were designed around the concept of handling http-requests and generating dynamic HTML content on the server side using Java classes.

Java Servlets was a very clean approach compared to the technologies available at that time (e.g. CGI, Perl, PHP, and ASP). Although it got a lot of popularity, it had started to be not practical when the need of generating relatively large HTML markups inside Java classes became mandatory for most web applications.

This had led to creating a new standard technology, JavaServer Pages (JSP) in 1999, which reversed the concept of generating dynamic HTML markups inside Java classes to writing Java code inside HTML pages using scriptlets.

JSP and Servlets were around together for a while, and they had been wildly implemented in all levels of applications. Most of the applications were designed so that Servlets was used for the business logic while JSP was used for dynamic view handling. This was based on the Model-View-Controller (MVC) design pattern.

In such applications, however, there was a lot of technical requirements that were time-consuming and manually handled by the application developers, such as: MVC, binding (i.e. linking the user interface input components to server-side fields), input validation, templating (i.e. encapsulation of UI design layout and views), pages navigation and workflow, composite UI components, among others. This has resulted in many frameworks and API’s created by 3^rd party organizations, communities, and vendors to solve such issues. The most popular were: Apache Struts, Tiles, Tapestry, and the Spring MVC.

In 2004, Sun decided to go with a new web-technology from the ground-up, to include all the required features that became mandatory for most web applications, along with modernized concepts of component-based and event-driven web applications, and that was JSF 1.0, then 1.1 and 1.2 in 2006.

JSF 1.2 didn’t become implemented as fast as its predecessors (JSP and Servlets) since there was a lack of maturity, IDE integration, and community support, along with serious performance and security issues.

Later on, in 2009, JSF 2.0 was announced with many new features and enhancements, including declaring Facelets (a 3^rd party view-language developed by Jacob Hookom in 2005) as a template engine and the default view declaration language over JSP, AJAX support, GET request support and many others. Later on, JSF 2.1 was released. Currently, the latest available release is 2.2, which has been released since 2013.

II. JavaServer Faces in Real-Life Applications

JSF has been designed with Rapid Application Development (RAD) in mind since the beginning. It has excellent community support as well as a great suite of 3^rd party components (e.g. PrimeFaces). However, there are still many detailed tasks involved in building JSF-based applications that are required across all the phases of the standard software development lifecycle (SDLC). Some of these tasks are already included in JSF standard implementation, whereas others are supported by the 3^rd party. These are classified as follows:

1. Project preparation and environment setup.
2. Pages prototype and design.
3. Development and debugging.
4. Performance tuning.

Although security is a very important topic, we have decided not to include it in this article, since it involves many standards, specifications, and technologies (e.g. Servlets Spec. JAAS, OWASP, and Spring Security), which are all not directly related to JSF. We may discuss the aspects of security in more detail in future articles.

1) Project Preparation and Environment Setup

When creating new JSF applications, there is a need for many configurations, libraries, and set-ups, which include:

1. The existence of JSF libraries (i.e. API and implementation) during the compile time only, since it is already bundled with any Java EE compliant application server. This is not the case, however, of Servlets containers like Jetty and Tomcat, in which JSF libraries should be bundled in the project class-path, which will cause a portability issue in turn.
2. The existence of web.xml inside the WEB-INF folder (although it has become optional since servlets 3.0 specifications in 2009).
3. Web.xml must include the following configurations:
   • JSF Servlets.
   • Map JSF pages.
   • Encoding servlets to solve encoding issues (in the case of Tomcat and Jetty).
   • Set project mode.
   • Set JSF time zone to system time zone.
   • Handle view expired exception by setting the compatibility mode.
4. Beans.xml must add CDI support as well as including CDI API and implementation (Weld) to the project-class path in case of servlet-containers.

2) Pages Prototype and Design

In the past, creating application prototypes was an easy task that could be done by the business analyst (B.A.) using any modeling tool such as Microsoft Visio, since the design expectations of traditional desktop and old-fashion web applications were not too high. However, this has dramatically changed with the emerging of new trends in web designs and user experience including responsive, light-weight, flat, and metro designs. Such trends have led to the need of building a complete application prototype in the early stages of the projects, and sometimes even before awarding, since the UI designs have become one of the main factors of awarding criteria in many software projects.

In JSF applications, this can be done in one of three options:

1. Pure JSF components and themes: This is considered the easiest approach for implementing the prototype. However, this approach limits the JSF developers to be fully dependent on the currently available components and themes, which are limited in options and considered heavyweight when compared to HTML5 modern themes and lacking the support of new trends. Also, this will result in increasing the project cost, since the labor cost of Java developers is considered high compared to web-designers cost. Moreover, this will make applications highly coupled with the components library, which will lead to a high cost of maintenance (i.e. the change of PrimeFaces dialog component between 4.0 and 5). It will also make the component's replacement by another one a big challenge, similar to what happened when many applications switched from ICE-Faces and Rich faces components to PrimeFaces(PF).

2. Pure JSF components with customization support by web-designers: Although it may be good to have some minor customization options on the design, the involvement of web-designers, in this case, will not be very helpful, which is the reason of many challenges. Firstly, customizing the theme and overriding its styles is not much flexible and it will not be an easy task. Secondly, it is a very time-consuming process with unguaranteed results. Thirdly, there is a clear lack of design tools to support such customization, which is one of the main factors of making this option un-recommended and un-friendly for the designers. Using Facelets as the declaration language will not solve the issue because using the JSF components for everything will still produce the same output from standard JSF syntax, and will they coupling with the components is still high.
3. Pure HTML 5: This will be the most cost-effective and practical approach to prototype and design the application. Using pure HTML5 we can get the results faster. In addition, modern designs can be done easily using the available design frameworks and libraries (e.g. Bootstrap). Applying ready-made web design templates is also possible and practical. In this approach, HTML5 shall be used for the whole design, and JSF components will be used only for binding input components.

3) Development and Debugging

JSF has been designed to include many of the needed technical requirements for modern web-applications to achieve a RAD approach, including:

1. Model-View-Controller (MVC) through views and managed beans.
2. Automatic binding between user-interface components and server-side counterparts using expression language (EL).
3. Built-in template engine (Facelets)
4. Navigation and workflow management (Navigation rules)
5. Ready-made user-interface components.
6. Built-in validation for input fields(Validators)
7. Built-in conversion for data-types (Converters)
8. Transparent AJAX support

Although JSF was built on a high level of abstraction and a long list of fancy-features, which shall theoretically reduce the development time, it comes with an expensive cost: debugging, troubleshooting and performance, especially with the lack of tools and IDE’s support.

This is caused by mainly two reasons, (1) the complexity of client-side code of sophisticated web applications, which is the case for most modern web applications, and (2) the limitation in JSF specifications and implementations, which is discussed later in this document.

Although JSF has been available since 2004, it still has many missing technical functionalities and features that make building and debugging a JSF application a big challenge. Some challenges include:

1. The design issues caused when using <head> tag instead of<h:head>
2. The no-action of commands if not surrounded with <h:form> tag
3. Missing exception handling for AJAX requests.
4. Converters of list data-types.
5. The handling of view expired exceptions
6. Using <html> tag inside include files and composite components to define, which may result in non-standard HTML DOM structure.
7. The resources reference inside complex CSS files (e.g. defining a new font style in CSS resources)
8. The complexity of building composite components using Java classes (Facelets have a nice work for making building composite components; however, creating it using Java classes is needed to be able to create parameterized and customized composite components using object-oriented approach).

To overcome these issues, many JSF developers are forced to use 3^rd party solutions and workarounds (e.g. Omni-Faces). However, the usage of non-standard libraries and APIs causes serious maintainability issues (e.g. the upgrade from Omnifaces version 1.x to 2.x to make CDI a required dependency).

4) Performance Tuning

JSF has some configurations that can be used for performance tuning, including refresh-period and project-stage context parameters, but as mentioned above, although JSF has been designed on a high level of abstraction and a long list of fancy features, it includes many serious performance issues, including:

1. The overhead of including all the static resources (Images, CSS, and JavaScript) in JSF components tree.
2. Missing standard and transparent caching functionalities for user-interface resources that should remain for a while and be avoiding handling them in JSF tree on every request in the component tree (e.g. dynamic page headers, dynamic footers, and dynamic menus).

III. Recommendations

To achieve the objective of making JSF technology the choice for web-based application development for the different levels of applications, we recommend the following enhancements to JSF:

1. Include the JSF API and implementations into the Servlet containers spec for a better portability.
2. Achieve the “zero-configuration” concept of JSF application
3. Reduce the coupling between the application and the actual JSF UI components by creating a new mapping approach between the tags in the view and the actual components, which should be created into the JSF components tree. This will also solve the issue of head and body tags in the views without the h prefix.
4. The direct access to JSF view pages should be restricted by default, to avoid exposing JSF source code to the client side.
5. The usage of images, CSS, and JavaScript resources shall be done by standard HTML tags not server-side. However, the problem of context path should be handled transparently by the framework.
6. The namespaces definition shall be handled dynamically on the server-side and no need to duplicate it on every page.
7. Default encoding to Servlets should be UTF-8.
8. Create a better mechanism for better JSF profiling (development, testing or production) that doesn’t require editing the web.xml, since most of the time it is miss-used and become hard to maintain.
9. And IDE support should be developed with WYSIWYG approach (e.g. .NET and Visual-Studio approach).

Also, utilizing what has been done by some of the 3^rd party (e.g. OmniFaces and PrimeFaces) will add a great value (e.g. caching, converters, and exception handling).

IV. Smart-Web

Based on the above constraints, limitations, and lessons learned from building JSF projects for different domains (e.g. government, banking, and education) with different scalability levels (e.g. small, medium, and enterprise), I have started Smart-Web, an open-source project with most of the above recommendations implemented.
https://www.smart-api.com/frameworks/smart-eis1/jk-faces/ 

Conclusion

Although JSF has been around for more than 10 years to achieve the objectives of rapid application development for building enterprise-level web applications, there are still many complex steps and constraints facing the developers working on it during all phases of software projects from the analysis to the final implementations. Some of these issues are handled by third-party libraries, some are handled on the application level, and some are still unsolved.

We have proposed some new features and actions to be considered in the future releases of JSF.

Acknowledgment

I would like to thank my dear friend Dr.Muhanna Muhanna, Assistant President for Accreditation and QA, and Assistant Professor at Princess Sumaya University for technology for the auditing and review.

Jalal Kiswani
Oracle Certified Expert, Java Server Faces
Sun Certified Java Programmer
Sun Certified Java Developer
Sun Certified Java Web Component Developer
Sun Certified Java Business Components Developer
Sun Certified Java Associate


Keywords: JSF in real life, JSF design patterns, JSF Best practices