Java Reference
In-Depth Information
A façade can invoke other façades in other subsystems, which in turn encapsulate their own logic
and l ow. This shows one of the benei ts of using façades: a simplii ed hierarchy of method calls.
There's one façade for each subsystem, and these subsystems communicate with each other via the
façades.
Façade with Stateful Bean
The same bean can be implemented as a stateful session bean or even as a singleton bean as long as
it hides some complicated logic and exposes an easy‐to‐use interface to the client. The only change is
the addition of the
@Stateful
annotation, which marks the bean a stateful EJB.
In J2EE (pre 5.0), the use of the façade pattern was encouraged in the implementation of the session
façade pattern. However, even in the simplii ed approach of Java EE, façades still have their place
when control and encapsulation of the workl ow are required.
WHERE AND WHEN TO USE THE FAÇADE PATTERN
The façade pattern should be used to encapsulate complicated (business) logic at a high level and
provide a cleaner single point of access via an API.
Whenever you are in the position to provide an interface or an API to someone, think i rst about
the complexity of the logic and the changes that might occur. The façade pattern does a good job of
providing a clean API while hiding the parts subject to change.
However, unnecessarily wrapping methods in a façade is bad practice and adds unnecessary layers.
Premature encapsulation could result in too many invocations and layers that don't add value.
When implementing the session façade, you must determine if the use case requires state to be
maintained. A use case that invokes only one method of the façade to receive the service that it
needs is considered nonconversational, so there is no need to save the conversational state between
one method invocation and the next. You should implement this façade as a stateless session bean.
On the other hand, if the conversational state must be maintained between method invocations, the
most appropriate way to implement the façade is as a stateful session bean.
You must be careful in the use of the stateful session façade because it ties up server resources until
the client that provoked the conversation releases them or times out. This could mean that, for the
majority of the time the stateful session bean façade is bound to the client, it is doing nothing; it's
just maintaining state and using resources. And, unlike stateless session bean façades, it cannot be
reused and shared between other clients because each request creates a new instance of the stateless
façade, maintaining the state for that client's session.
So take care when using this pattern. Analyze the use case and make appropriate decisions.
SUMMARY
You can implement the façade pattern as a POJO, a stateless session bean, or a stateful session bean.
The various ways to implement the façade pattern solve different problems for different use case
scenarios. But the variety of implementations does not distract from its principle intent: providing a
high‐level simple interface to a more complicated subsystem.
