About the OPS 3.0 XForms Engine

Two days ago we released OPS 3.0 beta. This is a great milestone for the open source Orbeon PresentationServer, because it's the first time OPS features an XForms engine with full support for events!

When we started designing OPS (then called OXF) back in the summer of 2002, we focused on two main things: the XPL pipeline engine and XForms. Our choice of XForms was motivated by the fact that we really did not want to reinvent the wheel, and that we have always believed we should choose standards whenever possible. However at the time XForms was still in its infancy at W3C, so our approach consisted in picking a few features of XForms we could easily implement server-side. There was born the first OPS XForms engine.

Between OXF 1.0 and OPS 2.8, we progressively added features to the XForms engine, based on users' needs, including our own. However, XForms events were nowhere to be seen, which left us a little bit uncomfortable since events account for a very large part of the XForms 1.0 specification.

Then came Ajax. Like everybody else, we had been doing Ajax forever at Orbeon. Back in 1999-2000, our Virtual Browser project had a user interface with underpinnings which were very much Ajax-like. However, to be fair, there was nothing of the sort in OPS. But the Ajax craze made us realize that we had now a mature solution to implement XForms events in OPS in a responsive way.

So we set to work, heavily refactored the OPS 2.8 XForms engine, designed a compatilibity mode in OPS for legacy applications, and updated the architecture of the Page Flow Controller which would accomodate the new XForms engine. The architecture, based around the concept of XML submission, turned out great! In just a few days of work, we had a functioning Calculator example. In another four weeks, we had a decent Ajax-based XForms engine with support for most XForms events and actions, the Switch module, and more, enough to do some pretty cool demos at XTech 2005. It then took us another 6-7 weeks and here we are with OPS 3.0 BETA!

Now this is actually quite exciting because the approach we have chosen for our XForms engine makes it different from the competition. Other XForms engines are available in the form of plugins (FormsPlayer, for example), native browser implementations (the in-progress Firefox XForms implementation), or pure Javascript implementations. Chiba is a pure XForms engine which can work as a pure server-side implemenation (non-Ajax at the moment) or as an applet on the client. The Ajax-based OPS implementation is in fact hybrid, with a light client-side module written in Javascript communicating with a heavier server-side module written in Java.

In short, what are the benefits of the OPS way?

• Deployment is trivial: there is in fact no deployment at all, as OPS is using stock web browsers.

• Upgrades are easy: update the server-side code, and your XForms engine is updated.

• Code is light on the client: the Javascript running on the client is much simpler than a full-fledged Javascript client-side implementation, or than a Java applet or Flash-based implementation.

• Extensions are easy: because the XForms engine can leverage the entire Java platform, it is possible to easily build extensions to XForms. For example, it is trivial to add XPath 2.0 support (in fact this is already supported in OPS 3.0 BETA).

• Optimizations are possible: for example, an option to keep state information on the server could be implemented. Large XForms instances could be kept on the server instead of being sent to the client, resulting in smaller pages and increased confidentiality.

• Other XForms engines are not ruled out: you can decide with OPS to send native XForms directly to clients that support XForms, and to use the OPS XForms engine for clients that do not.

• Time to market is shorter: this could is in fact be considered an implementation detail, but because the hybrid architecture chosen for OPS delegates most of the hard work to the server, development of the XForms engine is much faster: developing in Java gets you a strongly typed programming language, powerful tools like IntelliJ or Eclipse with incredible editors, debugging and refactoring, profiling tools, myriads of available open source libraries, and more. We argue that it is much faster to write an XForms engine in Java than in Javascript, Flash, or C++!

I probably forget some benefits, but you get the gist of it. Of course, to be fair, there are some drawbacks too, since any Ajax-based architecture requires communication between the client and the server. It is going to be up to application developers to evaluate how their use of XForms events in particular impacts the latency of their XForms-based application and the load of their server. But for sure, said latency and load can be smaller than by doing full client-server roundtrips that reload pages entirely, as is today customary for many web applications. And finally, this is the first version of the OPS hybrid XForms implementation, and optimizations can certainly be achieved in the future.

Don't forget to go check out the beta. The OPS examples are online, and the downloads are at ObjectWeb as usual.