The simple definition is that it hides the complex logic and provides an interface to the client. Sounds familiar? This is nothing much more than the core part of abstraction: one of the core principles of object orientation.

I often post about Java EE on Twitter. Click to Follow @readlearncode

So what is special about this and why does it deserve its own name and place in the catalog of design patterns?

It’s not merely about creating abstractions but creating a specific type of abstraction in an enterprise system. You will have a layer called the application layer that describes at a higher level what that part of your application/subsystem actually does. Think of this high-level use case. That would be described by a business analysis: make an order, get a list of products, and match a given search criteria.

That is really what you are doing with the façade, describing these high-level abstractions to any user above that layer, perhaps a GUI layer or remote service invocation, they are talking in very simplistic terms to the façade and telling it please do this: the underlining code for that would be non-trivial and fairly complex.

How do you do this in classic GoF fashion, it’s really not very difficult at all, they are general assumed to be stateless objects often named service or façade and you create atomic methods that do a single thing. That is generally how it is implemented in GoF.

What does Java EE give you?

In this case, Java EE has a specialized annotation, the annotation that I talked about before, that is the stateless annotation. It is essentially a marker to denote that this is a façade and that it is intended to be stateless and to describe atomic operations at the application layer.

It can do some very useful things.

[sourcecode language=”java” toolbar=”false”]
@Stateless
public class BankServiceFacade{

public void complexBusinessLogic(){
// Very very complex logic
}
}

@Inject
public BankServiceFacade service;
[/sourcecode]

It is entirely thread-safe when you access it, it will be thread safe but it is not a singleton. How it is made thread safe despite not being a singleton is beyond the scope of this talk but essentially it involves some container magic.

It is thread-safe and stateless, you will never run into thread safety problems, it is by default transactional and it is useful for that tier of your application as you would normally want those high-level use cases to be transactional, also it includes things like monitoring management as well as pooling and more importantly defining upper threshold for pool sizes for these services. It is very useful for defining high-level scalable APIs.

It is stateless in terms of what the API expectations are. The implementation may be using things that are stateful for example you might have an entity manager that connects to a database. The thread safety is to shield the implementation from any issue with thread safety concerns. Why does it need to be pooled? Very simply, this is essentially the backbone of your application. Let’s assume that you have a createOrder method and let’s assume that you get a sudden burst of orders and suddenly have 10,000 orders to process concurrently because this object has an implicit upper bound you won’t run into a thread starvation situation. It will only be processed within the upper bounds of that thread pool which is typically 10, 15, 100 threads.

The Good, Bad and the Ugly

The Good

Gives you a range of services which you can add on top: scheduling, remoting, asynchronous processing, you can publish it out as a SOAP Webservice, WebSocket endpoint, REST endpoint.

The Bad

Overuse may introduce unnecessary layers if you don’t need it don’t introduce one

The Ugly

There isn’t one really

What next!

If you are interested in learning more about Java EE, why not check out my new course here, you can even start with a free trial.