WanTii, Inc. Tech Blog

At this point, you may have read the first part of the series and thought, “Well… That’s nice, but it doesn’t really help me create a Struts2-based web-app.” If you were hoping to read that post and then go and create the next flickr.com, then I apologize. In case you have not figured it out yet, Struts2 is a complex framework. On the Strut2 mailing list, I constantly here people asking, “Where do I start?” My hope is that this series will give people an answer to that question. But, getting started is tougher than it sounds.

Before we get to the coding, let’s talk about the Struts2 architecture. At this point, if you are unfamiliar with Model 2 and MVC, then check out this post. Struts2 handles requests in a way that is different than other frameworks. Although the request processing in Struts2 may seem proprietary, it is also one of Struts2’s biggest advantages. The first and most important feature of Struts2 is that it is designed to incorporate Plain Ol’ Java Objects (POJOs) into it’s processing. This seems awkward to experienced Java/JSP developers because they are used to having access to the objects defined in the JSP and Servlet specs. Objects like “request,” “response,” and “session” are available with a bit of effort, but I would advise against using them because you will be placing a dependency on a Servlet container that is usually not necessary.

Let’s consider a simple browser request. The request comes in to the application server and the application server will hand it off to the Struts2 filter. The Struts2 filter will take a look at the request and check through it’s configuration for instructions on what to do with it. First, Struts2 will begin applying the “interceptors” to the request. The Struts2 interceptors act like filters. If some processing needs to be performed on all or a related group of requests, it is better to create an interceptor. Interceptors are configured as “stacks” so that one or more stacks can be injected into the processing logic. Struts2 comes with a slew of useful interceptors that control the behavior of the framework. As an example, there is an internationalization interceptor that will peak at the incoming request to find out which language to present in the response.

After all of the configured interceptor stacks and interceptors have performed their processing on the request, the Struts2 filter will then decide which “Action” to launch. If interceptors are like filters, then actions are like servlets. I am tempted to say that the Struts2 Action is where the processing happens, but an action should act more as a proxy into your business logic. Struts2 Actions are much simpler than Struts1 actions. Struts2 Actions are not dependent on objects like request and response the way that the Struts1 Actions are. A simple rule of thumb is that an action should retrieve the parameters and push the data into your business objects for processing. Tasks like persistence, RMI, emailing, etc. should all take place outside of the action. For example, imagine you are working on an e-commerce project and you must handle the credit card authorization. A JSP/Servlet developer will be tempted to take the parameters from the request and write the code for submitting the authorization request all within a CC_Verify Servlet. Putting all of that logic into the action code is poor design (after having used the Struts2 framework for a while, I would consider putting it all in a Servlet to be bad design as well). By creating business objects for the credit card authorization request, you will be able to write unit tests and maintain a stable library which can be used inside of the Struts2 framework and even outside the framework (like in a back-end script). The action should be in charge only with taking the parameters sent from the user and passing them off to your business objects.

This all sounds fine and dandy, but why would you go through the extra work of creating so many objects? This separation will create an application that is easier to maintain. When we (finally) start to look at some code, you will see just how well suited actions are at providing this “middle layer.” Actions work closely with the “Views” (JSP, freemarker templates, velocity templates, etc.) that are displayed to the web browser. The actions can be configured to validate the data passed to them as well. Once the action has completed it’s work, it will return a value that the Struts2 filter will read and based on that return value, a view will be picked to be displayed. This concept is familiar to Struts1 developers, but as you will see later, the code and configuration is much simpler in Struts2 than it is in Struts1.

At this point, the last step in the request processing is the presentation of the “View.” To keep things simple, let’s assume for a bit that our views are going to be JSPs. Although there are many different technologies available to present views, most of the time you will use a JSP. The views are similar to normal JSPs, but there are a few added features. One big feature is that the action being requested is placed onto the “Value Stack.” This allows you to use Struts2 tags to access data from the action very easily. Another feature is the availability of the Struts2 tags. There are tags for conditional processing, looping, AJAX and form validation. As you will see when we are coding actions and views, these tags are the perfect blend of functionality and versatility.

So, to sum up the Struts2 architecture, the Struts2 filter calls the interceptor stack, then hands the request to an action which will process the parameters and pick a view to present. In the next part of the series, we will compare Struts2 code with raw JSP/Servlet code.