Some reader favorites:
EJB fundamentals and session beans
Create a scrollable virtual desktop in Swing
More action with Struts 2
In a recent review of Struts 2 in Action, JW Blogger Oleg Mikheev notes that Struts 2 is "just a collection of extensions built upon WebWork, which is ultimately
the right thing to learn before starting a Struts 2 project." While Struts 2 has some architectural flaws, Oleg calls WebWork
well-designed, well-tested, and reliable. What are your experiences using Struts 2 and WebWork?
Also see "Hello World the WebWork way," a JavaWorld excerpt from WebWork in Action, by Patrick Lightbody and Jason Carreira.
| Memory Analysis in Eclipse |
| Enterprise AJAX - Transcend the Hype |
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.
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.
The solution to our design dilemma is to add a higher-level abstraction layer between the client-tier application and the EJB tier using the Session Façade design pattern, which is implemented as a session bean. The sequence diagram in Figure 2 shows the interactions between the client and EJB tiers after a banking Session Façade session bean is added.