Some added terminology that might help as you wade through assorted docs, articles, etc.
There is a difference between a web server and a servlet container, and a difference between a servlet container and a
jsp container. Apache, for example, is the first but neither of the last two. Tomcat is all three. These days I'm not sure you could find non-trivial servlet container implementations that weren't also jsp containers, but the open source predecessor to Tomcat (whose name escapes me) was only a servlet container.
Sun's buzzwordisms try to make the distinction between the responsibilities of the entire server process versus well-defined functionalities that are provided by pieces of that server process. Sometimes those pieces are referred to as "containers", sometimes as "services"; the distinction between the two gets quiet blurry, but I think their intention is that services provide required technical functionality to the containers, and the containers leverage/integrate that functionality into higher value-added capabilities to the user/developer. "Containers" tend to have pretty clear object lifecycle maintenance issues (e.g. handling a servlet request, or managing the EJB object lifecycle) that span multiple technology issues, but "services" are each about a particular technology area (e.g. security is handled by JAAS).
The terminology doesn't just apply to web servers versus servlet containers that may or may not be in a web server. A J2EE-compliant application server is expected to be the sum of a number of containers. It is expected to have a servlet/jsp container. It is expected to have one or more EJB containers. The EJB and J2EE specs determine a number of containers and services that are to be present. JBoss isn't required to use Tomcat, but for it to be a J2EE-complaint application server it will always have the option of plugging in some kind of jsp container.
[ March 15, 2006: Message edited by: Reid M. Pinchback ]