Java Reference
In-Depth Information
Much of this topic focuses on alternatives to
EJB
s because they frequently offer
better characteristics: good object-oriented design, testability, less complexity, eas-
ier maintenance, and a raft of other benefits. However, it's important to remem-
ber that
EJB
s are sometimes the right tool for the job, which is why chapter 10 is
about using
EJB 3
. The key is to be conscious of the options and to make explicit
informed decisions rather than slavishly following dogma.
1.1 The disillusionment with EJBs
This topic isn't a screed about why you shouldn't use “traditional” Java 2 Enter-
prise Edition (
J2EE
) architecture and design. It is sometimes the best tool for the
job, and later on in this topic I describe when you should use it. However, today
many developers use it for applications for which it is ill suited. Let's briefly review
the history of
EJB
s and discover why the Java development community's initial
enthusiasm for them has turned into disillusionment. After that, I will describe an
alternative approach to designing an enterprise Java application that uses
POJO
s.
1.1.1
A brief history of EJBs
EJB
is the Java standard architecture for writing distributed business applications.
It's a framework that provides a large number of useful services and handles some
of the most time-consuming aspects of writing distributed applications. For exam-
ple,
EJB
provides declarative transactions, which eliminate the need to write trans-
action management code. The
EJB
container automatically starts, commits, and
rolls back transactions on behalf of the application. Automatically handling trans-
actions was a huge innovation at the time and is still a vital service. In addition,
business logic implemented using
EJB
s can participate in distributed transactions
that are started by a remote client.
EJB
s also provide declarative security, which
mostly eliminates the need to write security code, which is another common
requirement handled by the application server. Entries in the bean's deployment
descriptor specified who could access a particular bean.
EJB
version 1.0 was released in 1998. It provided two types of enterprise beans:
session beans and entity beans. Session beans represent either stateless services or
a stateful conversation with a client. Entity beans represent data in a database and
were originally intended to implement business objects.
EJB 1.0
fulfilled its
mandate by insulating the application developer from the complexities of
building distributed enterprise systems.
EJB 2
refined the
EJB
programming
model. It added message-driven beans (which process Java Message Service, or
JMS
, messages) as well as enhanced entity beans to support relationships managed
Search WWH ::
Custom Search