Keep it simple and standard on the client side ... and let the server be a bit more complex. That's the philosophy of the web - and it makes sense because you'll typically have hundreds and thousand of clients - browsers - all visiting your web site which will probably be a single system - or a small handful of systems if you're a larger organisation. Furthermore, the browsers and the machines they'll be running on will be looked after by users who will have a very different range of technical skills, whereas you're likely to have experts (or access to experts) for your web server.
With thousands of clients, but only a few servers, teaching people how to build, install, configure, monitor and look after servers is a niche requirement. And the requirement is fragmented all the more by there being a number of different servers. So such training fits in very well with the Well House Consultants
approach, where people from far and wide come on public residential courses at Well House Manor
- our hotel and training centre which is located about 100 miles to the west of London, in Melksham Wiltshire.
Last Thursday and Friday, we ran a course on deploying Apache httpd and Tomcat
, and starting from scratch built and installed the components of a typical system.
As we did so, I built up a diagram on the whiteboard, showing how the various components go together - here is that diagram in its finished state.
The clients / browsers
To the left
, you can see boxes representing my browsing visitors - and I've labelled them as Melksham, Cambridge, Wymondham and Swanley to represent the bases of some of the delegates on the course. You'll note that I have the browsers contacting the upper box in the centre column
(the "server stack") as users want a single point of contact, no matter where abouts in the stack the information that's returned eventually comes from. There is one dotted access line on the diagram to the second server in the stack - that's to illustrate an extra way to access the middle server just for testing purposes
The client facing server - Apache httpd
The top box in the centre column
is the Apache httpd server (sometimes, confusingly, just called "Apache"). This is where all the requests come in when the system is running. Httpd takes the incoming request, and analyses it. If the request is for a plain file (HTML, image, or something that needs no work on it), then httpd will simply feed that data back to the browser. The data column is the right column
in my diagram, and this plain file data is the top box in that column.
If the user requests a program to run on the Apache httpd server (the user won't know this, but httpd will have been configured to recongise certain URLs that need to be processed in this way), then httpd will load that program - that's the second box down in the right hand column - and will run it as its own process, passing back the data that's output by the process via Apache httpd to the browser.
And if user requests a URL that's to be handled by another server, then Apache httpd will simply pass that request on, perhaps after changing a few of the headers. That's the blue line on my diagram leading down from the top box in the server stack to the second box in that stack.
Why are some jobs handled by the initial server that receives the request, and others passed on?
The Apache httpd server that we've looked at so far is excellent for serving static content, and for running programs of some types. However, it's very much a file server and it's not ideal for running "web applications" which work best if loaded into memory and stored as part of the server - for those, an application engine is best.
The application engine - Apache Tomcat
The second box down the centre column
is Apache Tomcat. It's also a web server
in that it responds to requests in the http protocol, but it's a very different beast to Apache httpd.
Tomcat is an application engine that's written in Java, and it runs Java applications. When a URL is first requested, Tomcat loads the program that's going to provide the response page from the disc - that's the third box down in the right-most column. And the response is duly returned. However, the application remains loaded within the Tomcat server engine, so that next time the same application is run (probably with different parameters), it doesn't have to be loaded again - and that's going to be much more efficient for aplications that are run many times. You'll notice on my diagram that there's only a dotted line from the disc store to Tomcat, and that's to indicate that the program is loaded only occasioanlly - when it's first called, and perhaps at a future point if it's not been used for a long time and has dropped out of the cache.
You'll note that my diagram has a blue line coming into Tomcat from httpd - that's to a "connector" that may be using either the http protocol, or a binary compressed equivalent known as ajp
that's useful for efficiency between several servers on the same network, or even on the same c.p.u. And there's also a dotted line coming in from one of our clients - that's going to be an http connection, and if it's there at all it will be used purely for testing.
But neither Apache httpd nor Apache Tomcat is a database engine, and many applications require to access and store complex data, often in considerable quantities - and for that you need a database engine.
The database engine - often MySQL
At the bottom of my central column
in a database engine. This will be addressed by the Java applications that are running on our Tomcat engine - and / or by applications running on our Apache httpd server.
The main purpose of the database engine is to provide a better way that plain files store, catalogue and access data, and to do so in such a way that amendments can be easily and efficiently applied, that complex selections and sorts can be performed, and that several such operations can be performed in parallel without interfering with each other.
Unlike the other servers in the stack, the database server is typically going to be contacted / referenence using a protocol which is NOT understood by the browser - i.e. it's addressed in SQL (Structured Query Language) rather than HTTP (Hypertext Transfer Protocol).
In my diagram, the underlying data that's been stored / retrieved / reported on is the box labelled "D" at that base of the rightmost column
Having seen the building blocks and how they'll go together early in the course, we compiled and istalled an Apache httpd server, and configured it using the file httpd.conf and files referred to therein.
We looked at (and checked) that we had the right version of Java on our system. For Tomcat 6, we require Java 1.6 (also know as Java 6), for example.
We then installed Tomcat, and a sample web application. As well as feeding through plain files, we used JSP (Java Server Pages) and Servlets (Java classes which double up as web applications), and we saw how to configure and update both JSPs and Servlets. We also had a look at tag libraries, allowing us to use classes which conform to the Java Bean convention from within our HTML, without actually having to embed any Java source code in there.
Configuration of Tomcat was also covered - looking at files such as server.xml
which controls the posts that Tomcat is listening on (and protocols), the hosts and other services, web.xml
which provides defaults for each web application, and tomcat-users.xml
which controls the authorisation for use of the Tomcat manager.
MySQL was installed, and following that we installed PHP onto the Apache httpd server, to show how other modules are added there.
Finally - for this installation process - we took a look at the connector story, with the various routes that can be used to get Apache httpd to talk to Apache Tomcat. After a brief discussion of mod_jk (since it's in use at one of the delegate's sites on legacy systems), we moved on to look at configuring mod_proxy, with forward and backward rewriting of URLs. (written 2012-10-13, updated 2012-10-20)
Associated topics are indexed underA050 - Web Deployment - General 
Twelve skills / knowledges needed for the design of a web site - (2010-01-24) 
Forums for your Melksham and open source discussions - (2010-01-09) 
Should I maintain the programming code on my own website? - (2009-03-23) 
Copyright, Portability and other nontechnical web site issues - (2009-03-09) 
The next generation of programmer - (2004-11-13)A100 - Web Application Deployment - The Components of a Web-Based Solution 
LAMP - Linux, Apache, MySQL, PHP - install, configure, administer - (2010-07-30) 
PHP / Web 2 logging - (2008-01-06) 
Apache, Tomcat, Jakarta, httpd, web server - what are they? - (2007-07-13) 
From Web to Web 2 - (2007-05-21) 
A pu that got me into trouble - (2007-05-04) 
The LAMP Cookbook - Linux, Apache, MySQL, PHP / Perl - (2006-11-13) 
Helicopter views and tartans - (2006-04-06) 
Dynamic Web presence - next generation web site - (2005-11-29) 
How far away is that server? - (2005-09-10) 
FTP - how to make the right transfers - (2005-09-01) 
Ajax - (2005-07-03) 
Acronyms - (2005-01-02) 
Business is the predominant user of Tomcat, Perl and Tcl - (2004-09-15) 
Linux / LAMP course - (2004-08-31)A099 - Java Application - Deployment on the Web 
Telling Apache web servers apart / notes for the non-technical - (2010-01-26) 
Linux and Java Course in London - (2008-04-24) 
Web Application Components - (2006-03-28) 
Why run two different web servers - (2006-01-25)
Some other Articles
Flowchart to program - learning to program with Well HouseA wet SaturdayPublic Transport across Wiltshire - a new mapDistributed, Balanced and Clustered Load Sharing - the differenceThe components of an Apache httpd / Tomcat / MySQL stack and what each doesHere comes Santa - on the train from Melksham to Swindon on 2nd December 2012Melksham Chamber of Commerce - whence in 2013 and beyond?What a difference a year made - Melksham CampusInheritance, Composition and Associated objects - when to use which - Python exampleFormatting output - why we need to, and first Python example