Developing with POJOs: faster and easier - POJOs in Action: Developing Enterprise Applications with Lightweight Frameworks - page 28

the application server or an open source implementation such as DBCP [ DBCP ]. If
the application needed to be clustered for scalability and reliability, then it would
use the clustering feature of the web container.
An application only needs to be deployed in a full-blown application server
(e.g., WebLogic Server or JBoss) if it requires those parts of the J2EE stack such as
JTA or JMS that are not provided by the web container or some third-party soft-
ware. You might also want to deploy your application in a particular server if you
wanted to use a vendor-specific feature. For example, some application servers
have sophisticated security and management capabilities. Only some applications
have these requirements, and if you break the dependency on EJB s by using POJO s
and lightweight technologies, you can often deploy an application in a simpler
and, in some cases, cheaper server.

1.2.8 POJO design summary

Let's review the design of the money transfer service that uses a POJO object model,
Spring for transaction management and dependency injection, and Hibernate for
persistence. The design, which is shown in figure 1.8, has more components than
the EJB -based design described earlier in section 1.1.2. However, this more modular
design is easier to understand, test, and extend than the original version. Each class
has a small number of well-defined and easy-to-understand responsibilities. The use
of interfaces for the repositories simplifies testing by allowing the real implemen-
tations of the repositories to be replaced with stubs. OverdraftPolicy enables the
design to be extended to support new types of overdrafts without requiring modi-
fications to existing code.
The core of the business logic consists of object model described earlier in sec-
tion 1.2.1 and includes classes such as Account and OverdraftPolicy . The
AccountRepository and BankingTransactionRepository classes encapsulate the
Hibernate API s. AccountRepository defines a method for retrieving accounts, and
BankingTransactionRepository provides a method for creating transactions.
TransferService is a simple service that looks up the accounts by calling Account-
Repository and calls credit() and debit() on them. It also creates a Banking-
Transaction to record the transfer.
TransferFacade is a simple wrapper around TransferService that retrieves the
data required by the presentation tier. This functionality could be implemented
by TransferService , but implementing it in a separate class keeps Transfer-
Service focused on transferring money and away from the presentation tier and
the details of detaching objects. TransferFacade is wrapped with a Spring Trans-
actionInterceptor that manages transactions.