|
Java Web Application Frameworks To avoid wasting other people's time, web application development and consequently choosing a web application framework, depends on a multitude of factors including, but not limited to, the size of the development team and the deployment environment. In this article I am targeting the small software house, say from a single developer to a five man team. Larger software houses will probably have enough resources to make their own decisions. I will also further limit the discussion by defining the deployment environment as targeting the lower end of the scale, 10 to 50 concurrent users, requiring lower memory size servers with lower bandwidth. I am also assuming that you can actually choose the web application framework, rather than being obliged (even contractually) to use a specific framework.
Matt Raible has been giving presentations on Java web application frameworks since 2004 and is also the founder and lead developer of the AppFuse, and AppFuse Light projects. In his personal blog, he has made two slide shows available that he prepared for presentation at the ApacheCon 2007. In those presentations, his preferences produce the following list:
That's still 10 frameworks. In another of his articles, Matt talked to founders and lead developers of some of these frameworks, asking some pertinent, but perhaps also leading questions. Matt's response to an article by Tim O'Brien also sheds some light on his personal views of some of today's web application frameworks in the previous list.
For reasons which he highlights, which have been repeated by others, and given the scope of this article that I have outlined above, I'll remove:
Which leaves us with five frameworks; Adobe Flex, Grails, Google Web Toolkit, Stripes and Wicket. Not all frameworks are born equal, or rather, they have particular strengths within the Model, View, Controller pattern. Adobe Flex is a client side framework. The Google Web Toolkit, Stripes and Wicket emphasise the Controller and View components, leaving the Model (or at least model persistence) to other libraries or frameworks, such as Hibernate. Grails is a complete framework in that it provides Model, View and Controller components, using Spring and Hibernate internally.
Before taking a closer look at these five, it is important to take a look at past, current and probable future practices in web application development, as this will help put each framework into prospective.
Past PracticeClassic web applications, which are still being produced today, consist in combinations of HTML, CSS, and JavaScript, all sent from the web server, using the HTTP protocol. The granularity of the web application is the HTML web page. Any modifications made require a request-response cycle for the complete HTML web page.
Current PracticeCurrent web applications are still based largely on the classic model of HTTP request-response cycles of a complete HTML web page. However, the major difference is that sub-page elements can be modified using AJAX request-response cycles and DOM manipulation. The major benefits are the reduced traffic of data to and from the web server, and hence more responsive web applications for the user.
This has had the effect of making web applications more complex, but also more flexible. The increase in complexity is due to the fact that they have to respond to the AJAX (HTTP/XML) requests, as well as the usual HTTP/HTML requests. The flexibility lies in the fact that these AJAX requests-responses can be made public in the form of APIs, (a form of Service Oriented Architecture), which other programmers can use in their own web applications, known as mashups.
Probable Future PracticeThe obvious evolution would be to remove the classic HTTP/HTML request-response cycle from the web application entirely. HTML pages can continue to be served by the web server, as for any other static content, leaving the web application to honour AJAX HTTP/XML request-response cycles.
This separation of the front-end from the back-end makes it possible to create new front-ends, such as traditional desktop applications, or substitute back-end servers with newer technologies. This can only be achieved, obviously, if the AJAX services requested and provided remain compatible.
Once this decoupling process is achieved, the prospects of off-line web applications, as proposed by Google Gears, becomes much easier to implement.
See Life above the Service Tier, and Does the Rise of Service Oriented UI (SOUI) Mean the Death of Server-Assisted MVC?, for other similar prospectives. There are also proposals for improving HTML. James Ward provides a good definition of the Rich Internet Application.
Adobe Flex The quality of the user interface is as good as it gets, going much further than anything possible with HTML / CSS / JavaScript combinations. With its Flash parentage, good eye-catching animation effects are also possible. It also benefits from being open source, and backed by Adobe. The Wikipedia article gives an overview of Flex's history and parentage.
The Flex development site provides specific information for Java programmers for interfacing Flex to Java web applications. The OpenLaszo project, which provides similar though incompatible functionality, may also be a good source for components.
Flex applications can be built using the free Flex Software Development Kit (SDK), but Adobe also sells a development tool, Adobe Flex Builder, which starts at about US$250.
The Flex Showcase shows a list of web applications built using Flex. The excellent article Crash Course in Next-Gen RIA: AIR, Silverlight, and JavaFX by Alexey Gavrilov, illustrates this technology, and compares it with Microsoft's Silverlight, and Sun's JavaFX. Adobe are also moving this technology to the desktop, via the Adobe Integrated Runtime (AIR).
There are some problems with Flex, other than those mentioned by Matt Raible (search engine unfriendly, HTML rendering and printing problems). The size of the client application can become very large. The Flex Showcase comes in at 705 KB, the Picnik site, which has a truly appealing user interface, weighs in at 1,350 KB.
The Google Web Toolkit and GWT-Ext The toolkit is open source, and comes with powerful tools, which can be integrated into Eclipse, for development and debugging. The Wikipedia article on the GWT gives a concise overview. The GWT web site also provides extensive documentation, articles and tutorials. The GWT-Ext project, among several others, provides additional components for the toolkit. The Timepedia blog provides some interesting insights into the GWT.
A great deal of effort has also been taken to make the interface fast and responsive. The intent is clearly to make the user interface “feel like a traditional web application, just better”.
As for Flex, GWT can provide a complete separation of the front-end from the back-end. Even with externally supplied widgets, which use the Script.aculo.us libraries, GWT cannot fully compete with Flex for animations and effects. Taking the Kitchen Sink example, the client application code size seems to be smaller than Flex. GWT does not have the disadvantages of Flex, but the security problems inherent in any JavaScript application remain.
I am less inclined to subscribe to Matt Raible's list of disadvantages. From the documentation, I don't see why it should be difficult to incorporate a partial GWT user interface inside a classic Java web application. I can't see how GWT could have implemented Java 5 syntax in the compiler, it is a limiting but natural constraint – though this may change in the future. GWT seems to be getting more and more support from widget designers.
One interesting point will be to see if the global programming community, as opposed to just Java programmers, will use GWT with say a Python, Ruby, or PHP back-end. This blog from Palantar, loosely explains how he integrated GWT with Django (Python).
Grails and Groovy Grails was heavily inspired by Ruby on Rails, and by the Groovy language, which was itself, at least partially, inspired by Ruby. The Wikipedia article gives a concise overview of the framework. This article, by Harshad Oak, gives a short introduction to Groovy and Grails.
After a first look, you might be wondering why any experienced Java programmer would consider such a radically different framework. It has a non-Java language, and uses the so called “convention over configuration” MVC framework.
If you have had any experience using Ruby and / or Ruby on Rails you will understand that together they create a very fast development cycle, while necessarily limiting some aspects of flexibility, due to the conventions used. The development process works very efficiently where those limits are acceptable. The development efficiency increase is so great that the limitations can become of secondary importance. This comes at the cost of creating a web application which is less performant than traditional Java web frameworks.
The Grails web site, much as the Ruby on Rails website provides tutorials, screencasts, and plugins. Marcel Overdijk has written two articles on integrating Adobe Flex with Grails, and a third article is available from Jacob von Eyben. A plugin has been created for GWT integration.
Stripes The How-To page provides articles on file uploading, AJAX, localisation, state management, and multi-page wizard construction, among others. Examples are provided for using both the Spring and Hibernate frameworks.
Similar to the Grails philosophy, speed of development is considered a primary concern, limiting some aspects of flexibility. This is one of the critiques made by Matt Raible, that URLs are hard coded to ActionBeans. Stripes supports incremental building of web applications, web pages can be prepared quickly without having to create the model components, which can be developed at a later stage.
According to the framework's inventor, Tim Fennell, Stripes is a high quality, action oriented framework, with powerful type conversion, binding, and validation, which shines in applications with lots of complex data interactions.
Kai has an article integrating Stripes with the GWT.
Wicket The programming experience is much closer to Swing application development than traditional web applications. Wicket has the concept of application, as well as page and component. The WebApplication class is responsible for setting the configuration for the entire application.
The framework's inventor, Jonathan Locke, describes Wicket as being a compact, focused, and powerful framework, designed to solve one very specific problem well; enabling component oriented, programmatic manipulation of markup, and very little else.
ContactsSyger can be contacted for consultancy work on any of the topics mentioned in this article, by sending an email to info@syger.it.
|
Tag cloud: |
|
|
