 |
| ||
 |
 |
|
|
|
 |
|
 |
|
Soapbox
SummaryBy Anil Hemrajani
Anil Hemrajani returns to JavaWorld as a columnist. In this first Soapbox column, he offers his opinions on whether Enterprise JavaBeans are really necessary. (700 words)
he
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 |
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.
About the author
Anil
Hemrajani is the chief technology officer at Isavvix, an emerging Java technology solutions
firm. He welcomes your comments and questions about this column. Write to him or
visit the iSavvix Soapbox
forum.
|
 |
|
|
|
Copyright © 2002 JavaWorld.com, an IDG Communications company |
|
 |
|
