JBoss does employ some dynamic detection and will implement remote interface calls in a local interface manner when within the same JVM as long as you do not change the default jndi.properties for java.naming.provider.url. See the conf/jndi.properties for your JBoss run-time instance.
However, there is still a performance penalty for this compared to making an explicit local interface call. You also still have to perform the RMI narrow operation on the remote object. The explicit local interface call does not need to include this.
You would need to assess whether these penalties are negligible in your chain of interactions. However, implementing only remote interface calls allows you to physically split apart your application architecture if it is required.
I do not know if WebSphere performs the same call optimizations but I suspect it would. At least I'd hope so for $30K. In any case, the WebSphere choice usually reflects business oriented decisions rather than purely performance.
WebSphere does indeed perform this optimization (it's included in the 30K price tag) as most of the other commerical appservers.However, keep in mind one thing:
Remote interfaces extend java.rmi.Remote which is intended for remote objects. As a result, any subtype is required to throw RemoteExceptions whether this is applicable or not (this would be in the abscence of Local intefaces). After sometime, I believe it would be difficult to distinguish between Local components and Remote components since they would be so similar.
I like Local component interfaces largely because I can demarcate functionality in my components based upon location. If I am developing an EJB that I know will only be deployed in an environment that has to be used locally then I can specify that this EJB only has local interfaces and therefore can only be invoked intraVM. This comes in handly with coarse grained Entity beans where a piece of the Entity component in question does not, and cannot exists without a parent (or relationship) and therefore should never be directly available to remote clients.
Of course, you always have the option to offer both types, and to be quite frank, this is required a great deal of the time in testing. When you go to production you can always remove the Remote interfaces from those beans that you you do not want to be accessible outside of the server VM.
Thanks for the explanation. One thing I'm still not clear on is what is the magnitude of the peformance hit when using the "optimized" remote calls versus a native local interface call? IOW, Marc's blue paper says serialization is the big performance killer causing your calls to be 5 to 10 times slower. When I make a remote call and JBoss figures out that the bean I am accessing is in the same JVM as the client, does it still perform the RMI calls and thus the serialization or is the performance hit you are talking about just the overhead of detecting the call and downcasting the return objects, etc...
Would you expect the overhead to be 10%, 50%, 100%? or more along the lines of 5x or 10x?
JBoss avoids the marshall/unmarshall step (a posh kind of
serialization) required for Remote invocations on the same server.