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!
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.
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.
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.