Webapp Review

Webapp Review A Comparative Approach to Webapp Development

OVERVIEW | STRUTS 1 | STRUTS 2 | JSF | RUBY ON RAILS | SPRING MVC | GWT

OVERVIEW

about webapps | tools | webapp features | framework features | the sample webapp
Last updated: August 2009
These pages evaluate some frameworks and illustrate the process of creating the same sample webapp in each of them. These are not tutorials but should help if you are starting out with any of the frameworks examined.
Use the navigation applet at the bottom of the page to reach the various sections of the review quickly. You can get a static version of the navigation control by clicking here.
First, some basics.

about webapps

A web site can potentially be just a set of static HTML pages but if it is delivering dynamic information, there is usually a web application on a server backed by a data source (e.g. an Oracle database) to make the site possible. Essentially the webapp is the site. It is what lets users log on, make comments, create reservations, etc., etc.
Webapp functionality like this is supported by a programming language along with (typically) some kind of framework. A framework is a software architecture with code libraries that make creating a web application easier and hide some of the low-level HTTP details from the application programmer.
Common webapp enabling solutions include Java frameworks (there are many possibilities), Microsoft's ASP.NET architecture, and PHP. These pages examine webapp solutions from a Java and open-source angle. The three frameworks examined are: Struts, JSF, and Ruby on Rails.
Struts was one of the earliest Java frameworks and became the most widely adopted - many big sites use it. JSF (Java Server Faces) is a newer, more modern competitor which is backed by Sun as a standard and therefore increasingly favoured by companies. Ruby on Rails is not a Java solution but it is popular with Java and open-source developers due to the high speed at which it lets you create a webapp, and for its adoption of modern concepts.
All of these frameworks have one thing in common: they are rooted in an MVC architecture. MVC stands for Model, View, and Controller. Each framework lets you create (1) a Model, representing the entities and data in your application (2) a View, to show things to the user, and (3) a Controller, to relay input to the Model and manage the flow of logic.

tools

The main tools used to build the sample webapp in these pages are free and open-source, so you can download them if you don't already have them and try out the code. It is quite common to work with webapps using free tools, although medium-to-large companies may feel more comfortable buying software and getting a support contract.
The core piece of software you need to run a webapp is a server, also known as a webapp container. Big commercial app servers for Java include WebLogic and WebSphere, but here I'm using Tomcat. Tomcat is free (download here) and simple and extremely popular for these reasons, though it does not offer the deeper J2EE functionality (for this you can add JBoss, also free).
In Java for convenience a webapp is often bundled up into a single file called a WARfile (like a zipfile where WAR = web application archive). Often the warfile can just be "dragged into" a container to activate the webapp -- "hot deploy". Tomcat supports hot deploy; however, redeploying an application cleanly can be a bit more involved and require extra configuration and depend on the version you are using.
A developer will often use an IDE (Integrated Development Environment) to create an application. The IDE mainly used in these pages is Eclipse (download), which works well with Java, Ruby, and other languages. To create Java webapps, Eclipse can be supplemented with the WebTools plugin (download) which allows you to create "web projects" (see image below) -- there are alternatives, but like Eclipse itself WebTools is free, open-source software. Both these tools are good though not perfect: sometimes the developer needs to do a bit of work to get the right versions of JARs/plugins, resolve classpath and Context conflicts with co-operating tools, etc., etc.

The webapp will usually be backed by a persistent data source such as a relational database, an object database, or an enterprise bus service (in an SOA type of architecture). A simple relational database used for many webapps is MySQL. The webapps in these pages were tested against MySQL Community Server 5.0 (again it is free and can be downloaded here) except where otherwise noted.

webapp features

To evaluate the different frameworks, I'm building the same web application in each one. If it's to be a good evaluation, the webapp has to offer the core functionality that most real-world webapps need. So what should a "typical webapp" look like?
To start with the obvious, there should be forms and the ability to navigate between pages. Many of the links need to be dynamic, i.e. usually links on a dynamic website will include the IDs of entities like Users or Tasks or Airline Reservations.
Now when you first fill out a form on a site, you are usually creating an entity (like one of those). You should also be able to read what you've created, update it (in the form), and delete it. So the key thing a webapp should have is CRUD (create-read-update-delete) functionality on a sample entity. It should also be possible to see entities (e.g. orders) in a list (this is implicit in the "read" part.)
A typical webapp manages more than one entity and there are usually relationships between them. For example, there is a parent-child relationship between Order and Order Item. It may even be desirable to edit these different entity types on the same form (sometimes called a master-detail form).
Some more features:
A typical webapp will have a standard look-and-feel and each page will have a set of standard elements (header, footer, navigation...) that give the site a standard look.
A typical webapp will allow users to log on, and keep pages secure against unauthorised users.
In some forms on the site the user may need to upload a file like a photo or a document. This is a handy feature to have, and may require support from the framework.
When you submit a form, your input should be validated. For example you may get an error message saying that a certain field is absolutely required or that you entered an email address in an impossible format.

