Goals

The goal of this case-study is to make a short overview of the development tools for developing web-based business applications. The tools must (should) satisfy the following criteria:

1. Best suits for developing server-side stateful applications with complex UI
2. Good support for localization/internationalization
3. Full isolation of applications – it should be possible (and simple) to deploy an application without (risk of) breaking other applications which run on the same production server.
4. Provide a mechanism for simple switching of web page appearance to “printer-friendly” or “mobile-device-friendly” look.
5. Use page templates in HTML so that designers can use WYSIWYG editors for making changes to the templates
6. Complete separation of code and HTML tags, so that changes in the application logic does not break the design

Overview

Software frameworks available for web-application are split onto three categories: (1) portals, (2) web application frameworks and (3) template engines (for definitions please follow the references to Wiki).

Portals

Portals are designed to provide good integration of applications within an enterprise. This is going against our goal to have subscriber’s applications as much isolated as possible. Although, in general, this goal is achievable, but, as shows our experience with JBoss Portal, such isolation takes extra human and hardware resources.
Portals are usually build on top of a web-development framework.

Application frameworks

Frameworks are designed to provide reusable functionality, design patterns, and offers highly-configurable environment.

Reusable functionality

To be truly useful, this functionality has to be learned by developers. Rich-on-functionality frameworks provide a lot more functionality but on the other hand requires more time to learn than simple ones. Open source frameworks usually poorly documented, which makes this learning curve much longer. As any software, frameworks contain bugs, and rich frameworks have even more bugs because it is made of bigger amount of source code. Accompanied with poor open source documentation, a simple issue may become a real obstacle just because it is hard to distinguish between a bug in framework and its misusage – system behaves in the way developers do not expect and no one can say whether this behaviour is correct or incorrect. Therefore experience is gained on trial-and-error path. This path makes the learning curve driving away from the application goals.

Design patterns

A typical framework is bound to few design patterns. These patterns were chosen by the vendor/developer of the framework and the reason for that choice is never or very rarely disclosed. Indeed, design patters have high impact on the product and the development process. Too concrete design patterns may not fit needs of a particular application. Too abstract design patterns give more chances to fail on mapping application. Proper design pattern will speedup the development process, improper – will slowdown.
Most of the available web-development frameworks are based on Model-View-Controller (MVC) (see definition in Wiki, good description can be found on [1]). It is not clear why this three-letter-design-pattern become so popular. Besides serious drawbacks of this pattern, every vendor has they own understanding of what is view and what is controller [2], which leads to various flavours of MVC, misimplementation and misusage of this design pattern.

Drawbacks of MVC

Paper [3] identifies the following drawbacks of MVC:

1. Increased complexity
2. Close coupling of views and controllers to model
3. Potential for excessive updates
4. Close coupling between view and controller

Framework comparison

Wiki lists [4] two dozens of web application frameworks. It does not seem possible to evaluate each of those, therefore we will relay on papers providing such comparisons: [5], [6], [7], [8]. As it appears, very few available frameworks provide good separation of concerns (code vs. HTML). This seems to be the consequence of using MVC as the design pattern and JSP as implementation of View. And even those few which claim good separation – Wicket and Trapestry forces to the component model, which will be an obstacle for producing printer-friendly version of pages.

Template Engines

List of Java template engines is given in [9]. Three of them that match our needs the best are Velocity, StringTemplate and IKAT. All of them use similar approach – use of special programming language for templates. With Velocity we had some experience and it has shown that debugging such templates is a difficult task. This experience we may propagate on the other engines that use a programming language in templates.

Conclusion

Existing frameworks and template engines, while giving advantage in some aspects of web programming, sacrifice the others, which makes the development process longer than expected, sometime even too long. It does not worth spending time on learning a framework which does not give obvious benefits in developing or maintaining the software.
As the experience has shown, implementing a home-grown Java template engine takes efforts comparable to learning a new framework.

References

1. Web Presentation Patterns, Jonathan Snook
http://www.digital-web.com/articles/web_presentation_patterns/

2. Whatsa Controller Anyway, KyleBrown,
http://c2.com/cgi/wiki?WhatsaControllerAnyway

3. Model View Controller
http://www.phpwact.org/pattern/model_view_controller

4. List of web application frameworks
http://en.wikipedia.org/wiki/List_of_web_application_frameworks

5. Java Web Framework Sweet Spots
https://appfuse-light.dev.java.net/framework-comparison/JavaWebFrameworkSweetSpots.pdf

6. Comparison of Java Web Frameworks, Neal Ford
http://bdn1.borland.com/article/borcon/files/6000/paper/6000.html

7. Comparing Web Frameworks, Matt Raible
http://static.raibledesigns.com/repository/presentations/ComparingJavaWebFrameworks.pdf

8. Comparison of web application frameworks
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks

9. Open Source Template Engines in Java
http://java-source.net/open-source/template-engines

10. Enforcing Strict Model-View Separation in Template Engines.
http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf

11. Passive View, Martin Fowler
http://www.martinfowler.com/eaaDev/PassiveScreen.html

_{October 2007}