EJB Good Practices

EJBs abstract your middleware or business logic layer. They are transactional in nature so when you hit your persistence layer (mostly through JPA), the transaction is already there for your database session. As a result, all DB operations are going to complete or none of them, i.e. EJB operation is atomic. Let's cover some of the good practices:

Don't create EJB methods for CRUD operations

Imagine creating operations in your EJB for creating, fetching, updating or deleting your entity. It's not going to serve the purpose; quite clearly, CRUD operations are not your business logic!

In fact, CRUD operations will be part of your more sophisticated business operations. Let's take that you want to transfer x amount from a bank account A to another account B. There should be just a single method which reads appropriate records from DB, modifies them and performs the update.

Also, creating a CRUD operation gives the impression that EJB is created for each entity. We should create EJB for a group of related problems like manage accounts, policy manager etc. You can abstract your CRUD operations in Data Access Layer though!

Minimise Injecting EJBs in the Presentation layer

Imagine yourself working in the presentation layer (Servlets, web services, ..) and having to deal with multiple EJBs to delegate the call. You are going to struggle to find appropriate EJB and then a method for delegating the incoming calls.  Especially when someone else is taking care of business layer!

This is going to defeat the separation of concern principle which is important to manage your complex distributed system. So what's the solution to deal with this - Bundle related EJBs in a single (super) EJB and inject this super EJB. 

But make sure that, in doing so, you are not putting un-related EJBs together just for the sake of minimizing the number of EJBs.  Each EJB (including super) should adhere to the single responsibility principle. 

Reusing EJB methods

Suppose you have quite complex use cases which resulted in a big EJB class definition. So, the obvious question would be, how do you achieve reusability with EJB methods?

Just like a normal Java class, you can create helper EJBs with reusable methods. Multiple EJBs can use the services provided by this helper EJB. And to make these helper utilities more clear, you can put this in a utility or helper package inside your main EJB package. 

References

http://palkonyves.blogspot.in/2013/03/how-to-design-clean-business-tier-with.html

---

would love to hear your suggestions/feedback about this post.

Why EJB (3+)

I have heard people mentioning, why do you need EJBs; my project is great without them. In early days, I too wasn't very convinced. What value it adds ? Can't we leave without EJBs ?

The answer to most of such questions would be; may be!

It's not that you can't implement a distributed application without EJBs. I have worked on couple of quite successful distributed applications which didn't use EJB at all. For that matter, there is no framework/technology which is must in a given situation. There are always few alternatives, but the question is what's the cost or advantages for making a particular choice?

Let's try to understand EJB and other server side Java components:

Where it fits

EJBs runs inside EJB container (of application server) for abstracting your business logic. Below diagram shows different server side components and their relationship with EJB (just shown some of them). When EJB is not there the line gets blurred and the business logic is spread across servlet and other middle layer components like JPA, JDBC, JMS etc.

Why do we need it ?

Business logic shouldn't be performed by web interface component and similarly by persistence layer as well. Web-interface should specialize in handling http request and delegating it appropriately to business component and persistence layer should focus on CRUD operations.  If your business logic is spread across multiple component, it's not easy to manage it. You are violating loose coupling and separation of concern design principles (not following MVC architectural pattern).

If your business logic is light-weight then you might go on with this approach. But are you sure, that it's going to remain light weight forever? Change is inevitable!

When you have a truly distributed application with multiple server side components and business logic is not so trivial, you will feel the need to bring in an specialized component sooner or later. EJB integrates quite easily with other server side components like JPA (for persistence services), JTA (for transaction services), JMS (for providing messaging services), JNDI (for providing directory services) etc. EJB helps scaling out your application.

Arguments given here are generic, but have written this article keeping in mind features and power of EJB 3+.  Development with EJB 3+ is quite simple - no complex configuration in XML, simple POJO class, uses annotation, and makes development quite a breeze. 

---
happy learning !