Flex, Java/JavaFX, Silverlight, AJAX & RIA Frameworks

RIA Developer's Journal

Subscribe to RIA Developer's Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get RIA Developer's Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


RIA & Ajax Authors: Javier Paniza, Pat Romanski, RealWire News Distribution

Related Topics: RIA Developer's Journal, Java EE Journal

RIA & Ajax: Article

Challenges in the J2EE Web Tier While Frameworks Driving Innovation

Several Web frameworks have been developed to resolve these issues, each with its own strengths and weaknesses

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.

More Stories By Matt Raible

Matt Raible is a J2EE consultant and developer living in Denver, Colorado, and the Spring and Web Frameworks Practice Leader for Virtuas. He has been developing Java Web applications since 1999 and is president of Raible Designs, Inc. He is also a member of the J2EE 5.0 Expert Group and hopes to help them make J2EE easier for developers. Matt is the author of Spring Live (SourceBeat Publishing).

Comments (3) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Mallesham Karnati 09/02/05 10:24:57 AM EDT

Nice analysis of the web frameworks. Can you write another piece on JSF exclusively giving some simple application as an example?

Raible Designs ~ We Build Web Apps 08/10/05 06:19:41 PM EDT

Trackback Added: First Magazine Article: Challenges in the J2EE Web Tier; It's official - I've written (and published) my first article in a magazine. If you received the July issue of Java Developer's Journal, you'll see my article titled Challenges in the J2EE Web Tier .

Over the course of its life, the J2EE Web Tier h

JDJ News Desk 07/18/05 09:37:08 AM EDT

Challenges in the J2EE Web Tier As Frameworks Driving Innovation. 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.