J2EE design decisions - POJOs in Action: Developing Enterprise Applications with Lightweight Frameworks - page 39

In this design, the presentation tier, which may be remote, calls the façade. The
EJB container intercepts the calls to the façade, verifies that the caller is autho-
rized, and begins a transaction. The façade then calls the underlying objects that
implement the business logic. After the façade returns, the EJB container commits
or rolls back the transaction.
Unfortunately, using an EJB session façade has some significant drawbacks. For
example, EJB session beans can only run in the EJB container, which slows devel-
opment and testing. In addition, if you are using EJB 2 , then developing and main-
taining DTO s, which are used to return data to the presentation tier, is tedious
and time consuming.

2.3.2 POJO façade

For many applications, a better approach uses a POJO façade in conjunction with
an AOP -based mechanism such as the Spring framework that manages transac-
tions, persistence framework connections, and security. A POJO facade encapsu-
lates the business tier in a similar fashion to an EJB session façade and usually has
the same public methods. The key difference is that it's a POJO instead of an EJB
and that services such as transaction management and security are provided by
AOP instead of the EJB container. Figure 2.5 shows an example of a design that
uses a POJO façade.
The presentation tier invokes the POJO façade, which then calls the business
objects. In the same way that the EJB container intercepts the calls to the EJB

Web
Component

Web
Component

Presentation Tier

Business Tier

Spring AOP

Encapsulation
AOP-Managed Transactions
AOP-Based Security

POJO
Façade

Business
Object

Business
Object

Business
Object

Figure 2.5
Encapsulating the business
logic with a POJO façade