|
J2EE Blueprints Design Pattern
Session Entity Facade
|
|
|
|
|
Session Entity Facade
|
|
|
Provide a single API to a collection of enterprise beans
|
|
|
Structural Pattern
|
|
|
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.
|
|
|
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
|
|
|
 |
Figure 1. UML Diagram for the Session Entity Facade.
|
|
|
|
|
- manage user interaction
- request application services on behalf of the user
- have no knowledge of enterprise beans' internal interactions
|
|
- abstract functionality of a specific application
- provide application-specific services, implemented in
terms of other enterprise beans
|
|
- 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
|
|
|
|
|
- send application service requests to SessionEntityFacade
- receive and display service request results from
SessionEntityFacade
- have no collaboration with or knowledge of other
enterprise beans
|
|
- provide application services to Client
- implement application services in terms of other
enterprise beans
|
|
- used in combination with other Entity EJBs by Session Entity
Facade to implement application services
|
|
|
|
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.
|
|
|
-
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.
|
|
|
The Java Pet Store's Customer class is a Session Entity Facade: see
Customer.java ,
CustomerEJB.java
CustomerHome.java
|
|
|
|
|
|
Facade (GoF)
|