It's not about the same computer, it's all about the same JVM. If your client code will run in the same JVM as the EJB container, then you may wish to have only local interfaces. (This can happen if, say, the client is running in a servlet container which is co-located with the EJB container.) It is much more efficient for a client to make local rather than remote calls, but you will not be able to separate out the client and EJB code into different JVMs without quite a bit of reworking of your code.
If you hide the local or remote decision in a Business Delegate then the client will never have to know which is being used. You might make your BD smart enough to switch between local and remote by configuration or dynamic load analysis. We use a framework where the BD might use EJB or raw sockets or XML over HTTP with no change in the client.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Sep 29, 2002
I haven't thought this through, but I can see the BD needing to obtain and return a business service to the client in order to invoke business methods. This business service will typically be any of the following:
1. A reference to a JavaBean running in the same JVM. 2. A stub to an EJBObject for an EJB application running in a different JVM. 3. A stub to a javax.xml.rpc.Service for a web service endpoint running in a different JVM.
It should be easy enough to do this via some sort of service locator, using a configuration variable read in on server startup.
Also, there is no reason at all for the client to ever receive RemoteException, the BD should catch this sort of exception, wrap and rethrow it as RuntimeException (or some suitable subclass thereof). The client will therefore only receive a system exception and, of course, any application exceptions.