Web Applications

Web Applications

Chapter 1 outlined the concepts of MVC and gave a brief discussion of web frameworks. The main reason for that discussion was to help you understand any major web frame-

work that has come out since 2000. In this chapter, however, I want to go over two things: a more detailed review of the web server side, and an introduction to the web applica- tions used in this book.

The fundamental component of any Java web application today is the servlet. It is the common denominator, and back in the '90s many of us wrote entire applications using only servlets. In this chapter, I will quickly cover what a servlet is and then we will get into some actual web application design. You will investigate a few implementation patterns. As I cover each of these implementation patterns used in Seam, I will highlight (when appropriate) the similarities and differences as compared to the Struts framework. This will expose you to more Seam code and should prepare you for Seam coding in Chapter 5.

Three major web applications are used in this book. In this chapter, you will learn about the main applications we are going to build throughout this book.

_Servlets

Servlets are the basis for any web application written today. However, they may be one of the least known APIs for new Java developers who started their web development by using a framework such as Struts. The Java Community Process ( JCP) designed the

Servlet specification in 1997 as JSR 53. The most current version of it is defined by JSR 154

and was released in September 2005.

A Servlet object in the most basic sense allows for communication between a client and a server via the Hypertext Transfer Protocol (HTTP). The most common application of this is of course dynamic web pages, although you will find client-side applets talking to servers in the same manner as well.

The Servlet class file resides in the javax.servlet package. Because servlets are a specification and not a Sun implementation, in order to use servlets, one relies on an individual web container vendor such as JBoss (which uses Apache Tomcat) to imple-

_{ment the specification. The most common implementation of the Servlet interface is the}

²³

HttpServlet object, which is the basis for most web frameworks. HttpServlet will accept requests (HttpServletRequest), allow for a method for processing, and return a response (HttpServletResponse). In addition, it can keep track of a ServletContext and HttpSession object; I will go over that in more detail in a bit. The HttpServlet object is called by the application server and calls methods (doPost(..), doGet(..), service(..)) that then con- tain data to process the request.

Contexts in Servlets

A context represents an area where serializable objects (classes that implement java.io.Serializable) are stored. These objects differ mainly in their life cycles. Some of the objects are saved indefinitely, whereas others are around for just a short period of time. In servlets there are three contexts by default: the ServletContext context, the ServletRequest context, and the HttpSession context. Each context uses maps for storage.

ServletContext

The ServletContext context is represented by the interface javax.servlet.ServletContext, which you can retrieve with the getServletContext() method on the Servlet object A ServletContext context contains application data that is not user specific. This data can be set at any time and will be stored for as long as the server is alive. The type of data that is stored in a ServletContext context is usually something such as names of states or names of countries-items that are the same for any user and generally not too large.

ServletRequest Context

The ServletRequest context is represented by the interface javax.servlet.ServletRequest, which is passed as a parameter to the Servlet(s) processing methods. The data that is set on ServletRequest is typically tied to a response for a single round-trip to the server. A round-trip consists of a request that originates from the web page, is sent to the servlet, and is then sent back to the web page. After the web page has finished rendering, ServletRequest gets recycled. This object will store data that was sent over-for exam- ple, when you fill out a form online and submit it, the data is saved to the HttpServletRequest object.

HttpSession Context

The HttpSession context is represented by the interface javax.servlet.http.HttpSession, which is stored as a property on the HttpServletRequest interface. HttpSession is created for the user explicitly by the server-side application calling getSession() or getSession(true) on HttpServletRequest. The HttpSession data will persist across multiple

requests to the server on one connection. To understand what I mean by one connection, think of opening a web browser and connecting to a server-that represents one connec- tion to the server. Opening more browser windows will each represent new connections to the server.

The HttpSession data can be destroyed in one of three ways: by explicitly calling the invalidate() method on HttpSession, by shutting down the browser window, or by the connection timing out (which is a configurable option on HttpSession).

Closing Thoughts on Servlet Contexts

Even though all three of these contexts are extremely useful, you cannot do everything you want with them. However, they provide the basis to create other contexts that can be customized to have more functionality. Seam, in fact, uses seven contexts that are all in some ways derived from these three. I will touch on these contexts in Chapter 5 and then go into much greater depth with them in Chapters 6 and 7. For now we will stick with these three.

Servlets and Frameworks

One final thought about servlets before we go on: you can be an experienced developer and have never touched an HttpServlet object. This is because the servlet layer is where frameworks (in general) start their abstraction. So if you are a developer who started cod- ing after about 2002, odds are that you have never had to write a servlet for a job. Even if you were developing before that, you probably had just one servlet sending you some- where else (or for the most part, you should have). However, I wanted this section to give those who are not familiar with servlets a chance to review the basics.

Implementation Patterns

In this section, I am going to present some challenges that arise when designing web applications. Developers face various challenges when creating web applications. These tasks can be described through implementation patterns. For the experienced devel- oper, these patterns will seem quite familiar-for example, displaying lists and logging on to a page. For the entry-level developer, these patterns will seem new but should seem obvious if you have spent any decent amount of time surfing the Web.

