Sun Java Center J2EE Patterns

Print-friendly Version

Context

In a multi-tiered application, server-side components, such as enterprise beans, encapsulate non-trivial business logic and business data. These components expose their interfaces and thus the complexity of the distributed services clients.

Problem

Three problems may arise in a multi-tiered J2EE application environment:

• Tight coupling which leads to direct dependence between clients and business objects
• Too many method invocations between client and server leading to network performance problems
• Lack of a uniform client access strategy exposing business objects to misuse

A multi-tiered J2EE application has numerous server-side objects that are implemented as enterprise beans. In addition, some other arbitrary objects may provide services or data or both. These objects are collectively referred to as business objects since they encapsulate business data and business logic. J2EE applications implement business objects that provide processing services as session beans. Coarse-grained business objects that represent an object view of persistent storage and are shared by multiple users are usually implemented as entity beans. Application clients need access to business objects to fulfill their responsibilities and to meet user requirements. Clients can directly interact with these business objects because they expose their interfaces. When you expose business objects to the client, the client must understand and be responsible for the business data object relationships and be able to handle business process flow. However, direct interaction between the client and the business objects leads to tight coupling between the two, and such tight coupling makes the client directly dependent on the implementation of the business objects. Direct dependence means that the client must represent and implement the complex interactions regarding business object lookups and creations, and must manage the relationships between the participating business objects as well as understand the responsibility of transaction demarcation. As client requirements increase, the complexity of interaction between various business objects increases. The client grows larger and more complex to fulfill these requirements. The client becomes very susceptible to changes in the business object layer, plus the client is unnecessarily exposed to the underlying complexity of the system.

Tight coupling between objects also results when objects manage their relationship within themselves. Often, it is not clear where the relationship is managed which leads to complex relationships between business objects and rigidity in the application. Such lack of flexibility makes the application less manageable when changes are required.

When accessing the enterprise beans, clients interact with remote objects. Network performance problems may result if the client directly interacts with all the participating business objects. When invoking enterprise beans, every client invocation is potentially a remote method call. Each access to the business object is relatively fine grained. As the number of participants increases in a scenario, the number of such remote method calls increases. As the number of remote method calls increases, the chattiness between the client and the server-side business objects increases. This may result in network performance degradation for the application because the high volume of remote method calls increases the amount of interaction across the network layer.

A third problem arises when a client interacts directly with the business objects. Since the business objects are directly exposed to the clients, there is no unified strategy for accessing the business objects. Without such a uniform client access strategy, the business objects are not protected from abuse or misuse.

Forces

• Provide a simpler interface to the clients by hiding all the complex interactions between business components.
• Reduce the number of business objects that are exposed to the client across the service layer over the network.
• Hide from the client the underlying interactions and inter-dependencies between business components. This provides better manageability, centralization of interactions (responsibility), greater flexibility, and greater ability to cope with changes.
• Provide a uniform coarse-grained service layer to separate business object implementation from business service abstraction.
• Avoid exposing the underlying business objects directly to the client to keep tight coupling between the two tiers to a minimum.

Solution

Use a session bean as a façade to encapsulate the complexity of interactions between the business objects participating in a workflow. The session façade manages the business objects, and provides a uniform, coarse-grained service access layer to clients.

The session façade abstracts the underlying business object interactions and provides a service layer that exposes only the required interfaces. Thus, it hides from the client's view the complex interactions between the participants. The session façade manages the interactions between the business data and service objects that participate in the workflow, and it encapsulates the business logic associated with the requirements. Thus, the session bean (representing the session façade) manages the relationships between business objects. The session bean also manages the lifecycle of these participants by creating, locating (looking up), modifying, and deleting them as required by the workflow. In a complex application, the session façade may delegate this lifecycle management to a separate object. For example, to manage the lifecycle of participant session and entity beans, the session façade may delegate that work to a Service Locator object (see Service Locator Pattern).

It is important to examine the relationship between business objects. Some relationships between business objects are transient, which means that the relationship is applicable to only that interaction or scenario. Other relationships may be more permanent. Transient relationships are best modeled as workflow in a façade, where the façade manages the relationships between the business objects. Permanent relationships between two business objects should be studied to determine which business object (if not both objects) maintains the relationship.

Structure

The following class diagram represents the Session Façade pattern:

