aspose file tools*
The moose likes Distributed Java and the fly likes Reasons to use plain RMI vs EJB Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Distributed Java
Bookmark "Reasons to use plain RMI vs EJB" Watch "Reasons to use plain RMI vs EJB" New topic
Author

Reasons to use plain RMI vs EJB

Paul Boyce
Greenhorn

Joined: May 31, 2004
Posts: 7
Hello!

I'm no expert on network communications, and am trying to decide whether to use RMI or EJB (Session Beans) for a project.

My issue is whether using EJB will better manage server resources in terms of network connections/threads. I understand that with RMI each client call will result in a *new thread*. Is this correct and likely to be a problem that would be solved by using EJBs?

Background:
-----------
Our basic architecture uses two machines, one providing the web tier, and one providing the business and data access tier, as follows:

WebServer/WebContainer(Tomcat) ---network calls---> "business services" hosted on separate server"

In the communication between the WebContainer and the Business Services, our option is to use RMI to talk to plain old java objects (POJO) or use EJB Stateless Session Beans.

At the minute we don't have a strong argument to add the complexity of a EJB Container, but we are considering the EJB option if it will avoid problems where the RMI creates a NEW thread for every client call (from the web server).

Can you give any advice or views on this?

Many thanks in advance,
Paul
Catalin Merfu
Ranch Hand

Joined: May 26, 2004
Posts: 42
The good thing about JavaSun RMI is that it's blazing fast.

The bad thing is that JavaSun RMI is opening a new socket for each registered remote object. The required number of sockets on the server would be

Number Remote Objects x Number Concurrent Clients.

Some commercial RMI implementations use only one socket per client and pool processing threads, though. This worth researching further.

Using EJBs is always good but would you invest a lot of money and use only stateless beans?


Catalin Merfu<br /><a href="http://www.accendia.com" target="_blank" rel="nofollow">High Performance Java Networking</a>
Nathan Pruett
Bartender

Joined: Oct 18, 2000
Posts: 4121

  • EJB is built on top of RMI.
  • RMI has built in thread pooling, so it's not technically a new thread every time.


  • There may be other arguments to using EJB rather than RMI though... do you need transactions? Security? Access to information in databases?

    If what you need to do is relatively simple, then RMI may be the way to go. It's simpler to understand and set up, and it's free.

    However, if you expect your project to grow to need (or it already needs) things like transactions, object pooling, security, etc. it would be much easier to use these services as they are provided through EJB than try to implement them all in-house.

    Plus, RMI and EJB aren't the only way to go... perhaps your project would be better served by other existing server side frameworks like Hibernate or Spring...

    Whichever technology you end up using, some design patterns that may help you cut down on network traffic are Business Delegate (you could cache results for multiple clients here) and Transfer Object (package all the data you need from the remote call in a serializable object).


    -Nate
    Write once, run anywhere, because there's nowhere to hide! - /. A.C.
    Tha'er Zayed
    Greenhorn

    Joined: Mar 10, 2004
    Posts: 20
    I agree with Nate.

    Choosing between RMI and EJB comes down to answering the following simple question:

    How complex and big is my application?

    Complexity in terms of DB transactions, concurrency, security, persistence. EJB 2.0 is a very robust and yet complex technology, and it comes with a considerable price tag in terms of performance(compared to POJOs/RMI) and learning curve. I would consider Plain RMI for my small to medium applications. I would also look at some robust persistence framewok such as Hibernate or Castor (Hibernate is my favorite). So again your plain RMI/POJO and Hibernate would be a reasonbly good fit for small to medium-sized applications. We run in our environment 30+ small to mediume servlet-based applications and we're doing just fine with out EJB.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Reasons to use plain RMI vs EJB