There is no right or wrong here (IMO).
You have the advantage of true hot incremental deployment with JavaBeans that you don't have with EJB components.
You are losing EJB timer, EJB interceptor for business methods (e.g. profiling method exec times), EJB transactions (you lose REQUIRES_NEW with Seam @Transactional), JTA distributed transactions (if you need it it's available with EJB), JMS/MDB, method-level security.
I'm a fan of EJB3 but there are advantages and disadvantages either way.
But if you really want to avoid EJB, then you could use Spring/Hibernate as well...
Also with SLSB, the ejb container maintains and manages a SLSB pool for you. Not sure if/how Seam does this with JavaBean components.
And with SFSB, the ejb container uses algorithms to passivate your SFSB to disk, etc and activate back into memory as required.
How does Seam handle this for session-scoped JavaBean components, if at all?
Arbi Sookazian wrote on May 16, 2009 00:11:
You are losing [...] method-level security.
Isn't Seam @Restrict covering that?
Hmm, in fact Seam doesn't have anything like the pooling or the passivate of SLSB/SFSB, I think. Anyway, from my studies pooling is not a miraculous thing for performance(maybe it was some time ago), and about the passivate thing, well i don't know, but it propabbly help to save memory or keep an application running even without enough RAM on the server. What can you say about, in numbers? Simply being a EJB increasse how much performance?
About Spring/Hibernate for transactions, again, is a bad thing to use plain Seam/JPA(Hibernate)?
And i think that Riccardo is right.
Thks for the answers.