Difference between local and remote calls

Discussions

EJB design: Difference between local and remote calls

  1. Difference between local and remote calls (5 messages)

    Hi guys,

    I have several stateless EJB deployed on JBOSS, on the same machine.
    They use the remote interfaces to communicate.

    I want to know if there is any benefit to use the local
    interfaces for communication between EJB on the same server,
    instead of the remote?

    In particular, is there any gain in performance
    when the local interfaces are used for calls
    between EJB on the same server ??

    Thank you
    Stan

    Threaded Messages (5)

  2. NonJboss help...[ Go to top ]

    I have no experience with JBoss.... (just WebLogic). The point with local interfaces is performance. Instead of going the long way with home and remote interfaces the container heads more directly to the implementation. You lose the possibility to deploy some beans on another server which wouldnt matter much since you can do some clustering to get that kind of performance boost. (Dont know if JBoss is clusterable????) A good EJB container would know by itself when to use local and when to use remote interfaces, wouldnt it?
  3. Local Vs Remote Interfaces[ Go to top ]

    Using local interfaces have some advantages compared to remote interfaces. These are:

    1.Simpler programming model, no need to catch remote exceptions that can't happen in co-located deployment.
       
    2.Since RemoteException is not needed on every method signature, your EJB business method's interface is independent of EJB. This can free callers from dependence on the EJB API.

    3.As it is running in the same JVM and not in a distributed environment, although coded to call-by-value it is running with call-by-reference.

    I hope this helps.

    Fore more info on this check this.

    htpp://www.tusc.com.au/tutorial/html/chap9.html

    Vishal.
  4. Local Vs Remote Interfaces[ Go to top ]

    Thanks a lot
  5. Hi,
    The main difference is the RemoteException. You hav eto be awware of the fact that you are talking on another machine, the latency is higher that on a local call, there is serialization involved, the network might fail, etc. So what I am trying to say is that the RemoteException tries to warn you about all this stuff.
    Best regards, Mircea
  6. In JBoss, I did performance tests and discovered that Remote interfaces were actually faster than Local interfaces! I can't tell you why it was faster, but I can tell you why it's at least no slower than Local interfaces. I think I was using 3.0.6 at the time.

    JBoss automatically knows when you are accessing an EJB in the same container, even if you use Remote interfaces. Thus, it passes by reference instead of by value, offering the performance advantage of Local interfaces. Why was it faster in tests I did? I can only speculate that in that version of JBoss the Local interfaces had some inefficient code associated with it, which is logical considering that Local interfaces were new at the time. The Local interfaces code could been cleaned up by now.

    Local interfaces always pass by reference. Remote interfaces are supposed to pass by value, and do indeed do this in JBoss if you access your EJBs remotely. This means it makes a copy of the data. However, they pass by value in the same container, and this is particular to JBoss, as I understand it.

    Keep in mind that Remote interfaces are inherently less secure, since they can be accessed from anywhere on the network via port 1099 on JBoss (JNDI). Thus, for this reason alone, I highly recommend using Local interfaces for all entity beans.

    I choose to use Local interfaces for all entity beans, and only use Remote interfaces from the web tier. This ensures that the web tier supports the session facade, and is distributable, while also ensuring that my data is never directly accessible outside the container via port 1099.

    By creating a smart getHome() method, you can have it read a properties file to determine if it should connect remotely to another server, or within the same server. Either way, it returns a Remote interface, so your web module is immune to whether or not your EJB tier is distributed.

    Another benefit to using only Remote interfaces from the web tier is web modules tend to be highly portable across J2EE vendors. I couldn't believe how easy it was to deploy a WAR create with JBoss in WebSphere, while still accessing the EJBs running in JBoss. WebSphere simply needed a JBoss client jar in its path to use JNP over JNDI to connect to obtain the remote home interfaces. If I had used Local interfaces in the web tier, then this wouldn’t have been possible without porting the EJB modules.

    I'd like to see the rules for Local interfaces tightened to permit them to increase security inside a single container. Basically, I’d like to see them limited to the EJB tier, and only accessible within a single EJB module. In the meantime, I do enjoy knowing that they can't be accessed outside the JVM.

    Erik Sliman
    http://as.joshuabranch.com Application security today