Do you really need Enterprise JavaBeans?
EJB is not a one-size-fits-all solution
The Java 2 Platform, Enterprise Edition (J2EE), and Enterprise JavaBeans (EJB) have now become household names for Java programmers. If you are new to Java or more specifically, server-side Java, Figure 1 will help you understand the components involved in a J2EE environment. If you are an experienced Java developer, then you most likely do not need an explanation of the key components in the J2EE, but here is a brief description just the same: a servlet is a Java class that provides the functionality of a CGI script. JavaServer Pages (JSP) are essentially dynamic HTML pages. Enterprise JavaBeans (also known as Enterprise Beans) is a server-side component architecture; Enterprise Beans contain the business logic of an enterprise application. JDBC is a database-independent API to interface with popular databases such as Oracle, Sybase, and Microsoft SQL Server. The focus of this article is on EJB.
Source: Designing Enterprise Applications with the Java 2 Platform, Enterprise Edition, by Sun Microsystems’ Nicholas Kassem and the Enterprise Team
Spotlight on EJB
Ever since its debut in early 1998, Java developers have been clamoring about working with Enterprise JavaBeans. I work at a Java-focused IT consulting and solutions firm, and we come across our share of Java developers who only want to work with J2EE or, more specifically, EJB. While EJB is an elegant technology, many developers new to that technology do not understand that it is not a one-size-fits-all solution. EJB brings with it a lot of bells and whistles (e.g., security, transactions) that are not required by every application. For example, sometimes developing Web applications with local classes is perfectly acceptable, especially for smaller projects, provided good object-oriented design principles are applied.
Also, EJB might not be needed for nondistributed applications such as batch processes in which speed might be more important than security and transactions. Due to the distributed nature of EJB, data must be marshaled (serialized) and unmarshaled (deserialized) to facilitate communication between a client and the EJB component (server). That consequently introduces a lot of overhead and can result in poorer performance. Using local classes in the same JVM might be a better option.
Familiarize yourself with the technology
If EJB is appropriate for an application, then a different type of problem is often introduced: lack of theoretical and practical knowledge of EJB technology. I am surprised that so few Java developers who design J2EE-based applications have actually taken the time to read the J2EE Blueprints from Sun (see Resources section below).
Developers who are not very knowledgeable about how the EJB architecture works and expect that the application server will handle all scalability issues can end up creating applications that do not scale. That can happen in several ways. For example, when using Container Managed Persistence (CMP) for entity beans with products such as WebLogic in which each bean is mapped to a single table, the application can perform poorly in a complex database environment. In such a situation, several developers resort to using Bean Managed Persistence (BMP), which involves coding in the database calls in the Enterprise Bean. Here, an inexperienced developer can face performance problems because there is no standard for how often methods such as ejbLoad() and ejbStore() are called; in other words, improper design means that an Enterprise Bean can wind up hitting the database much more than would be required. With BMP style, persistence-related portability issues need to be addressed as well.
Other than the dilemma of when, where, and how Enterprise Beans should be used, knowledge of third-party products in the market is essential in building highly scalable enterprise applications. For example, using products such as TopLink from WebGain or Javlin from Excelon can boost performance of EJB-based applications.
In my opinion, we need better guidelines from Sun and other sources for when and how to use Enterprise JavaBeans. Case studies about how Enterprise JavaBeans are implemented in the real world and in real products — not just reference implementations — would also be very helpful. Developers that are not familiar with the J2EE environment should rely on experts that understand the overall architecture of J2EE and that have hands-on development experience. Also, a thorough understanding of the J2EE-compliant application server and available third-party products is crucial. But most importantly, read the J2EE Blueprints from Sun to get details about the environment before jumping into development.
