The Struts Framework is based on MVC
(Model-View-Controller)Architecture. In the last edition, we had seen how we can improvise our own MVC implementation without using Struts. This helps in understanding the concepts of Struts. However, Struts offers many advantages. For this reason, most Software Architects in Enterprise level, favor the Struts Framework .In this tutorial on Struts, the author explains its essential features , with a simple lab-oriented practical example.
Sound knowledge of Struts Framework with hands-on experience in developing applications based on Struts , is a skill that is very much in demand now. Struts Framework was developed by Craig McLanahan in 2002 and subsequently handed over to Apache Jakarta project group.
As Sun Micro Systems, works in close collaboration with Jakarta-Tomcat group, Struts has acquired semi-official status, though , it is not officially endorsed by JCP, yet. Craig McLanahan is also the architect of Tomcat4, which is the 'Reference implementation' of Servlet & JSP API by Sun. And the recently introduced JSF (Java Server Faces) also is the contribution of Craig McLanahan. What is more, Craig is also the Implementation Architect for Sun's Java Web Services Development Pack (JWSDP). That is sufficient enough list of credentials, to indicate the backing from Sun. There have been dissenting voices too, against Struts , partly because , it is somewhat difficult to learn and implement. And even an acknowledged spokesman & member of Struts Development Team and author of Struts Tutorial , Ted Husted, had to admit that the Struts naming of its classes leaves much to be desired. (for instance, instead of 'ActionServlet', it could have been called 'Controller' . Adding 'action' to everything in Struts like 'ActionForm', 'ActionServlet', 'Action', 'ActionForward' and even 'ActionErrors' etc tends to make the beginners grudge that' there is too much action here !' to their liking!). And it appears that, of late, some leading Architects feel that Struts is likely to give way to other Open-Source technologies from the same Apache group ,like Turbine and Torque( which are even more obscure and less documented).Judging by the number of latest job-advertisements calling for Struts skills, it is a bit difficult to concur with that perception. Struts appears to have become 'de-facto' standard, like SAX, though one wishes that everything had been done within JCP ,so that developers will always be dealing with officially approved standards, rather than maverick standards, however good they might be. ( by the way, the correct term is 'struts' and not 'structs', as is mis-spelt often).
Here are some of the points listed by Author John Carnell ('Professional Struts Applications'-Wrox press-2003) in favour of adopting Struts. To paraphrase....
**i)Senior developers and Architects in large software houses are extremely over-worked and the main job of in-house senior programmers is developing business-logic and not application-framework!
ii) Struts framework was built by some of the finest developers in the Industry, and is open-source and free.
iii)It has been tested and debugged by hundreds of expert volunteers, thus giving it a high degree of Quality Assurance. If a company tries to build a similar framework by itself, it will take thousands of expert man-hours and millions of dollars!
A good understanding and practical knowledge of Servlets, JSP, JavaBeans, Tag Library, MVC Architecture ,XML conifig files and Tomcat server , is required before a learner could even attempt understanding Struts.(It is for this reason, that we covered our own MVC implementation in the last edition).
And it has to be supplemented with real practical work, to get it going. Without sufficient lab-experience, a hundred things can go wrong! Just a bit of careless 'casing' and package names and we are confronted with stubborn compile errors. Remembering the fact that xml files also are 'case-conscious', would save us a lot of frustrating delay. And it is so easy to get lost in the paths and class paths of Java, especially with 'Struts'!
Struts is a framework for building really complex Enterprise-level web applications.
Note the emphasis on 'Enterprise-level'. Such applications are by necessity, multi-tier.
Carnell makes a neat distinction between Enterprise-services like Transaction management, Resource pooling, Load Balancing and Security and Application-services like Data-validation , error-handling, Application navigation and screen-layout and personalization.
While EJB takes care of Enterprise-services, the task of developing easily alterable and maintainable Application-services in a really large web-application, could be a maddeningly chaotic and tangled ' web'( literally) and such problems are NOT tackled by EJB. Enterprise-level projects are developed by teams and unless there is a well-known and standard framework, the teams? work would fail to dovetail. The business-tier, Data-tier and presentation-tier,all have to be co-ordinate seamlessly. This requires that all the teams and team-members know and practice a given standard. This point has been forcefully stressed in web-forums. As Struts has acquired wide awareness & acceptance, it fulfils this need admirably.
Carnell lists the challenges of Web Development as :
Many companies have web-based applications where the number of screens that the user can navigate to, is in thousands!
(SAP user-interface is composed of over 1,50,000 screens, reports and dialog
boxes!--- and they were reported to be converting them into java-GUI .to provide
(p.376 of Java Web Services by Hendricks..WROX).
For all these reasons and more, Application-services are important and
daunting to develop!
In the true spirit of MVC, the Struts framework separates the View, Controller and Model. It does not concern itself with the implementation details of business-logic and data-access tiers.
That said, the very fact that it is an Enterprise-level framework, presumes( or it should) that we are using some form of EJB and some type of well-proven method of separation of Data-tier and business-logic tier. Though, Struts has provision for local data access, it is not advisable to use that facility for Enterprise-level work, nor does it recommend it. At present, the recommended method is to use a stateless EJB for data access directly or as a facade for CMP or JDO. The advantage of CMP and JDO , is that details of the actual database product used , do not find a place in code. This enables us to use Object Databases too(JDO), as well as RDBMS. As Carnell rightly points out, the moment we speak of products like Oracle/SqlServer/MySql in our code , we get locked with vendor-specific details, which preclude changes. According to a number of authors, BMP seems to have been less of a success, if the yardstick is 'avoidance of SQL & vendor specific features of SQL.' and JDO is the recommended method. Oracle/PL-SQL if used in EJB code, ties our application , inextricably with Oracle .This is undesirable. The EJB3.0 version ,to be released shortly ,is said to favor JDO strongly.(BMP introduces SQL in java code while CMP & JDO adopt declarative management for database and query.). ( bmp persistence code need not necessarily be sql but in most cases, it is sql).
Some authorities from BEA-WebLogic, are even, advocating the use of stateless-bean for simplicity and speed.(Java Server Programming by Allama Raju of WebLogic-WROX press), though it may involve sql in code itself. And a design based on such stateless-session bean can easily be exposed as XML-WebService by simple drop-in deployment in Axis.( see DeveloperIQ...April & May -2004).
Thus, unless we are careful in implementing separation ,not merely between View , Control and Model, but going further in separation of Model into delegation, service-location, business logic , data access and data itself, even a Struts applications may become brittle.(We can easily imagine, how dangerous a brittle struts is, to a strut-walker!).In a well-designed system, each of these tiers should be pluggable (ie) any change in one tier should not affect other tiers.(ie)
The layers should be de-coupled from each other, as much as possible.
Standard Design Patterns, such as
are some of the patterns recommended in the 'model' region of Struts work!. In an earlier part of this J2EE tutorial , we had used a simple utility bean, for carrying out a specific function. That would be a case of 'Business Delegation'.
If such a bean is used as a client for an EJB, typically, it would be an example of 'Service Locator'. And if that ejb happened to be a stateless bean connecting with a CMP , it would illustrate 'Facade Pattern'.
Ideally, in an Enterprise application ,based on Struts, we should provide for all the above three patterns and implement them, though , in this lesson, we are using 'business delegation' alone, to keep the example simple.
J2EE students are expected by the Industry, to have read two famous and essential books on Design Patterns.
(Some Struts authors are intent in showing that the Struts design follows some standard design patterns, while Carnell is concerned with suggestions for implementing Design patterns in the Model stages of Struts application. It is well to bear this in mind while reading books).
Recommend the tutorial