framework features

The previous section talked about a webapp from a user perspective. What about the perspective of the person developing the webapp? What features can a framework offer to make life easier for the developer?
When you are writing a page in a webapp, usually you are not writing raw HTML. The general structure may look like HTML but it is likely to be supplemented by tags offered by the framework. You use the tags in the page source code, and then the framework translates that to HTML (often passing through Java code). For example in Struts:

<s:textfield required="true" label="First Name" size="12" name="contact.firstName" value="%{contact.firstName}"/>

may get translated to:

<td class="tdLabel"> <label for="contact_contact_firstName" class="label">First Name <span class="required">*</span>:</label></td> <td><input type="text" name="contact.firstName" size="12" value="" id="contact_contact_firstName"/></td>

Tags require that you have more knowledge than just HTML: you often have to do a lot of looking up to use them properly. However, there are a lot of advantages. For example, a tag inside a form like the one above can be smart enough to work in both a creating context and updating context so you don't have to write all the logic for each yourself. Furthermore, if you find the prepackaged tags too inflexible you can write your own tags. They act as components which can encapsulate as much HTML generation as you want. But they force you to think about what you're doing, and discourage you from putting business logic in the web page (the View) itself.
Earlier, there was discussion of how a form maps to an entity in the Model. When evaluating a framework, it is interesting to see how seamless this process is. If something doesn't quite fit, how easy is it to make it fit? Note also that the entity will ultimately be mapped to the database. This is not handled by the webapp framework itself but (most likely) by an object-relational mapping (ORM) technology such as Hibernate or JPA. But it is good to test how everything fits together to form a total solution.
Apart from the View and the Model, there is the Controller to consider. Very often the flow of control will be abstracted into a single file (especially an XML file) and you can see what view responds to what action and so forth. It has to be asked: how easy is the format to understand? Does it let you do everything you want it to? Bear in mind that the framework will be doing a lot of work behind the scenes for each request that comes in. This process may be easy to customise or it may not. A frequent developer complaint about frameworks is, "I can't see what it's doing, so I can't fix it." You are relying on the framework to either work perfectly or allow you to make it work perfectly.
Testing is recognized more and more as an integral part of webapp development. A good question is: what support does the framework offer for the various types of testing: unit testing, functional testing, and integration testing? More explanation here.
Finally there is simply the overall usability of the framework to consider. How clear and maintainable is the code you find yourself writing? How effective is the separation between Model, View, and Controller? How easy is it to fix something when things go wrong? How big and helpful is the developer community? What about support for logging and debugging with an IDE? How well does it integrate with tools for testing and with servers? And the bottom line: how long does it take to write a typical webapp compared with other frameworks?

the sample webapp

It is time to define the requirements of the sample web application. Each version of the webapp in these pages guarantees the same essential features described here, although there may be cosmetic differences between them.
The webapp is a contact management application called WebOfContacts. The core entity of the webapp is the Contact, a person the user wants to remember. Apart from typical address book information, the user can add comments to each Contact. It's very general and flexible. For instance, a contact could be a customer, and a comment could be an order. WebOfContacts is not a big application: it just focuses on a few core things.
Firstly the user needs to be able to log in (being authenticated):

(These screenshots show the Struts 2 version, but it is similar in the other versions.)
Once logged in, the user can see the possible actions in the left navigation bar. There is also a header, footer, and main area. The webapp needs to have a system keep this consistent across the screens.

Clicking on "CREATE CONTACT" brings the user to the main form of the application, which is for the Contact entity:

On a form submit, if there are bad errors in the form, such as the first name being omitted or an invalid email address being entered, the user will be advised with an error message and returned to the same form.
Notice that the form includes a File Upload box for an image of the Contact.
The same form should be reused for updating a Contact entity. On a create or update there is the possibility to add one new comment, while the previous comments are displayed below:

This update form is accessed by clicking on an existing contact in the "LIST CONTACTS" screen, which looks like this:

