A Mock exam question from SOFT-SCBCD

[R.x Lan]

True or False:
A remote client of an entity bean may be in the same JVM as the entity bean instance.
The answer is TRUE: when the remote client and entity bean instance are in the same JVM then the client accesses entity bean instance as it remotely located.
I do not understand... Could any people explain?

[Maulin Vasavada]

Hi Rixin
Okay. The purpose of the Local interfaces was to enable clients in the same JVM bypass stub/skeleton communication overhead BUT BUT BUT there is nothing that prevents local clients to use Remote interfaces if they wish. The reason is, why they should be? Client is a client. Doesn't matter to the client if it resides in local or remote environment but if we know that a particular client is going to be "always" within the same JVM as the EJBs then we make it use Local interfaces BUT if there is a possibility that client could move around or can be executed in different JVM then its better to use Remote interface right from the beginning of the client code to allow flexibility...
You see what I mean?
Regards
Maulin

[Anthony Watson]

Let's say you have a ejb .jar file deployed to your container. It has remote interfaces defined but no local interfaces. You then create a servlet that accesses the ejbs and deploy it to the same container in a .war file. Although the two applications are local to the same machine, container, and jvm, the servlet must use rmi remote semantics to access the ejb. This is because it must use the remote interfaces. Any client that uses the remote interfaces is considered to be a remote client even if it is located on the same jvm as the bean. So, even though the servlet is in the same jvm, it may serialize all its paramters and send them to the ejb.
A J2EE container MIGHT use logic that will figure out that the servlet client is on the same jvm as the ejb and so use local semantics, but this is container specific.
[ March 12, 2004: Message edited by: Anthony Watson ]

[R.x Lan]

Thanks for replying.
It is reasonable but why does the local home and component interface come since EJB 2.0? it looks OK if EJB just comes with remote home/ component interface. (I do not go through all EJB 2.0 spec. details.)

[Vishwa Kumba]

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 ]

[Rajnish Bhasin]

One more point:
1)The original purpose of having Local Home/Component interfaces was not becoz of the JVM thing.It was basically to allow for Container Managed Relationships(CMR), which allow u to access Objects of another Entity Bean u r in a relationship with extreme ease and less overhead of calling diffrent queries.
2)Although it was later that SUN also provided Local Home/Component interfaces for client bean calling to save upon overhead of having remote calls being made to Objects on the same heap.