Web Server vs Application Server

1· Concept & Definition

The three runtime categories differ in how many enterprise services they provide. A web server serves static content and proxies HTTP. A servlet container (web container) runs Jakarta Servlet, Pages, EL and WebSocket components. An application server is a full Jakarta EE runtime: a web container plus CDI, REST, Persistence, Transactions, Messaging, Security and more, certified against a Jakarta EE profile.

2· Why It Matters

• Choosing the runtime determines which APIs are available without adding libraries, and who is responsible for integrating them.
• It drives operational model: embedded containers in fat JARs vs. managed server installations with deployed WARs/EARs.
• It shapes the network topology — which component terminates TLS, serves static assets and balances load.

The distinction also matters because people use the words loosely. Many design documents say "application server" when they mean an embedded Tomcat inside a Spring Boot JAR, and the difference only surfaces when someone assumes that a JTA transaction manager, a managed JMS connection factory or a JNDI data source is available. Being precise about the category tells reviewers which services the platform provides, which ones the team must select, configure and patch itself, and which component owns each concern at run time. It is also the first question in any runtime migration, because moving from a full server to a plain container means replacing every built-in service the application silently relied on.

3· How It Works

Web server

A web server (nginx, Apache httpd, Caddy) is optimised for high-concurrency network I/O. It does not run Java components; in Java architectures it acts as a reverse proxy in front of containers.

Servlet container

A servlet container implements the Jakarta Servlet specification and related web specifications. It manages connectors (network listeners), thread pools, request mapping, the filter chain, sessions and component lifecycle.

Application server

An application server provides the full Jakarta EE programming model and manages shared resources such as connection pools, transaction managers, JMS destinations and security realms. Modern servers are modular and can also run as runnable JARs.

Responsibilities

Deep Dive — The Path of One Request

Following a single HTTPS request through a typical topology shows where each runtime category does its work. The client opens a TLS connection to nginx or a cloud load balancer, which decrypts it, answers directly if the URL matches a static location, and otherwise picks a healthy upstream and forwards the request over a pooled keep-alive connection, adding X-Forwarded-For and X-Forwarded-Proto headers so the container knows the original client and scheme.

In Tomcat, the connector's acceptor thread accepts the socket and registers it with a poller, which uses non-blocking I/O to wait until bytes are readable. Only then is the socket handed to a worker thread from the executor. The worker parses the request line and headers, maps the URL to a context and a servlet, runs the filter chain and calls service(). It stays busy until the response is committed, unless the servlet uses asynchronous processing to release it while waiting for slow back-end work.

An application server adds layers inside that call. Before a business method runs, container interceptors start or join a JTA transaction, propagate the authenticated identity and activate CDI contexts, and managed resources such as data sources and JMS connection factories come from server-wide pools. A servlet container with libraries can provide similar behaviour, but each piece is wired and configured by the application rather than by the platform.

4· Java / Jakarta EE Code Examples

# nginx reverse proxy in front of two Tomcat instances
upstream app_pool {
    server 10.0.1.11:8080 max_fails=3 fail_timeout=10s;
    server 10.0.1.12:8080 max_fails=3 fail_timeout=10s;
}
server {
    listen 443 ssl http2;
    location /static/ { root /var/www; expires 7d; }           # served by nginx
    location / {
        # forwarded to containers
        proxy_pass http://app_pool;
        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

<!-- Tomcat server.xml: trust forwarded headers only from the proxy network -->
<Valve className="org.apache.catalina.valves.RemoteIpValve"
       internalProxies="10\.0\.0\.\d{1,3}"
       remoteIpHeader="X-Forwarded-For"
       protocolHeader="X-Forwarded-Proto" />

<!-- Open Liberty server.xml: enable only the features the application uses -->
<featureManager>
    <feature>servlet-6.1</feature>
    <feature>restfulWS-4.0</feature>
    <feature>cdi-4.1</feature>
    <feature>persistence-3.2</feature>
</featureManager>

5· Configuration, Defaults & Diagnostics

Most runtime-layer incidents first appear as 502 or 504 responses at the proxy, so diagnose from the outside in. A 502 means the proxy did not get a valid response, often because the container closed an idle keep-alive connection that the proxy reused, or because the instance was restarting. A 504 means the upstream was slower than the proxy's read timeout. Inside the container, compare busy threads with maxThreads, log request duration in the access log, and take a thread dump when the pool is saturated to see what the workers are waiting for.

# Busy request threads (Spring Boot needs
# server.tomcat.mbeanregistry.enabled=true for this metric)
curl -s localhost:8080/actuator/metrics/tomcat.threads.busy

# Tomcat access log pattern with request time in ms (%D)
#   %h %t "%r" %s %b %D

# nginx: log upstream time separately from total request time
log_format timed '$remote_addr "$request" $status '
                 'rt=$request_time urt=$upstream_response_time';

# Thread dump of a saturated container
jcmd <pid> Thread.print > threads.txt

6· Production Usage Patterns

• Edge proxy + embedded container per service: each microservice packages Tomcat/Jetty/Undertow; nginx, an ingress controller or cloud LB handles TLS and routing.
• Shared application server with multiple WARs: common in established enterprises; centralised resources and administration.
• Trimmed application server in containers: Liberty features or WildFly Galleon layers produce small images with full Jakarta EE APIs.
• CDN for static assets with the Java tier serving only dynamic content and APIs.

7· Common Pitfalls & Misconceptions

• Calling Tomcat an "application server" in design documents — it is a servlet container; missing services must be added and integrated.
• Serving large static files through the Java tier — wastes request threads and heap.
• Double compression or double TLS configured accidentally on both proxy and container.
• Deploying many unrelated applications on one server — shared failure domain and coupled upgrades.

8· Best Practices

• Choose the smallest runtime that provides the required specifications (Core/Web profile or container + selected libraries).
• Put a reverse proxy or managed load balancer in front of Java runtimes for TLS, static content and protection.
• Keep one application per runtime in container-based deployments for isolation and independent scaling.
• Align container thread pools, proxy timeouts and load-balancer timeouts end to end.

9· Architect's Perspective & Trade-offs

10· Interview Q&A