Local vs. Remote Interface

[Ashok Paulraj]

from EJB 2.0, i heard that itz easy to instantiate a EJBean without much overhead in going thru' whole process of accessing local stub, then marshall parameters......etc. with the use of LOCAL OBJECT & LOCAL interface.
Could anybody detail a bit on this and how itz different from Remote object(EJBObject)/remote interface ?.
Any input is appreciated.
~ Shalini

[lali virdi]

hi we use Local Interface in the same way as Remote Interface
but in local interface there is no remote call it is local call
no network traffic it is like local method call
but in Remote Interface
network traffic is there
the difference is that local interface are more efficient

[Vishwa Kumba]

In local interfaces, you still need EJBLocalObjects...
but no stubs, so no RMI and of course, better performance

[sarah Marsh]

If I have Tomcat and Weblogic on the same machine, when servlet/JSP call the EJB, we should use Local or Remote interface?
What if Tomcat and Weblogic sitting on different machine but with network connection?

[David Harkness]

Originally posted by sarah Marsh:
If I have Tomcat and Weblogic on the same machine, when servlet/JSP call the EJB, we should use Local or Remote interface?
What if Tomcat and Weblogic sitting on different machine but with network connection?

This is a great case for using the Business Delegate pattern. Instead of clients looking up a local or remote interface and using it directly, they get a delegate from a Service Locator. For this case, you basically take the local interface and use it as the base delegate interface. The local delegate implementation simply proxies the call to the local object. The remote implementation should do the same but catch RemoteException and throw a different exception that is already listed in the throws (or is added to the base interface).
This way the clients don't have to know whether they have a local or remote object. The Service Locator decides either via configuration or at runtime which one to give to the client, but both implementations have the same interface.
Here's an simple example:

public interface IUserDomain
{
    public User findUserByEmail ( String email )
    throws UserNotFoundException, DomainException ;
}
public class LocalUserDomain implements IUserDomain
{
    UserDomainLocal localEJB;
    
    public User findUserByEmail ( String email )
    throws UserNotFoundException, DomainException
    {
        return localEJB.findUserByEmail(email);
    }
}
public class RemoteUserDomain implements IUserDomain
{
    UserDomainRemote remoteEJB;
    
    public User findUserByEmail ( String email )
    throws UserNotFoundException, DomainException
    {
        try {
            return remoteEJB.findUserByEmail(email);
        }
        catch ( RemoteException e ) {
            throw new DomainException("Network failure", e);
        }
    }
}

Of course you'll need to provide the code to look up the EJBs in each implementation, but you already need that.

[Vishwa Kumba]

Originally posted by sarah Marsh:
If I have Tomcat and Weblogic on the same machine, when servlet/JSP call the EJB, we should use Local or Remote interface?
What if Tomcat and Weblogic sitting on different machine but with network connection?

My understanding is that, for local interfaces to work, both Servlet/JSP and EJBContainer need to run on the same JVM. Some application servers do allow local interfaces access from Servlet/JSP layer if it is the same application server that hosts both Servlet engine and EJB Container, but I am not entirely sure about 2 different products from 2 different vendors like Tomcat and Weblogic.
I am curious as to, why use Tomcat when you have access to one of the best application servers in the market, Weblogic ...Is it something to do with licensing, does Weblogic license its EJBContainer seperately?

[Vishwa Kumba]

Originally posted by David Harkness:
This is a great case for using the Business Delegate pattern. Instead of clients looking up a local or remote interface and using it directly, they get a delegate from a Service Locator. For this case, you basically take the local interface and use it as the base delegate interface. The local delegate implementation simply proxies the call to the local object. The remote implementation should do the same but catch RemoteException and throw a different exception that is already listed in the throws (or is added to the base interface).
This way the clients don't have to know whether they have a local or remote object. The Service Locator decides either via configuration or at runtime which one to give to the client, but both implementations have the same interface.[/QB]

This is a good design pattern. But it is also essential to know that the Remote client view assumes that copies of objects are passed, while the local client view assumes that references of objects are passed.

[Seetesh Hindlekar]

Hi Shalini,
Remote EJB are nothing but distributed objects.
Distributed objects are called by in-process clients, out-of-process clients or a client located elsewhere on the network.
For Distributed objects :-
1. Client calls stub : client side proxy object. Stub is responsible for masking network communications from client.
2. Stub calls over the network to a skeleton : server side proxy object.
Skeleton masks network communication from distributed object.
3. Skeleton delegates call to distibuted object, which does its work and returns control back to the Skeleton, which returns to the Stub, which then returns back to the client.
In short Stub clones the Distibuted Objects method signatures.
Local objects do not need all this Networking concepts.
HTH,
Seetesh