In his blog, Craig McClanahan recounts how, when he joined Sun Microsystems in 2000, he continued to support the development of an open-source application project. As part of that effort, he needed to take a U.S.-centric application and produce it in four languages and make it available to European users on the Web and through other channels.

McClanahan couldn't find a development framework that did what he wanted for the project, so he decided to create his own. "Open-source developers often call this 'scratching your own itch,'" he writes in his blog. The result was Struts.

Framework, as we use it here, refers to a set of libraries or classes for a specific operating system that developers can use to implement the standard structure of an application. Because it bundles a large amount of reusable code, a framework speeds development and saves the developer from having to rewrite standard code for each application.

McClanahan's framework worked well for his application, and he moved to make it an open-source project under the auspices of The Apache Software Foundation, which released it in December 2000.

"What happened next was nothing short of extraordinary," McClanahan writes. "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)." Struts was integrated into many major application servers and tools and was "supported by a rich ecosystem of knowledgeable professionals and skilled developers, backed by significant documentation in the form of books and articles," he explains. It was eventually embraced by a large user community.

The name Struts, incidentally, was picked for its reference to architecture, as a reminder of the unseen pieces that support buildings and bridges, according to McClanahan.

Developing for the Web

Since Struts was developed for building Web applications, it has to handle the "stateless" connection between the client and server, in which the server disconnects as soon as a Web page is presented to the user's browser. Thus, if the user modifies the page (for example, by filling in a form or entering data), the server is unaware of the changes until the browser queries the server again.

Struts deals with this by implementing the model-view-controller, or MVC, design approach. Here, the user interface is decoupled from the data and business logic:

-- Model contains the core of the application's functionality and/or encapsulates the application's state. It doesn't need to know anything about the view or controller.

-- View is the look of the application to the user. The view knows nothing about the controller but can access (though not change) the model. View is implemented with no flow logic, no business logic and no model information -- just JavaServer Pages, HTML pages, style sheets, JavaScript files, Resource bundles, Java beans and JSP tags.

-- Controller manages the whole process by reacting to user input, then initializing and manipulating the model. The controller is typically implemented in Java as a servlet (a Java program that runs on the server; programs that run on a browser are called applets) and is configured by an XML file, struts-config.xml, that contains all necessary routing and configuration information. The controller handles the flow of the application but not the business logic.

Action classes, found in the controller, act as bridges between user-requested URLs and the application components that implement the business logic. Actions take a request and return an ActionForward object that identifies the next component to invoke. That next component might be a full-fledged application, a JavaBean, an Enterprise Java-Bean, a CORBA object and/or a Java data object.

The Struts framework itself, it should be noted, is concerned only with the view and controller pieces; the model elements are completely defined by the developer and will likely be shaped by other software in use, such as database management and enterprise integration systems. In addition to being a development framework, Struts contains an extensive library of XML and JSP tags and utility classes that work independently.

Different Struts

Because of its status as the grandfather of Web application frameworks, the original Struts design predated many of the newer technologies that have since emerged. To keep Struts current, its development in the Apache Struts project now consists of three separate frameworks, two fully implemented and one in transition:

-- Struts Action 1 is the original request-based framework, as described above.

-- Struts Shale is a next--generation, component-based framework for JavaServer Faces, a technology for building user interfaces for Web applications. JSF technology includes a set of APIs and a JSP custom tag library for representing user interface components and managing their state, handling events and input validation, defining page navigation, and supporting localization/internationalization and accessibility. (Echoing the meaning of the geological term, the Shale moniker references the framework's layered approach.)

-- Struts Action 2 is under development. An extension of Action 1, it will incorporate the code of and build on OpenSymphony WebWork (another Java-based development framework), which is now part of the Apache Struts project. Essentially, Struts Action 2 will be what would have been called WebWork 2.3.