Participants & Collaborations

The following sequence diagram shows the interactions of a session façade with two entity beans, one session bean, and a data access object as participants in fulfilling the request from the client.

SessionFacade

The SessionFacade is implemented as a session bean. The SessionFacade manages the relationships between numerous BusinessObjects and provides a higher level abstraction to the client. The SessionFacade offers coarse-grained access to the participating BusinessObject represented by the Invoke invocation to the session bean.

BusinessObject

The BusinessObject is a role object that facilitates applying different strategies, such as session beans entity beans and a DAO (See the Strategy section for an explanation.) A BusinessObject provides data and/or some service in the class diagram. The SessionFaçade interacts with multiple BusinessObject instances to provide the service.

Strategies

The Session Facade is a boundary object that controls the interactions between the client and the participant business data and service objects. Thus we refer to the Session Façade as a boundary controller. In a complex application, there may be numerous session façades that can intermediate between the client and these objects. You can identify where a Session Façade might be useful by studying the client requirements and interactions typically documented in use cases and scenarios. This analysis enables you to identify a boundary layer-the Session Façades- that can act as a façade for these scenarios.

This section explains different strategies for implementing a session façade.

Session Façade Strategies

Stateless Session Façade Strategy

When implementing the session façade, you must first decide whether the façade bean is a stateful or a stateless session bean. Base this decision on the application use case that the session façade is modeling.

Recall that careful study of the use cases and scenarios enables you to determine the session façade definitions. During this analysis phase, pay attention to the nature of the interaction depicted by the use cases. Identifying the state maintained across interactions (also know as a conversation) can also help you identify the whether the session bean needs to be stateful or stateless.

If the use case is non-conversational, then a single method in the session façade initiates the use case. When the method completes, the use case completes too. There is no need to save the conversational state between one method invocation to the next. In this scenario, the session façade can be implemented as a stateless session bean.

Stateful Session Façade Strategy

If a use case is conversational, then a single use case requires multiple method calls to complete. The conversational state must be saved between each client method invocation. In this scenario, a stateful session bean may be a more suitable approach for implementing the session façade. In both strategies discussed above, the business objects can be implemented in different ways as explained below.

Business Objects Strategies

You can represent a business object as a session bean, entity bean, data access object, or regular Java object. The following strategies discuss each of these choices.

Business Object is a Session Bean

You can represent the business object by a session bean. The session bean usually provides a business service and, in some cases, it may also provide business data. When such a session bean needs access to data, it may use a data access object to manipulate the data. The session façade can wrap one or more such service or data-oriented session beans acting as business objects.

Business Object is an Entity Bean

Representing the business object by an entity bean is the most common use of the session façade. When multiple entity beans participate in the use case, it is not necessary to expose all the entity beans to the clients. Instead, the session façade can wrap these entity beans and it can provide a coarse-grained method to perform the required business function, thus hiding the complexity of entity bean interactions.

Business Object is a Data Access Object

The session façade can directly use one or more data access objects to represent the business data. This is done when the application is so simple that it requires no entity beans, or when the application's architecture is based only on session beans and does not use entity beans. Using data access objects inside session beans partially simulates the persistent nature of entity beans.

The application might need the services provided by an arbitrary Java object (that is, an object that is not an enterprise bean or a DAO, though a DAO can be viewed as a type of arbitrary Java object). In such cases, the session façade accesses this service object to provide the necessary functionality. A common usage is a Java object which is a member of the object model.

Consequences

• Introduces Boundary Controller layer
  Session Façades can represent a boundary layer between clients and business tier, as identified through analysis modeling. A Session Façade encompasses the interactions between the client and the business components. In a sophisticated application, one can identify numerous Session Façades that can intermediate between the client and the participating business tier objects. For simpler applications, one might feel that a Session Façade is not adding much value as it may act to mostly proxy the client requests to a single business component. However, as applications grow more complex over time, using a Session Façade upfront will yields benefit at a later stage.
• Simpler Uniform Interface
  The underlying interactions between the business components participating in a use case can be very complex. A session façade pattern abstracts this complexity and presents the client a simpler interface that is easy to understand and to use. By applying a session façade, one can design a service layer that exposes simpler interfaces to the system as a whole. Thus a façade provides a uniform coarse-grained access layer to all types of clients and can protect and hide the underlying participant business components.
