Here's some good links.

http://www.serverwatch.com/tutorials/article.php/10825_1355131_1

Here's a good reason as to why you would want to integrate the two.

http://tomcat.apache.org/faq/connectors.html#integrate

There are three layers really.

"Web servers" serve static content, such as HTML files, images etc..
They don't do anything other than serve static content, unchanged.

Most web servers now have some sort of "plugin" architecture that allows
"filters" to be installed. These recognise particular sorts of content
and can perform operations on them server-side, before serving the
document across the web.  Simpler examples of these plugins could
process SSI (include files) in HTML documents, select an appropriate
langauge version of pre-existing HTML content according to browser
request headers, or re-size images on demand.  Under Apache HTTP Server
these plugins can be found as "mod_negotiate"  and the like, for IIS
look at "ISAPI filters"

It's now rare to find a web server that does anything more than either
serve content, or pass it to the plug-ins. The plug-ins are doing much
of the complexity, if not the sheer volume.

A sophisticated plug-in would be a server-side language processing
engine, such as mod_php or the ASP filter for IIS. These can either
process a recognised language from the file type, or (as IIS does) it
hands off the language interpreter to a further plug-in language engine
that interprets any one of a number of "<foo>Script" languages, from
JScript and VBScript through to PerlScript or even COBOLScript.  Each of
these languages supports a common syntax for embedding language
fragments in an ASP page and their engines support a common COM
interface for ASP Script.

Tomcat is something different, but externally similar-looking. It's
termed a "Java Servlet container" becase what it does is to execute Java
Servlets (Java programs that use a particular web-dependent
HTTP-specific interface).  It's both the externally visible server, and
the language engine (not a plug-in). As both Tomcat and HTTP Server are
part of the Apache project, they do integrate well together.

JSP (Java Server Pages) are ASP-like in that they appear to be HTML with
embedded code fragments in them. However they're executed by being
turned into Servlets first, compiled and then executed by Tomcat just as
if they'd been coded as Servlets in the first place. This is quite
different (and better) than how ASP works.

Tomcat is usually run in conjunction with Apache HTTP, but you can run
it alone, as its own web server. Not ideal for a mainstream production
site (just use Apache as well) but it can be convenient for light use.

JSP and Servlets are part of J2EE, but they're not EJB (the other main
component of J2EE). EJB are run under an App Server, such as Weblogic,
Websphere or JBoss.  There are several reasons why you might wish to do
this.
- You need the performance of executing middleware components on a
large server farm.
- You already have pre-existing EJB components.
-  You want an architecture with more layers than simple Servlets.
- You want an architecture like SOA that's distributable over multiple
sites.

In general, Apache HTTP is the pragmatic solution to anything involving
web serving. Tomcat is the solution to anything with complex server-side
scripting. Ruby on Rails might cope for the small stuff, otherwise go
Tomcat. Avoid "enterprise" tools like EJB or App Servers until you
actually need them. Most projects, even quite big ones, don't.

Be warned that "simple" configurations that have happily deployed onto
Tomcat for many versions past may fail entirely when deploying onto an
App Server. They're fussier and more variable about their configuration
too  (guess what today's problem is!)