Learn about the limitations of Tomcat and how a typical enterprise environment is set up.
Does your Tomcat installation need to be a single server in a development environment only? Isn't that quite limiting? Yes, it is, as a matter of fact! Tomcat has actually been downloaded millions of times, and it successfully runs many well-known Web sites in production environments. However, it has its limitations.
Commercial software products—particularly, IBM WebSphere Application Server—are available that are far superior for a production environment, mainly because of full J2EE compliance, additional functionality, and security. If you're looking to implement Tomcat in a fully functional production environment, you can still use this tutorial to build your foundation.
The enterprise architecture shown in Figure 1 is a more or less accurate description of what you may see behind the scenes when you press Enter in your browser. The architecture consists of recurring elements that I have seen working for clients around the nation, including multi-million dollar mission-critical applications at IBM and the United States Air Force. The sections that follow expand on each area in Figure 1.
Figure 1. Example enterprise architecture
Typically, there are guards to your network—routers or firewalls, then proxy servers (reverse proxy, to be specific) that match up the Web request with the appropriate domain. There may be a level of authentication and even authorization at the front-end IBM Tivoli® Access Manager (TAM)/TAM WebSEAL server level before the request even hits the first server in your network, which will likely be protected by a demilitarized zone (DMZ).
Next are the Web servers. Note that all these servers likely have vertical and horizontal failover, meaning separate hardware at each level that is cloned and possibly even duplicated at the software level. When your Web server passes the Web request and does its job of serving up the static content, you may have another layer of network dispatchers (NDs) or at the very least, a plug-in (such as the IBM HTTP Server [IHS] plug-in) that performs additional routing.
Now you have a J2EE engine (WebSphere Application Server), which is likely composed of a Web or servlet container as well as an Enterprise JavaBean (EJB) container to handle basic and advanced Java functions and business logic. You likely have multiple adapters to do a myriad of things, including connecting Web services and IBM WebSphere MQ messages. And more often than not, you have a database connection pool that connects to a MySQL, IBM DB2®, or Oracle back end.
When you tie in the potential connections to Lightweight Directory Access Protocol (LDAP) servers and even legacy servers, you have a true n-tier architecture. Now, take a look at a starter Web server environment.
Look at Figure 2 with the assumption that it's based on a single-server installation on a single UNIX operating system that also has some means of accessing the Internet through a browser. This server will house your Tomcat installation, various operating system-level tools, as well as (possibly) your own local database or, at the least, software and application code stored in a local repository (local directory structure).
Note: When I say Tomcat server, I'm talking about the whole container.
Figure 2. Example stand-alone server architecture
Although this looks nothing like a true enterprise architecture, you will at least be able to replicate basic application functionality from your server. You are very limited, but for all intents and purposes, you're treating this installation as an example test development server or just a sandbox server to play in if you are an administrator.
You can choose to set up and run a separate Apache HTTP Server front end with your Tomcat installation, but this is not recommended for purposes of this tutorial, because it requires more overhead and a lot more administration and setup. You would also need the mod_jk module, you'd have to set up proper routing, and so on.
Either way, let's move on to some common questions before proceeding to the installation and configuration.