To EJB, or not to EJB. That is the question

[Eric Mission]

I've been a JSE developer for about 7 years now- writing applications ranging from serial communications on Unix boxes to JDBC and AWT on Win boxes. In the 7 years I've learned a lot about architecture and design... what works and what to avoid in order to reduce time, cost and effort for deployments.

I've recently taken up trying to learn JEE by reading books (HeadFirst series and the like), doing online tutorials, and even searching through forums like this one for information. I started with learning EJB 2.1 and then moved on to EJB 3.0 and finally to EJB 3.1. Sticking with JEE5 and just browsing through JEE6.

During the course of searching and learning I have discovered 1 thing about the JEE standard that seems to escape me. When should an object be declared an EJB and when should it not? The major difference, that I've found, between JSE and JEE is the introduction of EJBs. And it is this additional component that really confuses me. Should my logging be an EJB or should it just be a regular POJO that is called from a JSP page? Should my LDAP lookup into Active Directory be an EJB or should it be a regular POJO?

Hopefully, I have stated this correctly. I feel that the majority of answers will be- depends. Depends on design needs, user needs, and architecture. More often than not, that answer has the ability to confuse a question further than what is intended. What I am looking for, is more of an answer that states... "A Java class should be an EJB if it needs this and that" OR "A Java class should be a POJO if it doesn't need this and that".

Any thoughts?

[Jaikiran Pai]

Eric Mission wrote:And it is this additional component that really confuses me. Should my logging be an EJB or should it just be a regular POJO that is called from a JSP page? Should my LDAP lookup into Active Directory be an EJB or should it be a regular POJO?

An EJB is a component which kind of wraps your POJO around some server provided services like transactions, security etc...

For example, if your POJO does some business operations and those business operations need to be part of a transaction, then in the absence of container provided services, you would manage the transaction creation, propagation and termination yourself by writing transaction related code. If however you mark your POJO as an EJB, then you no longer have to write that transactional code. The container will take care of initiating/propagating/termination the transaction at the right boundaries. All that you will have to write is the business specific code in your POJO.

[Ivan Krizsan]

...and don't forget about concurrency management by the container!
In most cases, a developer does not need to contemplate multiple threads being able to execute in one and the same instance of an EJB.
This has changed with EJB 3.1, but I would still say that the most common use cases will have concurrency in EJBs managed by the container.
Best wishes!

[Jaikiran Pai]

...and don't forget about concurrency management by the container!

Yes, good point! That's one other important factor.

This has changed with EJB 3.1, but I would still say that the most common use cases will have concurrency in EJBs managed by the container.

Right. Except for @Singleton beans with Bean Managed Concurrency, the concurrency management for rest of the beans are managed by the container and are always thread-safe.