In EJB1.1, there were no local interfaces, so irrespective of whether my EJB client and entity bean instance ran in the same JVM or a different JVMS, there was no choice but to use remote interfaces. This had a performance overhead because of the remote calls.(RMI is slow!)
In EJB2.0, local interfaces were introduced, so there is a choice of using either local interfaces or remote interfaces for an ejb client, which is a design decision. As a good design practice, if both run in the same JVM local interfaces are used, and if they run in different JVMs, remote interfaces are used.
But in EJB2.0, it is still possible to use remote interfaces even though both the ejb client and the bean instance run in the same JVM, just like in EJB1.1. This may be a bad design and defeats the very purpose of local interfaces, but still is possible. The reasons, why we would do this, were explained by Maulin and Anthony in the above posts...
So to summarize, in EJB2.0, there are 2 types of interfaces.
1. Local type: local home and local interfaces
(extending from EJBLocalHome and EJBLocalObject respectively)
and
2. Remote type: remote home and remote interfaces
(extending from EJBHome and EJBObject respectively)
For the local and remote interfaces, SUN coined the term "component" which could be either of the interfaces type.
So when we talk about EJBs in a high level discussion, we only talk about the 2 interfaces for an EJB, the home interface and the component interfaces.
(These 2 interfaces could either mean local interfaces or remote interfaces, which is not too important in a high level design discussion)
Now, was that too confusing?

[ March 13, 2004: Message edited by: Vish Kumar ]