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.
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).
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).
Write once, run anywhere, because there's nowhere to hide! - /. A.C.
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’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