J2EE Blueprints Design Pattern
Session Entity Facade

 name

Session Entity Facade

 intent

Provide a single API to a collection of enterprise beans

 category

Structural Pattern

 motivation

Entity beans provide object-oriented access to server-side business logic, and are commonly shared across different applications. These applications often access different but overlapping subsets of an enterprise data model. For example, both a payroll management application and a general ledger need access to labor financial information, although payroll will also access worker time records, while the general ledger will access financial information unrelated to worker pay.

A common design approach when application data models overlap is to create a global, integrated data model. Above the data model lies a component layer of enterprise beans that abstracts the persistent data from the database in component classes and groups these various classes in useful ways (an object representing a workers timecard for a pay period, for example). The various application clients can then be written in terms of the component beans. Application development in this context involves creating a user interface which manipulates a composition of back-end component instances (typically through those instances' home and remote interfaces.)

Creating multiple applications against the same integrated data model and clustering back-end functionality into enterprise beans can greatly improve application integration, since all applications share the same "view of the world", and the beans' remote interfaces clearly define what services are available from them. The drawbacks of this approach have to do with the complexity of large data and programming models. First, designers and developers should not have to understand an enormous, highly-normalized data model or set of component APIs when writing an application that only uses one small corner of the model. Second, the entities in a large model can often represent abstractions that are not of interest to an application modeler. In the example above, payroll financial information might be indexed by timecard punch, a level of detail not of interest to the general ledger application. Third, if applications are written directly in terms of the underlying database schema, any change in the schema can potentially affect multiple parts of multiple applications. Writing applications in terms of database schema makes the schema difficult to modify. This same limitation applies to component APIs: a change in one component's API can cause problems across applications.

For these reasons, it is often useful to model application functions at an application level, implementing them in a single session bean class, called a "Session Entity Facade". The Facade class provides a unified, simple interface to all of the clients of an application. Clients of the application use the Facade as "one-stop-shopping" for application functionality and data access. Meanwhile, it retains integration with the enterprise data model, since the Session Entity Facade is written in terms of enterprise beans. And being an enterprise bean itself, it retains the object-oriented benefits of the enterprise bean model. The Facade class may be stateful or stateless depending on whether it needs to track session state.


 applicability

Use Session Entity Facade:

  • to provide application clients with a centralized source of application functionality
  • to support thin client development by encapsulating application functions on the server
  • to hide unnecessary enterprise data model complexity from application clients
  • to support code reuse by decoupling client code from the enterprise data model
  • to facilitate enterprise data model evolvability by centralizing schema dependencies in a small number of classes

 structure

Figure 1. UML Diagram for the Session Entity Facade.

 participants

Client

  • manage user interaction
  • request application services on behalf of the user
  • have no knowledge of enterprise beans' internal interactions
SessionEntityFacade

  • abstract functionality of a specific application
  • provide application-specific services, implemented in terms of other enterprise beans
Entity enterprise bean

  • abstract enterprise data model entity and business logic
  • represent persistent state in enterprise data model
  • implement business logic in terms of enterprise data model
  • service multiple applications simultaneously

 collaborations

Client

  • send application service requests to SessionEntityFacade
  • receive and display service request results from SessionEntityFacade
  • have no collaboration with or knowledge of other enterprise beans
SessionEntityFacade

  • provide application services to Client
  • implement application services in terms of other enterprise beans
EntityEJB

  • used in combination with other Entity EJBs by Session Entity Facade to implement application services

 consequences

Session Entity Facade has the following consequences:

  • Simplifies client design. The Session Entity Facade provides an interface to application functionality tailored to a client's needs. It presents application services and data to the client, hiding the details of the enterprise bean implementation. Client design is simplified because much of the application functionality is implemented within the Session Entity Facade, whereas the client's focus is on user interaction and client-side resource management.

  • Supports thin client development. Since the application functionality is concentrated in the Session Entity Facade, the client is left with little to do besides manage presentation and user interaction: the common definition of a thin client.

  • Decouples developers from one another. The unification of data services by a Session Entity Facade provides client developers with a single source of application functionality, freeing them from worrying about the details of how that functionality is implemented. From the client developer's point of view, the Facade class either supports all of the functions necessary to a particular use case, or it doesn't. The Facade class API is a common frame of reference for client and server developers in discussions of how services are to be delivered across a network. The client/server interface is the Session Entity Facade, and unifying this interface in one class concentrates design discussions on what services are to be delivered, not how the services are implemented on either side of the Facade. The result is that developers working on different parts of the system can work more independently.

  • Facilitates impact analysis. Assessing the impact of proposed changes to the enterprise data model is easier if all interactions with that model are centralized in Session Entity Facade classes. Likewise, proposed client modifications can be analyzed in the context of their interaction with the Session Entity Facade API.

  • Centralizes security, logging, and transaction control. Since the application functionality resides in the "middle tier" Session Entity Facade bean, application logging can occur at the level of method calls on the facade. Since it is an enterprise bean, security can be managed at the level of application functions; that is, at the Session Entity Facade API level. Instead of defining transaction control for all Entity EJBs on the back end, application transaction control can be centralized at the facade. Finally, the facade is a logical place to implement automatic transaction retries when client transaction requests fail.

  • Increases server implementation flexibility. Since the implementation details of the server overhead and from the client, application services can be implemented or modified without client redeployment. The Session Entity Facade can use EJBs, JDBC, CORBA, or other technologies to provide application functionality to its clients. It also provides a logical place to switch server function implementations as needs, resources, or technologies change.

  • Promotes component reuse. Decoupling client and server implementations promotes code reuse, because of decreased dependencies between modules. The Session Entity Facade interface also allows creation of new applications whose functionality span that of existing applications.

  • Adds an additional level of indirection. A Session Entity Facade is yet another class to write, and may require additional support classes to manage its internal complexity. The result is an additional level of indirection in the system, and an additional maintenance burden for the Facade and its helper classes.


 implementation-issues

  • Session Entity Facade may be implemented on server or client. While the Session Entity Facade looks like a middle-tier server object, it can actually reside on the client, the server, or some middle tier server. The benefits of the Session Entity Facade pattern stem from application API centralization and client-server code decoupling. Performance and availability issues are most important in determining where to host the Session Entity Facade component. Even if a "fat client" solution is appropriate for your application, the Session Entity Facade pattern is useful from the point of view of flexibility, maintenance, and testing.

  • Control Session Entity Facade code complexity. Since the Session Entity Facade class encapsulates all of the functionality for particular application, it is as vulnerable to complexity problems as an application that does not use a facade. A Facade pattern manages complexity by centralizing it in one place, but once centralized, that complexity must be properly managed. Structure the Session Entity Facade code to manage this encapsulated complexity well. Consider using other design patterns, such as FrontController, to keep essential application complexity under control.

  • Consider using a Facade pattern on both client and server. When implementing a Session Entity Facade on the server, it may be a good idea to implement another Facade class on the client, which then talks to the server-side Facade. This separates the client GUI code (which is often messy) from the server's Facade API, allowing them to vary independently during development. Also, a client-side Facade provides a centralized point of management for multithreaded access to the server Facade's (non-reentrant) session beans.


 sample-code

The Java Pet Store's Customer class is a Session Entity Facade: see Customer.java, CustomerEJB.java CustomerHome.java

 also-known-as


 related-patterns

Facade (GoF)