Enterprise JavaBeans (EJB) is one of the most complicated technologies in the J2EE platform, which puts some developers off from deploying it for their projects. This article is for developers who are still on the fence about whether to invest time and energy into learning and applying EJB technology to their projects. I start by examining EJB's advantages and disadvantages, then I outline when you may or may not want to use EJB, and I conclude by offering my thoughts about common EJB myths.

Advantages

  • Specification: EJB is a specification-based technology. (This is both the main advantage and main disadvantage to EJB.) The EJB specification describes almost all aspects of implementation, including data types, component life cycles, role distribution, and many other things.
  • J2EE tight integration: There is a whole server technology zoo built around J2EE, which includes EJB and highly valued technologies such as servlets, JavaServer Pages, Java Message Service, J2EE Connector Architecture, Java Database Connectivity, Java Authentication and Authorization Service, Java Transaction API, and JavaMail. This makes J2EE and EJB a very attractive solution.
  • Scalability: As long as you pass most resource management functions to application servers, vendors can apply complex scalability algorithms.
  • Access to resource management systems: Along with the EJB container, you get thousands of lines of code for accessing and managing resources, including transaction management systems, security management systems, and directory services. Without EJB, you would implement all of these components by yourself.

Disadvantages

  • Large and complex specification: This is normal for a specification that describes such a complex distributed system, but not all information in it is really necessary to start writing code, which makes specification an inconvenient tool.
  • Voluminous documentation: Before you start a development project, you usually need to read more than 1,000 pages of documentation. This is a huge deterrent for deploying EJB.
  • Increases development time: The EJB solution requires more time than using plain Java code. Debugging of EJB code also takes more time than debugging of plain Java. The main reason why is because you can almost never be sure whether the bug is in your code or in the container.
  • EJB code is more complex: For instance, to implement one session bean, you must write three classes; for an entity bean, you must write four classes. Add a couple of deployment descriptors, and the simplest "Hello world" application turns into 10 files instead of one.
  • Overdesign threat: This point is a consequence of specification complexity. If you do not understand the concepts of EJB well, you will not be able to use the technology effectively, and you will probably make the project more complex than is really necessary.
  • Specification changes: EJB is an emerging technology, and your code can potentially be obsolete, which will require additional efforts and costs to make it compatible with new EJB containers.

When you might want to use EJB

Imagine you have a simple servlet Web application that uses a database. You use JDBC for accessing the database from your application. As a result of the SQL query, you are getting the ResultSet object with a set of some data representing your business objects. This is not a very convenient way of using data; you will eventually create Java classes representing a database structure. Your code will contain something like this:

MyObjectobj = new MyObject();
obj.setXXX(rs.getString("XXX"));
obj.setYYY(rs.getString("YYY"));

After playing with passing result sets into object presentation and back, you will start thinking about how you can move that logic into MyObject itself. Let the object find itself in the database and then amend or delete it in order to separate your servlet from JDBC accessibility details and without direct usage of classes from the java.sql.* package.

Get developer tips in your inbox
Delivered each Thursday, our free Java newsletter provides insight and hands-on tips you need to unlock the full potential of this programming language.
Automatically sign up today!

Now you have another problem: How can you find an object in the database by some query? If you need to find it by the primary key, then pass the primary key into the class constructor and that's it. If you need to search by several criteria, you will require many special static methods. You will also probably need a way to support transactions and roll them back if necessary.

When your application gains popularity, an uptime percentage and reliability will become important, and you will need replication, fast object persistence, object caching, database connection pools, secure transactions, and so on. All of these problems are solved by Entity Enterprise Java Beans. You do not need to duplicate mistakes already done by thousands of programmers. You just implement a couple of interfaces and do not think about some database that must be accessed if your bean is a Container Managed Persistence (CMP) entity bean. If it is not exactly what you need, it's not a problem -- you can implement persistence by yourself with Bean Managed Persistence (BMP) entity bean.

In your application's business domain, there are not only objects that keep data, but there are also some actions with these objects; these actions represent business logic. When you start writing your application, all business logic will live in the servlet. The application will eventually require the support of several servlets, and you will be able to choose whether to copy-and-paste the business logic code or put it in separate classes. Some users will eventually require interaction with your application at separate Web pages, so you will need to keep his session information between each user's requests. The solution to this problem is called Session Bean, which encapsulates all business logic of your application. It can be stateful or stateless.

When you may not want to opt for EJB

EJB is a truly elegant technology, but it is not a one size fits all solution. EJB offers a lot of features (like security, persistence, and transaction support) that are not required by every application.

In addition, you may not want to use EJB non-distributed applications in which speed might be more important than security and transactions. Due to the distributed nature of EJB, data must be marshaled (serialized) and then unmarshaled (deserialized) to facilitate communications between a client and the EJB component (or server). This introduces a lot of overhead and can result in poor performance, which is why using local classes in the same JVM might be a better option.

Common myths about EJB

  • EJB is expensive technology: This is partially true. There have been recent releases of several low-cost or free application servers that have all the capabilities of fully commercial servers. In large enterprise application projects, the cost of an application server is a very small part of the costs associated with the project.
  • You don't need SQL knowledge if you're using CMP beans: This is not true.
  • EJB application is easily ported between different containers: This is partially true. EJB code can be ported only if it is written in a portable way. Session beans and BMP beans are easily portable, but porting CMP beans can require a lot of effort.
  • Entity beans work slowly:This is mostly true. Entity beans work really slowly and, in many cases, it's better to change them with session beans.

Conclusion

Before making a decision about whether to use EJB technology in your project, you need to understand all the requirements of your application, perspectives of its evolution, and the main goals of EJB and its limitations.

Resources for further reading about EJB

Peter V. Mikhalenko is a Sun certified professional who works for Deutsche Bank as a business consultant.