A Tapestry framework implementation - Case Study

A Fortune 100 client, one of the top two in their segment, embarked on computerization of their contract management system. Presently, all their contract details, legal paperwork were not available in electronic form.
The goal was to provide a web interface to capture, manually clean up any issues with data while still maintaining ready access to the scanned version of paperwork for cross-verification.
Additionally, scanning and loading of data into the system was to be done for both current ongoing contracts as well as archived (no longer active) contracts.

Technology selection

In initial discussions with the business team, it was agreed that we would have a free hand in choosing the right technology for the job given that the users of the systems will be within a single department.
As part of the initial assessment of budget constraints, applications/technology already in use in the concerned department, it was decided to go with the following combination:

• Oracle 10g
• JDK 1.5
• Hibernate
• JBoss or Tomcat/Apache combination
• Tapestry web framework
• Spring Framework

As part of justifying the choice of Tapestry (this framework was almost unheard of in that company), it was compared to Struts which was suggested earlier.

Oracle 10g was suggested due to issues identified with Oracle JDBC drivers and BLOBS (used to store the scanned contracts) for 9i which was standard in the organization.

JDK 1.5 was the chosen for observed speed differences in server applications (after the one-time hit during first execution). Additionally, the option to use Hibernate/Tapestry annotations was attractive. In the final application, annotations were used only for Tapestry. XDoclet was used to generate the mapping for Hibernate due to missing support for some complex-primary key functionality.

To keep cost low on the application server side, it was decided to go with JBoss / Tomcat+Apache combination. This despite the deep penetration of Weblogic in the organization.

While deciding on Tapestry, the key attractiveness was the ability to split the HTML design from the application logic. Use of OGNL made it fairly easily to access pretty much anything in the application.

Technical issues

At the time of project kick-off, we consciously decided to choose the Beta stream of Tapestry4 instead of the production version which was 3.x. This way, we figured, when the project went live, we will most likely be tracking and going live on Tapestry4 stable version.

The above decision, led to some issues during the project with incompatibilities between Beta releases, inconsistent/non-existent documentation etc. The positive of the entire episode was the opportunity to quickly identify and fix any incompatibilities immediately.

After much deliberation during the course of the project, our project became the first project to pilot on variety of fronts:

• first to be tested / released on JDK 1.5
• first to use Oracle 10g
• first on the 8x stream of Weblogic (due to use of JDK 1.5)
• first to use Tapestry

Initially, the code was designed to use form based authentication against a custom user database, it was subsequently changed to use Weblogic realms with in turn gave way to internal security mechanism driven off an LDAP server.

Use of spring provided us the easy way to move from one authentication mechanism to another (we had modelled Authentication as a module).

As part of the corporate standards the weblogic server hosting the application was configured for HTTP on a non-standard port and hidden behind Apache SSL proxy servers. This change, introduced just prior to UAT, caused some unexpected issues with the application, with "Page not found" errors on successful login. It was traced to the <base> tag being generated by Tapestry without the knowledge that the application is residing behind an SSL proxy. After some thought on alternatives, it was decided not to tinker with Weblogic, instead going for BaseTagReWriter that emits nothing.

A key component developed for Tapestry during this period was for CRUD (Create, Update, Delete cycle). This came in very handy due to the very data-centric nature of the application.

User interface required a tabbed (CSS implementation) page with some dynamic components. Both of them were complicated to implement in Tapestry. There were some Tab controls in the wild, most of them were insufficient for our use. As for Dynamic components, an example was the ability to attach more than one document on the same page. The application does not know how many files will be attached. In addition, we could not transfer the files in the background (AJAX upload?) until the user explicitly Submitted the form.

AJAX

As part of POC we used DWR to asynchronously verify few fields on forms. It was finally, decided that AJAX will not be used extensively due to user preference for a 'traditional' webapp with ability to go "Back" etc.

Spring + Tapestry integration

While we used HiveMind to enhance core tapestry functionality (custom tag writers) and components (for e.g. Excel export from Table components), we chose to use Spring extensively for our services. Services for DAO, Authentication, Logging were foremost. The approach to access spring compoents from within Hivemind/Tapestry4 is well documented and without any issues.
Spring provided us extensively documented approaches to datasources/pooling/authentication (initially Acegi until we decided not to use it)/lifecycle control.

Application performance

The application was working with around 16 tables with various data characteristics. The widest table consisted of around 80 columns. The largest number of rows on a table was around couple of millions (this was the versioned version of another table, for audit/historical reasons).

Tapestry tables, with paging, custom column rendering etc. were extensively used. Where there was concern about caching lot of data in session without time limits, we chose to restrict the users to maximum number of results.

Well established load testing tools are in place in the organization and the Tapestry application came out shining in comparison to other applications. Granted, this is due to focussed tuning of Oracle queries, tables; judicious caching in the application itself and suitable 'forgetPage' calls to clear out cached page level objects.

Project debrief

The project acheived its goals as far as the business goalas were concerned. As part of the project review/debrief, there were reservations expressed as to the choice the technologies. Primary target for the comments was the use of Tapestry instead of Struts.
Around the time of launch Tapestry 5 was already in very preliminary stages of design and concerns being expressed on different fora regarding backward compatibility and support.

The smooth performance of the application and easy changes towards the end due to use of services through Spring helped mitigate some of the concerns.

Given another opportunity to select technologies, we would still probably look favorably at Tapestry when evaluating against the other frameworks. Nonetheless, use of Tapestry turned out to be additional work for managing client expectations and preconceptions

Written on 1st March 2007 We welcome your feedback, please send mail to enquiries