I am definitely not an expert on that topic, but I'd like to add my
comments :)

For one, beans have the advantage of running in the context of the
server. So you can assume that JBoss will manage security and
transactions if you so desire. This by itself is already worth
something, IMHO.

You have also access to all internal ressources like DataSources (not
available outside the context of the server). 
As well, if your session bean (implementing business code) needs to use
Entity beans, they could run within the same JVM. This sort of intra-JVM
type of communication is optimized in JBoss, so that calls that would go
through RMI are handled as normal method calls. (This is how I
understand it... hope it's correct :)) 

If you use stateless session beans, code can be pooled and reused by the
server to serve many clients in succession. 

This is not very complete, but I see those points as good reasons to use
SB vs. non EJB code. But as always, there is a good place for every bit
of code. Session Beans (stateless) are normally used to implement
business code. 

Hope it's a little bit informative :))

Daniel

ps. If I was wrong on any of this, please tell me :) I'm still learning.
Thanks!

-----Message d'origine-----
De : Michael Hustler [mailto:[EMAIL PROTECTED]]
Envoyé : 26 avril, 2001 16:18 
À : Jboss (E-mail)
Objet : [JBoss-user] EJB Question


I have a general (and likely simple) question about EJB's - session
beans in
particular.

What are the advantages of a stateless session bean over a non EJB
helper
class provided to clients.

Thanks,
-mike.


_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user

_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user

Reply via email to