Annexed is an overview of the Struts architecture that I put together for my spec. I'd be very interested in any comments or criticisms, or anything I've got totally wrong. Of course, if anyone wants to use any part of this for their own project, please do. I'm now dissecting the example application (15 Dec build) to add JDBC database support along with i18n switching (per Kapur and Geary). My own application is database-centric, and I want to be sure I understand the arcitecture right before starting my own code. If anyone else has done work along these lines, I'd be very interested in your comments or samples. -- Ted Husted.
What's Struts? Struts uses a switchboard, or controller, servlet to route requests to other Struts servlets. When initialized, the controller parses a configuration resource file. The configuration resource defines (among other things) the servlet mappings for the application. The controller uses these mappings to determine how to route the requests it receives. At a minimum, a mapping must include (1) the request this mapping handles and (2) the servlet that handles it. The action's servlet can then handle the request, and return a HTTP response to the controller, which the controller can pass back to the client. The action's servlet can also indicate if control should be forwarded to another action. For example, if a login succeeded, the loginAction servlet may wish to forward control to the mainMenu action. The configuration resource allows control to be forwarded by name; and an action servlet can check the configuration resource for that name at runtime. This allows an action servlet to return a "logical" response, and leave the details to the configuration resource. When forwarding control, a servlet can also include a shared object, or JavaBean, by storing it within a collection that other servlets can access. There are standard collections for a page, request, session, and application that are shared by all servlets and JSPs in the same Web application. So, one servlet can have an item added to a shopping cart bean, place the bean in the session collection, and forward control to a JSP that will display the contents of the updated cart. Since each client has their own session, they will each also have their own shopping cart. In a Struts application, most of the business logic is represented using JavaBeans. JavaBeans can also be used to manage input forms. A key problem in designing Web applications is retaining and validating what a user has entered between requests. With Struts, you can store the data for a input form in a form bean, which is automatically maintained through the user's Struts session. The form bean can be used by a JSP to collect data ... by an action servlet to validate what the user enters ... and then by the JSP again to display any validation errors, along with the other data entered. Form beans are defined in the configuration resource and linked to an action mapping by name. When a request calls for an action that uses a form bean, the controller either retrieves or creates the form bean, and passes it to the action's servlet. The action's servlet can then check the contents of the form bean before its input form is displayed, and also queue messages to be handled by the form. When ready, the action's servlet can return control with a forwarding to its input form, usually a JSP. The controller can then respond to the HTTP request and direct the client to the Java Server Page. The Struts framework includes custom tags that can automatically populate fields from a form bean. The only thing most Java Server Pages need to know about the rest of the framework is the proper field names and where to submit the form. Components like the messages set by the action's servlet can be output using a single custom tag. Other application-specific tags can also be defined to hide implementation details from the JSPs. The custom tags in the Struts framework are designed to use the internationalization features built into the Java platform. All the field labels and messages can be retreived from a message resource, and Java can automatically provide the correct resource for a client's country and language. To provide messages for another language, simply add another resource file. Other benefits to this approach are consistent labeling between forms, and the ability to review all labels and messages from a central location. For the simplest applications, an action's servlet can handle the business logic associated with a request. However, in most cases, an action's servlet should pass the request to another object, usually a JavaBean. To allow resuse on other platforms, business-logic JavaBeans should not refer to any Web application objects. The action's servlet should translate needed details from the HTTP request and pass those along to the business-logic beans as standard Java variables. In a database application, the business-logic beans would connect to and query the database and return the result set back to the action's servlet ... to be stored in a form bean, and then displayed by the JSP. Neither the action's servlet nor the JSP need to know (or care) where the result set comes from. The Struts framework is compliant with the classic Model-View-Controller paradigm, which is the architecture recommended by Sun and most other vendors. In Struts, the ActionServlet object (described above) is the MVC controller, the view is handled by JSP or directly by an Action servlet, and the model is handled with business-logic beans, or directly by an Action servlet. -- Ted Husted, 18 Dec 2000 <[EMAIL PROTECTED]>. ###
