Seam :

1. Developed by Jboss.
2. We must use JSF as Front end.

Spring vs seam

Spring mvc is a framework that has been long time out there, it is well documented and
proven technology. A lot of web sites are using spring.

Seam is a framework based on jsf - rich faces implementation. It has a lot of ajax based
components. It uses some heavy stuff like EJB, JPA. All of this is prone to errors and this
framework is so slow (at my computer it is almost impossible do develop something because it is
really slow, especially redeploying on jboss) But is is very good for back office applications.

I use both: Spring-MVC (2.5) and Seam

Because Seam uses Java Server Faces Technology (A server-side based Technology), behind the
scenes, It is better designed for small and medium applications. (Each JSF view Tree is stored on
Session - You can store on client side, but be aware bandwidth issues). But it has some
advantages:

Typically web application uses the following path

view >> controller >> service >> domain

With Seam, you can get

view >> service >> domain

Or even (by using mediator pattern provided by Seam Framework)

No controller, No service

view >> domain

Besides that,

 JSF 2 supports JSR 303 - Bean Validation

 You can use Wicket instead of JSF if you want
 Conversation and Business process management support
 Use can use Spring DI if you want
Spring-MVC

It has a powerful web-Tier infrastructure

 Handler Mapping (It chooses which Controller should handle the request)
 View resolver (It chooses which View should render the response)
 It can be used for large applications
 Powerful data-binding
 Spring 3.0 supports Annotation-based Controller (JSR 303 - Bean Validation, coming
soon)

But i still not use Spring 3.0 because

 By using (and extending when needed) MultiActionController, i can get convention over
configuration without no xml settings to define your Controller (You just need to set up
your MultiActionController as @Component)
 SimpleFormController provides similar behavior found in Spring 3.0 annotation based
controller

...

About The learning path, i think both are similar.

Opinions on JBoss Seam vs Spring

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?

Opinions on JBoss Seam vs Spring

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?

Randy Johnson

View Public Profile

Send a private message to Randy Johnson

Find all posts by Randy Johnson

  #2  
Jun 13th, 2007, 05:09 AM
gonzalad Join Date: Jul 2005
 
Senior Member Posts: 135

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

gonzalad

View Public Profile

Send a private message to gonzalad

Find all posts by gonzalad

  #3  
Jun 13th, 2007, 11:21 AM
Join Date: Dec 2006
Manuel Palacio
  Location: Stockholm
Member
Posts: 78

Quote:

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

Last edited by Manuel Palacio; Jun 13th, 2007 at 05:07 PM.

Manuel Palacio

View Public Profile

Send a private message to Manuel Palacio

Visit Manuel Palacio's homepage!

Find all posts by Manuel Palacio

  #4  
Jun 13th, 2007, 06:24 PM
gonzalad Join Date: Jul 2005
 
Senior Member Posts: 135

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...

gonzalad

View Public Profile

Send a private message to gonzalad

Find all posts by gonzalad

  #5  
Jun 14th, 2007, 03:50 AM
Join Date: Dec 2006
Manuel Palacio
  Location: Stockholm
Member
Posts: 78

Quote:

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.

Last edited by Manuel Palacio; Jun 14th, 2007 at 03:56 AM.

Manuel Palacio

View Public Profile

Send a private message to Manuel Palacio

Visit Manuel Palacio's homepage!

Find all posts by Manuel Palacio

  #6  
Jun 14th, 2007, 09:40 AM
Join Date: Feb 2005
wpoitras
  Location: Boston, MA
Senior Member
Posts: 1,140

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.
__________________
Bill

wpoitras

View Public Profile

Send a private message to wpoitras

Find all posts by wpoitras

  #7  
Jul 21st, 2007, 04:39 PM
Join Date: Mar 2006
Nik
  Location: Turku, Finland
Member
Posts: 93

Speaking of Seam...

Does anyone know if it possible to do something like @configurable in Seam (e.g. injecting a
stateless EJB into an entity bean)?

Does anyone know (or have theories on) how close the Web Beans (JSR 299) specs are going to
be to the current Seam implementation?
Nik

View Public Profile

Send a private message to Nik

Find all posts by Nik

  #8  
Jul 22nd, 2007, 06:04 PM
Join Date: Dec 2006
Manuel Palacio
  Location: Stockholm
Member
Posts: 78

Quote:

Does anyone know if it possible to do something like @configurable in Seam (e.g. injecting a
stateless EJB into an entity bean)?
It seems that right now this is not possible. Entity bean components do not support bijection or
context demarcation.

Quote:

Does anyone know (or have theories on) how close the Web Beans (JSR 299) specs are going
to be to the current Seam implementation?
Seam will be the reference implementation for Web Beans, and is one of the inspirations and
sources of ideas for Web Beans.

So a future version of Seam will implement Web Beans (I imagine it will be the first
implementation of Web beans).

According to Gavin King,

Quote:
Guice is another source of inspiration and ideas and, indeed, some features of the current Web
Beans draft look more like Guice than Seam. The current design of Web Beans is very much
superior to both Guice and Seam, since it draws ideas from both and mixes them together in a
very elegant way.

Manuel Palacio

View Public Profile

Send a private message to Manuel Palacio

Visit Manuel Palacio's homepage!

Find all posts by Manuel Palacio

  #9  
Jul 23rd, 2007, 01:33 AM
Join Date: Mar 2006
Nik
  Location: Turku, Finland
Member
Posts: 93

Quote:

Originally Posted by Manuel Palacio

It seems that right now this is not possible. Entity bean components do not support bijection or
context demarcation.
That's a shame. Well, you can always pass in a repository or look it up before using it.

Quote:

Originally Posted by Manuel Palacio

Seam will be the reference implementation for Web Beans, and is one of the inspirations and
sources of ideas for Web Beans.
I am sure Spring will have its place but I'm also sure WebBeans + JSF + JPA + EJB + (Facelets,
IceFaces and others) will have a significant impact. In a year or so, that is.

Nik

View Public Profile

Send a private message to Nik

Find all posts by Nik

  #10  
Jul 23rd, 2007, 10:07 AM
Join Date: Dec 2006
Manuel Palacio
  Location: Stockholm
Member
Posts: 78

Quote:

That's a shame. Well, you can always pass in a repository or look it up before using it.
Actually, there's a way to work with rich domain models in Seam. The way to do it is by using
the jBPM support provided by Drools, the rules engine. Using this approach services can be
declared in .drl (drools) files globally so they can be used whenever entities need them.

Still, it would be very convenient to be able to use @In within entities as well.

Last edited by Manuel Palacio; Jul 23rd, 2007 at 03:12 PM.

Quote:

Originally Posted by Manuel Palacio

Actually, there's a way to work with rich domain models in Seam. The way to do it is by using
the jBPM support provided by Drools, the rules engine. Using this approach services can be
declared in .drl (drools) files globally so they can be used whenever entities need them.
OK. Good to know. Although quite a heavy price to get rid of some oneliners

Quote:

Originally Posted by Manuel Palacio

Still, it would be very convenient to be able to use @In within entities as well

Yep, it would make the dependencies more clearly visible. Perhaps WebBeans will allow for
this, being non-EJB also...