Chapter 1: Getting Started

In this chapter:

1. You will learn about Model1 and Model 2 (MVC) and their differences

2. You will understand the shortcomings of Model 1

3. You will understand the problems with Model 2 ‚ The Fat Controller Anti pattern

4. You will learn how to overcome the problems in Model 2 by using Model 2 with a configurable controller

5. You will see how Struts fill the gap by providing the configurable controller and much more to boost developer productivity

6. You will look at installing Tomcat and Struts on your computer

What is Struts?

Struts is a Java MVC framework for building JSP based web applications on the J2EE platform.

That ‚ s it! As you can see, a whole lot of buzzwords appear in the above sentence. In this chapter let us dissect this sentence word by word to get a complete picture of what Struts is and why it is required. Struts is primarily used in JSP based web applications, but you can use it in template based (non-JSP) web applications such as Velocity. Although you know how to develop and deploy J2EE web applications, let us start with a quick overview of J2EE and JSP before moving on to more interesting buzzwords in the above sentence.

J2EE Platform

As you might be already knowing, J2EE is a platform for executing server side Java applications. Before J2EE was born, server side Java applications were written using proprietary vendor APIs. Since each vendor has unique APIs and architectures, developers and architects could not reuse the lessons learnt in the trenches. There was also a huge learning curve (and hence cost) for Java developers and architects to learn and program with each of these API sets. Consequently the entire Java developer community would be fragmented into islands isolated and stunted thus making it next to impossible to build serious enterprise applications in Java.

Fortunately the introduction of J2EE and its adoption by the vendors has resulted in standardization of its APIs thus reducing the learning curve for server side Java developers. J2EE specification defines a whole lot of interfaces and a few classes. Vendors (like BEA and IBM for instance) have provided implementations for these interfaces thus creating application servers, as they are called adhering to the J2EE specifications.

The J2EE application servers provide the infrastructure services such as threading, pooling and transaction management out of the box. The application developers can now concentrate on implementing business logic and user interfaces that are important for the business.

J2EE specification defines containers for managing the lifecycle of server side components . There are two types of containers - Servlet containers and EJB containers. Servlet containers manage the lifecycle of web applications and EJB containers manage the lifecycle of EJBs.

J2EE web application

Any web application that runs in the servlet container is called a J2EE web application. The servlet container implements the Servlet and JSP specification. It provides various entry points for handling the request originating from a web browser. There are three entry points for the browser into the J2EE web application - Servlet, JSP and Filter. You can create your own Servlets by extending the javax.servlet.http.HttpServlet class and implementing the doGet() and doPost() method. You can create JSPs simply by creating a text file containing JSP markup tags. You can create Filters by implementing the javax.servlet.Filter interface.

The servlet container becomes aware of Servlets and Filters when they are declared in a special file called web.xml . A J2EE web application has exactly one web.xml file. The web application is deployed into the servlet container by bundling it in zipped archive called Web ARchive ‚ commonly referred to as WAR file.

JSPs

JSPs are servlets in disguise! So, if JSPs are servlets, why do you need JSPs anyway? The answer lies in the separation of concerns that exist in real J2EE projects. Back in the days when JSPs didn ‚ t exist, servlets were all that you had to build J2EE web applications. They handled requests from the browser, invoked middle tier business logic and rendered responses in HTML to the browser. Now that ‚ s a problem. A Servlet is a Java class coded by Java programmers. It is okay to handle browser requests and have business and presentation logic in the servlets since that is where they belong. HTML formatting and rendering is the concern of page author who most likely does not know Java. So, the question arises, how to separate these two concerns intermingled in Servlets? JSPs are the answer to this dilemma.

The philosophy behind JSP is that the page authors know HTML. HTML is a markup language. Hence learning a few more markup tags will not cause a paradigm shift for the page authors. At least it is much easier than learning Java and OO! JSP provides some standard tags and java programmers can provide custom tags. Page authors can write server side pages by mixing HTML markup and JSP tags. Such server side pages are called JSPs. JSPs are called server side pages because it is the servlet container that interprets them to generate HTML. The generated HTML is sent to the client browser.

We just said JSPs are server side pages. Server side pages in other languages are parsed every time they are accessed and hence expensive. In J2EE, the expensive parsing is replaced by generating Java class from the JSP. The first time a JSP is accessed, its contents are parsed and equivalent Java class is generated and subsequent accesses are fast as a snap. Here is some twist to the story. The Java classes that are generated by parsing JSPs are nothing but Servlets! In other words, every JSP is parsed at runtime (or precompiled) to generate Servlet classes.

Presentation Logic and Business Logic ‚ What ‚ s the difference?

The term Business Logic refers to the middle tier logic ‚ the core of the system usually implemented as Session EJBs. The code that controls the JSP navigation, handles user inputs and invokes appropriate business logic is referred to as Presentation Logic. The actual JSP ‚ the front end to the user contains html and custom tags to render the page and as less logic as possible. A rule of thumb is the dumber the JSP gets, the easier it is to maintain. In reality however, some of the presentation logic percolates to the actual JSP making it tough to draw a line between the two.