Opinions on JBoss Seam vs Spring

[Randy Johnson]

I just watched Rod Johnson's presentation in Denmark "Are We There Yet?", and I read some technical reviews of JBoss's Seam functionality. It seems there are several areas of competing technology:
- Seam's heavy use of annotation vs. Rod's 'perceived' concerns about them
- Seam's notion of bijection vs dependency injection
- Rod's preference for moving business logic into the domain layer vs the notion of jBPM (I admit these may be approaches that are more complimentary than competing)
- Seam's use of EJB (Entity and Session Bean) vs POJO's

What is the Spring team's take on Seam?

[gonzalad]

Hello,

I'm not in the Spring team, and just a newbie in this framework and this forum.

I'll just give my 0.2 cents (all I have ).

We're going to use Jsf / Seam / Spring in our company. So perhaps, it can give you some hints.

The reason why we're going to use Seam is because we want to use Jsf (and this is the only reason).

To explain the reason in detail :
Our first purpose was to use Jsf (sandard framework in JEE 5) and Spring (standard de facto integration framework).
After making several attemtps on experimenting Jsf, it appeared to be (to us) unusable without some add-on framework (i.e missing center functionnalities such as exception handling, poor security handling, conversation or page scope, templating, ...).
Seam was the only framework we saw which targeted all those points (or perhaps the most of these).

So the last question was :
- are we going to keep Spring or just gonna use Seam ?

We kept Spring because :
- there's no really wide experience about using Ejb3 as controllers for the moment - but there's a lot of experience using classical (and procedural - not DDD) service pojo layer.
- we're not only using Jpa in our company - but also jca accessing mainframe (50%/50% each) (so Extended Persistence Context and the new development model for it isn't really usefull for us).
- it's really wider in scope thanSeam (i.e. scheduling, available templates, security system, ....).

So we're actually have some pain integrating the 2 frameworks but so far so good... Sure it would be good if Spring provided the same functionnalities than Seam for Jsf but there isn't.

I hope this helps you

[Manuel Palacio]

there's no really wide experience about using EjB3 as controllers for the moment - but there's a lot of experience using classical (and procedural - not DDD) service pojo layer.

You can create the same "pojo" (anotated pojos are not pojos?, aren't ejb3 components also pojos? nevermind...) layer with Seam, you don't have to use EjB3 if you don't want to...

I don't see a huge difference between using "classic" spring service pojo layers or SFSB/SLSB in EJB3 in terms of using them as procedural controllers. The only pain with EJB3 is that you *have* to implement an interface everytime (you should not need to if you don't want to). The big advantage is that you get replication "out of the box" in case you need it. Seam also provides replication for "pojos" but it's a bit invasive, the recommendation is to use EJB3 if you need this. Another huge advantage of SFSB/Seam components is that you can use them as conversational caches in Ajax, wizards or in combination with extended persistence contexts. The integrated ORM support is a killer, super-easy to use. This is great stuff that most applications need out of the box.

Seam has nowadays support for asynch strategies like java.util.concurrent and Quartz in addition to EJB3 timer service. It also comes with a security framework and extension points for integration with non-JTA transaction environments.


The best thing about Seam/JSF is that you can build feature rich apps with a fraction of the effort that it would take with other popular MVC frameworks

[gonzalad]

Sorry,

My point was only : if you're goign for Jsf Seam appears an excellent choice.
If you go for another web framework, stay out of Seam for the moment.

For Manuel Palacio
I didn't explained very well my concern about lack of real experience of Ejb 3 :
- I was not talking about JPA.
- I was only talking about the statefull session bean and the extended persistence context. With those two components (the SFSB acting as a controller), you can create long running conversation between various user interactions, and you change is commited only when you call the controller method annotatd with @End.
All changes made to your domain model are kept in persistence context and only commited when the conversation is ended.
If you go for a Jpa based application, great solution. If not you won't use Extended Persistence Context, and so SFSB will be of lesser use.

Another point : my container isn't Ejb3 ready. Don't know how many containers are production ready for Ejb3 and how many persons are using it...

[Manuel Palacio]

All changes made to your domain model are kept in persistence context and only commited when the conversation is ended.
If you go for a Jpa based application, great solution. If not you won't use Extended Persistence Context, and so SFSB will be of lesser use

Yeah, if you are after fully atomic conversations and no LIEs in views with Seam then you need JPA.

[wpoitras]

You should try to compare Seam with Spring Web Flow. It has JSF support and gives an experience closer to Seam than straight Spring can.