û	Using EJBs

When should you use EJBs?

EJBs are incredibly powerful components that allow developers to easily take advantage of the application server’s security, transaction, naming and distribution services. However, EJBs are also incredibly resource intensive. If you use EJBs excessively, you’ve just bought yourself a one-way ticket to performance problemville.

Before committing to using an EJB, ask yourself the following questions:

F  Do I need to manage some serious database transactions? 

EJBs are great for managing transactions, and if you have a largely transactional system, EJBs just may be your saving grace.

F  Do I need object distribution? 
F  Are users calling my components remotely?

This is a good case for using EJBs, as EJBs are inherently distributed objects. However, this alone is not a compelling reason to employ an EJB centric solution. 

There are many mechanisms for implementing remote distribution including remote method invocation (RMI) and network socket programming, both of which are more efficient than using an EJB. 

Needing object distribution is a good reason for using an EJB, but I’d look for another reason or two before committing to an EJB based solution.

F  Do I need security down to the method level?

EJBs provide the ability to interact with the security service of the application server, and you can lock EJBs right down to the method level. This type of security would be relatively difficult to implement with regular JavaBeans.

Needing this type of security is a good reason to use an EJB, but it shouldn’t be a reason on its own.

If security is the problem you need addressed, you could probably avoid using EJBs and lock down your applications by securing Servlets and JSPs instead. The Java Authentication and Authorization Service (JAAS) could also be used to facilitate a secure system without using EJBs, but even JAAS introduces an extra level of complexity.

EJBs do indeed provide secure access right down to the method level, and if this is the type of security you need, EJBs might be a viable solution.

F  Do I need to make sure that the data my application receives is completely and totally in sync with the data in the database?
F  Do I need a persistence model? 

CMPs and BMPs address the many difficulties associated with communicating with a database, as they provide a persistent object model that makes sure the data obtained by your application is completely and totally in sync with the database. 

Again, if this type of persistence modeling is what you need, go ahead and use EJBs. However, if your application is largely reading data from a database, and data collisions are rare and not likely to be detrimental when the do happen, I wouldn’t use an entity bean framework.  In that scenario, I’d look at Java Data Objects (JDO) or Hibernate.  Remember, entity beans are incredibly resource intensive.  Use them only if you need them.

F  Do I need multithreaded access with large workloads

EJBs are inherently multithreaded, and application servers, especially WebSphere, are highly scaleable. This is a good peripheral reason for using EJBs, but I wouldn’t base my decision on multithreading support alone. After all, you can always synchronize methods in a regular POJO (plain ordinary java object.).

Use EJBs Sparingly

The point is, EJBs are incredibly powerful, but they are also incredibly resource intensive. Use them when they make sense, but use them sparingly. 

Unnecessary EJBs will slow down your applications and performance will quickly become an issue. There is a good reason why many of the J2EE design patterns demonstrate how you can achieve many of the benefits of using EJBs while minimizing their actually use.

If you choose to use EJBs, choose to use them wisely.