Why Servlets Are Not Dead
The advent of JSP was first thought to be the end of the day for servlets. It turned out this was not the case. JSP did not displace servlets. In fact, today real-world applications employ both servlets and JSPs. To understand why servlets did not become obsolete after the arrival of JSP, you need to understand two design models upon which you can build Java web applications.
The first design model, simply called Model 1, was born right after the JSP was made available. Servlets are not normally used in this model. Navigating from one JSP to another is done by clicking a link on the page. The second design model is named Model 2. You will learn shortly why Model 1 is not recommended and why Model 2 is the way to go.
The Problems with Model 1
The Model 1 design model is page-centric. Model 1 applications have a series of JSPs where the user navigates from one page to another. This is the model you employ when you first learn JSP because it is simple and easy. The main trouble with Model 1 applications is that they are hard to maintain and inflexible. On top of that, this architecture does not promote the division of labor between the page designer and the web developer because the developer is involved in both page authoring and business logic coding.
To summarize, Model 1 is not recommended for these reasons:
• Navigation problem. If you change the name of a JSP that is referenced by other pages, you must change the name in many locations.
• There is more temptation to use scriptlets in JSPs because JavaBeans are limited and custom tags are hard to write. However, as explained above, mixing Java code and HTML in JSPs is a bad thing.
• If you can discipline yourself to not write Java code in JSPs, you’ll end up spending more time developing your application because you have to write custom tags for most of your business logic. It’s faster to write Java code in Java classes.
Model 2
The second design model is simply called Model 2. This is the recommended architecture to base your Java web applications on. Model 2 is another name for the Model-View-Controller (MVC) design pattern. In Model 2, there are three main components in an application: the model, the view, and the controller.
Note
The term Model 2 was first used in the JavaServer Pages Specification version 0.92.
In Model 2, you have one entry point for all pages and usually a servlet or a filter acts as the main controller and JSPs are used as presentation. Compared to Model 1 applications, Model 2 applications enjoy the following benefits.
• more rapid to build
• easier to test
• easier to maintain
• easier to extend
Struts Overview
Now that you understand why Model 2 is the recommended design model for Java web applications, the next question you’ll ask is, “How do I increase productivity?”
This was also the question that came to servlet expert Craig R. McClanahan’s mind before he decided to develop the Struts framework. After some preliminary work that worked, McClanahan donated his brainchild to the Apache Software Foundation in May 2000 and Struts 1.0 was released in June 2001. It soon became, and still is, the most popular framework for developing Java web applications. Its web site is http://struts.apache.org.
In the meantime, on the same planet, some people had been working on another Java open source framework called WebWork. Similar to Struts 1, WebWork never neared the popularity of its competitor but was architecturally superior to Struts 1. For example, in Struts 1 translating request parameters to a Java object requires an “intermediary” object called the form bean, whereas in WebWork no intermediary object is necessary. The implication is clear, a developer is more productive when using WebWork because fewer classes are needed. As another example, an object called interceptor can be plugged in easily in WebWork to add more processing to the framework, something that is not that easy to achieve in Struts 1.
Another important feature that WebWork has but Struts 1 lacks is testability. This has a huge impact on productivity. Testing business logic is much easier in WebWork than in Struts 1. This is so because with Struts 1 you generally need a web browser to test the business logic to retrieve inputs from HTTP request parameters. WebWork does not have this problem because business classes can be tested without a browser.
A superior product (WebWork) and a pop-star status (Struts 1) naturally pressured both camps to merge. According to Don Brown in his blog (www.oreillynet.com/onjava/blog/2006/10/my_history_of_struts_2.html), it all started at JavaOne 2005 when some Struts developers and users discussed the future of Struts and came up with a proposal for Struts Ti (for Titanium), a code name for Struts 2. Had the Struts team proceeded with the original proposal, Struts 2 would have included coveted features missing in version 1, including extensibility and AJAX. On WebWork developer Jason Carreira’s suggestion, however, the proposal was amended to include a merger with WebWork. This made sense since WebWork had most of the features of the proposed Struts Ti. Rather than reinventing the wheel, ‘acquisition’ of WebWork could save a lot of time.
As a result, internally Struts 2 is not an extension of Struts 1. Rather, it is a re-branding of WebWork version 2.2. WebWork itself is based on XWork, an open source command-pattern framework from Open Symphony (http://www.opensymphony.com/xwork).
So, what does Struts offer? Struts is a framework for developing Model 2 applications. It makes development more rapid because it solves many common problems in web application development by providing these features:
• page navigation management
• user input validation
• consistent layout
• extensibility
• internationalization and localization
• support for AJAX
Because Struts is a Model 2 framework, when using Struts you should stick to the following unwritten rules:
• No Java code in JSPs, all business logic should reside in Java classes called action classes.
• Use the Expression Language (OGNL) to access model objects from JSPs.
• Little or no writing of custom tags (because they are relatively hard to code).
Upgrading to Struts 2
If you have programmed with Struts 1, this section provides a brief introduction of what to expect in Struts 2. If you haven’t, feel free to skip this section.
• Instead of a servlet controller like the ActionServlet class in Struts 1, Struts 2 uses a filter to perform the same task.
• There are no action forms in Struts 2. In Struts 1, an HTML form maps to an ActionForm instance. You can then access this action form from your action class and use it to populate a data transfer object. In Struts 2, an HTML form maps directly to a POJO. You don’t need to create a data transfer object and, since there are no action forms, maintenance is easier and you deal with fewer classes.
• Now, if you don’t have action forms, how do you programmatically validate user input in Struts 2? By writing the validation logic in the action class.
• Struts 1 comes with several tag libraries that provides custom tags to be used in JSPs. The most prominent of these are the HTML tag library, the Bean tag library, and the Logic tag library. JSTL and the Expression Language (EL) in Servlet 2.4 are often used to replace the Bean and Logic tag libraries. Struts 2 comes with a tag library that covers all. You don’t need JSTL either, even though in some cases you may still need the EL.
• In Struts 1 you used Struts configuration files, the main of which is called struts-config.xml (by default) and located in the WEB-INF directory of the application. In Struts 2 you use multiple configuration files too, however they must reside in or a subdirectory of WEB-INF/classes.
• Java 5 and Servlet 2.4 are the prerequisites for Struts 2. Java 5 is needed because annotations, added to Java 5, play an important role in Struts 2. Considering that Java 6 has been released and Java 7 is on the way at the time of writing, you’re probably already using Java 5 or Java 6.
• Struts 1 action classes must extend org.apache.struts.action.Action. In Struts 2 any POJO can be an action class. However, “Actions and Results” it is convenient to extend the ActionSupport class in Struts 2. On top of that, an action class can be used to service related actions.
• Instead of the JSP Expression Language and JSTL, you use OGNL to display object models in JSPs.
• Tiles, which started life as a subcomponent of Struts 1, has graduated to an independent Apache project. It is still available in Struts 2 as a plug-in.
References:
Struts 2 Design and Programming: A Tutorial
By: Budi Kurniawan
