J2EE Design Pattern : Business Tier Patterns : Session Façade Design Pattern

• Session Façade Design Pattern?
• Example for Session Façade

Session Façade hides business object complexity and centralizes workflow handling.

The Session Façade will be responsible for Locating, creating and modifying the business objects Providing a uniform coarse-grained service access.

Problem

• Tight coupling between the client and the business components leads to direct dependency.
• Direct access require the client to have complex logic to coordinate and interact with many business components, thus the client must have the complex logic to do lookups, demarcate transactions, manage security, and do business processing. This increases the complexity and responsibility of the client.
• When you have different types of clients, direct access to business components leads to inconsistent use of the common business components.

Context

• You want to expose business components and services to remote clients.
• Controls client access to business objects.
• Limits the network traffic between remote clients and fine-grained business components and services.

Solution

• Use a Session Façade to encapsulate business-tier components and expose a coarse-grained service to remote clients.
• Clients access a Session Façade instead of accessing business components directly.

Session Façade Class Diagram

Participants and Collaborations

Client

The Client represents the client of the Session Façade that needs access to the business service. This client is typically a Business Delegate in another tier.

SessionFacade

The SessionFacade is the main role of this pattern. The SessionFacade is implemented as a session bean, stateful or stateless as needed to support the use cases it services. The SessionFacade hides the complexity of dealing with several BusinessComponents that participate in a use case and thereby provides a higher-level, coarse-grained remote service abstraction to the Clients.

BusinessComponent

BusinessComponent participates in fulfilling the client’s request. A BusinessComponent can be implemented as a Business Object that models business data and behavior, or as an Application Service. For example, in the sequence diagram, the Business Object participants are implemented as entity beans, as shown in BusinessObject1 and BusinessObject2.The ApplicationService participant is implemented as a POJO.

ApplicationService

ApplicationService encapsulates the BusinessObjects and implements the business logic that is executed to provide the required service. The SessionFacade can interact with several ApplicationService objects to fulfill a single request from the client.

DataAccessObject

DataAccessObject represents a role when you use Data Access Objects with a Session Façade. In some applications, a Session Façade can directly use one or more Data Access Objects to obtain business data. Typically, this is done in simple applications that do not require a layer of Business Objects in the business tier.

Implementation Strategies:

• Stateful Session Façade Strategy
• Stateless Session Façade Strategy

Fine Grained Entity Bean Design

The client calls accessor methods on an entity bean to read the value of every individual data member

Coarse Grained Entity Bean Design

The client uses an entity bean to retrieve a state object populated with database data