RIFE with possibilities

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're 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. It also determines 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 four months I have been developing a very interesting Web-based business application, but deciding exactly how to implement the product took many months and a lot of agonising 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 on 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 two basic ways to write an application: either on top of an HTTP server, or 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" (ie, J2EE or J3EE) like Geronimo, JBoss, WebSphere, or GlassFish; or Web application servers like Tomcat or Jetty.

On top of each of these, hundreds of frameworks, libraries, and the like have been developed. 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.

If you're thinking about developing an application, the first problem you'll wrestle with is deciding which development platform to use. 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 agonising 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 underlie 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.

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 management and high-level access to 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 website, 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 eight databases 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 database-backed system is also supplied); and
  • A "participants" file 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 is about 80 per cent of what's useful in Hibernate with only about 5 per cent of the set-up. Basically RIFE allows you to define your data in plain Java Beans (a simple Java class with setter/getting methods), make a separate file that describes the constraints (the metadata) that need to be applied to the members of that object -- for example "usernames must be at least six 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 a 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.