Over the course of its life, the J2EE Web Tier has faced many challenges in easing Web application development. While it's a scalable, enterprise-ready platform, it isn't exactly developer-friendly. Particular challenges to Web developers include the need for a standard Web framework, compatible expression languages, and availability of components. Several Web frameworks have been developed to resolve these issues, each with its own strengths and weaknesses. This article discusses the unique challenges of the J2EE Web Tier and how various technologies have attempted resolve them. By learning from and competing with each other, these Web technologies play an important role in pushing the limits of excellence to produce ever-higher standards of Web application development.

Problem: Too Many Frameworks for J2EE
A plethora of frameworks is available for building Java-based Web applications. Most of the Web frameworks in Java result from the difficulty in using servlets and JSPs, which are part of the J2EE standard. While servlets and JSPs serve as the underlying APIs for most frameworks, they don't have any built-in features to ease development. Using plain servlets and JSPs is cumbersome, and you end up writing a lot of plumbing code, when you should be writing application code. By using a Web framework, you can concentrate on coding your application, rather than the architecture that makes it work.

Over 50 Java Web frameworks exist to make the developer's life easier. It begs the question, "Why not have a standard Web framework as part of J2EE?"

Solution: A Standard Framework Called JavaServer Faces
At the JavaOne Conference in 2002, Sun Microsystems announced the development of a standard Web framework to include as part of the J2EE bundle. Its name was JavaServer Faces (JSF) and it was designed to put a pretty face on developing Web applications in a J2EE environment.

JSF was developed to be tool-friendly, so IDE vendors could create WYSIWYG environments where developers could drag-and-drop their applications into a usable system. Microsoft has always had good tools for its technologies, and Sun wanted to fuel innovation in the Java IDE space to produce tools similar to Visual Studio .NET.

JSF's architecture is similar to ASP.NET, which is more page-centric than controller-centric. Controller-centric frameworks make requests go through a front-controller servlets that dispatches requests to smaller "worker" servlets. In Spring MVC, these workers are controllers, while in Struts and WebWork they're actions. A worker servlet will typically put things in the request for the view to render. On the other hand, JSF is page-centric. This means that users will typically navigate to a template page in the application rather than go through a worker servlet. JSF pages are backed by classes that contain data and actions that the UI can invoke. These actions are also known as listeners and contain logic that ties the class to a backend system.

Early Challenges of JSF
The development of JSF went through some challenging times. Sun announced it in June 2002, but didn't release its initial 1.0 version until March 2004. During that time, many other Java Web frameworks cropped up and JSF got some bad press. The spec changed significantly between iterations, and it often lacked backward compatibility. Authors and publishers produced books that were out-of-date before they were released. Developers who tried to work with JSF often found that the functionality didn't work according to the documentation. Furthermore, since Sun architected JSF with tools vendors in mind, some developers (who were used to coding their JSPs by hand) became frustrated with JSF's verboseness.

While JSF was being developed, so were JSP 2.0 and its Expression Language (EL). JSP's EL made retrieving values and resolving variables easier. Rather than using <jsp:useBean> and <jsp:getProperty>, a developer could simply use ${bean.property} to retrieve a property from a JavaBean. Developers could also use the new EL with the Java Standard Tag Library to implement iterations, calculations, internationalization (i18n), and number/date formatting.

Ideally, JSF would have used the JSP 2.0 EL syntax to resolve variables and expressions. However, JSF's Expression Language didn't have some of the concepts that existed in JSP's EL. First, it didn't have a page scope like the EL did. Second, JSF Expressions were often formulas (the left side of the equation) rather than solutions (the right side). For example, in JSP EL, the following expression means "call getAction() on the userForm bean in any scope."

${userForm.action}

While the same expression in JSF's EL can mean the same thing, it can also be an invocation of a method such as "call the action method of the userForm bean."

#{userForm.action}

To complicate things further, developers were demanding a workable version of JSF. The JSF Expert Group didn't want to wait for JSP 2.0 and J2EE 1.4 to be finished, so they created their own expression language, hereafter referred to as JSF EL.

Problem: JSF EL vs JSP EL
For the most part, the JSF EL hasn't affected other Web frameworks because it's JSF-specific; however, the lack of compatibility between the two expression languages (JSTL and JSF) has been a point of developer contention and frustration. JSTL has been one of the most widely accepted and praised additions to the Servlet API, but it didn't work with JSF as many expected.

The JSP EL has also produced some problems for framework developers who support JSP as a view choice. Mainly, some framework developers can no longer use the ${...} syntax as a placeholder to indicate variables. Since these placeholders are reserved for JSP 2.0, if the framework resolves variables outside of the standard scopes (page, request, session, application), variable resolution will simply fail. Frameworks like WebWork and Tapestry use OGNL as their expression language, and they resolve variables according to a ValueStack and component hierarchy, respectively.

Note: OGNL stands for Object-Graph Navigation Language. It is an expression language for getting and setting the properties of Java objects. You use the same expression for both getting and setting the value of a property. OGNL is more powerful than the JSP/JSTL Expression Language. Not only can it get and set values, it can invoke methods. Furthermore, OGNL expressions can contain almost any Java code.

Solution: A Unified Expression Language
To solve the disconnect between JSF EL and JSP EL, the JSP 2.1 and JSF 1.2 specifications have created a Unified Expression Language. If you're using a JSF 1.2 implementation, you can use JSP expressions in your JSF applications. It also adds a variable resolver to JSP. This means that frameworks like WebWork can control what ${...} means and tell it to talk to its ValueStack instead of the standard scopes. This is important for many framework developers because they don't want to invent their own syntax for resolving expressions. The new JSP and JSF versions are part of J2EE 5.0 and will be required by any J2EE 5.0-compliant containers.