Remote v Local

[D. James]

Hi all,
Just finished reading the HF book and I seemed to have missed the point of Local interfaces. Is the Local interface to be used when one bean wants to access another? Why would a client ever want a local interface?
Also, I downloaded and printed the EJB spec. It is huge! Is it really necessary to read it all? Any tips?
Cheers !

[Valentin Crettaz]

Just finished reading the HF book and I seemed to have missed the point of Local interfaces. Is the Local interface to be used when one bean wants to access another? Why would a client ever want a local interface?
A local interface is necessary for entity beans that want to have container-managed relationships with other entity beans.
More details at https://coderanch.com/t/159105/java-EJB-SCBCD/certification/elaborate-reason-Local-interface-EJB
Also, I downloaded and printed the EJB spec. It is huge! Is it really necessary to read it all? Any tips?
I have made a tentative at mapping the spec sections with teh exam objectives. You can check that out here
Moreover, you might want to have a look at Things you do NOT need to know

[bas duijzings]

local interfaces are used when a bean (any type) has to access another bean - roughly speaking. In earlier days you could only use remote interfaces which use rmi to connect to each other and are therefore relatively slow. With local interfaces they do not need rmi and connect directly, and therefore faster.
I may be wrong however.

[Marcelo Sousa Ancelmo]

Local Interfaces are used when you bean try to access another bean that runs in the same JVM of the caller Bean (Session >>> Entity, Session >> Session, MDB >>> Session, MDB >>> Entity). Typical example is a Session Bean accessing an Entity Bean
Local interfaces are much more performatic than remote because they skip the network stage of parameter's call, which occur when the client of the bean is running in another process, e.g. JVM. Example is a Swing client accessing a Session Bean

    JVM 1 Client                  JVM 2 Server
  --------------      -----------------------------------------
  |            |Remote|   Session              Entity         |
  |call session| Call |  -----------   Local  ----------      |
  |  method()  |----->|  |method() |   Call   |        |      |
  |  (Remote)  |      |  |call's   |--------->|method()|      |
  |            |      |  |Local Ent|          |        |      |
  |            |      |  -----------          ----------      |
  --------------      -----------------------------------------

Regards,
[ April 07, 2004: Message edited by: Marcelo Sousa Ancelmo ]

[Rajnish Bhasin]

Well everybody has been beating around the bush saying that, CMR require Local
Component interfaces rather than Remote ones.
But no one has yet explained as to why Local Interfaces are required for CMR!!!
What is so special abt CMR that it requires only LOCAL Interfaces ?
Hope we get a reply for the same...

[Valentin Crettaz]

OK, folks, I'll try to expose my view of why entity beans must expose a local interface in order to participate in container-managed relationships.
As Marcelo said, one of the reasons is for performance purposes, as it is much quicker to perform a local call in the same JVM on an object reference instead of a remote method invocation through RMI.
BUT, the rationale for this is that the relationships between two entity beans must be specified as an abstract persistence schema in the deployment descriptor where the <relationship-role-source> elements must contain the name of en entity bean declared in the same descriptor. For this reason, it is mandatory that entity beans with container-managed relationships are specified in the same deployment descriptor, and are thus deployed together in the same container. Assuming this, it does not make much sense to require that collocated entity beans communicate with each other by using the network loopback. A huge performance penalty would incur.
As an analogy, consider the following. Imagine that you want to make a recipe and you need some ingredients like milk, butter, flour and sugar. Instead of buying all items at once, you drive to the supermarket for buying each single item. The scenario would look as follows:
You are in your kitchen and you see on the recipe that you need a bottle of milk. You dress up, you get in your car, you drive to the supermarket, you get in the shop, you find the milk, you stay in line, you pay, you get in your car, you drive back, you get out of car, you get back in your kitchen and add the milk to your recipe. Then, you need to add some butter and you repeat the exact same steps again. And so on with the other ingredients. Wouldn't it be easier to go once to the supermarket, buy everything you need and put them in the fridge or wherever, and then just open it to get what you need?
The analogies are the following:

recipe: business process

ingredients: beans you need to carry out the process

get in the car: RMI marshalling

find the product: retrieve the correct bean

get out of the car: RMI unmarshalling

incorporate the ingredient: invoke some method on the bean

your kitchen (in the case you have to go to the supermarket): client application or session bean

your kitchen (in the case you already have everything in the fridge): the EJB container

going to the supermarket: remote calls

opening the fridge and getting something: local call

[ April 08, 2004: Message edited by: Valentin Crettaz ]

[Rajnish Bhasin]

Very Well Said...
Thanks a lot for the excellent example and explanation.