J2EE design decisions

Learn how to discern which design patterns and frameworks would work best for your enterprise applications

1 2 3 Page 2
Page 2 of 3

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 transactions, persistence framework connections, and security. A POJO façade encapsulates 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 5 shows an example of a design that uses a POJO façade.

Figure 5. Encapsulating the business logic with 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 façade, the AOP interceptors intercept the calls to the POJO façade and authenticate the caller and begin, commit, and roll back transactions.

The POJO façade approach simplifies development by enabling all of the business logic to be developed and tested outside the application server, while providing many of the important benefits of EJB session beans such as declarative transactions and security. As an added bonus, you have to write less code. You can avoid writing many DTO classes because the POJO façade can return domain objects to the presentation tier; you can also use dependency injection to wire the application's components together instead of writing JNDI (Java Naming and Directory Interface) lookup code.

However, there are some reasons not to use the POJO façade. For example, a POJO façade cannot participate in a distributed transaction initiated by a remote client.

1 2 3 Page 2
Page 2 of 3