Spring Web Flow or JBoss Seam?

I was just discussing a dilemma with our UI architect: what framework should we choose for our web front end? The whole discussion revolved around Spring Web Flow, or SWF, and JBoss Seam, or Seam. Both frameworks offer roughly the same capabilities, so we ended up talking about small distinctions that, at least to me, favor SWF.

If you haven’t heard of either framework, I recommend Vlasta Vávra’s article on Spring Web Flow and Petr Ferschmann’s talk on Seam and JSF.

What matters to us is that both frameworks offer conversations, or definitions of application flows. A conversation is a sequence of request and response cycles that make up one logical unit from the application’s point of view. An order, for example, includes entering the details, checking the data, choosing delivery and payment, previewing and submitting. Both frameworks also integrate with Spring, which matters because Spring assembles most of our application logic.

What I miss in both frameworks is broader support in development tools. Both support Eclipse only. It’s a shame that, at least in SWF’s case, the announced Spring Tool Suite won’t change that.

Seam

In my opinion Seam has two major characteristics, which you might count as advantages, drawbacks or at least points of contention. It encourages extensive annotation use and bypasses controller and view helper components. To be fair, Seam offers XML configuration too. I can’t judge how equivalent it is. Bypassing the controller and view helper means pulling data from and displaying it directly through the model class. Architecturally I have more trouble with that because the application logic bends to the needs of the web framework. Since the same logic is exposed through REST, that coupling causes problems.

I see an advantage in Seam becoming a J2EE standard through WebBeans. That will spread the concepts Seam introduced and bring benefits with it. The early draft WebBeans specification is available, as is Gavin King’s Web Beans Sneak Peek series.

SWF

SWF offers three interesting features we would use. First, it supports extending conversations in code and controlling them programmatically for integration tests. Second, it is much more flexible about view technology, whether JSF, Spring MVC or Struts. Third, like most Spring projects, it follows the open–closed principle, which matters to us because we already have a framework it must work with.

Seam does not properly support any of those three things. I would put that down to its focus. It is gradually becoming an application framework in its own right, as its scheduler support suggests. SWF focuses closely on the application’s front end. If SWF expands, it will probably develop in that direction, while Seam will go the other way.

After weighing the pros and cons, I decided in favor of SWF. If you have an argument for or against Seam or SWF, I’d be glad to read it in the discussion.