Developing a web-based application is never a small undertaking. At the very best it’s a lot of work just to develop the code that does whatever it is your application is supposed to do but before you even get to the point of writing your application’s code, you have to decide what you going to write it in.

Deciding what framework or even platform to use can be an excruciating decision and can greatly influence how well your final product works and how easy it is to maintain or connect up to other systems should you need to either export your systems capabilities or import services/data from them.

For the last 4 months I have been developing a very interesting web-based business application (which I will announce here as soon as we’re out of our alpha-test) but deciding exactly how to implement our product took many months and a lot of agonizing analysis about what platform and framework to use. In the Open Source universe, just like Linux or *BSD distributions there is an almost incomprehensible list of options to choose from, and the decision what to write your application in must almost always come after what to write your application on.

Did I hear you say”Huh?” I’ll explain…

In the world of Web development there are 2 basic ways to write an application: 1) on top of an HTTP server, or 2) on top of a web application development/server platform. The most common HTTP servers are Apache and Microsoft’s IIS; Web Application servers are usually Java-based engines that support either “Enterprise Application Services” (i.e., J2EE or J3EE) like Geronimo, JBoss, Websphere, or Glassfish or web application servers like Tomcat or Jetty.

On top of each of these have been developed hundreds of frameworks, libraries, and the like. For Web Servers these are usually scripting languages like ASP, PHP, Perl, Ruby. For Web Application Servers Java frameworks like Struts, Tapestry, Spring, or Wicket to name a few (there are dozens) all the way down to the HTML/Java fusion that is Java Server Pages (JSP) or even more recursive hybrids like Groovy or Jython on top of Java on top of a Java Web application platform.

The first problem anyone thinking about developing an application has to wrestle with: What’s the development platform? The answer to this question is often dictated by the skills of the people involved: If you are a really hot Perl programmer it’s unlikely that you will randomly decide to leap into a Java framework. If you have a diverse collection of skills, you have more choices, but the hard part is deciding which frameworks or libraries supports most of the capabilities you need, so that you don’t spend lots of time implementing things that could have come for free inside a framework..

After surveying, evaluating, and agonizing well over a hundred frameworks and libraries in Perl, PHP, Python, Ruby, and Java, we chose perhaps the most under-the-radar, yet most powerful web application currently available. It’s called RIFE.

What is RIFE?

RIFE is a web application framework developed at Uwyn which is a custom software development shop in Belgium, and Open Sourced several years ago. It has been in more or less continuous development since about 2000 (back when there were very few choices in large-scale Java web frameworks).

It is a “Full Stack” framework, and by that I mean that the RIFE framework supports application development at every level of abstraction, from the presentation layer all the way down to the management of the databases that underly the web application. RIFE sits on top of a web application container (like Apache Tomcat or Jetty) and provides all of the application level services needed to start up and run a web application.

RIFE Component Diagram

As shown in the RIFE application stack diagram (courtesy Geert Bevin, Uwyn), the services RIFE provides look very much like the kind of services and processes you might find in a traditional desktop application development environment framework, such as Microsoft’s Foundation Classes or Apple’s AppKit. RIFE provides high-level access to and management of web pages, databases, timed events and asynchronous task execution, email processing, exports of RSS/ATOM feeds, authentication and access controls and more.

Clearly, the design goals of RIFE were to take away as much of the grunt work in Web Application development as possible, allowing developers to focus as strictly as possible on the processes and features that make their application unique.

