This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
The EJBLocalHome and EJBLocalObject interfaces in EJB refer to home and remote interfaces running in the same JVM as the bean. Does this mean that when ever an application client (end-user) is trying to access this EJB - there needs to be another remote object(some sort of facading pattern) ? If so, what specific advantage do these local interfaces offer - if we need to have a remote interface anyhow why need local interfaces also?
1.If client connects to EJB through local interface then n/w, marshaling protocols would not come in to picture. (Parameter passing - by ref) 2.If client connects to EJB through remote interface then n/w, marshaling protocols would be used. (Parameter passing - by value) 1st case use less resource compare to 2nd case. That's why local interface was introduced. Thanks.
Originally posted by PN Kumar: if we need to have a remote interface anyhow why need local interfaces also?
You may not use both interfaces for the same object. You can use a Value Object Assembler to create a Value Object using the local interfaces of the entity beans involved. You could then provide a session facade that uses the VOA and provides the VO via its remote interface. By doing so, you incur only one network (remote) call from the client to facade and several less-expensive local calls from the facade's VOA to the entity beans. If you expose the remote interfaces of your entity beans instead, you'll be making an expensive remote call for each attribute you need from the entity.
A large majority of the time the client is packaged with the EJBs in a J2EE Applications. This means that the client can indeed use the local interfaces instead of the remote interfaces. However, it is important to note that most J2EE Application Servers do indeed optimize away the remote call if the client is in the same VM. Therefore, it is questionable what performance, if any, local interfaces would provide over remote interfaces to clients in the same VM. However, performance aside, local interfaces always make sense in those cases where you definitely don't want remote access to the component. Generally speaking, you should use local interfaces by default and in those few cases where you really do want to allow distributed calls then you should apply a Remote Facade. The important thing to remember is that you need to approach remote calls from a much different viewpoints then you do for local calls. The inherent overhead in remote calls is just too high to ignore. Remote calls should be very coarse-grained to allow for acceptable performance while local calls should be fine-grained to allow for greater flexibility. Regardless of the choices, you can technically apply both local and remote interfaces to the same EJB. However, as I alluded above, this is hardly ever a good idea because what works well for a local call would kill performance in a remote setting and what works well for a remote call is just not fine-grained enough for local clients.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com