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