There’s a lot of stuff in there, which is all nicely covered at the RIFE Web Site, but some of the most interesting features are:

  • Extremely simple configuration with a minimum number of XML files. RIFE has the concept of a “repository” in which all application level configuration files are stored.
    RIFE’s repository consists of:
    • A “site” XML file that defines how the application components are wired together,
    • A “datasources” file which is pre-populated with the 8 DBs that RIFE works with out of the box (including Oracle,PostgreSQL, MySQL, and Derby),
    • A “users file” which supports an in-memory user authentication system (a DB-backed system is also supplied), and
    • A “participants” file which allows you to tell the application framework about the subsystems (including a “cron” type job scheduler, and an email queuing system) you want activated when your application runs.

    With the exception of your code, that’s all the configuration that generally has to be done in RIFE (you can have more XML files of course, if you decide to break your site wiring descriptions into smaller chunks). It’s a nice change from most frameworks that leave the developer downing in XML files that must be edited.

  • Components Everywhere – Almost anything you create with RIFE can be re-used as a component. So this means that if you create a page that say, displays a calendar, you can reuse that page as an embedded component on another page by simply invoking its name inside another page’s template. This feature alone has saved me hundreds of hours of re-coding and has allowed me to develop a whole suite of generic GUI elements for my application.
  • Database Persistence Capability that is about 80% of what’s useful in Hibernate with only about 5% of the setup. Basically RIFE allows you to define your data in plan Java Beans (a simple Java class with setter/getting methods), make a separate file that describes the contstraints (the metadata) that need to be applied to the members of that object — for example “usernames must at least 6 characters but no longer than 20” and RIFE will instantiate a table in your database and give you a query manager that handles all of the common functions you need to manage that data transparently.
    RIFE also has a CRUD (Create-Read-Update-Delete) functionality that can automatically create basic data management forms akin to the “scaffolding” capability available in Ruby on Rails.
  • “Logic-Less” HTML Templates – Unlike PHP or even JSPs, RIFE doesn’t co-mingle commands and presentation — but at the same time you can control presentation programmatically by changing the values of template variables (via “Blocks” to change sections of a template and “Values” to perform more finely grained changes) from inside the Java code that loads the template.
  • Flexible Content Management Framework that can be used to store just about anything from PNGs to videos. Oh, and it does versioning so changes to content can be tracked.
  • Web Continuations – this feature allows RIFE applications to support multiple code execution paths that allow the user to be able to, for example, go backward and forward when dealing with forms or processes that present several decision paths. For example, imagine checking out air fares where you might get all the way to the “submit payment” button and realized you needed to correct a mistake several pages back; continuations allow you to hit the “back” button without losing all the data you’ve entered on the intervening pages. RIFE’s continuations also provide a feature to ensure that data can’t be submitted for action multiple times, so once you did hit that “submit payment” button, clicking it a second time wouldn’t charge your credit card twice.
  • Web Services – out of the box RIFE supports access to Web Services such as SOAP and ReST based data services
  • Out of Container Testing – one of the biggest problems with web applications is that you have to be running them in order to debug them. Of course, you’re then up against all sorts of complications with regard to whatever application server your code is running on which often comes down to stepping through reams of code until you get to the small portion that you actually want to test or debug. RIFE allows you to test your application outside of the server using standard Java unit testing tools.
  • Constraints – RIFE delivers a constraint-based meta-data capability; this means that you can specify parameters about the structure of your data that framework will use automatically to ensure that data entered into your system conforms to the parameters you specify. These constraints can be simple (“username field must not be empty, or greater than 20 characters”) or arbitrarily complex though the use of custom designed constraints.

 

What makes RIFE different from my perspective compared to most (if not all) other frameworks out there is that the RIFE framework is, out of the box, a fully functioning web application. The standard RIFE distribution, called “RIFE JumpStart” is a basic application that is ready to be customized with which one can (and it is even demonstrated in some great videos over at the RIFE web site) create pretty substantial applications in under an hour.

Yet, for all that RIFE provides in terms of what’s built-in, the framework doesn’t preclude you from using, even embedding other web technologies into your applications. A lot of other technologies have been integrated into RIFE, including the very slick flash-based OpenLaszio and even AJAX toolkits like DWR.

Writing web applications using RIFE feels very different than writing in most other Java frameworks. As mentioned above, it it a lot more like working with an event-driven desktop application framework. For the most part you don’t write much infrastructure code – the stuff you often need to write before you get down to writing your application. RIFE provides all of the application skeleton, and you just plug in your features and then tell RIFE how they should be connected together to control the flow of your application.

One interesting aspect of using RIFE was what I would call a steep UNlearning curve: In particular I had to stop trying to invent reasons to try and stuff all sorts of processing into my web form handlers — RIFE handles most web form processing for you (in fact, it compiles your HTML into Java classes on the fly) and just hands you back the data you expect — or will automatically highlight errors or incorrect data that users need to correct before a submission can be completed. Once I got over my ingrained desire to write more code than I needed to and learned to just focus on my business logic, I was able to crank out amazing amounts of work.

This entry has gone on a bit longer than I intended, so I’ll close by suggesting that RIFE should be on the evaluation list for anyone is planning on developing a Web-based application: it’s fast, incredibly powerful, and very easy to get started using and to quickly see productive results from.

In the resources section below are links to RIFE and a few applications that have been developed in it. When our application goes live, I’ll talk about some more about RIFE and the very powerful application I have been developing using it.

Resources

The RIFE Framework
The Bla-bla List (A shared web to-do list system)
An IRC Utility Robot (“Drone” an IRCbot written using RIFE)
MoochSpot (A site for tracking shared expenses (or debts) with your friends from the developers of Facebook)