Struts Or JSF? Struts And JSF?

Introduction

It should come as no surprise that the most frequent questions I get asked center around the issue of which of these two web tier technologies an organization or individual developer should consider using. It makes sense to ask me, because I was the original creator of the Struts Framework, and was the co-specification lead for JavaServer Faces 1.0 (JSF).

Usually, the question is framed as an or issue, based on an understanding that the two technologies are mutually exclusive. That turns out not to be the case, but it can still be difficult to determine what to do. This blog entry provides my current advice on the subject -- but, to understand it better, it's worth briefly reviewing the development and focus of the two technologies.

The story is a little long compared to typical blog entries; if you want to cut to the chase and see my advice, scroll down to the section entitled The Bottom Line, below.

Struts

Struts grew out of a personal need (open source developers often call this scratching your own itch) to support the development of an application that I was responsible for, prior to joining Sun in 2000. My task was to take a US-centric application to Europe, initially in four languages, and make it available (among other delivery channels) on the web. At the time, there was lots of discussion about appropriate architectures for on the JSP-INTEREST mailing list at java.sun.com, but there were few available implementations. Therefore, I set out to create an application framework for my own use, particularly focused on some key functional areas:

  • An architecture based on the Model-View-Controller design patterns commonly seen in rich client applications, focusing on separation of concerns between presentation logic and business logic.
  • A request processing lifecycle that is applied to all incomding HTTP requests, allowing the centralized management of common functionality like input form validation, and invoking business logic via a logical alias, rather than embedding knowledge of the business tier into a view tier component.
  • Robust support for localizing the user interface of a web application.
  • Since I was planning to use JSP for the view tier, a set of JSP custom tags that simplified the creation of user interfaces based on HTML forms.

The resulting framework served my needs quite well. As it became obvious that my needs were not unique, I began the process of open sourcing this idea of a web application framework at the Apache Software Foundation. What happened next was nothing short of extraordinary -- Struts quickly became the de facto standard web application architecture in the J2EE space (the number of significant Internet applications built with it is substantial, but is dwarfed by the number of intranet applications that use it), integrated into nearly all the major app servers and tools, supported by a rich ecosystem of knowledgeable proffesionals and skilled developers, backed by significant documentation in the form of books and articles, and the basis for a large user community centered around the Struts User mailing list (to subscribe, send an empty message to user-subscribe@struts.apache.org).

As Struts became a common starting point for developers new to the Java platform, an interesting phenomenom was occurring -- for many developers, the key perceived value of using Struts was assumed to be the JSP custom tags for HTML forms. While these tags are quite useful, they do not constitute a robust user interface component model, which has led to the need to create or integrate of third party tag libraries for more complex presentation requirements. To me, the core value has always been in the controller tier (the request processing lifecycle, and the features which this lifecycle has enabled, such as the additions of the Tiles framework for reusable look and feel, and the Validator Framework for client side and server side enforcement of form validation business rules). This perception, then, has led to some of the current confusion.

JavaServer Faces

After Struts was released, and was beginning to demonstrate its popularity, an increasing number of other frameworks and component implementations were becoming available. Indeed, at one point during the development of JSF, I had pointers to over 50 such technologies on a spreasheet being used to survey the market. While a large amount of innovation occurred, it was difficult to forsee the development of a common standard API for user interface components -- one that would enable the creation of a component marketplace where tools vendors could support one component API instead of 50, and where component developers could count on interoperation with many tools instead of one or two.

JSR-127 was introduced with the goal of solving this problem -- providing a common base level API for building user interface components for web applications, with the specific goals of being both accessible to developers writing applications by hand, but also easy to integrate into tools. In order to complete this JSR in any reasonable amount of time (and, if you wish to argue that we didn't achieve this goal, I won't disagree :-), we stayed strictly focused on the view tier. Controller tier functionality was considered out of scope, although to be of any practical use we had to provide hooks for basic things like instantiating objects on demand, as well as support for page navigation.

