Seam vs Spring Web Flow Part 4 – Conclusion
The last installment is finally ready. After many a re-write and consideration of all the issues to come to a fair conclusion, especially as new versions were coming out and new features are being added, I’m finally able to publish it. Framework Comparisons – are they ever completed? Anyways, here it is in all it’s ….well, it’s here. Enjoy.
17 thoughts on “Seam vs Spring Web Flow Part 4 – Conclusion”
Comments are closed.
Your comparison, while quite fair overall, was subtly biased for Seam. That is, until the summary in part 4, when pejorative terms like ‘irrational phobia’ and ‘Spring follower’ shows it clearly. Rephrasing of some parts would be welcome.
A typo: ‘Here is a diagram demonstrating this problem in Seam :’ in part 4 has no following diagram.
Nice and useful article, thanks.
Thanks Tetsuo,
To be honest, I thought the last part was turning a bit too pro-Spring, partly because I am thoroughly aware of problems in Seam while I have not discovered all the pitfalls of Spring. That works both ways though, I am also aware of most of the good things in Seam and not so with Spring. I found this a very difficult part to balance which is why it took forever to get ready.
Regarding the term “Spring follower”, I really didn’t mean anything derogatory about it, simply referring to Spring users, particularly those that advocate it, and the idea was that SWF works the same way most other Spring stuff does. However, I can see how it might be inflammatory so I will change it.
As for irrational phobia, I think this is fairly accurate. In light of the changes in a newer and lighter EJB 3.0, there are still plenty who behave as if EJB was still in its 2.x days and unusable. In addition, there is a bit of a stigma with using Java standards or JBoss stuff and Gavin has been involved in a number of heated ‘debates’ over the years. As a result, there is plenty of (unreasonable) animosity on these issues in the Javalobby and Server Side forums.
Personally, I don’t think I am biased especially as I’m even considering using SWF for my next project having used Seam in the previous. I don’t think the conclusion came out that biased since the sentiment was that they both have strengths and flaws, but they are both great, one is ‘lighter’ while the other has deep integration. For the sake of impartiality, I’ll change the wording as it would be a shame to signal a bias where none exists because of a careless turn of phrase.
Thanks for spotting the typo, that section was removed at the last minute, but I’ll be putting up a couple of posts regarding Spring/Seam persistence context management, and another regarding managing data in conversational frameworks.
Cheers,
Andy Gibson
I’m siding with the first poster that you’re favoring Seam. That’s ok, we all have our preferences. A couple things that could/should be added (there were about 8, but here’s a couple).
1. Stateful/Stateless – Seam is entirely stateful, which is much harder to cluster. Plus, when the server goes down that is holding my state, I (the user/client) gets hosed. Not a good scenario.
2. Hiring – you touched on this, but I thought more consideration should be included. Look at the job trends of seam, ejb, spring and you’ll see that seam and ejb have leveled off, yet spring contiues to climb. If I’m running a company, there’s no reason (right now) to think that Seam will grow, thus making hiring more and more difficult (right now it’s very difficult to find Seam developers). I personally don’t feel it’s my companies responsibility to train others on my dime/time…
Hey Jim,
Taking your points in reverse, regarding hiring, I think the level of jobs for EJB & Spring are probably a statistical tie. Whichever way you go there are jobs with those techonologies. The fastest growing view technology is JSF and many who find their way to JSF end up using Seam as a way to bridge the problems of JSF. Your arguments about training people in Seam would also apply to Spring Web Flow which right now doesn’t have a lot of job support, and even technically, Spring MVC which also doesn’t have a high job count (less than JSF). However, I think we agree on the generalities. Seam nor Spring Web Flow have a strong job market right now.
Regarding the stateful/stateless nature, I think Seam can be as stateless/stateful as Spring Web Flow with Spring MVC. You can use a plain old Spring MVC controller to render a stateless page and you can use stateless components in Seam, plus there is the page scope that allows state to be held in the page and not on the server. However, in both cases, there is the danger that state will be over used without careful attention.
Regarding bias, when I wrote it I was more experienced with Seam and able to cover it more completely, currently I’m enjoying the basic simplicity of Spring MVC & Web Flow. It’s like going back to assembly language after using Java or c#.
However, I have been finding that without state and a component view technology simple search & pagination is a pain (passing all those parameters around).
I’m actually starting to wonder if something like Wicket is the compromise than provides the best of both worlds which is something else I’ll be looking into soon.
Not sure I agree on your job results comparison (but that’s difficult to assess). If you look at each layer, I think Spring is ahead (but slightly in some areas). JSF is a wash. Looking at page flow in seam vs. spring web flow, I think there’s more support for web flow (but very little). I made a call to a couple recruiters and they both are limited. I think Spring wins clearly when compared to EJB.
http://www.indeed.com/jobtrends?q=ejb+and+java%2C+spring+and+java
Plus, according to a couple surveys, Spring is soaring..
http://www.eweek.com/c/a/Application-Development/Survey-Spring-Framework-Adoption-Soars/?kc=rss
I’m also not a fan of a framework (EJB) that has a history of failure, only to be influenced by another (Spring).
Accordingly, the EJB 3.0 specification (JSR 220) was a radical departure from its predecessors, following this new paradigm. It shows a clear influence from Spring in its use of POJOs, and its support for dependency injection to simplify configuration and integration of heterogeneous systems.
http://en.wikipedia.org/wiki/Enterprise_JavaBean
Don’t get me wrong. Seam is a great solution. The main reason I prefer Spring is it’s maturity and support in other ares (Web Service, Integration). Seam is geared towards web based development. While Seam does support mainstream service technologies (JAX-WS, REST-WS), it doesn’t support SCA.
Sorry..forgot. I’d be very interested in your Wicket findings…
Hey Jim, Sorry, your comment got stuck in the spam filters, probably because of the links.
Your thoughts make a lot of sense and fall within the margin of error of agreement. Spring does have this clean implementation such that even with something complex like Spring web flow. Because it is made up of small blocks, the concept of each block is easy to grasp, and therefore, one thinks (and it may be true) that the implementation is simple giving you the feeling you can easily adapt the framework to suit your needs. This gives the developer the feeling of control. Like Open Source where most developers never compile projects but they like to know the source is there should they want it.
EJB on the other hand often feels like a heavy black box dropped on the server and it’ll just figure out all that “stuff” for you with a fixed rigid implementation. I do think EJB needs to undo some of the complexity and even some of the bundling. However then it wouldn’t be EJB which wouldn’t be a bad thing as a complete re-branding (web beans?) might do it a world of good. Even web beans seems too web centric (read container-centric) as opposed to OOP-centric which is what Spring really is at its heart.
While all that is true, Seam does a great job of taking EJBs for better or worse and running with it to create a single platform to develop with and ties it all together with a great IDE. It is worth pointing out that Seam no longer requires an EJB container nor does it require EJBs and can run easily with Non-EJB POJOs (since EJBs are now also POJOs). However, the marketing thing matters and people now have the impression that Seam requires EJB & JBoss & Hibernate to run while the Seam team is making it as diverse as possible (server and technology-wise). On the other hand, Spring is doing everything they can to make sure you are running only Spring and on a Spring Web Server, and yet public perception has it the other way around.
I’ve had this flu thing recently, so I’ve not had much time to get into the Wicket stuff, but I’m thinking it really might solve a number of problems without compromising too much.
Thanks again for your thoughts Jim,
Cheers,
Andy
Let me ping your experience. I thought EJB needed a container. Isn’t there a JBoss embeddable container that’s needed? I know there’s the Non-EJB (POJO) approach, but there’s more configuration required for that. Every book I’ve read is pushing the EJB approach. To be specific, can I run a JUnit test from Eclipse/Intellij without using any kind of container (AppServer, Embeddable Container) using EJB3 and Seam?
On the Spring/Seam being dependent on their ‘own’ technologies, I think we’re fairly in agreement. When I look at Seam, I see, JBoss Rules, JBoss jPDL, Hibernate and all these technologies are under JBoss. Even some people think EJB is JBoss:
http://www.devx.com/opinion/Article/21244
With Spring, you can use Struts, JSF (with or without Web Flow). Can I swap out Seam page flow for something not under JBoss? Didn’t Seam run on JBoss AS in it’s initial release and not support other AS’s?
I can use pretty much any UI framework (JSF, Struts,..) with Spring, but that’s not the case with Seam. Gavin King has explicitly said he wants Seam to have few choices, which is fine. But those few seem to be JBoss related.
I do think both companies are putting out tremendous technologies that work well together. I just think Seam doesn’t support as many, but this could be due to the maturity levels of both.
On the multiple tabs and back button issue you talked about, do both technologies support them? I haven’t run into the back button you’re experiencing with Seam, but I’d be curious if I can reproduce and test it out with Spring Web Flow…
thanks
EJB does need a container (although now there is the embeddable container), but Seam doesn’t require EJB, therefore it doesn’t require a container. Configuration is usually handled as a one-off by the app generators so. You have extra configuration in Spring to set up a datasource and transaction and an entity manager for JPA. Granted, Spring does each piece of configuration in the same way making it easier, while with Seam, different things need setting up different ways. As for your testing question, it is as doable as it is to test a pojo without Spring. It’s no problem as long as the pojo has no dependencies, if it does, then you need Spring or some container to inject them unless you do it manually. There’s really no difference (or at least there won’t be soon) between the Spring container and an embeddable EJB container which I believe is part of EJB 3.0.
Spring can use JSF or Spring MVC and Seam can use JSF and now Wicket. The pageflow mechanism is based on the JSF navigation handler so I suppose you could use another one since all the data (conversationally managed and otherwise) is available through EL. If you look in the source for the navigational handler, all it does it see if a pageflow is running and if so, delegates the navigation to the pageflow handler. Thinking about it, it is very Spring like in that it could be replaced.
When you start asking can I use X instead of Y with Z, you have to be careful because in many cases, Y is Z and is unreplaceable.
The classic case is that EJB needs a container while Spring doesn’t and can use any web server, but that is simply because Spring is the container, which leads to “can I swap Spring out for another dependency injection provider?” No, because Spring is Spring which is why many people have said that Spring leads to vendor lock in. When you start using the hibernate template and so on, you really are getting tied to Spring.
You can use any framework with Spring as long as it is only handling the Dependency Injection / AOP pieces. The more Spring you want to use (web flow, security etc), the more restricted you are in your choices. The other factor is how well they integrate which exhibits the same mannerisms. Spring is easily integrated as long as you stick to the core. When you start using the more specicialized piece (web flow etc), then integration becomes a more manual and difficult process. The same applies to Seam except the problem Seam has is it starts out as a 10 piece band, while Spring starts with a drummer and builds itself from there. If two instruments clash in Spring, then you add one or the other, but with Seam, you have to take one out before you can put the other in which is a more difficult process. Regardless, they both have the same limitations.
I still think of Seam as the ASP.net for Java, a one stop platform for getting things done. The idea of being able to interchange every piece of a platform will be the undoing of java as it brings complexity and probably bugs. It is a good platform as is the Spring & web flow platform which I’ve been investigating further over the last month or so.
If all we had was Seam & JSF or Spring and Spring Web Flow, we would all probably be happy, and rather than re-invent the wheel we would all be working on making those platforms better. I think it will be interesting to see how Web Beans will change all this at least on the web development side.
Thanks again for you comments,
Cheers,
Andy
Andy,
Great article! You went just deep enough on each topic to make the important points clear.
It’s sad that certain posters can’t see the forest for a couple of trees. This is the LEAST BIASED discussion of the merits of Spring and Seam I have ever seen. I would love to be shown to be wrong on this. Please post a link, as I would sincerely like to read such an article.
Any plans to update the security section to cover Seam 2.1’s identity management?
Thanks Rocka,
I realize that Seam has since beefed up their security API, and I’m not sure whether I will get around to update the docs with limited time and the other projects I’ve got going on plus trying to blog Lost. Briefly though,I think that the new Seam security puts Seam on the right track, and while it doesn’t offer the same number of features as Spring security, I think they probably cover the most popular elements of it. Seam and SWF both offer a number of places to insert security and role checks into your applications.
Disclaimer : I have to confess, we haven’t upgraded to Seam 2.1.1 GA yet, and I’ve only tinkered with it.
Thanks again for commenting,
Cheers,
Andy
Andy,
I enjoyed reading your comparison. I wanted to let you know we’ve made significant updates to the Web Flow reference manual in in 2.0.6 and 2.0.7, particularly in the area of exception handling. We also fixed the one typo related to currentEvent attribute access–thanks for pointing that out.
Regarding exception handling: generally the best way to handle business exceptions in Web Flow is to catch them in Web Flow Action Java code, take whatever recovery action is required (typically adding a message to the MessageContext), and return an appropriate error event the flow can handle. This is discussed in the Rendering Views and Executing Actions sections of the reference guide. I find I recommend use of custom generic exception handlers much less often (though I do expect we will add more convenience for general exception handling cases in future releases).
I also posted a Web Flow project update recently here: http://blog.springsource.com/2009/04/20/spring-web-flow-project-update/ you might find interesting.
Thanks for taking the time to do such a detailed comparison. I wish you continued success using Spring and Spring Web Flow in your projects.
Keith
Web Flow Project Lead
Hey Keith,
Thanks for commenting and congratulations on a great framework. As always, it’s great to see innovation in action.
You are right about the exception handling, writing code to sit between the business objects and the view to catch exceptions and put out error messages is the best and only way to do it and still leave your business logic untainted by the view tier.
I will take a look at 2.0.7 as time permits, and in the meantime, here’s wishing you all the best for SWF.
Cheers,
Andy
Here is my take on this issue, but focusing only from the perspective of JSF development
http://edemmorny.wordpress.com/2009/04/29/jsf-applications-%e2%80%93-jboss-seam-or-spring-web-flow/
Will like to hear your opinion on this
Hi Edem,
A good list of points, I left a more complete comment over on your blog.
Cheers,
Andy