Introduction

When designing applications and considering the use of EJBs, you can choose from a number of options. These options offer different levels of complexity, advantages, and disadvantages. Based on the Model-View-Controller (MVC) architecture, you can use a session bean as a facade to an entity bean. The facade session bean increases performance by reducing the number of network calls. Besides performance improvements, the facade session bean hides the complexity of EJBs leading to separation of presentation logic and business logic.

This best practice applies to the following product, version, and platform:

• WebSphere Application Server Base (all platforms), 3.0.2.x, 3.5.x, 4.0

Back to top

Recommendation

The main advantage of using the facade session is the calls to the entity beans from the facade session bean are local method calls and avoid costly network communications. The WebSphere® object request broker (ORB) handles remote calls differently when the client and server are running in the same Java™ Virtual Machine (JVM). Rather than sending the remote call over remote method invocation/Internet inter-ORB protocol (RMI/IIOP), the ORB makes a local method call from the client to the server. Another reason for using the facade session is serialized objects can be passed to and from EJB remote method calls as these calls are over RMI/IIOP, an extension of RMI. The serialized objects can contain all of the information from one or more entity EJBs, reducing the number of method calls as well as hiding large number of parameters and complexity into a single method call.

Using the facade session bean also follows the Model-View-Controller (MVC) programming model offering other advantages. The MVC enforces the separation of presentation logic and business logic in an application. The MVC model also offers the benefits of applying specific security models to the presentation logic and business logic and role separation in a development team, where the work of a page designer can smoothly integrate with the separate work of a business logic developer. The separation of presentation logic and business logic is defined by three parts.

• Model - Encapsulates the business logic and rules and does the business processing, usually implemented by JavaBeans or EJBs.
• View - Uses the result of the business process and constructs the response presented to the user, usually through JavaServer pages (JSPs).
• Controller - Manages and controls all the interaction between the user and the application. Usually the controller is a servlet that receives the user request and passes all the input parameters to the model that does the actual work. Finally, the controller calls the view to generate the results.

A stateless EJB session bean, acting as a facade to hide the entity bean complexity from the requester (usually a servlet performing the controller component function), correctly follows the MVC model and separates the presentation logic from the business logic. The facade provides the business methods of the entity bean in the remote interface and the create and finder methods of the entity bean in the home interface.

Following the MVC model, this provides the advantages of hiding the persistence model from the client and causing the EJBs to be viewed as a general purpose data sources. Other advantages include tying together multiple data sources to act as a single point of entry to the business data layer and centralizes control of transactions and security at the facade level allowing for more efficient management of the application. All of these advantages lead to easier development as the servlet programmer only has to deal with method calls independent of the underlying implementation. This technique will allow smaller and simpler interfaces and provide a higher level of abstraction that shields the requester from changes in the EJB implementation.

With the ability to change the EJB implementation (business logic) or the servlet interface (presentation logic) without affecting the other, a valuable option of flexibility is gained as new enhancements are added to the application or features are changed.

Back to top

Alternative

Direct access and access beans are two other options to consider when designing an application with EJBs. Although both options offer some advantages over using a facade session bean, the lack of separation between the presentation logic and the business logic limits the extent of the advantages.

Direct access

Direct Access of EJBs is easy to implement, requiring the home of the entity bean to be initialized in the init method of the servlet. Since the initialization is taking place in the servlet on the client side, the separation between the presentation logic and the business logic is missing. Developers using Direct Access of EJBs may have difficulties changing the business logic in the application without affecting the presentation logic. Also with Direct Access, each method in vocation performed by the client is a remote call, causing the method to be routed through the TCP/IP stack, even when the servlet is running on the same system as the EJB container (same JVM).

Access Bean

The Access Bean method is much faster than Direct Access of EJBs. The home is cached in the access bean as well as other caching is performed. The Access Bean method also allows developers with no EJB knowledge to write servlets and JSPs that can access enterprise Javabeans and display their properties. By modifying the enterprise bean implementation, the number of remote calls going over the network can be greatly reduced, significantly improving performance. This modification, however, causes incompatibility with the other options for accessing EJBs, locking into a single implementation. Another disadvantage is when an Access Bean is involved in an association made navigable. The navigation method of the access bean returns an access bean corresponding to the enterprise bean at the other side of the association. This requires the developer to generate access beans for all the enterprise beans related through associations, as errors will occur when following associations through access bean methods.

Resources

• Building Layered Architectures for EJB Systems
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Recommendation
• Alternative
• Resources
• About the author
• Comments

Next steps from IBM

With the WebSphere Application Server you can benefit from the simplified EJB 3.0 development experience, new persistence model, and interceptors.

---

• Try: Download a free trial version of WebSphere Application Server Community Edition, the lightweight Java 5 application server with robust EJB 3.0 funtionality.
• Article: Learn how call patterns and components involved in making calls to EJB components deployed in the EJB container operate in WebSphere Application Server.
• Tutorial: This tutorials shows you how to create an enterprise J2EE application that implements both Plain Old Java Object (POJO) and EJB Web services endpoints.
• Buy: WebSphere Application Server

My developerWorks community

Dig deeper into WebSphere on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers