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.
Problem: JSP Unfriendly to Component-Based Frameworks
JSP is the primary view choice for JSF apps, but it's clunky at best. Most frameworks that use JSP simply render values as they encounter them when loading a page. Relationships between portions of a page will only occur at the HTML level, rather than on the server-side.
JSF has a different model - it builds a component tree when a page loads. JSP adds page components to the tree in the order they appear on the page. This makes it difficult to create relationships between components, such as labels and input fields. To work around this, you can wrap your forms with an <h:panelGrid> tag, but then you have to remove any HTML from your form (or wrap it with an <f:verbatim> tag). You end up with a JSP page that doesn't have a single line of HTML in it. In other words, you're back to the pre-JSP days with JSF, where Java code, rather than HTML authors produce the entire HTML.
Solution: HTML Templates
The good news is that JSP isn't the required view technology for JSF. It was simply chosen because of the proliferation of JSP-based apps and because so many developers were familiar with it. JSF 1.2 lets JSF use HTML Templates like Tapestry does. These templates will either reuse existing HTML attributes (such as id), or add an additional one (such as jwcid). Hans Bergsten provides an example of this in his "Improving JSF by Dumping JSP" article. An Open Source project called Facelets (http://facelets.dev.java.net) also implements such a solution.
JSF doesn't just render HTML; that's just one of the possible render kits. In theory, it's possible to create render kits for all kinds of view options: XUL, J2ME, or even Laszlo.
The Future of J2EE's Web Tier
The future of J2EE's Web Tier depends largely on JSF - at least from a standards perspective. However, many popular Open Source alternative Web frameworks are available, such as Spring MVC, Struts, Tapestry, and WebWork. These frameworks have already helped shape the future of J2EE's Web Tier. JSF incorporates many of the ideas and features of Struts. The managed properties of a JSF Managed Bean are very much like Spring's Dependency Injection. A JSF Managed Bean looks very similar to a WebWork Action. JSF mimics many of the concepts in Tapestry to enhance its ease of use, such as a rich set of components and HTML templating. Furthermore, all of these frameworks are part of J2EE in a sense, since they build on top of J2EE's Servlet API. Without J2EE, these frameworks probably wouldn't exist in their current form. Likewise, J2EE wouldn't be where it is today without these frameworks and the innovation and competition they've provided.
Having choice among frameworks is a good thing because it forces framework developers to innovate and compete for users. Not only do the different frameworks show different ways of doing things, but they're also borrowing from and competing with one another to become better. Competition breeds innovation. J2EE stands to benefit from this innovation because the good ideas can be added to JSF and the bad ones can be removed. The Java Community Process and Expert Groups for J2EE and JSF are very open to the community, so the community will contribute and help improve it, much like they have with the many Open Source alternatives.
All of the frameworks mentioned do the same thing, just in different ways. JSF and Tapestry are making developing Java Web applications easier due to smarter defaults and better plumbing. They don't require the developer to know much about the Servlet API, and they handle most input types transparently - without using custom converters. Furthermore, their concept of components lets developers create reusable components that they can use with only a few lines of code.
The future of J2EE's Web Tier isn't one of self-determination. Many other factors will play into the success of a standardized Web framework. J2EE and its developers can ensure its continued success on the Web by being willing to adapt. As a community, we need to continue to recognize good technologies and ideas from experienced developers and Open Source projects. We need to be willing to support remote scripting with Ajax, and we need to adapt to produce rich-client experiences, like those that Laszlo offers with the Open Source Flash-rendering system. By accepting and enhancing these technologies, we can continue to use J2EE and its APIs to make our lives easier. By developing more efficiently with the best technologies available in Java, we can continue to produce satisfied customers.