Reasons to use plain RMI vs EJB

[Paul Boyce]

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]

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?

[Nathan Pruett]

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).

[Tha'er Zayed]

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.