This chapter is from the book
This chapter is from the book
This chapter is from the book
Tomcat 5 Resources
Very few of us are going to run Tomcat in isolation. Yes, for getting a quick application up on a laptop, we might, but for most work, we at least need some sort of database connectivity, an email mechanism, and possibly hooks into a Lightweight Directory Access Protocol (LDAP) server or other authentication mechanism. We often call these things resources. But many other things are called resources. It is an oft-used term that can, depending on the context, mean just about anything related to the subject. When I first got started in developing complex Web applications, I was more than a little confused by the meaning of the term. In fact, very few of the terms we so easily throw around are well explained. So let's start with some definitions, which will serve us for the rest of the book.
Definitions
At the risk of being obvious, I want to clearly define a number of things, starting with the term Web application. What is a Web application? After all, this book is about writing and deploying these beasts, so we should have a clear idea of what we are talking about! Let me first, then, define a Web application as a package of functions whose job it is to provide responses to Web clients for a defined set of URLs. In other words, a Web application is configured to respond to one or more URLs, and deliver responses, depending on the requests. These responses usually return data or content, such as the content on a page showing the products a company sells. Typically, the primary function of a Web application is to return some sort of HTML data to the Web client, usually a browser. But what makes a Web application dynamic is that it can do other things besides serve content: it can perform certain tasks, such as inserting data into a database, authorizing a charge on a credit card, or sending an email.
With this understanding of what a Web application is, you can now look at what makes up a Web application. Broadly, I can define four types of things that make up a Web application. They appear in Figure 3.3.
){kind=small}
Figure 3.3 Web application contents.
First, a Web application has data—the data you write in your HTML files or put in your database. Second, it has logic, encapsulated in some programming language and executed to perform some task, including simply returning data to the client. Third, a Web application has a context—the environment in which it operates. This context or environment provides various parameters that might or might not affect the operation of the application itself. Finally, the application can have services that it requires to function, services that can either be within its environment or outside of it. In our case, the kinds of Web applications we are using are called J2EE Web applications because they use Java to generate the content.
Now, I can finally define a resource. Unfortunately, the term is often used to refer to all components of an application, such as static data files, class files, environment parameters, and external services. Because I like precision, I am going to limit my strict definition of a resource to a service on which Web applications depend. To make it clear, I refer to these resources as service resources. Thus, with this definition, a database server, LDAP server, email server, authentication mechanism, and so forth are all examples of service resources. The key factor is that these services are all outside of the Web application.
When a J2EE Web application runs inside a container, like Tomcat, that container provides various services to the Web application. For one thing, Tomcat loads the Web application, runs it, handles the TCP/IP communication with clients, and transports requests and responses between the clients and the application. In addition, Tomcat can read static files (HTML files, images, Cascading Style Sheets [CSS] files, and so on) and return the contents to the client. Tomcat can read JSPs, turn them into Java files, compile them, and execute them on behalf of the application. These tasks are indeed useful because it saves the application from having to do them. When it comes to resources, Tomcat is also a great friend to the Web application because it can make service resources available to it. These services can either be internal to Tomcat or external, in which case Tomcat handles the connectivity.
In Chapter 21, "Administering JNDI Resources," I talk about configuring Tomcat for various kinds of resources, but in this chapter, I'm only focusing on database resources. What we will do is create a JSP page that takes some data from a database table and presents it in HTML to the client. We'll keep things simple and just create a two-column table to hold a list of useful Tomcat-related URLs and their descriptions.
So we have four tasks ahead of us:
Install a database server and start it.
Create a database containing a single table populated with some data.
Configure Tomcat to maintain a pool of database connections.
Create a JSP page to access your table using a Tomcat-provided database connection.
In this chapter, I use a MySQL database. If you want, you can use any database server of your choosing as long as you can get the Java drivers for it and you make any necessary changes to the syntax of my examples.