InfoCenter Home >
7: Multimachine management >
7.1: Using WebSphere Application Server in a multimachine environment >
7.1.3: Multimachine topologies >
7.1.3.6: HTTP server separation sample topologies >
7.1.3.6.1: HTTP transport sample topology
7.1.3.6.1: HTTP transport sample topology
WebSphere Application Server can use the HTTP protocol to route requests from the Web
server to application servers on remote machines.

In the diagram, Machine A hosts the Web server and receives HTTP requests from clients.
The Web server forwards the requests to the application server on Machine C by using the
HTTP or HTTPS protocol. Machine B hosts the application and administrative repository
databases.
Variations on this configuration include vertical scaling of the application servers.
Additional application server machines (D, E, ... N), can be added to the configuration to
implement horizontal scaling.
The HTTP transport supports NAT firewalls. For more information on firewall
configurations in WebSphere Application Server, see articles 7.1.3.7
and 7.1.4.
The HTTP transport is fully integrated with WebSphere Application Server's workload
management and cloning facility. It balances loads between individual application servers
and their clones, and among the clones of an application server.
- Load balancing between application servers. The HTTP transport can be
configured to forward requests from each URL to a different application server and its
clones, enabling manual load balancing. For instance, URLs that generate a large number of
requests can be forwarded to application servers on more- powerful machines.
- Load balancing among application server clones. The HTTP transport
automatically distributes requests among the clones of an application server that is
defined to respond to a single URL.The method for selecting which clone handles a
particular request combines a round-robin selection policy with server affinity.
If
session persistence is not enabled (the default), requests are distributed among all
available clones of an application server using a strict round-robin policy. Each clone
gets the next request in turn. The only exception is when a clone is added or restarted;
see Failover support (later in this article) for
details.
If session persistence is enabled (that is, session clustering and server affinity are
enabled), requests are distributed as follows:
- The HTTP transport distributes the first request of each session and all requests that
are not associated with a session as if session persistence is not enabled. That is, they
are distributed using a round-robin policy except when clones are added or restarted.
- The HTTP transport attempts to distribute all requests associated with a particular
session to the same clone of an application server. Different sessions are assigned to
different clones of the application server.
Be aware that there is no guarantee that
the same clone will be used for all requests within a session. Session affinity cannot
always be maintained in situations where the number of available clones changes during the
lifetime of a session. The Session Manager's session clustering facility ensures that
session state is not lost if requests are switched to another clone during a session.In
any case, applications that require session information to be available across multiple
client invocations must store session information in a database.
The HTTP transport automatically handles failover and changes in the number of
available clones.
- If a clone is stopped or unexpectedly fails, all subsequent requests are distributed
among the remaining clones. The unavailable clone is skipped.
- If a clone is added or restarted, the system automatically begins to distribute requests
to it. The next several requests are dispatched to that clone before HTTP resumes its
normal methods for distributing requests to the clones of an application server based on
whether session persistence is enabled. (See Load-balancing
support, for details.)
HTTP transport has the following advantages:
- It supports load balancing and failover.
- It does not require database access through the firewall. The administrative server runs
on the machine that hosts the application server, which is typically behind the firewall.
- It supports WebSphere security.
- It supports Secure Sockets Layer (SSL) encryption for communications between the Web
server and the application server.
- It supports NAT firewalls.
- Performance is relatively fast.
The HTTP transport has the disadvantage of requiring at least one firewall port, more
if multiple application server clones are configured or WebSphere security is used on the
machine hosting the Web server.
|
|