Enterprise Java Beans are a much maligned technology. There are some well documented problems with the EJB spec and alternative technologies are quickly gaining prominence. While it is easy to find people willing to expound on the drawbacks of EJB, there is very little on the topic of when you might want to use EJB.

Many say that “EJB is only appropriate for the largest N% of applications” or that it is meant for “Enterprise” applications only, whatever that means. This advice is not very helpful; there surely isn’t a lines of code rule indicating when you should use EJB. For that matter, many organizations think of themselves as “Enterprise” developers and therefore all of their projects are “Enterprise” projects. Furthermore, how do you know if your application is one of the largest N% of applications and should you care?

The penalty for using EJB in an inappropriate situation can be large, so you want to be well informed before jumping in. Here are a few guidelines on when you should use EJB and some alternatives for those times when you don’t. Keep in mind that these are only guidelines and there are no hard and fast rules for when to use EJB and when to shy away. For more information, check out the Java EE Reading List.

Entity Beans

Remote entity beans in EJB 2 are a bad idea. It is not clear that remote data objects make any sense architecturally and there is a significant performance penalty for remote entity beans. In fact, I think it is safe to say that you should never use remote entity beans.

Local entity beans aren’t actually much better; there are still serious complexity and performance considerations. Some like to use local entity beans because they have a tool that provides good support for creating them (Weblogic Workshop anyone?). This approach has some significant risks. Developers risk becoming “Tool Developers” who don’t understand how the technology works, but are adept at using the wizards in a specific tool. If you can’t code it by hand, then using a tool doesn’t mean you know the technology.

Entity beans are heavyweight objects. They are difficult to create and incur a performance penalty when they are called at runtime. You have to carefully consider whether or not the benefits of entity beans are worth the pain. The good news is that there are some excellent alternatives to entity beans. Hibernate and JDO are good Object/Relational tools that are light-weight and high performance. You can also use plain JDBC (gasp!). Tools like the Spring Framework and iBatis make using JDBC easy and productive.

Stateless Session Beans

Stateless Session Beans (SLSBs) can be very useful in certain circumstances. The most useful benefits of SLSBs are:

• distributed transactions
• declarative security
• scalability across multiple servers

Distributed transactions take place across multiple resources such as databases, message queues or EIS systems. Not many organizations actually need this, but when you do need it SLSBs provide it.

Declarative security can make it easy to secure a distributed system, but again, you have to determine if that is really necessary in your environment. If the clients of the SLSB can be trusted then security may not be an issue.

Their stateless nature means that SLSBs can scale well compared to other technologies. It is common for architects and developers to assume that their application will need to scale across multiple servers. This is not often the case and is an example of the Premature Optimization antipattern.

With the exception of distributed transactions some of these benefits can be gained from web services. Both SLSBs and web services are stateless, so programming for one is similar to programming for the other. Of course, web services have their own “gotchas”. The security standards for web services are still evolving whereas the J2EE security standards are well established. Also, the SOAP protocol for web services can have serious performance implications since it requires parsing XML. The Hessian web services protocol is an alternative that is easy to use and performs better than SOAP.

Stateful Session Beans

Stateful Session Beans (SFSBs) are like SLSBs and thus have many of the same strengths and weaknesses. However, their stateful nature means that they don’t scale as well since the state must be replicated between servers. Consider whether storing state at the session level is really appropriate. It is often better to push the state into the presentation tier.

Message-Driven Beans

Are you using JMS in a J2EE environment? If so, MDBs might be a good fit. The pain of creating and deploying an MDB will likely be outweighed by the pain of dealing with JMS directly. The Spring Framework can help make this easier, whichever route you take.

Conclusion

The long and the short of it is that designing an application architecture is difficult, especially in an “Enterprise” setting. There are no easy answers, and EJB is not a magic bullet. Many architects and developers default to using EJBs. It is better to consider all of the alternatives first and fall back to EJBs when there is a demonstrated need and the team has determined that the tradeoffs are worth it.

The EJB 3.0 specification that is currently under development looks to change the situation somewhat. EJB 3.0 takes advantage of annotations to make EJBs easier to build and deploy. Also, entity beans in EJB3 using a persistence model that is similar to Hibernate, TopLink and JDO. This should make entity beans a viable alternative again. However, it will probably take 2 or 3 years for EJB 3.0 to be adopted by the major J2EE vendors.

Tags: ejb, java