• Reduced Coupling, Increased Manageability
  Using a session façade decouples the underlying business objects and system from the clients, thus reducing the tight coupling between the two tiers and the client's dependency on the business objects. It is best to use a session façade to manage workflow among business objects, rather than making the business objects aware of each other. A business object should only be responsible for its own (data and logic) management. Inter-business object interactions can be abstracted into a workflow in a façade. This provides better manageability, centralization of interactions (responsibility and workflow), greater flexibility, and greater ability to cope with changes. Separating workflow into a session façade eliminates the direct dependency of the client on the participant objects and promotes design flexibility. Although changes to participants may require changes in the session façade, centralizing the workflow in the façade makes such changes more manageable. You change only the session façade rather than having to change all the clients. Client code is also simpler because it now delegates the workflow responsibility to the session façade. The client no longer manages the complex workflow interactions between business objects, nor is the client aware of inter-dependencies between business objects.
• Performance Impact
  The session façade also impacts performance. The session façade reduces network overhead between the client and the server because its use eliminates the direct interaction between the client and the business data and service objects. Instead, all interactions are routed via the session façade in a coarse-grained manner. The session façade and its participants are closer to each other, making it more efficient for the façade to manage interactions between the participant objects. All data transfer and method invocations from the façade to the participants are presumably on a relatively high-speed network. The network performance can be further tuned to provide maximum throughput by applying the Value Object pattern for the participant objects where applicable.
• Coarse-Grained Access
  A session façade is meant to be a highly coarse-grained abstraction of the workflow. Thus, it is not desirable to have one session façade per entity bean interaction, which would represent a fine-grained abstraction rather than a coarse-grained one. Analyze the interaction between the client and the application services using use cases and scenarios to determine the coarseness of the façade. Determine the optimal granularity of the session façade for the application by partitioning the application into logical subsystems and providing a session façade for each subsystem. However, providing a single façade for the entire system can result in a very large session façade whose numerous methods make it inefficient. A single façade may be sufficient for very simple applications that do not warrant sub-systems.
• Centralized Security management
  Security policies for the application can be managed at the session façade level, since this is the tier presented to the clients. Because of the session façade's coarse-grained access, it is easier and more manageable to define security policies at this level rather than at the participating business component level. Business components offer fine-grained control points. It is easier to manage security for Session Facades that provide coarse-grained access because there are relatively fewer coarse-grained methods to be securely managed.
• Centralized Transaction Control
  Because the session façade represents the workflow for the use cases, it is more logical to apply transaction management at the session façade level. Centralized transaction control has similar advantages as centralized security. The façade offers a central place for managing and defining transaction control in a coarse-grained fashion. It is much more work to do transaction management individually on participant business components, especially since they are more fine-grained than the façade. Also, without using a session façade and having the client access the enterprise beans directly puts the transaction demarcation burden on the client and can produce unwanted results.
• Fewer remote interfaces exposed to clients
  Clients that interact directly with the business data and service objects cause an increase in chattiness between the client and the server. Increased chattiness may degrade network performance. All access to the business object must be via the higher level of abstraction represented by a façade. Since the façade presents a coarse-grained access mechanism to the business components, this reduces the number of business components that are exposed to the client. Thereby, the scope for application performance degradation is reduced due to the limited number of interactions between the clients and the session façade when compared to direct interaction by the client to the individual business components.

Related Patterns

• Façade Pattern [GoF]
  The session façade is based on the Façade design pattern.
• Data Access Object Pattern [SJC]
  One of the strategies for the business component in the session façade pattern is to use the Data Access Object. This can be the case in simpler applications designed using session beans and data access objects instead of entity beans.
• Service Locator Pattern [SJC]
  The session façade is a coarse-grained object that allows encapsulation of the workflow by managing business data and service objects interactions. Business data objects can be entity beans or data access objects, and the business service objects can be session beans and other objects that provide service. The session façade can use the Service Locator pattern to reduce the code complexity and to exploit the benefits offered by the Service Locator.
• Business Delegate Pattern [SJC]
  The Session Façade is used by the Business Delegate when the client requests access to business services. The Business Delegate proxies or adapts the client request to a Session Façade that provides the requested service.

(c) 2000-2001 Sun Microsystems, Inc. All Rights Reserved.

Version 1.0 Beta