Introduction

most of the J2EE design patterns come down to the simple principle of adding more layers in your application design. This is also the case for the session facade design pattern.

However, there is more to it than simply adding another layer of abstraction in your application in order to minimize the impact of changes on your system:
The real reason to implement the Session façade design pattern is a performance gain it can bring.

Why apply it?

Suppose you have one or more Enterprise JavaBeans in your application.
These beans can be session or entity beans. You'll want to use the services they provide from within your client, which can be a standalone application or a JSP/Servlet in the webtier.

To get any meaningfull work done, you'll probably need more than one call to the same EJB, or even more than one EJB at all.

This can be a real performance bottleneck if your EJBs expose remote interfaces.
When doing so, every single call to every single method on each EJB you use will become a remote (RPC) call over the network!

something like a getName() on your Customer Entity bean will initiate it own remote cross-network call!
And if this doesn't sound worse enough, the whole EJB services stack is passed for each invocation: security, transactionality, location transparency, etc ...

The session bean façade design pattern solves these problems.

Instead of directly using your EJB services from the client side, and having your control structures for a certain piece of work located there, you expose a more service-based API on a Session Bean Façade, a Session Bean that exposes a more coarse-grained approach to the service.

An example

If you are writing a piece of logic that gives all employees a 2% salary increase, you would logically write something that looks like this:

Get All customers
Loop Customers
  Add 2% to the salary of customer

Now, if you program this logic inside, let's say, a servlet, you're not getting the most out of your application!
If there are for instance 10 employers, you're doing 11 calls (1 to fetch the customers, and then 10 to add the salary of each one.

If you implemented this logic inside a session bean with one method, for instance:
public void increaseSalaries ( double percent );
then your client code would be cleaner, having only 1 line of EJB calling functionality, and -- most important of all -- your application would make only 1 remote call.

By applying this simple design pattern, you can greatly reduce the number of times a remote (and this costly) network call is made.

Is it still needed?

With EJB2 (EJB 2.0), the local interfaces to Enterprise Beans were introduced. This way, your calls from the web tier (servlet/jsp) to the EJB tier could become local (call-by-reference) invocations if the two containers were located in the same VM.
No doubt that the performance gain found in not making any remote calls is significant. Also, network traffic is reduced.

So, why still bother about the Session Façade pattern? The only advantage is brings is less code on the client, but this can be solved by introducing a simple class that contains the same business logic as the session facade would.

Well... no! There IS a big advantage that the session façade design pattern gives you, even when using local interfaces.
Keep in mind that each call to an EJB (both session and entity beans) can start a transaction. So even if you're using local interfaces, something like this piece of code can be dangereous for performance:

Employee employee = ... // retrieve Employee Entity EJB

String name = employee.getName ( );
String address = employee.getAddress ( );
String phoneNr = employee.getPhoneNr ( );

Each one of these innocent looking lines of code would start it's own transaction, and thus laying an unneeded burden on the application server.
The performance loss that is caused by this phenomenen can really be significant, but depends on the software used.

Conclusion

The Session Façade EJB Design Pattern delivers not only cleaner code, where the client only calls a single service-related method, it can also reduce the number of remote calls, transactions, security checks, etc ... which are all a consequence of the usage of EJBs.
The most important thing to learn from this is that programming EJB isn't that easy after all. Sometimes, things that look clean and simple can hide unexpected problems!