My understanding is that eventhough the client that invokes the Bean is running in the same JVM it is good to expose the bean as remote as in future it would be helpful scaling it horizontally.
In the case of AdviceBean example, the AdviceClient is being invoked in the same JVM as the server in which the bean is deployed. So my question is when we do a PortableRemoteObject.narrow(o, AdvisorHome.class) which would generally return a reference to the stub of a component Interface, does the Container know when it did a JNDI lookup that it found the AdvisorBean locally and that it does not have to make remote calls and thereby instead of returning a reference to the stub of a Component Interface, returns a direct reference to the EJBObject??
You can access the ejb thru its remote interface, even if you are in the same container.
Joined: Feb 26, 2005
It wont be like a box of chocolates, you will always know what you are gonna get.
Joined: Sep 22, 2005
Yes I know that we can access the ejb thru the remote interface even if it is in the same container.
The question is How?? Does the container have to determine that it does not need to use serialization as all the processing is going to happen in the local heap and it can pass object references to method calls??
Originally posted by Agasthya Iyer: My understanding is that eventhough the client that invokes the Bean is running in the same JVM it is good to expose the bean as remote as in future it would be helpful scaling it horizontally.
While that is possible technically, architecturally speaking that is a Really Bad Idea. To quote Rod Johnson from Expert One-on-One J2EE Design and Development (p.224; find a great sample chapter here):
The following issues should be considered before giving an EJB both a remote and local interface:
It is potentially confusing to have the same object supporting both call-by-value and call-by-reference, even if it doesn't happen through the same methods.
Remote and local interfaces are likely to vary in level of abstraction and granularity, confilicting with it being good OO practice for all object's methods to be at a consistent level of abstraction. Remote interfaces should be coarse-grained; the local interfaces may be finer grained.
If the bean is really a remote object, yet it provides a local interface to support local callers, it might be better to refactor the functionality used by local callers into a helper class. Having one EJB call another indicates questionable design.
The greatest benefit of local interfaces is that they make the implementation of the session facade possible - because many entity beans are just too finely grained to be accessed remotely.
Originally posted by Agasthya Iyer: In the case of AdviceBean example, the AdviceClient is being invoked in the same JVM as the server in which the bean is deployed.
No it's not. If you are running the setup as described in HFEJB then your client and application server are running in different processes - that means the client has an instance of the JVM and the server has a separate instance of the JVM - even if its on the same physical machine.
Originally posted by Agasthya Iyer: Does the container have to determine that it does not need to use serialization as all the processing is going to happen in the local heap and it can pass object references to method calls??
The EJB specification makes no such requirement - so in general all the usual overhead is still done even if the "remote" call is local. Some vendors feature value-added optimizations that you can turn on - however you have to be very careful that you handle the call-by-value/call-by-reference issues very carefully - otherwise the optimization could break your code. [ November 11, 2005: Message edited by: Peer Reynders ]