Okay, remote and local interfaces:
When an
EJB has a remote interface, it is essentially available to the entire world. With a remote interface, any client can grab a handle to the home interface and start calling it's methods. Sure, we can slap some security constraints on a method with an EJB, but just making an important method available remotely is a security lapse.
So, when Entity beans essentially represent data, and we guard data like gold, why would you provide clients a remote interface? You probably shouldn't. So, with J2EE 1.4, the idea of every EJB having a remote interface went away, and now EJBs can have either a remote interface, which Session Beans often do, or a local interface, which entity beans often do. You can actually have both remote and local interfaces for a bean, but that's just wacky.
Furthermore, old EJB specs assumed every invocation was a remote invocation, which means a whole bunch of CORBA strippig and IIOP stuff, even on local calls from within the same JVM. This was wasteful. Sure, most vendors said they were doing optimizations for local invocations, but can you really trust any of those J2EE vendors out there other than IBM? You make the call.
So, a local interface also allows for optimizations for invoking methods that might not be available when going through a remote interface.
So, there you go. A few reasons for having local vs. remote interfaces for Enterprise
Java Beans.
-Cameron McKenzie
