J2EE Design Patterns

Design Patterns are the best practice solutions to common recurring problems.

Some of the well known Design Patterns.

• Session Facade
• Mesage Facade

Session Facade

Problem description: - In J2EE environment there are some problems arise, There is direct dependence between the client and Business objects, Too many method invocations between client and server leads to network performance problems., Lack of uniform client access strategy, exposing business objects to misuse
Solution: - Use a session bean as a facade to encapsulate the complexity of interactions between the business objects participating in a workflow. The Session Facade manages the business objects, and provides a uniform coarse-grained service access layer to clients. The Session Facade abstracts the underlying business object interactions and provides a service layer that exposes only the required interfaces. The Session Facade manages the interactions between the business data and business service objects that participate in the workflow, and it encapsulates the business logic associated with the requirements.

• When implementing the Session Facade, you must first decide whether the facade session bean is a stateful or a stateless session bean. Base this decision on the business process that the Session Facade is modeling.
• A business process that needs only one method call to complete the service is a nonconversational business process. Such processes are suitably implemented using a stateless session bean.
• A business process that needs multiple method calls to complete the service is a conversational business process. The conversational state must be saved between each client method invocation. In this scenario, a stateful session bean may be a more suitable approach for implementing the Session Facade.
  

Message Facade

Problem:- Session bean and entity bean methods execute synchronously that means the method caller has to wait till a value is returned. In some situations like sending hundred's of mails or firing a batch process or updating processes, the client does not have to bother about return value. If you use synchronous session and entity beans in such situations, they take a long time to process methods and clients have to wait till the method returns a value.

Solution: - To avoid blocking of a client, use asynchronous message driven beans, so that client does not have to wait for a return value. If a client uses asynchronous messaging then the client need not wait for a return value but can continue its flow of execution after sending the message.
Here the client sends a message to JMS server, gets acknowledgement from the JMS server immediately in two step process and continues it's flow of execution. Whereas JMS server delivers the messages to Message driven bean (Message Facade) without blocking client's execution and Message driven bean executes messages. You can use normal JMS consumers instead of Message driven beans. This process improves performance by reducing the client's blocking time considerably.