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

Overview

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.

Load-balancing support

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.

Failover support

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.)

Typical use

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.

Go to previous article: HTTP server separation sample topologies Go to next article: Semi-remote HTTP sample topology

 

 
Go to previous article: HTTP server separation sample topologies Go to next article: Semi-remote HTTP sample topology