Advantages and Disadvantages of Using Container Managed EJB

I'm building a javaee6 application that processes smses. basically smses come in via smpp, to a JMS Queue and then are processed by my application.

I'm using glassfish v3, I decided I was going to use开发者_如何学编程 EJBs for the business logic. Here is the structure of my application

Dashboard Web app - JSF 2, Business Logic - EJB 3, Message Receiver - JMS, Persistence provider - JPA (eclipselink).

I have never used EJBs before, I'm currently using the container to manage my Session beans. I just want to know if there are any disadvantages of using EJBs(container managed to be specific) rather than just call basic java classes from the JSF Managed beans.

The system I'm building has to be very scalabale. There isn't much complex business logic. is it overkill to be using ejbs?

---

I can't see any disadvantage to use EJBs.

With EJBs you can: - EJB 3 are very easy to develop - transactions are managed by container, distributed transactions - dependency of injection and IoC. - distribute your beans in a cluster - you doesn't know about infrastructure - authentication and authorization (roles with JAAS) - EJBs are portable and scalable. You will not be tied vendor. - and many others...

---

The disadvantage of container mangaged EJB is, if we want to insert multiple rows in a table and we want either all rows to be inserted or none...

In this case we can not rollback our transaction...

---

The main advantage of allowing the Container to manage the transactions and EJB has a very robust setup to allow for tweaking of the transactional levels on each bean and between beans.

On very rare occassions would you ever want to actually manage the transactions yourself. If you are really considering managing the transactions yourself I would recommend trying to rearchitecture your solution first to something where you can allow the Container to manage the transactions and only as a last resort ever manage them yourself.