Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

Combine the Session Façade pattern with XML

Apply the Session Façade pattern to J2EE-based applications

By Jason Cai, JavaWorld.com, 01/11/02

The Session Façade design pattern is popular for developing enterprise applications based on J2EE (Java 2 Platform, Enterprise Edition). It not only enforces reusable application architecture design but also provides many advantages, including reduced network overhead, centralized security management and transaction control, coarse-grained abstraction of business data and service objects, and reduced coupling between clients and business objects.

The Session Façade design pattern is a must-have to successfully develop software with J2EE. It is difficult to decide how to most effectively use Session Façade in a specific project. There are many factors to consider: project business requirements, project scope, and complexity, just to name a few. In most situations, developers use the Session Façade pattern with Value Object and other related design patterns, but I have found some limitations to this approach in several projects, especially when constructing large and complex systems.

Within this article, I will first provide an introduction to the Session Façade design pattern, the benefits it brings, and the pros and cons when using Session Façade with the Value Object pattern. Then I will present the alternate solution: Session Façade with XML.

Session Façade overview

The Session Façade design pattern uses an enterprise session bean as a façade, which abstracts the underlying business object interactions and provides a uniform, coarse-grained service access layer to clients.

In a distributed J2EE application, the client-tier application interacts with the server by exchanging data between itself and the EJB (Enterprise JavaBeans) tier. Due to the overhead of multiple network calls and poor concurrency, it can be a performance killer if the client-tier application directly invokes multiple fine-grained methods on session/entity EJB components (which I call business objects) in the J2EE application's EJB tier.

Consider a J2EE banking application, where a bank customer asks a bank teller to transfer money from his savings account to his checking account. In this scenario, the bank standalone client application must first validate the customer before withdrawing money from the savings account and depositing it into the checking account. The sequence diagram in Figure 1 shows the interaction between the client tier and the EJB tier.

Figure 1. Interaction between client and EJB tiers

This approach features two main drawbacks. First, it doesn't scale. The client application must make remote calls to each enterprise bean. There are six network calls in all, as shown in Figure 1's sequence diagram.

The second drawback: This approach has poor concurrency. The client application must wrap the calls to SavingAccount and CheckingAccount within one transaction to maintain the customer's account in a consistent state. The transaction will be stretched longer due to network overhead, and as a result, this approach inevitably increases the chances of deadlock and reduces concurrency.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.