Level: Intermediate WebSphere Practices Team (WebSphere_Best_Practices@us.ibm.com)IBM
08 Aug 2001 This best practice describes how you can use EJBs to improve performance and to separate presentation logic and business logic.
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
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.
Figure 1. Application based on the Model-View-Controller architecture
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.
Figure 2. Application using a facade session bean to hide the complexity of an entity bean
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.
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
About the author  | | | This best practice was written by the WebSphere Best Practices team. |
Rate this page
| 
