EJB – Architectural Patterns – Session Facade

Session Facade – The most commonly used of all EJB Design Pattern. This Design Pattern is almost mandatory for all EJB Application.

This approach is somehow the most generic form of design consideration, its basically putting another layer of service abstraction on the model side that will handle client request. The abstracted layer is formed to support the application’s use case scenario. How about an example of a bank withdraw and transfer use case:

The user tries to withdraw money from Account 1 and Transfer money to Account 2.

Sequence Diagram without Session Facade on the Model Layer:

This seem to be a fine process right? We’re actually calling the model from the controller.

Well, MVC really is a good thing to consider, the overall picture suggest that we are actually seperating each layers concern – view for the presentation, controller for the servlets, model for database transactions.

Yet that’s just 50% of the actual architecture problem we solved. How about considering: Network overhead? poor concurrency? tight coupling? reusability? maintainbility? development practice? How will these problems affect the users transaction?

Network Overhead problem: We are actually calling each functionality from the model one at a time on the servlet level (client side), we are passing data through the network each time a person logs in with a valid credentials). You called more than 1 functionality over the network for a use case, now what if I have 5000 users simultaneously logs in?

Poor Concurrency Problem: What if one of the processes / transactions from the servlet broke down? What if the network was out right in the middle of the process?

Tight coupling Problem: The servlet is actually calling the bean, what if there are changes to the bean in the future? We might need to change client as well if these happens right? – and that’s not good.

Reusability Problem: What if a future functionality needs the user validation process? How do we re-use the existing functionality?

Maintainability Problem: Since we put all our model calls on the servlet, we need to implement a transaction API on it (commit and rollback process). Would it be much more easier if we implement a new layer for this so that we can tweak them without affecting business cases on the client side?

Development Practice Problem: Sure we did put the model calls on the servlet, yet the actual business logic is still in the controller, thus development roles (jsp/servlet and ejb developers) separation will not be as easy as it could be.

MVC alone will just give you the overall separation for each layers, yet that only solves coupling between layers (and possibly not so losely). We still need to improve our architectural structure to solve recurring problems (above) on Enterprise Application Development.

Session Facade solves these problems by creating a new layer of abstraction in-between the Controller and Model, to wrap business cases and hide actual implementation calls. This process will clearly separate our client from the model.

Sequence Diagram with BankTeller SessionBean (Facade).

Obviously, Enterprise Software applications has different business process and rules to support. Using Session Facade approach, developers can wrap functionalities from use cases and create Session Beans to support each (Maybe, investment fund or loan services?).

Alright, so what did putting another layer yield’s to our application development? Obviously:

Lower Network Overhead: Since we are now just throwing one request for multiple process, we actually minimized the network overhead.

Concurrency: Since we are calling the bean only once, concurrency issues will be minimized. Transactions will now be placed on an independent layer thus can be more controlled and contained.

Low Coupling: We have separated the client from the model by putting another layer in between. this gives flexbility to the application when a large functionality will be implemented.

Re-usability: Since we wrap a certain process in a Session Facade, we can re-use that facade for future functionalities.

Maintainability: Separation brings maintainability across layers, its far more easier to maintain a layered application since developers can clearly see the overall picture.

The Session Facade is a mandatory design pattern in EJB development. Its the most basic form of enterprise software development pattern that will clearly solve many recurring issues. The separation obviously is the key to its long standing approach and the concept of “one request for multiple process” clearly helps Networking Overhead issues.

Reference: EJB Design Patterns by Floyd Marinescu