Although this book is dedicated to the Jakarta Struts framework, Struts is far from the only Java Web framework available. There are quite a few available, each with their own proponents and evangelists.
Because framework versions and features may change with each new release, it’s not always practical to compare and contrast Struts simply by reading these descriptions; you should conduct your own research with the latest stable versions of framework alternatives. This list is by no means exhaustive, but it will provide you with a launching pad.
Note that only solutions based on or around the Java platform are listed here. Microsoft also offers a competing technology based on Active Server Pages (ASP). Although the goal of ASP is similar to that of JSP, ASP and ASP+ are not discussed here—they’re better left for a book on JSP and servlets. Furthermore, the Struts framework goes well beyond what is offered by JSP alone, and comparing ASP or other technologies similar to Struts wouldn’t make sense.
Microsoft also has also introduced an “Application Block” called User Interface Process (UIP). UIP shares some of the same goals as MVC frameworks like Struts, but is meant for use with for the .NET programming model. Although interesting, it won’t be presented here either.
At first, it might seem strange to include building your own framework as an alternative to using Struts. Why would you want to build frameworks from scratch when they already exist in readily-available products? The answer is the same reason that other open source or commercial products are developed. The available selection of products just might not be close enough to your desired framework, and it might be preferable to build it in-house.
The best advice I can give regarding building your own framework is to ask yourself several questions:
Have I taken the time to inspect what’s available and build a prototype using an available framework?
What does my application need that doesn’t exist in one of the available frameworks?
Can I extend an existing framework to suit my needs or find what I need at another source and add it?
Do I know enough about building this type of framework to be able to meet my requirements?
Am I willing to provide support for bug fixes and feature enhancements for my framework for at least one year?
Depending on the honest answers to these questions, you might find that building your own framework isn’t the best decision. A good guideline to which many in the software-development industry subscribe is that if it pertains to your core business, you should build it in-house. However, if the software component is not directly related to your core business, it might be wise to get it elsewhere. Play to your team’s strengths and minimize its weaknesses.
The Barracuda presentation framework is a type of Model 2 architecture similar to Struts, but it goes a step further and provides a model event-notification mechanism. Unlike a strictly JSP approach, the Barracuda framework has created a template engine component, which is supposed to allow for more flexibility and extensibility. The framework leverages code-content separation provided by the XMLC approach of creating user interfaces. XMLC is a Java-based compiler that uses either an HTML or XML document and creates Java classes that can recreate the document when executed. The generated Java classes can be used to insert dynamic content into the document at runtime by manipulating Document Object Model (DOM) interfaces. The separation of markup and application logic allows web designers to focus on markup and programmers to focus on coding. It also includes a Form mapping and Validation package for taking HTML form data and automatically validating it.
The available documentation for Barracuda is abundant, which makes it easy to get started. You can find more information on the Barracuda presentation framework at http://barracudamvc.org/Barracuda/index.html.
Stefano Mazzocchi founded the Cocoon project in January 1999 as an open source project under the ASF. The goal of Cocoon is to help separate the content style, logic, and management functions for XML-based web sites. Cocoon leverages XML, Extensible Stylesheet Language Transformations (XSLT), and Simple API for XML (SAX) technologies to help create, deploy, and maintain XML server applications. With the release of 2.0, Cocoon has been raised to a higher level by providing a pipeline-style of assembling components. This allows for easier assembly of its various components and allows Cocoon to fit inside your existing web architecture.
Most types of data sources, including RDBMS, LDAP, and File Systems, are supported. More information on Cocoon can be found at http://cocoon.apache.org.
The Expresso framework from Jcorporate is an application development framework that provides a component-based framework for developing applications. It provides a set of core components, compatible with both EJB and non-EJB applications alike. Although completely independent of Struts and other frameworks, the Expresso components can also be integrated into Struts in order to add security capabilities, object-to-relational mapping, background job handling and scheduling, and many other features. More information on the Expresso framework can be found at http://www.jcorporate.com.
These three products are grouped together because they all represent similar types of template engines.
Freemarker is an open source HTML template engine for Java servlets. With Freemarker, you store the HTML in templates, which eventually get compiled into template objects. These template objects then generate HTML dynamically, using data provided by servlets. Freemarker uses its own template language and claims speeds approaching those of static HTML pages. The software is free and licensed under a BSD-style License. You can find more information about Freemarker at http://freemarker.sourceforge.net.
Velocity is another Jakarta project like Struts. It is a Java-based template engine that is similar in many ways to Freemarker, but it is capable of more than just creating dynamic content for web sites. Velocity can generate SQL, PostScript, and XML from templates, for example, and can be used either as a standalone utility for generating source code and reports or as an integrated component of other systems. Velocity also provides template services for the Turbine web application framework. Many other frameworks either support the Velocity scripting syntax or actually depend on it. For more information on Velocity, go to http://jakarta.apache.org/velocity.
WebMacro is an open source Java servlet framework used by several large web sites. The WebMacro framework uses a lightweight scripting language that allows separation of how a page looks from the page logic. WebMacro can be run in standalone mode or with a servlet container. More information about WebMacro can be found at http://www.webmacro.org.
The Maverick MVC framework offers the ability to render views using JSP, the Velocity scripting language, or XSLT. Maverick is an MVC-type architecture, but it actually provides a view template mechanism. One neat feature of Maverick is that it can use reflection on JavaBeans in the presentation layer to create a DOM interface, so no XML generation or parsing is required. This allows for a little less clutter and probably better performance when using XSLT to generate the views. You can find more information on the Maverick framework at http://mav.sourceforge.net.
SiteMesh is a web page layout and integration system that makes it easier to create web sites that need a consistent look and feel. SiteMesh intercepts requests to any web page, whether it’s static or dynamically generated, parses the content, and generates a final page. This process is based on the well-known Decorator pattern.
SiteMesh is built with Servlet, JSP, and XML technologies, which makes it appropriate for J2EE applications. However, it also claims to be easy to integrate with other web technologies, such as CGI. More information on SiteMesh can be found at http://www.opensymphony.com/sitemesh.
Turbine appears to be focused on providing a collection of reusable components. A large set of components is included with the framework, including components for using relational databases, security, and scheduling—just to name a few. More information on Turbine can be found at http://jakarta.apache.org/turbine.
WebWork has now moved under the umbrella project known as OpenSymphony. OpenSymphony is a SourceForge project dedicated to providing open source J2EE applications and components. You can find information on OpenSymphony at http://www.opensymphony.com.
WebWork is a web application framework that uses the Pull Hierarchical Model View Controller (HMVC) design. With a standard MVC design, changes made to the model are pushed to the view. In the case of WebWork, the views pull the data when they need it. Interestingly, WebWork doesn’t seem to be tied to a servlet; therefore, it can support other types of clients such as Swing. More information on the WebWork framework can be found at http://www.opensymphony.com/webwork.
Spring is a relatively new J2EE application framework developed by Rod Johnson and included in his J2EE design book. Spring is not just a web framework—it’s strength lies in the ability be integrated with other disparate components. More information on Spring can be found at http://www.springframework.org.
In 2001, a new Java Specification Request (JSR) was issued for a new Java technology called JavaServer Faces (JSF). The goal of this JSR is to lessen the burden on Servlet and JSP developers by providing a standard set of JSP Tags and classes to aid in the management of complicated HTML forms, event handling, and presentation state. The proposal also attempts to account for various platforms and client types by allowing pluggable rendering kits.
The JSR defines the architecture and a set of APIs for the creation and maintenance of Java server web applications—it’s simply a set of standard APIs, not an actual implementation. Vendors can create their own implementations, so developers have more than one implementation to choose from.
The JSR indicates that the creators of JSF are aware that other projects (such as Struts) already have addressed many of the problems that this specification attempts to solve. The JSR is aimed at creating a standard that will help unify this fragmented area. Keep your eye on this specification, as it may have a huge impact on Struts and the entire web application area as a whole. The good news for Jakarta Struts users is that one of the primary authors of Struts, Craig McClanahan, is co-specification lead for JavaServer Faces. His influence will surely help ensure a smooth transition for the Struts framework.
At the time of this writing, the Java Specification Request (JSR) has moved past the 2nd public review and a final specification is expected in the near future. More information on the specification can be found in Chapter 18 and online at http://www.jcp.org/jsr/detail/127.jsp.
 The Decorator pattern is a structural design pattern mentioned in the book Design Patterns (Addison Wesley), by Gamma, Helm, Johnson, and Vlissides, affectionately known as the “gang of four.”