In the last years I have met many people that do not fully understand the Façade design pattern. They all understand the concept of encapsulation, and agree on it being a must-to, but most of them fail to understand why Façades are always explained as being so important in J2EE.
Over this time, I have realized that most of them fail at the same point. They do not fully understand the rationale of a distributed architecture, and keep thinking in terms of self-contained applications. All of them think about EJBs and other components in J2EE just as encapsulations of the services provided by the container. They see the advantages of having a container that takes care of components transactionality and life-cycle. But they still think in terms of all the staff being under the same Virtual Machine.
This little misconception leads to some wrong assumptions:
- “Distribution” is just another name for “Clustering”.
- The access to EJBs in the same server is innecessarily complex to program.
- A Façade is not necessary. All my exposed functionality is already high-level.
Unfortunately, I must admit that most of the literature I have read until now fails to explain why these assumptions are wrong. The need for examples being simple usually prevents authors from presenting a good scenario showing how a Façade can be of help.
The Source of Misunderstanding
Essentially, what those people fail to see is the big picture. They just try to map into EJBs a standalone application, without realizing that:
- Not all components need to be high-level.
- Not all components need to be in the same server.
That is, a distributed application may use several components from a server or cluster (let's call it A), and several other components from another geographically separated server (B, obviously). In such a scenario, components exposed at A or B will not usually have operations defined in business-level terms, as they may be used by different applications with different business goals. Instead, low-level operations may be composed to obtain coarse-grained business-level operations.
These components, although low-level, still have to be made public, so any application can directly invoke them. This, by itself, may be perfectly legal, even for client applications. For example, you might be developing some very specific functionality for your application that will most probably never be useful for any other one.
However, business-level operations will probably be reused at many points. And here is where the Façade pattern shows its usefulness. A Façade will let you expose a “coarse-grained” operation that combines your already exposed low-level components, and maybe add some extra logic in-between.
Encapsulation here is not related to hiding the low-level functionality; all low-level components are still there. Instead, you add an extra component that knows how to use them. The key terms here are reusability and maintainability.
Façade is About Reusability
Speaking about fine and coarse-grained, or low-level and high-level components —the exact terms are not relevant— is speaking about reusability. Functionality is not separated in several layers if you do not expect each low-level component to be used by more than one high-level component. It is not worth the effort. The term itself, component, implies that there will be some kind of composition somewhere.
Programming this composition directly on the client applications has several drawbacks with regard to reusability:
- It makes client code dependent on low-level components. Encapsulation dictates that it should be dependent on business-level logic only.
- Probably, several client operations will repeat the same composition, as business-level operations are usually used at many points.
- We lose the ability to cache the results of the business-level operation. Obviously, a good caching policy may lead to great performance improvements.
Façade is About Maintainability
Maintainability is a concept with different meanings depending on who are you talking to.
A Façade exposes a high-level interface to the client applications (and to other components), isolating them from the low-level components used for its implementation. This gives the freedom to move and modify low-level components without altering the final applications. So, from a designer/developer point of view, Façades can improve code maintainability.
But the Façade pattern also encourages a multi-layer separation within the business layer. Performance problems are easier to detect and analyse in low-level components, because they have simpler logic. Additionaly, as they are often used by several other components, improving their performance has better impact on the overall application behaviour. That is, the relation cost/benefit of a performance improvement is usually higher for low-level components. For example, if a bottleneck is detected on a low level component, several strategies can be used to improve its performance (caching results when they have temporary locality, or moving the component to a cluster in order to balance its workload, etc.) This architecture style will benefit system administrators, as it will help them to maintain and tune production servers. So, from the administration point of view, Façades can also improve maintainability.
No Pattern is a Holly Grail
As the reader may have noticed, I do not declare that a Façade will “automagically” improve performance, reusability, or maintainability. These improvements will come from a carefully studied architecture, and a correct programming.
It just happens that the Façade pattern is a good step towards that architecture, if correctly applied.
Again, even among those that use this pattern, there are still many people with some wrong concepts:
- Directly accessing Entity EJBs is not a sin by itself. Creating a façade that just duplicates the operations of an Entity Bean does not help anybody. Façades must be coarse-grained.
- Façades are not mandatory in order to expose business-level logic. Façades are high-level components that use other components to perform their tasks. If a component exposes business-level logic, but does all the work by itself, it is not, strictly speaking, a Façade. Of course, it may become one after some refactorings, but that may not be necessary. If the task can be accomplished by a simple component, with no need for extra complexity, just apply the KISS principle. You can always refactor it later.
Adding a component that only replicates the public interface of another one, and calling it a Façade is an error. And adding innecessary components just to have a pattern name in a UML diagram is, by all means, an error. This will not lead to a better design, but just to a heavier, slower and more expensive application.
Enhancing the Pattern
A “traditional” Façade is a programmed component that implements some business-level logic within an application. This is a good approach when low-level components interaction is simple, and algorithmic logic is needed to accomplish the task. However, at the same time the number of low-level components to orchestrate raises, or their interaction becomes more and more complex, the programming approach becomes harder to maintain.
Workflow engines are a great tool to have in mind for these cases. BPEL and other similar frameworks/languages are extremely flexible and powerful, and can simplify the maintenance of otherwise very complex business-level processes. They provide the mechanisms for “declarative façades”, as a complement to the “programmed façade”.
Again, take BPEL and the like with a grain of salt. They are very useful for complex processes, but their completeness and flexibility come at the expense of an increased complexity. What is more, in most cases algorithmic logic will not be implementable through the workflow syntax, and instead it will have to be moved to some utility component that will be integrated into the workflow. If a process is simple, the benefits may not be worth the cost of these refactorings, and probably programming a simple Façade will be a better approach.
