Review of Spring Webflow 2

I've been excited about the promise of workflow tools since I began my career fifteen years ago. But all the tools I've worked with failed to deliver on that promise. My complaint is that they've always been too complex and I've consistently held that if you can't use notepad to make flows, the tool will never be a hit with developers. Simple is why the SMTP protocol rules the e-mail planet long after better, more secure protocols have been available to replace it.

The thing I like best about Webflow and how it works is that for the first time in my career we were able to truly create a flexible layer between the services and the user interface.

Spring Webflow is simple as far workflow systems go (Webflow is made for web based use cases hence the name) but there is definitely a learning curve. A colleague of mine (Mike Blank) and I decided to use Webflow to implement complex web flows we were building out for a Coca-Cola project. Though we are both very senior architects, it took us about a week to really be proficient.

The biggest problem we ran into quite frankly is that there are two versions of Webflow, 1.0 and 2.0. The documentation that comes with Webflow is ok but a lot of what you need simply isn’t documented. For example, you can use OGNL expressions to do some powerful things but the docs don’t really cover that. As you browse the net looking for documentation, you come across some nice samples and tutorials but they are often for Webflow 1.0. Webflow 2.0 changed a lot and so just when you find what you’re looking for you realize that it’s not for the version you’re working on. There is a great book on Webflow called The Definitive Guide to Webflow but though the publish date is after the release of Webflow, the book is based on Webflow 1.0. Many of the examples simply don't work with 2.0.

We were doing some complex stuff though and once we got things up and running, we were able to be very efficient. The flows we were building often had up to ten actions in them with many different view states. We had to handle things like…

  • Prevention of multiple transactions resulting from reloading a POST page.
  • Redirecting to HTTPS from HTTP and back again at the appropriate times.
  • Efficiently handling the back button and resubmitting data.
  • Making sure the application would work properly in a WebSphere cluster.
  • Complex flows based on complex business rules.

We hit a lot of gotchas. For example, Webflow requires all of your classes to be Serializable because it serializes your objects into the HTTP session in between calls. This was a pain for us because we were not using clustered sessions so it was not necessary to serialize objects into the session. To make matters worse, we were doing web services and the domain objects we needed to serialize were generated by another organization. We had to decompile the code, implement serializable, recompile, and rejar.

In the end though, if we had tried to handle all of the complex issues without Webflow it would have been much more difficult. Now that we understand Webflow better, we can tackle new tasks with ease. We literally replace about 10,000 lines of code in 15 classes with 1,500 lines of code and 500 lines of XML.

The thing I like best about Webflow and how it works is that for the first time in my career we were able to truly create a flexible layer between the services and the user interface. As an example, we were able to create login and registration services that would give the client the ability to move from a two step to three or four step registration process without code changes. More importantly, they could use two step registration for some users and three step for others based on business rules. If the user came as a referral from another company we could give them the ability to capture their rewards number from that company in another step in registration. To do that without writing code is a wonderful thing.