Daniel Cardin wrote:
> 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.
Especially the transaction support.
>
> 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 :))
Nearly as a normal method call. The spec dictates that the method calls
always behave as though they're remote insofar as passing of references
go. This can be turned off for performance reasons.
>
> If you use stateless session beans, code can be pooled and reused by the
> server to serve many clients in succession.
Comparing this to a non-ejb helper that's used (for example) as a bean
on a JSP page, you should save a lot of memory and garbage collection
overhead.
-danch
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
