Enterprise Design Patterns
Posted April 17, 2009on:
Enterprise Design Patterns
If you are the beginner of the web application development you are the lucky. Because someone has already done this work for you. Using J2EE-specification and other design patterns you can simplify your code and your life. And the most significant design patterns for web application, MVC, even has wildly popular framework like Struts, Spring, rails that will help you craft a flexible, maintainable, extensible your application.
Designing and building a J2EE application is challenging proposition to say the least because a J2EE application distributes processing across multiple tiers, each consisting of many components, some of which reside on different JVM.
Over time and through trial and error, J2EE developers have come with the best way to solve complex J2EE programming problems. These techniques are called patters.
“A pattern is a proven technology that is used to develop an efficient J2EE application.”
“A repeatable solution for commonly occurring software problem.”
Professional developer use patterns to avoid making common mistakes when designing and building a J2EE application.
• Web Application Server configuration get complicated
In the real world, If your web application became popular at the time, and your application get thousand of request per hour, per day, It will not easy to handle with normal server. Then your hardware configuration became quite complex. A common architecture was quite familiar to all developer which is configuring hardware in tiers functionality. Adding more server and computer to tier is known as horizontal scaling, and it is best way to increase output your web application. As we know most of the web application lives in either the “Web tier” or the “Business tier”.
As web application developer we have already know our web application to be made up many different kinds of software components. The web tire frequently contains HTML pages, JSPs, Servlet, controller, model components, images, and so on. The business tire contains EJBs, legacy application, lookup registries, and most case database driver, and databases. Luckily we have J2EE patterns, these design patterns have been used, tested, and refined by other developers, so that you can don’t have to work out on it.
When we are developing any large scale we application the most important job is to provide the end user with a reliable, useful, and correct experience. In other words, the application must satisfy the functional requirements, and requirement for what happens behind the scenes, I mean the requirement which is not functional.
There are so many non-functional requirements we have to take into consideration and those are,
- Re usability
• Design Principles
As we know patterns also follows design principles which makes patterns to easy and satisfied functional and non-functional requirement with web application. We keep in mind some of design patterns when we are developing web application.
- High Cohesion
Cohesion means degree to which a class is design for one, task or purpose.
- Hide complexity
Design your application component in such a manner, that one component hide the complexity of another component.
- Use interfaces
As we know interface is kind of contract between two objects. Another main benefit of interface is polymorphism. Many classes implement the same class and just override the method and use it.
- Loose Coupling
As we know OOPs concept making object of one class just get the property of another class and get the access of another class. So design your class in such a manner that one class not depend another class for perform the class functionality. So design your class which take away which another class.
Declarative control over the web application is a powerful feature of J2EE containers. We can implement it using our deployment descriptor web.xml file in our web application. Modifying the DD gives us power to change the behavior of application without changing the code. The DD is Xml file that can de maintain and update by non-programmer.
• How web application sprint
Ok, before we move ahead for more details of design patterns let’s get some basic idea how web application works when we use MVC architecture, run on a single JVM.
As we all know MVC mainly stands for Model-View-Controller and I give you brief introduction how it works when any request comes from the client. First of all when user hit request from the browser controller get request, according to mapping logic at controller it send control to model. Model mainly contains business logic for web-application and that models connect to the database and get record according to requirement and business logic at model component. Now as per result from database the model set that result to simple bean (POJO- Plain old java object) class. And then again controller set that bean reference to the request object and controller pass the control to the view component. Now the view (jsp, servlet, freemarker) get the control from the controller and get reference to the bean object set by controller. Then view use EL (Expression language), scriplets, JSTL and gets the bean property and displays it to as a presentation.
Again that is for web-applications those run on single JVM.
Then what when if our web-application business logic or model component on another Physical machine or say another JVM and our view and controller on another JVM. That means our application distributed and all the object communicate to each other through network. Now the question is how to handle application run on different JVM. Then JNDI (Java Naming and Directory Interface) and RMI (Remote Method Invocation) comes into the picture for communicate our application object or available object to the network. Both work like a directory which contains list of objects and object details, for communicate across the whole network. Those object we need across network simply we have to register with JNDI and RMI directory. If we want to access those object then application first look up JNDI and RMI directory and get the reference of that object and use it with application, so that way our object communicate across network when our application runs on different JVM.
So, as I told you that RMI and JNDI handle all the complexity like they handle complex networking communication, I/O performance, serialization and deserialization. Think about it when your application get distributed or say your model and view, controller on different JVM.
Patterns are grouped into a collection called a pattern catalog, which you can reference whenever you are designating a J2EE application. The pattern catalog contains many patterns that you will find benefit at your application.
• Model view controller
• Business delegates
• Front controller
• Filter intercepting
• Zero Sum Pattern
• Status Flag Pattern
• Sequencer Pattern
• Transfer Object
• Service locator
• Consolidator Pattern
• Simplicity Pattern
• Stealth Pattern
There are also some patterns available for J2EE but I think that are mostly usable. As I describe above two scenario for web application one for all component on same JVM and other where your component are distributed or say different JVM. So, first we discuss patterns which is related to component are distributed or different JVM. There are three patterns for that scenario.
Patterns use when application component on different JVM.
• Business delegates
• Service locator
• Transfer Object
So, first I explain basic of this three J2EE patterns what I understand about this patterns. JNDI and RMI both use in all these three patterns.
So, when your components are on different JVM, then your business developer registered their model component to JNDI service. When controller get request, the controller code does a JNDI lookup to get object for remote model service. The controller makes business method calls against the object just as actual model object itself. That is the basic scenario when component on different JVM. But as we know controller mainly use for pass request from model and model to view. But in this situation controller makes complex business logic which is use for JNDI lookup. That is not good for the application. In this case all three patterns are comes. First we discuss business delegates. That business delegates is object for the controller to talk to rather than having the controller deal directly with the remoteness of the remote model.
1) Hide the complexity of JNDI lookup.
2) Hide remoteness complexity.
So, rather controller communicate with JNDI lookup or model one more object make layer between controller and model component which handle all complexity and hide to controller.
But in these patterns we have to create more than one business delegate for every request. That business delegates contains duplicate code for JNDI look up business logic. That is again not good for our application. Then a Service locator pattern comes.
Unless your business delegates use a service Locator, and that Service Locator will have duplicate code for dealing with the lookup service. To implement Service Locator, we will take all logic for doing the JNDI lookup and move it out of multiple Business Delegates and into a single Service Locator.
1) By making the business delegates an object that handless only the business methods rather than also handling JNDI registry look up and that will increase the cohesion for the business delegates.
2) Again it hides the complexity of JND lookup for business delegates.
3) We can also create service locator catch and that optional cache can reduce network calls.
We talk, that is about only controller. By using business delegates and service locator patterns, we have got only controller protect from the complexity of remote model components. So, what about view part or how to protecting the web designer’s JSPs from remote model complexity. Business delegates also create remote stub for the JSPs and that jsp use EL expression to get data from the that stub, but that is actual remote object each time it calls getter of the remote object and makes network call massive. Which over load on server. And the JSP is not good to hide the exception that might occur if the remote server crashed.
So, over rule that situation Transfer Object use. Actually Transfer Object is pass from the remote model server as serialize form and pass to client’s local JVM heap, their serialize object deseralize and use as local object. That objects only simple POJO class which contains populated data from the database. And JSPs use el expression and use to display at view.
1) It basically reduce the Network traffic
2) Reduce coupling between tires.
3) Can follow java bean convention so that it can be easily access by another object.
MVC (Model view controller)
As, we all know about MVC so, I am not going to explain it details.
1) MODEL holds the real business logic and the state. In other words, it knows the rules for getting, updating, selecting and deleting state. It is the only part of the application that talks to the database.
2) CONTROLLER takes user input from the request and interprets what it means. Then it talk to
model and give command to update model, makes the model state available for the view and
forward to the JSPs.
3) VIEW responsible for the presentation. It get the state of the model from the controller as a request form and then JSPs get the all requested parameters and use according to display at user browser side.
1) View can change independently from controller and model.
2) Model component hide internal details, from the view and controller component.
3) Increase reusability of model component.
4) Separation of model code from controller code allows for easier migration to using remote business component.
But, in MVC there will be corresponding set of model, view and controller component. But, in this case our application with duplicate code across the entire different controller, and didn’t give us a happy feeling about maintainability and flexibility.
So, all developer have question now how to improving the MVC controller. Beside a lack of cohesiveness, the controller also tightly couple to the model and view component.
Now, we can achieve this goal using front controller patterns. Now all well known framework like Struts, spring all work on front controller patterns. The basic idea of the front controller patterns is that a single component, usually a servlet but possibly a JSP, act as a single control point for the presentation tier of a web application. With this patterns all the request of the web application pass through a single controller, which handles dispatching the request to the appropriate places.
1) Centralize a web application’s initial request handing tasks in a single component.
2) Using front controller with other patterns provide loose coupling.
3) Decrease over all complexity of application.
4) Increase maintainability of application.
There is only one way to intercept you request or response and that is using Filter. Use the intercepting filter pattern to modify request being sent to servlet, or to modify response being sent to user.
1) We can intercept and/or modify request or response before they reach the servlet or to the client.
2) Filters are modular so that they can be executing in chains.
3) Declarative control allows filters to be easily implemented on either a temporary or permanent basis.
The objective of the handle-forward pattern is to create a handle or forward model infrastructure whereby a request is passed from one component to another component until the request reaches the component that can fulfill the request. The handle forward pattern is ideally suited for an application that implements an approval process such as when an order is received from a client. A company might refrain from processing the order until certain approvals are given and so on. Each approval process applies different routines and is likely to be contained within different components.
1) This pattern simplifies the request for service that is made by an application because the requests are always made to one component.
2) The application makes fewer requests for service, which decrease the overhead.
3) Last major advantage flexibility.
Zero Sum Pattern
Zero sum patterns is to treat a group of independent processes as a single processing until that collectively can succeed or fail. The until succeeds only if all processes within the until terminate successfully. However, the until fails if even one process fail. This mean that successfully terminated processes must be reversed whenever a process fails. This pattern is ideally use for any type of transaction processing that has multiple coordinated but independent component used to complete transaction processing.
1) Easy to maintain and coordinate the activities of independent components by using one component the processing controller component.
And many more patterns are available.
SCJP 1.5, SCWCD 1.5
Enterprise Design Patterns
Configuring an Application with a Deployment Descriptor