链接：https://pan.baidu.com/s/1qSOOwZ2ObQCkuMI2lG0Rog 

提取码：895c

 The disillusionment with EJBs

This book 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 book 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 EJBs 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 POJOs.

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 EJBs can participate in distributed transactions

that are started by a remote client. EJBs 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

6 CHAPTER 1

Developing with POJOs: faster and easier

by the container. The evolution continues in EJB 3 (described later in this

chapter), which simplifies the programming model considerably by enabling

POJOs to be EJBs.

1.1.2 A typical EJB 2 application architecture

Let’s look at an example of a typical EJB 2 application architecture. Imagine that

you work for a bank and you have to write a service to transfer money between two

accounts. Figure 1.1 shows how you might use EJB to implement the money transfer service.

 The business logic consists of the TransferService EJB and data access objects

(DAOs). The TransferService EJB is a session bean that defines the interface that

the business logic exposes to the presentation tier. It also implements the business logic.

 The TransferService EJB calls the AccountDAO to retrieve the two accounts, and

performs any necessary checks and other business logic. For example, it verifies

that fromAccount contains sufficient funds and will not become overdrawn. The

TransferService EJB calls AccountDAO again to save the updated accounts in the

database. It records the transfer by calling TransactionDAO. The TransferService