SWF vs Seam??

[toppac]

This may be a sore subject but I was just curious what the major differences are. I've worked heavily with SWF and really like it. I know some people really like Seam. They appear to be very similar in concepts, just a little different implementations (and Seam seems to require jBpm to really do everything webflow does). Can anyone point out where these two frameworks really differ?

[klr8]

Disclaimer: I've never studied Seam in-depth, so this could be inacurate and incomplete. Please correct me if I'm wrong.

I'm not sure SWF and Seam are all that similar.

SWF has 3 main design goals:
- an expressive flow definition language
- it solves the back button problem
- it allows 'modular reuse' of flows
SWF focusses on these problems, serving as an extension to many hosting web frameworks, for instance JSF.

On the other hand, (As far as I know) those are not really the main goals of Seam. Seam seems to have a much wider scope, including things like PDF generation, email support, ... It's main goals seems to be "provide a consistent and easy-to-understand programming model for all components in an enterprise web application".

The overlap of the 2 frameworks is only in the area of supporing statefull web applications, where Seam uses jBPM as a work flow engine and SFSBs to manage conversational state. I don't think Seam addresses the back button problem or modularity concerns.

Another thing to keep in mind is that Seam is JSF specific and targetted at JEE 5 (although I think the more recent versions are usable on earlier J2EE versions).

I'd like to hear from people that have used both SWF and Seam. What are your experiences with regard to the areas where the frameworks overlap?

Erwin

[jamesclinton]

Personally I think they are v.similar.

They both offer:
- variable scoped beans and conversational state management.
- complex flow navigation.
- back button support

Seam is definately pushing EE but you can use it without and deploy on tomcat using normal hibernate.

Seam is designed to work with JSF and have tags to support integration of Spring.

Horses for courses.

[toppac]

I agree with james. From what I have read of Seam it's main goal is to provide conversational level management, similar in concept to SWF. What just Seam does lack is the complex flow navigation that SWF has out of the box. Seam relies on jBPM to provide this level of functionality.

Seams bidirectional injection is interesting but I am not a big fan on annotations. Seam also is written specifically for JSF.

I like SWF's ease of use and concepts. It also is pretty independent of other technologies.

[Delphi's Ghost]

I've been evaluating Seam and Spring + SWF for a while, so I can give you a good idea of the differences.

Comparing SWF & Seam is a bit apples and oranges. A Better comparison is to compare Seam & Spring and JBpm and SWF.

The main goal of seam is to take a set of technologies such as JSF, JBpm, EJBs, Ajax, JBoss Rules and provide a single framework that glues them together, with some Dependency injection thrown in. Seam also handles the whole lazy initialization problem transparently, as well as allowing extended persistence contexts.

It handles conversation and state management across conversations, which can also consist of pageflows.

It does also provide template based email and PDF support in a JSF like syntax, and it does solve the back button issue, as well a reusable flows.

SWF is very similar in nature to the Jpbm pageflow part of seam, but the Jbpm part is not required. You can still use JSF navigation (eugh!) or seams extended JSF type navigation that allows for calling methods on transitions and decisions in the navigation. Or, you can use the full blown Jbpm pageflow tools. Jbpm also provides a task based flow which can span multiple sessions, and even users (like order processing from one person to the next).

Excluding the task work flow, SWF + Jbpm are very similar, in fact looking at SWF helped me 'get' some of the concepts in Seam pageflows (and vice versa).

Seam is great if you are planning on using JSF, JPA (probably with hibernate), and want pageflows that tightly integrate with them. Seam uses the EL Expression language throughout the framework (i.e. I can write log messages like Log.debug("Saving person #{personEdit.person}", or make security checks using EL).

The one thing missing from the JBpm side that SWF has is it allows parameters on method calls on transitions which I don't think JBpm does (yet?).

My only other concern is that they don't seem to eat their own dog food. I'm sure Interface21 have used Spring in plenty of projects, whereas I doubt too many on the seam project have time to use seam other than creating demo apps.

Seam is tied in with the JSF, JPA, EJB , Jbpm stack, so in this respect, I kind of think of it as the ASP.Net of the Java world. I know everyone loves choice in the OSS and java side, but with a narrower view, they can, and have tightly focused on a limited set of technologies and how they interact rather than than the framework & library soup that would be needed otherwise (JSF, Struts 1 & 2, tapestry, spring, Stripes, velocity, hibernate, JPA, toplink, freemarker, acegi, JSP, Wicket, Rife, Spring MVC, facelets).
It also makes it very easy to get support since everyone is using the same libraries. With technologies like spring it's often hard to find answers when everyone is using different persistence/view/templating/security libraries.

The seam documentation is very good, but only a chapter is on Jbpm, whereas SWF has a whole document to itself.

Quick SWF question while I'm here, how do you push an object from a bean to the pageflow variable? I have a <var name="person" scope="conversation">, if I'm creating a new person (if the personID page param is null) how do I push the newly created person into the conversation/flow?

[toppac]

Great explanation of the pros and cons of each. Thanks!

[dkane]

I have done two projects with Seam in last half of an year, and now mastering Spring. So far no enough experience with Spring to make deep comparison. Some thoughts (regarding to Web development only, as Seam is not player in other tasks):

Seam+Richfaces is pretty quick when you need to create standard CRUD things. Seam app can be developed just like stateful desktop app , without knowledge of HTTP, requests, etc. You can even generate ready to use CRUD skeleton from database with JBoss Tools and SeamGen.
Spring has not achieved such level of abstraction so far.

This coin has the opposite side, though. Seam+JSF has many layers , and exception stack traces are awful. Even with perfect Seam debug capabilities, it is very hard to understand what happened and where.
Richfaces provides cool UI components with ajax support . But some of them are still buggy. Although RF team accepts bug reports quickly, resolution took weeks and monthes , which often shifted my production schedule.

Seam app deployment on servers other that JBoss / Tomcat is tricky. Formally many servers are supported, but you have to dance around jars and configuration .

Seam-managed persistence context is great. Eliminated LIE and detached entity problems. So far have not seen anything like that in Spring.

In general, majority of ideas (bijection, contextual components, interceptors, pageflows) looks common for these two frameworks. These are definitely competitors, and that's good because any competition stimulates evolution .