The focus on the view tier was clear from the feature list for JSF 1.0:

  • Standard component API for user interface components, ranging from simple input fields to more complex tree controls and menus, to sophisticated scrollable tables which allowed both input and output. Components also support standard JavaBeans style events and event listeners.
  • Decoupled rendering model, so that the same component could be rendered in different ways (for example, a command component used to submit a form might be rendered as either a button or a hyperlink).
  • Request processing lifecycle focused on the handling of user interface events (such as the node of a tree control being expanded or contracted), coupled with support for data type conversions and component level validation rules.
  • Utility technologies supporting the component APIs, including value binding and method binding expressions, managed beans (create on demand), and page navigation support.

JSF 1.0 was released in March 2004, followed by a maintenance release (1.1) in May, and is being rapidly adopted by tools vendors, component writers, and application developers alike. The beginnings of widespread adoption are clearly occurring, and any application which you are about to start should certainly evaluate JSF to see if it meets your needs. Besides the functional APIs described above, you will enjoy the availability of robust tools support from many vendors (shamless plug -- including the product I am currently an architect for, Sun Java Studio Creator).

The Bottom Line

But what about all those existing Struts applications? Are they going to get left out in the cold, or the developers forced to abandon their existing code and rewrite it? Nothing could be further from the truth.

The ideal scenario for existing Struts applications would be that we should be able to migrate, one page at a time (nobody has time to replace their entire UI in one fell swoop) to using JSF component tags -- either the standard ones shipped with JSF, or from any available third party component library -- to improve the richness of the user interface. And, because of the original MVC-based promise of separation of concerns, this migration should require little or no change in the back end functionality of the application (for Struts, that primarily means Action and ActionForm classes). Also, the migration should not eliminate the ability to use key Struts features like Tiles and the Validator Framework.

This scenario is, in fact, achieveable. In the Struts source repository is the Struts-Faces Integration Library, that achieves exactly this goal. It is currently available in nightly builds, but will shortly be released as a stand-alone add on library for Struts 1.1 or 1.2 based environments. The nightly builds include two versions of the canonical Struts example application, one using Tiles and one not, both using the Validator Framework.

If you have an existing Struts based application, then, I encourage you to evaluate a migration towards using JSF components instead of the original Struts HTML tags. Not only are the original tags effectively superceded by JSF, they are also not undergoing active development at the moment. You will find effectively equivalent functionality in JSF components already available, and much more sophisticated user interface components under development by many providers, for use in the future.

