Two Laptop Bag
The moose likes EJB and other Java EE Technologies and the fly likes why to use EJB? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "why to use EJB?" Watch "why to use EJB?" New topic

why to use EJB?

M Nadeem Khan

Joined: Jan 23, 2006
Posts: 2
can anybody give me good reasons for using EJBs in my web application.
Please give more realistic example if you have, rather then telling "transactions, security, extensibility,interoperatibility, etc.."
Mohan Karthick
Ranch Hand

Joined: Apr 11, 2005
Posts: 199
Now a days lots of other technology also supports the same, but here are the some reason to use EJB, as following:-

1. Component based flexible architecture, any time DB can be changed
2. If you identify that same method can be called from JSP, PDA, or any xyz system then we can go for EJB, for example data need to processed at server side either when user give inputs from browser or some automated created data comes from JMS provider / C++ client, so you are going to use the same EJB method.

Again you need maintain session when browser is accessing the EJB method or some external system so session should be maintained at middle ware here comes stateful session bean.
Please correct me if I am wrong.
M Nadeem Khan

Joined: Jan 23, 2006
Posts: 2
Thanks Mohan for your comment,
but the complexity,learning-curve and performance price which we pay to use EJB really worth it.
Nick Meverden
Ranch Hand

Joined: Jul 03, 2006
Posts: 59
1. This thread seems to be trolling.
2. If you're willing to listen to an answer here it is:


Taken from "Enterprise JavaBeans" O'reilly

when to use EJBs:

- Single and multisystem business transactions
- Distrubuted functionality
- Portable components (not classes)
- Applications relying on asynchronous messaging
- Security roles

when not to use EJBs:

- Read-mostly applications
- Applications requiring thread control
- Performance


As far as Performance concerns which seems to be the big buzz regarding EJB's, yes EntityBeans are slow, no way around it to much over head from all the benefits of using EBJs. If you can live without O/R Mapping and wan't to use hand written ANSI SQL-92 then stick to JDBC (recommend for read-only). Brett Mclaughlin wrote a great book published by O'reilly called "Building Enterprise Applications" showing how to create wrappers with SessionBeans to get around the performance issues of EntityBeans. Really some of the first POJO's style coding examples.

If your from the J2EE 1.3 days you'll probably be a EJB hater, we all know 90% of the books available at that time was about developing applications without using EJBs. But times have changed, and EE 5 with the new persistence APIs are a step towards simplicity.
John Calabasas

Joined: Jun 11, 2006
Posts: 17
I dont see any real case for Entity beans, and there are many alternate approaches like ORM tools. Maybe EJB3 makes it better.

When it comes to Session Beans, it make sense to use only in the following conditions.

1. Need to expose services remotely to other Java applications
2. Need to support transaction and security propagation from clients

MDBs however are quite useful if you have Async messaging in your application. I dont know of any alternatives considering the container support for the same Transactions, Pooling, configurability etc. Of course we can have a MessageListener. But then it need to be managed programatically.
[ July 04, 2006: Message edited by: John Calabasas ]

I hate quotations. Tell me what you know.
Mohan Karthick
Ranch Hand

Joined: Apr 11, 2005
Posts: 199
I am not aware of other alternatives for EJB can any one through some light that apart from EJB what are the other frameworks supports following:-

1.Transaction between multiple different types of database.
2.Some thing called RAR files for J2EE connector, to access different system.
3.Method level security.

EJB does not mean that we use CMP, BMP. Probably we can create simple DAO object and encapsulate it by BMP, so we are having both the flexibility of entity beans as well as POJO classes.

When you want to have flexible system then need to bear something like learning curve etc.
I agree. Here's the link:
subject: why to use EJB?
It's not a secret anymore!