J2EE Patterns - Why Back | TOC

Why do we need J2EE Patterns?

An application I worked on required that I connect to a web server from a mobile application as well as from a standard web browser. On the web server I have a servlet to process requests from the clients - in this case the client can be a web browser or the mobile device. The servlet therefore must figure out upfront where the request came from so as to forward it to the appropriate request handler. The servlet also needs to format the response so the client receives it in a format suitable for display. 

How does the servlet do it? The servlet checks the HTTP_USER_AGENT to make the choice, and based on the result passes the request to the appropriate handler. The response is generated and similarly returned to the requesting client after due formatting and or encoding as required. All this is of course hand-crafted and only the developer who did this knows how the mechanism works.

This is a frequent requirement of web-based applications where the web server serves a variety of clients. You also probably have a need to check whether the client needs to be authenticated, or has a session running. You may also need to log requests per user, and a host of other things that you need to do before passing on the request to the handler object.

It is clear that there are actually three steps involved in the whole request-response operation:

This is common to all web-based applications, and the server program invariably goes through these scenarios in every request-response. Is there a standard uniform way to code these situations so that a variety of clients may be handled easily without too much hacking into existing code? Now this is a common situation faced by many developers across the globe, and there is no point in doing the same thing differently if the goal is same. When there is a clean separation of concerns in processing a request, you get code that is easily managed, with centralized control. This is where we identify a pattern. 

The pattern therefore is a description of a problem in context and consists of a solution to that problem. The pattern documentation describes the problem as well as a solution together with its benefits and constraints if any. When you code according to a documented pattern, you get code that is easily understood by newcomers who can maintain the system without having to figure out how the mechanism works. This of course is possible only when developers become pattern-literate.

Sun Java Center, the technology consulting wing of Sun Microsystems, documented patterns for enterprise computing and released them in the form of a catalog. In the words of Sun, "...The Sun Java Center consulting organization brings together application architecture services, Java technology expertise, and best practices and methodologies in software design and development". The patterns are designed to benefit the programmers, and provide a standard mechanism to handle operations that are typical in enterprise application development. They ease the development process and at the same time help build scalability and extensibility into the application by reducing the coupling among collaborating objects.