why to use EJB?

[M Nadeem Khan]

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]

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]

Thanks Mohan for your comment,
but the complexity,learning-curve and performance price which we pay to use EJB really worth it.

[Nick Meverden]

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]

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 w.r.to 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 ]

[Mohan Karthick]

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.