Table 2-1 summarizes the patterns discussed in this section. Most of these imple- mentations will be used in this section for finding, updating, and viewing restaurants in a given zip code.

Table 2-1. Presentation Implementation Patterns

Topic Description

Displaying dynamic data We make a request to the server to get the best restaurant and save it to the request object to be displayed on the page.

Requesting and saving data We make a request to the server to get the best restaurant as in the first pattern. However, the user will then be able to change the name of the best restaurant.

Logging in The user passes in a username and password for validation.

If the user is validated, the username will be saved to the

HttpSession context.

Listing and viewing a page We display a list of restaurants. The user can then select one restaurant to view the details of it.

For each pattern, I will explain to you the task at hand and the problem we are try- ing to solve. Then I will present a standard activity diagram indicating how this issue will be solved.

I will first present the Struts implementation of it and then the Seam implementa- tion. I decided to use Struts for the examples mainly because it is simple to understand a Struts Action class even if you have no knowledge of Struts. Also, because Struts is so prevalent in the marketplace, it will either be familiar or provide helpful exposure to the majority of developers out there.

Now the thing to remember is that these are not 100 percent complete code samples. I have left out the JSPs (for Struts) and the JSF pages (for Seam). Also, for the Struts exam- ples I am not actually implementing the business class created. However, the business class will get implemented for the Seam example. This is because Seam essentially skips having to write any servlet-based class and gets you directly to the EJB3 page.

The purpose of these pages is not to give you lots of code examples to learn from, but to give you an ability to compare and contrast what the code looks like in Struts as com- pared to Seam. My hope is that you will start to gain an appreciation for Seam and some of the benefits to using it. As you read along the rest of the book, we will use these imple- mentation patterns at various points to cut down on coding time and increase the clarity of the code. So for right now just look at these patterns from an abstract point of view of how they could help you more.

Before diving into the patterns, you will take a look at brief explanations of the Struts and Seam pages that will be used in the examples.

Understanding the Parts of Our Examples

As I said, these examples are going to have two Java files for them: a Seam one and a Struts one. Because not everyone is going to understand each, I will present a crash course on each example setup.

Struts

For those of you who have never seen Struts, think of this as a crash course. If you understand a Servlet object, you will understand an Action class. The Action classes very much mimic the way a Servlet object looks. Listing 2-1 provides an example of an Action class.

Listing 2-1. An Example of a Basic Struts Class

public class GenericStrutsAction extends Action

}

A couple of these attributes should be familiar to you-HttpServletRequest and

HttpServletResponse, which we have just gone over. The other two objects will take a bit more explanation.

ActionForm is a Struts object used to represent the request data that the user has sent over. This object allows us to have a more concrete implementation that is defined in an XML file. Notice that in the method itself, ActionForm is casted to DynaActionForm. DynaActionForm is a DynaBean, which are type-safe maps. This means that in a configura- tion file, you can specify that this object is being stored as a Boolean. This is useful because all objects sent over from the browser-whether numbers or letters-are strings by default.

Finally, you have ActionMapping, which is used to look up what page to forward the next request to. This allows the user to map names to actual JSP pages. This way, if you decide to change to a different page, you can do it in the XML file instead of changing your code.

Throughout the Struts examples, I will be referring to a business service that is a global property on the Action class. You can think of this as an EJB that has been injected into the Action class. I won't provide concrete implementation of these inter- faces because what they specifically do is not important. The important thing is what the Struts page is doing and how it interacts with the business service.

Seam

Now although it may seem unfair to display a bunch of Seam pages without more expla- nation, the purpose is just to appreciate Seam's simplicity. However, I do want to make a few notes about these pages. The classes are all annotated with @Stateless, which indi- cates that these are all actual stateless session beans (SLSBs). There will be no plumbing code such as Action or Servlet classes to write; that is all handled by the framework. Also the Seam objects each implement an interface. I have not provided a concrete represen- tation of the interface, but just assume it contains the same methods that are on the Seam component itself.

Now that you have the basics underway, I'll start showing some code.

Displaying Dynamic Data

Aside from a perfectly static page of text, a page that is generated by dynamic data is probably one of the most commonly used types of pages. In this example, we have a request made to the server to find the best restaurant for an inputted zip code.

Figure 2-1 shows an activity diagram outlining the steps to take when creating this page. As you can see, after the request is made, the server will retrieve the name of the best

restaurant for display on the page. In Struts this will happen by an Action class calling a business service. Listing 2-2 provides this code.

Listing 2-2. The Struts Action for Retrieving the Best Restaurant

public class LookupRestaurantStrutsAction extends Action

}

Figure 2-1. Activity diagram of a call to a stateless page

This code is fairly straightforward, and its steps can be outlined as follows:

1. Retrieve the zip code passed as a request parameter called zipCode.

2. Use our business service to look up the best restaurant by zip code.

3. Set an attribute so we can pass back the restaurant on a request attribute called

bestRestaurant.

4. Finally, look up the success page and return to that page.

Although this is not that complex, remember that we still have to code and inject the business class for it to work, and we have basically spent this entire page setting variables to be sent over and then retrieving the variables. So now let's take a look at the Seam ver- sion of this page in Listing 2-3.

