Choice is a good thing. But sometimes we are overwhelmed with too many of them. In selecting a framework for Web applications, we are confronted with a wide variety of frameworks, application servers, SDKs, libraries, etc. It can even be hard to figure out what belongs to a particular category and what the differences between them are. Making a decision in the J2EE environment is especially hard. Every time I search the Net, I seem to come across yet another framework I've never heard of.
In such a scenario, the tendency is to select a framework based on brand, popularity or familiarity. Exploring and evaluating the options is just not viable. We understand that the motivation behind each option is to simplify development. The war cry, 'DRY' (don't repeat yourself) of Ruby on Rails, perhaps best describes the intention. Hence, to a certain extent, we choose any framework to save us effort. But the concern remains-why are there so many options?

•We have multiple implementations conforming to the same standards. This is a good option because it is easy to substitute one for the other with only configuration differences and no programming changes needed.
•We have solutions to problems for which no standards exist.
•We have solutions that intentionally go against the standards, because developers believe that standards are unduly complex. These will, in general, co-exist with solutions based on standards.
The net effect is:
•Some frameworks are interchangeable
•Some frameworks add functionality to existing frameworks
•Some frameworks co-exist with other frameworks, solving similar problems.
If the choice of frameworks is bad enough, the combination of frameworks, which can reasonably solve a problem, is truly mind-boggling. Hence, rather than looking at various frameworks and what each one does, it is desirable to look at the fundamentals and look at the problems that are being addressed. Using an example helps. We will choose TurboGears, a Python-based framework, because it is composed of multiple projects, each addressing a well-defined need and each conceptually distinct from the other. The boundaries of the alternatives in the Java environment are often not as we]] defined. We will give some names by selecting the primary problem domain of the framework.

The basic problem We have people using a variety of Web browsers communicating with a Web server, which will need to deliver dynamic content. The first problem we need to resolve relates to the Web server. It must accept a request from a client and deliver the response to the same client. We as developers do not wish to be concerned about the protocol and the low-level issues associated with this task. A Web server like Apache will do this job very well except for the dynamic content. The burden of handling CGl scripts will fall on the programmer. So, our Web server must also be able to handle requests for dynamic content easily. It must be a 'container' for the server-side code. In TurboGears, these tasks are performed by CherryPy.

There must also be a way to map the request coming from a client to the code in the server, which needs to be Insight Developersl executed. This is often accomplished by XML configuration riles. The increasingly preferred option now is to use conventions instead of configurations. This is because the Web applications have become very complex and maintaining the necessary configuration flies becomes a pain. Unless conventions are fo]]owed, trying to figure out what went wrong and why, can be very difficult for programmers, especially if they did not write the affected code.

A key aspect in selecting the Web server will be looking at the way the URLs are mapped to the servlets, keeping in mind that flexibility is not necessarily a good thing. Another issue will be integrating the Web server with, say, Apache, and the volume of transactions it can handle.

In the Java world, the open source options include Tomcat, Jetty and Resin.
The response to the client Let's look at a He]]o World example in CherryPy.
This will return the expected string. If we wanted to send a formatted HTML page, the code for the HelloWorld class will look like what's shown below:
</HEAD>
<BODY LANG="en-US" DIR="LTR"> <P>Hello World'</P>
</BODY> </HTML> The readability of the code goes down by several orders of magnitude. The mixing of HTML and Python like syntax creates a mess. A solution is obvious. Let us reIactor the code and see where it leads us.

•The HTML page will need dynamic data. So, we will pass the data to the method that will construct the HTML page and return it.

•All pages will have a look and feel, created by a designer. We can have the designer create an HTML page with placeholders for the dynamic data, that is, a template. We pass the template and the dynamic data to our method.
•Why not use a readymade template engine?
TurboGears uses KlD as the templating engine. It
is Pythonic. [n the Java world, the common templating engines are Velocity and Freemarker, which surprisingly, are not commonly used!
There is an alternate to the messy code problem. In the early days of the Web, most of the HTML pages were tagged with only a part of the page containing dynamic data. Hence, a natural approach was to create a language, which used tags like HTML, but allowed flexibility of a programming language. This approach has been immensely successful with PHP. Java followed a similar model and created JSp'
The Struts 2 J2EE framework uses Freemarker templates internally, but allows you to use JSP, Velocity or Freemarker to create the HTML pages. If the project had compelled organisations to switch from JSP, it would have doomed the framework to oblivion!

So, the second solution the frameworks are trying to evolve is a convenient way to present the information to the user. The layout will have inputs from the designers. Evaluation should seriously look into the implications of designers changing page layouts and its impact on development.

How does the client interact with the application? Web 2.0 has added to the difficulty of \vriting Web applications. Users expect to interact with the Web application almost as if it were a desktop application. This is made feasible by the technologies known as AJAX. The code to achieve this goal is actually running on the client. Hence, the key component of this technology is actually Javascript. TurboGears uses the MochiKit library to provide rich client interfaces. A wide variety of options are available like DOJO, Prototype and YUL In the Java world, it is worth looking at GWT and Echo options as well, as one can code in Java, and the appropriate Javascript code will be generated by the toolkit.
Options in the Java world include Ajax4jsf/RichFaces.

Frameworks like Struts 2 and Seam support the creation of rich client interfaces.
The integration of the client-side Javascript code with the server side code is currently evolving. How transparent should such integration be is debatable. At least a few people feel that programmers should use Javascript, and relying on framework 'helpers' is a bad idea (see James Bennet's blog The B-List: Entries on July 2, 2006 django-and-ajaxl) .

Persistent objects

FinaLly, all the work the user does has to be saved somewhere. We come to the Model part of the MVC pattern. We would Like to be able to work with and manipulate data as objects and not have to worry too much about the database hidden behind this layer. Since the common databases are relational, we are looking at object relational mapping (aRM). Turbogears uses SQL Object for aRM, which uses the Active Record pattern. Ruby on Rails also uses the Active Record pattern. In the Java world, the most common aRM is Hibernate and, now, EJB3.

Earlier versions of EJB were quite complex to use. This resulted in attempts to create frameworks that were easier to use but still allowed the business data model to be separated from the rest of the application. A successful example of this is Spring.

Working with a Web page does not depend upon the technologies being used on the server. Web services make it easy for us to work with different applications. Hence, it is possible for us to choose a framework based on the need and appropriateness for the problem under consideration. We are not trying to suggest that we should have a zoo of application frameworks on our server, but that we do not have to stick to a decision made earlier if better options are available.

The conventional configuration approach of Rails, Django, and TurboGears, and the advantages of the agility available by using scripting languages have also appealed
to many people who are using Java and J2EE frameworks. It is possible to run simple Rails applications using JRuby. Users are experimenting with running Django, TurboGears and Pylons using Jython. Another promising entry is Grails, a Rails clone built using Groovy and on top of existing J2EE frameworks like Spring and Hibernate.
The choice is about to get wider; but it is defmitely worth exploring and adopting one of these frameworks for, at least, the less frequently used application components and get more features for the same effort. What more can one want