Win a copy of The Business Blockchain this week in the Cloud forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Remote v Local

 
D. James
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Gold Digger
Sheriff
Posts: 7610
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 http://www.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
Ranch Hand
Posts: 83
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 498
Eclipse IDE Fedora Firefox Browser
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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

Regards,
[ April 07, 2004: Message edited by: Marcelo Sousa Ancelmo ]
 
Rajnish Bhasin
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Gold Digger
Sheriff
Posts: 7610
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
    Greenhorn
    Posts: 29
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Very Well Said...
    Thanks a lot for the excellent example and explanation.
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic