Howdy Manish,
good questions...
There are a couple of reasons why local interfaces are perhaps more important with entity beans:
1) For one entity bean to have a CMR relationship with another bean, the entity must use the LOCAL interface of the bean for which it has a CMR field.
2) If you allow direct Remote client access to a bean, and the client is not itself another bean, then the client cannot *scope* the transaction. This means that for each method the client calls on the entity bean, there is potentially a complete cycle of starting a new transaction, ejbActivate, and ejbLoad, and THEN the method, followed by the reverse -- ejbStore and ejbPassivate. Let's say the client wants to call three business methods on the bean, and each method has a Requires tx attribute. Those 3 method calls result in:
ejbActivate
ejbLoad
BizMethodOne
ejbStore
ejbPassivate
ejbActivate
ejbLoad
BizMethodTwo
ejbStore
ejbPassivate
ejbActivate
ejbLoad
BizMethodThree
ejbStore
ejbPassivate
All that for just three method calls from the client!!
So, if the client is, say, a Session bean, then the Session bean can start the tx and make the three calls as follows:
ejbActivate
ejbLoad
BizMethodOne
BizMethodTwo
BizMethodThree
ejbStore
ejbPassivate
A huge improvement.
Now, this client tx scoping really has nothing to do with whether the client is using the local or Remote interface of the bean. But if a client *is* a session bean, then the client has the option for using the local interface of the bean, depending on your design.
The main reason, and often the *only* good reason to use local interfaces, though, is for entity bean relationships. Even in the scenario I described with a Session bean accessing the Entity bean (rather than letting the client go directly to the entity bean), there are compelling reasons to make the entity bean Remote to the Session bean -- mainly that the beans can be deployed anywhere, at any time. The session bean can be placed on another network node without causing things to break. Once you make the decision to keep beans local to one another, you're more or less stuck that way. (although there are some design hoops you can go through to try to still give yourself some location "transparency", by having a bean that uses both local and Remote interfaces and doing a bunch of stuff to make it work either way, but this is often kludgey).
Local interfaces were introduced into the spec to support CMR. Period. But because people had complained about having unnecessary overhead with RMI even when beans were in the same JVM, the spec developers decided to (under pressure) extend the local capability (but at your own design and maintenance risk) for other purposes as well, including session beans.
cheers,
Kathy
