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.

Collection FrameWork

A collection is simply an object that groups multiple elements into a single unit. Collections are used to store, retrieve, manipulate, and communicate aggregate data.

• HashMap :- Hash table based implementation of the Map interface.

• Permits null values and the null key.
• It is unsynchronized.
• This class makes no guarantees as to the order of the map.
• Since it is unsynchronized to make synchronized use following

     Map m = Collections.synchronizedMap(new HashMap(...));

• HashTable :
  
• Null vaule and Key not allowed.
• To successfully store and retrieve objects from a hashtable, the objects used as keys must implement the hashCode method and the equals method.
• Hashtable is synchronized.

• Comparable and Comparator :- An implementation of the Comparable interface allows the user to create a specific strategy to compare with another object(which should be mutually comparable).The Comparator on the other hand doesn't tie you with a single comparison strategy.
• Comparable interface has “compareTo” method which is normally used for natural ordering but Comparator interface has “compare” method which takes two arguments. It can be used where you want to sort objects based of more then one parameter.
• The java.util.Collections class has an overloaded sort method(i.e. other than sort(List) that accepts a List and a Comparator as an argument.
• Sample Code :-
  

• 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

  public class Employee implements Comparable { private String name; private int age; public Employee(String name, int age) { this.name = name; this.age = age; } public int compareTo(Employee e) { //Write the code for sort. } }

  
  

  1 2 3 4 5 6 7 8 9 10 11 12 13

  public class Main { public static void main(String[] args) { List employeeList = new ArrayList(); employeeList.add( new Employee("Ranga", 10) ); employeeList.add( new Employee("Madhu", 11) ); employeeList.add( new Employee("Babu", 12) ); Collections.sort(employeeList); }

• Vector and ArrayList
  

• Arraylist is not synchronized while vector is.
• Arraylist has no default size while vector has a default size of 10.
• Arraylist don't define any increment size while vector does.
• Arraylist can be seen directly without any iterator while vector requires an iterator to display all it's content. (not very sure).
• Sometimes Vector is better; sometimes ArrayList is better. Chose based on your requirement. If u don't need thread-safe collection, then use the ArrayList.
  
• A Vector defaults to doubling the size of its array, while the ArrayList increases its array size by 50 percent. Depending on how you use these classes, you could end up taking a large performance hit while adding new elements. Vector does possess a slight advantage since you can set the increment value.
• Traversing an ArrayList is since you can simply use an index instead of having to create an iterator.