Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

Do you really need Enterprise JavaBeans?

EJB is not a one-size-fits-all solution

By Anil Hemrajani, JavaWorld.com, 10/06/00

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.

Figure 1: The J2EE environment
Click on thumbnail to view full image (25 KB)

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.

 

Improve efficiency with Visual Studio(r) 2010 Beta 2. - Microsoft

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.