For new development, here's the best strategy for determining what to do:

  • Evaluate the two technologies individually, to see if they satisfy your requirements.
  • If one or the other technology is sufficient, go ahead and use it (it's easier to learn and use one technology rather than two where possible); keeping in mind, however, the caveats about Struts HTML tags mentioned above.
  • If your requirements include unique features supported only by Struts (such as Tiles or client side validation support), feel free to use the two frameworks together.

The Future

It should be clear by now that there is overlap between Struts and JSF, particularly in the view tier. Over time, JSF will continue to evolve in the view tier area, and I'm going to be encouraging the Struts community to focus on value adds in the controller and model tiers. Thus, it will become more and more clear that there is room in many web application architectures for two frameworks, each focused on their own tiers, cooperating to meet overall architectural requirements. The details of this, however, will be the subject of further discussions on the Struts developer mailing list, and (undoubtedly) future blog entries.

Comments:

How about using Spring Framework and thus, unlike Struts, make your code testable and web layer independant? I do think in all honesty that Spring Framework simply destroys the value of Struts and JSF.

Posted by guest on September 27, 2004 at 12:12 PM PDT #

It may well be that the Spring Framework's MVC implementation is competitive with Struts at a technical level (although the market adoption ratio is dramatically in the favor of Struts), but I don't see the Spring team thinking that they are destroying the value of JSF. Indeed, they recently announced an integration between JSF and the Spring Framework's IoC mechanisms, providing bidirectional use of JSF managed beans and Spring beans in either sort of application.

For more information, see the JSF-Spring project web site.

Craig

Posted by Craig McClanahan on September 27, 2004 at 12:57 PM PDT #

It may well be that the Spring Framework's MVC implementation is competitive with Struts at a technical level (although the market adoption ratio is dramatically in the favor of Struts), but I don't see the Spring team thinking that they are destroying the value of JSF. Indeed, they recently announced an integration between JSF and the Spring Framework's IoC mechanisms, providing bidirectional use of JSF managed beans and Spring beans in either sort of application.

For more information, see the JSF-Spring project web site.

Craig

Posted by Craig McClanahan on September 27, 2004 at 03:28 PM PDT #

What bothers me is that you keep mentioning for over a year now the struts-jsf library but it's amzingly buggy and i don't see much progress being made. I gave up on struts and moved to JSF-spring.

Posted by guest on September 27, 2004 at 04:31 PM PDT #

Excellent. I look forward to digging into this. I know I will have clients that want to use this integration lib. I've dug into earlier versions with varied success. The navigation flow in JSF (jsf-config.xml) seems much more natural than the Struts action mappings. Why would I use Struts action-mappings in place of JSF navigation rules? I've been using JSF with Tiles. The two seem to play well together already. I've used Struts and JSF in application without this integration library with success. I don't feel this is a requirement for including JSF with a Struts app. Am I wrong? What is the real value add of the jsf-struts integration lib? I think I know, but would love to hear it from you. If you have time. Thx

Posted by Rick Hightower on September 28, 2004 at 06:56 AM PDT #

additional thoughts on the subject

Posted by Rick Hightower on September 28, 2004 at 07:17 AM PDT #

Controller tier functionality was considered out of scope, although to be of any practical use we had to provide hooks for basic things like instantiating objects on demand, as well as support for page navigation.
I believe this is the main thing people should consider while looking at Struts (or any other similar framework, like Spring MVC), and JSF.
JSF -I believe- needs this Controller thing, and I think that will be the case in all real projects.
Ramy

Posted by Ramy M. Kamel on September 28, 2004 at 05:05 PM PDT #

"Controller tier functionality was considered out of scope, although to be of any practical use we had to provide hooks for basic things like instantiating objects on demand, as well as support for page navigation."
But providing those hooks, don't you think you provided a controller that will meet 95% of the needs of web applications?
So, most people won't need Struts anymore since JSF view components are better than Struts' and JSF controller is sufficient, will they ?

Posted by benb on September 28, 2004 at 06:11 PM PDT #

I'm a firm believer that the controller does belong as a separate entity from JSF. I like Struts for it's simplicity but I'm well aware of the shortcomings.
I think that we're now at a crucial time in the evolution of web app development - vendors are already producing tooling for Faces in their IDEs and the chances are most of those will \*de facto\* based around Faces Navigation (just like Studio Creator is) and before you know it the controller, as we know it, will disappear from the stack - to no one's benefit in the long run. Now is the time to start thinking about formalising the role and specification of the Controller, from the Struts point of view I think that the time is moot - this would give Struts 2.0 direction and focus as a potential RI. It would be great to finalise the standardisation of the whole MVC stack for Web Apps: Faces for the View, JSR227 for the Model Bindings, EJB 3.0 for persistence and something new for the controller

Posted by Duncan Mills on September 28, 2004 at 06:16 PM PDT #

"(the number of significant Internet applications built with it is substantial, but is dwarfed by the number of intranet applications that use it)" Now this is one question that I am asked usually. Why isn't Struts popular in a B2C scenario ? What are the internet applications that you are talking about ? I usually answer that I can't see any serious Struts drawback in an internet application like amazon or ebay. What do you think ?

Posted by Mohan Radhakrishnan on September 29, 2004 at 03:20 PM PDT #

gh

Posted by guest on September 30, 2004 at 02:15 PM PDT #

Hi; I have divided my application in 4 layers : GUI, services, busines objects and DAO (access to database). I would like to use a framewok : struts or another and my question : Which is the best architecture ? for example GUI will be realize via JSP or JSF, DAO with EBJ entity or JDO, etc... My application use much of the GUI. Regards;

Posted by how implemented software layers on September 30, 2004 at 11:40 PM PDT #

We run with Struts, Spring and Hibernate .. and its a heavy loaded web page .. specially introducing Spring and Hibernate six months ago gave us an incredible performance and just-in-time development boost.

Posted by guest on October 22, 2004 at 12:33 AM PDT #

Well, I have been working in the development business for more than 5 years but I've never heard of Struts. Thank you for enlightning me.

Posted by Larry, web designer on December 19, 2004 at 10:17 PM PST #

Post a Comment:
Comments are closed for this entry.
About

craigmcc

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today