Listing 2-3. The Seam Component for Retrieving the Best Restaurant

@Stateless

@Name("restAction")

public class LookupRestaurantAction implements ILookupRestaurantAction

}

In this page we do not have to explicitly set any variables because that is done for us

by Seam through injection of the variables labeled by the annotations. Additionally, we are already in our business object, so there is no need to call anything else except maybe a database. Not only does the code look cleaner now, but we do not have to worry about the HttpRequest and HttpSession data explicitly; it is handled behind the scenes by Seam.

Requesting and Saving Data

The previous example, although somewhat trivial in problem solving, hopefully exposed you a bit to the power of using Seam over traditional Struts applications. In the following example, we will still be using our restaurant, but this time we are going to save the

restaurant's name. So you will first have to find the restaurant, and then the user can save it back to the page. This is drawn out for you in Figure 2-2.

Figure 2-2. Activity diagram of a call to a page that wants to save and validate data

Just as before, the user makes a request to the server to find the best restaurant, which is a retrieval process. Now the user can also input data and send it back to the server to save a new restaurant. Listing 2-4 shows the Struts version of this code.

Listing 2-4. The Struts Action for Retrieving and Saving the Best Restaurant

public class ChangeRestaurantStrutsAction extends Action else

}

}

Notice that I have introduced a Boolean to decide to save or update. We could have

done this instead with two separate method calls by using DispatchAction. However, for those not too familiar with Struts, I did not want to add to the code's complexity. Also, this example introduced DynaForm. The following steps indicate what the code is doing:

1. Cast the form to its instantiated type.

2. Retrieve the Boolean value to know whether this is a save or update.

3. If it is a save, perform the following:

a. Retrieve the new best restaurant name that we are going to save.

b. Retrieve the zip code we are going to save it to.

c. Save the new best restaurant based on the preceding two parameters.

d. Return to the completePage mapping.

4. If it is not a save, you request the best restaurant for the zip code by performing the following:

a. Retrieve the best restaurant by using the lookup service.

b. Save the best restaurant to the request attribute as we did before.

So as you can see, this code is a bit more complex than before, but using the form object does save some time on more-complex matters. Now let's take a look at the Seam example in Listing 2-5.

Listing 2-5. The Seam Component for Retrieving and Changing the Best Restaurant

@Stateless

@Name('changeRestAction')

public class ChangeRestaurantAction implements IChangeRestaurantAction

public String saveBestRestaurant()

}

As you can see in this example, we only had to add another method to save the restaurant, and we had to simply add another annotation to declare that the restaurant variable can be inputted as well. Quite the minimal modifications for the performance increase.

Logging In

So now that we have covered two basic examples of retrieving and saving data, we are going to go on to another common type of code-for logging in. Now there are lots of different ways to log in to a website and many authentication models to use. In fact, Chapter 8 covers some Seam-specific ways of logging in.

For this example, however, we are going to stick to a very basic authentication process: you attempt to log in with a username and password; if you are verified, your username will be saved to the session. The HttpSession object is a common object for saving login data because it will persist the entire time that you are active on the site. When you read this, do not get too worked up about this login model, but look at it as a way of saving session-related data. Figure 2-3 shows an activity diagram of what we are going to do.

This is a simple one-request run-the user either correctly inputs the username and password and continues, or is rejected to a failure page. Listing 2-6 provides the Struts version of this code.

Listing 2-6. The Struts Page for Logging In to a Website

public class LoginStrutsAction extends Action else

}

}

Figure 2-3. Activity diagram of a call that is for logging in to a page

The biggest difference between this page and the pages you have seen before is that now we are saving to the HttpSession object. Another thing to keep in mind when using Struts or any HttpSession object directly is that even if you retrieve an object from the ses- sion, you cannot just change the object but you will have to reset the attribute on the session again. The steps that this page goes through are as follows:

1. Retrieve the username.

2. Retrieve the password.

3. Call the business service to see whether this is a valid login.

4. If it is a valid login, save the username to the session and return to the

"success" page.

5. If you are not successful, forward to a "failed" page. Listing 2-7 provides the Seam version of this page.

Listing 2-7. The Seam Page for Logging In to a Website

@Stateless

@Name('loginAction')

public class LoginAction implements ILoginAction else

}

}

Again, the majority of this page should seem simple, except all we have to do is label the variable to describe that the object is exposed to HttpSession. You will notice that this code is clean, and once again the amount of code is less. Furthermore, we are even in the business service already!

Listing and Viewing a Page

For our final example, I am going to show off one my favorite features with Seam: its ability to display lists and retrieve them. For this example, we are going to access a page with a list of restaurants. The user then has the ability to click on any of the restaurants and retrieve detailed information about it. Figure 2-4 shows the activity diagram for

our request.

This type of request is fairly standard with web operations. Listing 2-8 shows how we perform this with Struts.

Listing 2-8. The Struts Action for Displaying a List and Retrieving a Specific Restaurant

public class ListOfRestaurantStrutsAction extends Action

return mapping.findForward('success');

}

}