Hunter Hillegas wrote:
> If the beans are all running on the same server, what is the
> difference
> (assuming no cluster)?
I don't want to steal Jim's thunder, but I thought I'd jump in and answer
this as I've spent a lot of time looking at this recently.
In most app servers, you would still have the overhead of the RMI call. In
addition to this, your parameters would be passed by RMI conventions
(meaning you get a copy of the object, not the object itself).(*) In
addition to this, you are forced to expose all your EJBs, which can give you
a cluttered view of the system.
With local interfaces, you lose the RMI call, you actually pass the
parameters as per normal Java conventions, and you don't have to worry about
remote exceptions. Also, by deploying some of your low-level entity beans
purely locally, you provide a cleaner public view of the system, without
losing flexibility.
Also note that session beans can be accessed via local interfaces. This
means that you can use session beans as purely pluggable components,
accessed via a factory pattern. Anything that you would like to be
configurable or separately upgradeable in your system can be, simply be
converting it into a local stateless or stateful session bean. This gives
you a lot of flexibility in your design, and is significantly more powerful
a concept than the dependent objects it replaces.
> Are security/transaction/etc... still managed by the
> container if you access
> a bean via a local interface?
Yes.
> Does anyone know if MVCSoft supports local interfaces?
This I don't know. I doubt it though... the new spec version is still very
new.
Robert.
(*) Some web servers "optimise" the RMI call out of the way when accessing
something in the same app server. Comes as a nasty shock when your
application breaks when you shift part of it onto a separate server, all
because you violated an RMI constraint without realising it.
--
"Duct tape is like the Force: it has a light side, a dark side,
and it holds the universe together"
Robert Watkins [EMAIL PROTECTED] [EMAIL PROTECTED]
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