The contacts are ordered by priority, which you can modify in this screen. Contacts can also be deleted, completing the CRUD functionality.
Notice that in the bottom left of the screen there's a search box. If you type in a keyword, the system will search on all fields and return a filtered version of the "LIST CONTACTS" screen.
That's all the main functionality. There's also a little form for adding new Users that can be authenticated in future. (Don't miss the difference between a User and a Contact.)

That sums up the sample application. The other pages describe how it is created for each framework. There was no special effort to abstract code that is common to all solutions. However, the stylesheet is the same for each one, the Model code is basically the same, and for the Java solutions there is a service layer which does not need to change much.
As according to the specification from Sun, web applications are packaged in a standard structure with a root directory, a WEB-INF folder, a web.xml file for main configuration, and some other configuration files depending on the framework. To run a web application, you would put this directory structure in your server at a deployment location specific to the server, e.g. for Tomcat under the webapps directory. A web application directory is often bundled into a single archive file and given the extension .war for convenience -- for instance, in these pages, you can easily download a .war file for each version of WebOfContacts. A .war file can be deployed just the same as a full directory, by copying it into your server's deployment location. However, sometimes a web application might require that files can be uploaded into the webapp folder itself. If this is the case, as it is with WebOfContacts, you need a fully exploded directory. Therefore, after downloading a .war file here, you should explode it with a procedure like this:

mkdir WebOfContacts mv WebOfContactsStruts.war WebOfContacts cd WebOfContacts java -tvf WebOfContactsStruts.war

Note that an .ear file is similar to a .war file, but it contains additional functionality such as EJBs -- it is an Enterprise ARchive, not just a Web ARchive. Tomcat cannot run .ears -- you need a full app server like JBoss.
The WebOfContacts database is the same for all the solutions. Before actually deploying any of the WARs you should set up the database schema. Any RDBMS could be used, but the following instructions assume MySQL 5.0 -- there will be slight differences for other database systems.
If you don't have a database system, install MySQL after downloading it. Towards the end of the Config Wizard, check the option "Include Bin Directory in Windows PATH", then, after setting the root password, check the "Create Anonymous Account" box.
Assuming MySQL with an anonymous account, download populate-db.sql and create-tables.sql into a directory of your choice. Open a command window, cd to that directory, and execute the scripts as follows:

mysql < create-tables.sql mysql < populate-db.sql

The second script includes sample data and can be omitted if you like.
If you have installed MySQL but couldn't/didn't create an anonymous account:
Run the scripts using root, e.g.
mysql -u root < create-tables.sql
, then grant access to anonymous db requests by logging in to the db as root and running these commands:
use contactsdb; grant all on *.* to ''@localhost;

	OVERVIEW about webapps \| tools \| webapp features \| framework features \| the sample webapp Last updated: August 2009 These pages evaluate some frameworks and illustrate the process of creating the same sample webapp in each of them. These are not tutorials but should help if you are starting out with any of the frameworks examined. Use the navigation applet at the bottom of the page to reach the various sections of the review quickly. You can get a static version of the navigation control by clicking here. First, some basics.
	about webapps A web site can potentially be just a set of static HTML pages but if it is delivering dynamic information, there is usually a web application on a server backed by a data source (e.g. an Oracle database) to make the site possible. Essentially the webapp is the site. It is what lets users log on, make comments, create reservations, etc., etc. Webapp functionality like this is supported by a programming language along with (typically) some kind of framework. A framework is a software architecture with code libraries that make creating a web application easier and hide some of the low-level HTTP details from the application programmer. Common webapp enabling solutions include Java frameworks (there are many possibilities), Microsoft's ASP.NET architecture, and PHP. These pages examine webapp solutions from a Java and open-source angle. The three frameworks examined are: Struts, JSF, and Ruby on Rails. Struts was one of the earliest Java frameworks and became the most widely adopted - many big sites use it. JSF (Java Server Faces) is a newer, more modern competitor which is backed by Sun as a standard and therefore increasingly favoured by companies. Ruby on Rails is not a Java solution but it is popular with Java and open-source developers due to the high speed at which it lets you create a webapp, and for its adoption of modern concepts. All of these frameworks have one thing in common: they are rooted in an MVC architecture. MVC stands for Model, View, and Controller. Each framework lets you create (1) a Model, representing the entities and data in your application (2) a View, to show things to the user, and (3) a Controller, to relay input to the Model and manage the flow of logic.
	tools The main tools used to build the sample webapp in these pages are free and open-source, so you can download them if you don't already have them and try out the code. It is quite common to work with webapps using free tools, although medium-to-large companies may feel more comfortable buying software and getting a support contract. The core piece of software you need to run a webapp is a server, also known as a webapp container. Big commercial app servers for Java include WebLogic and WebSphere, but here I'm using Tomcat. Tomcat is free (download here) and simple and extremely popular for these reasons, though it does not offer the deeper J2EE functionality (for this you can add JBoss, also free). In Java for convenience a webapp is often bundled up into a single file called a WARfile (like a zipfile where WAR = web application archive). Often the warfile can just be "dragged into" a container to activate the webapp -- "hot deploy". Tomcat supports hot deploy; however, redeploying an application cleanly can be a bit more involved and require extra configuration and depend on the version you are using. A developer will often use an IDE (Integrated Development Environment) to create an application. The IDE mainly used in these pages is Eclipse (download), which works well with Java, Ruby, and other languages. To create Java webapps, Eclipse can be supplemented with the WebTools plugin (download) which allows you to create "web projects" (see image below) -- there are alternatives, but like Eclipse itself WebTools is free, open-source software. Both these tools are good though not perfect: sometimes the developer needs to do a bit of work to get the right versions of JARs/plugins, resolve classpath and Context conflicts with co-operating tools, etc., etc. The webapp will usually be backed by a persistent data source such as a relational database, an object database, or an enterprise bus service (in an SOA type of architecture). A simple relational database used for many webapps is MySQL. The webapps in these pages were tested against MySQL Community Server 5.0 (again it is free and can be downloaded here) except where otherwise noted.
	webapp features To evaluate the different frameworks, I'm building the same web application in each one. If it's to be a good evaluation, the webapp has to offer the core functionality that most real-world webapps need. So what should a "typical webapp" look like? To start with the obvious, there should be forms and the ability to navigate between pages. Many of the links need to be dynamic, i.e. usually links on a dynamic website will include the IDs of entities like Users or Tasks or Airline Reservations. Now when you first fill out a form on a site, you are usually creating an entity (like one of those). You should also be able to read what you've created, update it (in the form), and delete it. So the key thing a webapp should have is CRUD (create-read-update-delete) functionality on a sample entity. It should also be possible to see entities (e.g. orders) in a list (this is implicit in the "read" part.) A typical webapp manages more than one entity and there are usually relationships between them. For example, there is a parent-child relationship between Order and Order Item. It may even be desirable to edit these different entity types on the same form (sometimes called a master-detail form). Some more features: A typical webapp will have a standard look-and-feel and each page will have a set of standard elements (header, footer, navigation...) that give the site a standard look. A typical webapp will allow users to log on, and keep pages secure against unauthorised users. In some forms on the site the user may need to upload a file like a photo or a document. This is a handy feature to have, and may require support from the framework. When you submit a form, your input should be validated. For example you may get an error message saying that a certain field is absolutely required or that you entered an email address in an impossible format.
	framework features The previous section talked about a webapp from a user perspective. What about the perspective of the person developing the webapp? What features can a framework offer to make life easier for the developer? When you are writing a page in a webapp, usually you are not writing raw HTML. The general structure may look like HTML but it is likely to be supplemented by tags offered by the framework. You use the tags in the page source code, and then the framework translates that to HTML (often passing through Java code). For example in Struts: <s:textfield required="true" label="First Name" size="12" name="contact.firstName" value="%{contact.firstName}"/> may get translated to: <td class="tdLabel"> <label for="contact_contact_firstName" class="label">First Name <span class="required"></span>:</label></td> <td><input type="text" name="contact.firstName" size="12" value="" id="contact_contact_firstName"/></td> Tags require that you have more knowledge than just HTML: you often have to do a lot of looking up to use them properly. However, there are a lot of advantages. For example, a tag inside a form like the one above can be smart enough to work in both a creating context and updating context so you don't have to write all the logic for each yourself. Furthermore, if you find the prepackaged tags too inflexible you can write your own tags. They act as components which can encapsulate as much HTML generation as you want. But they force you to think about what you're doing, and discourage you from putting business logic in the web page (the View) itself. Earlier, there was discussion of how a form maps to an entity in the Model. When evaluating a framework, it is interesting to see how seamless this process is. If something doesn't quite fit, how easy is it to make it fit? Note also that the entity will ultimately be mapped to the database. This is not handled by the webapp framework itself but (most likely) by an object-relational mapping (ORM) technology such as Hibernate or JPA. But it is good to test how everything fits together to form a total solution. Apart from the View and the Model, there is the Controller to consider. Very often the flow of control will be abstracted into a single file (especially an XML file) and you can see what view responds to what action and so forth. It has to be asked: how easy is the format to understand? Does it let you do everything you want it to? Bear in mind that the framework will be doing a lot of work behind the scenes for each request that comes in. This process may be easy to customise or it may not. A frequent developer complaint about frameworks is, "I can't see what it's doing, so I can't fix it." You are relying on the framework to either work perfectly or allow you to make it work perfectly. Testing* is recognized more and more as an integral part of webapp development. A good question is: what support does the framework offer for the various types of testing: unit testing, functional testing, and integration testing? More explanation here. Finally there is simply the overall usability of the framework to consider. How clear and maintainable is the code you find yourself writing? How effective is the separation between Model, View, and Controller? How easy is it to fix something when things go wrong? How big and helpful is the developer community? What about support for logging and debugging with an IDE? How well does it integrate with tools for testing and with servers? And the bottom line: how long does it take to write a typical webapp compared with other frameworks?
	the sample webapp It is time to define the requirements of the sample web application. Each version of the webapp in these pages guarantees the same essential features described here, although there may be cosmetic differences between them. The webapp is a contact management application called WebOfContacts. The core entity of the webapp is the Contact, a person the user wants to remember. Apart from typical address book information, the user can add comments to each Contact. It's very general and flexible. For instance, a contact could be a customer, and a comment could be an order. WebOfContacts is not a big application: it just focuses on a few core things. Firstly the user needs to be able to log in (being authenticated): (These screenshots show the Struts 2 version, but it is similar in the other versions.) Once logged in, the user can see the possible actions in the left navigation bar. There is also a header, footer, and main area. The webapp needs to have a system keep this consistent across the screens. Clicking on "CREATE CONTACT" brings the user to the main form of the application, which is for the Contact entity: On a form submit, if there are bad errors in the form, such as the first name being omitted or an invalid email address being entered, the user will be advised with an error message and returned to the same form. Notice that the form includes a File Upload box for an image of the Contact. The same form should be reused for updating a Contact entity. On a create or update there is the possibility to add one new comment, while the previous comments are displayed below: This update form is accessed by clicking on an existing contact in the "LIST CONTACTS" screen, which looks like this: The contacts are ordered by priority, which you can modify in this screen. Contacts can also be deleted, completing the CRUD functionality. Notice that in the bottom left of the screen there's a search box. If you type in a keyword, the system will search on all fields and return a filtered version of the "LIST CONTACTS" screen. That's all the main functionality. There's also a little form for adding new Users that can be authenticated in future. (Don't miss the difference between a User and a Contact.) That sums up the sample application. The other pages describe how it is created for each framework. There was no special effort to abstract code that is common to all solutions. However, the stylesheet is the same for each one, the Model code is basically the same, and for the Java solutions there is a service layer which does not need to change much. As according to the specification from Sun, web applications are packaged in a standard structure with a root directory, a WEB-INF folder, a web.xml file for main configuration, and some other configuration files depending on the framework. To run a web application, you would put this directory structure in your server at a deployment location specific to the server, e.g. for Tomcat under the webapps directory. A web application directory is often bundled into a single archive file and given the extension .war for convenience -- for instance, in these pages, you can easily download a .war file for each version of WebOfContacts. A .war file can be deployed just the same as a full directory, by copying it into your server's deployment location. However, sometimes a web application might require that files can be uploaded into the webapp folder itself. If this is the case, as it is with WebOfContacts, you need a fully exploded directory. Therefore, after downloading a .war file here, you should explode it with a procedure like this: mkdir WebOfContacts mv WebOfContactsStruts.war WebOfContacts cd WebOfContacts java -tvf WebOfContactsStruts.war Note that an .ear file is similar to a .war file, but it contains additional functionality such as EJBs -- it is an Enterprise ARchive, not just a Web ARchive. Tomcat cannot run .ears -- you need a full app server like JBoss. The WebOfContacts database is the same for all the solutions. Before actually deploying any of the WARs you should set up the database schema. Any RDBMS could be used, but the following instructions assume MySQL 5.0 -- there will be slight differences for other database systems. If you don't have a database system, install MySQL after downloading it. Towards the end of the Config Wizard, check the option "Include Bin Directory in Windows PATH", then, after setting the root password, check the "Create Anonymous Account" box. Assuming MySQL with an anonymous account, download populate-db.sql and create-tables.sql into a directory of your choice. Open a command window, cd to that directory, and execute the scripts as follows: mysql < create-tables.sql mysql < populate-db.sql The second script includes sample data and can be omitted if you like. If you have installed MySQL but couldn't/didn't create an anonymous account: Run the scripts using root, e.g. mysql -u root < create-tables.sql , then grant access to anonymous db requests by logging in to the db as root and running these commands: use contactsdb; grant all on . to ''@localhost;