Session Facade

Avijeet Dash and Satyabrata Dash

Introduction

In a multi-tiered environment, different sub-systems communicate with each

other either in same process or different processes. In that case we can design

the system where the service provider sub-system (server) exposes fine grained

Business Objects to service seeker sub-system (Client). In an EJB application,

the process flow is implemented using Session Bean Business Object where as the

Coarse-grained business objects that represent an object view of persistent

storage are modeled as Entity Beans.

The client application can directly invoke individual Entity Beans

(Approach-1) and then aggregate the results at client-side. This kind of

approach is acceptable if both client and server reside in the same process

space. But the approach becomes very expensive because of network overhead when

Client is a remote client and each call to the Server is an intra-process call.

The other drawback with this kind of approach is too many server side interfaces

are exposed to client and hence

The other drawback with this kind of approach is too many server side

interfaces are exposed to client and hence different tiers are tightly coupled

to each other. So maintainability also becomes an issue along with performance

in this kind of approach.

Approach-2 gives a better design approach by designing the sub-systems in

such a way that only one interface is exposed from the subsystem to outside.

Approach-2 gives a better design approach by designing the sub-systems in

such a way that only one interface is exposed from the subsystem to outside.

Facade pattern by GOF already explains the problem and the solution to solve

this. It recommends providing a unified interface to a set of interfaces in a

subsystem. Façade defines a higher-level interface that makes the subsystem

easier to use. Session Facade is just an implementation of Facade in J2EE

architecture where the Facades are implemented using Session Beans.

Session Bean should just explain the workflow and the actual implementation

of various sub-processes should be delegated to other Business Objects.






Stateless/Stateful Session Bean:

Session Facade uses a Session Bean as the Facade to Server side interfaces.

So the type of session bean has to be decided depending on the nature of

application. The Session Bean describes the business workflow of the

application. So Stateful Session be used only if the client session has to be

stored across method calls else Stateless Session Beans are preferred over

Stateful Session Beans as they have less overhead and hence give better

performance results.

Role of Entity Bean:

In EJB1.1, both Session and Entity beans expose only Remote Interfaces to the

client. So even though approach-2 has only Session bean exposed to client and

Session Bean and entity bean reside in the same process space, still each call

made to Entity Bean is essentially an remote call. So Session Bean doesn't have

to necessarily use Entity Beans as the Business Objects, it can also use Data

Access Objects (http://developer.java.sun.com/developer/restricted/patterns/DataAccessObject.html)

to work as Business Objects.

Role of Usecase in Session Facade

Martin Fowler suggests the

following guidelines to choose the number of Session Facades in an application.

1.prefer a coarser grained structure with much fewer Session Facades.

2.Use a single Session Facade for a moderate sized application.

3.Even for a large application have half a dozen Session Facades. This means

that each Session Facade has a lot of methods, but all these methods should be

small.

Code Example:

The code example is given here for the remote interface of the StockTrading

stateless session bean.

public interface StockTradeSession extends EJBObject {

  public TradeVO getOrderDetails(String orderId) throws



    RemoteException;

  public void putBuyOrder(TradeVo obj)



    throws RemoteException;


  public void putSellOrder(TradeVo obj)


    throws RemoteException;

}

The client to this Facade can be implemented using Business Delegate Pattern

(https://www.ciol.com/content/technology/j2ee/102022601.asp)

Related Patterns

• Facade
  
  Pattern
  
  
  
  The session facade is based on the Façade design pattern.
• Data Access Object Pattern
  
  
  
  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
  
  
  
  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

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.

References:

1. https://www.ciol.com/archive/articledetail.asp?arid=26286
2. http://www.martinfowler.com/isa/distributedFacade.html
3. http://www7b.boulder.ibm.com/wsdd/library/techarticles/0106_brown/sessionfacades.html
4. http://developer.java.sun.com/developer/restricted/patterns/SessionFacade.html
5. Core J2EE Patterns, Deepak Alur, John Crupi, Dan Malks

(The authors are senior developers at MindTree Consulting. They can be

reached at avijeetd@mindtree.com

and satyabrata_dash@mindtree.com.)