Processing requests

Once a cluster and its members have been set up, the plug-in can start directing requests from the Web server to the correct appserver. Figure 5-7 shows what occurs within the plug-in when processing a request.

Figure 5-7 How the plug-in processes a request

Here is an example walk-through of Figure 5-7. Users asks for the page http://web1:80/snoop from their browser. The request is routed to the Web server over the Internet.

  1. The Web server immediately passes the request to the plug-in (1). All requests go to the plug-in first.

  2. The plug-in then starts by looking at all Route definitions in the plugin-cfg.xml. For each Route it searches through its configuration to find if there is any match to the virtual host web1:80 and URI /snoop. It will find the first match and then decide that WebSphere should handle the request (2). If there isn't any match, WebSphere will not handle the request.

  3. The plug-in takes the request and separates the host name and port pair and URI. The plug-in now starts by looking at all the defined Routes. It gets a Route and then searches for a virtual host match to web1 port 80 in that Route. It matches that host name and port to web1:80 in the VirtualHost block (3).

  4. The plug-in then tries to match the URI /snoop in the current Route. It searches its configuration for a URI mapping that matches the requested URI in the UriGroup block (4). It matches /snoop in the UriGroup.

  5. Once the VirtualHostGroup and UriGroup are found, it sets a score depending on the number of characters in the URI and virtual host (5).

  6. The plug-in continues to the next Route and searches through virtual hosts and URI's setting scores for matches with any URI and virtual host match. The Route that has the highest score is chosen (6) and the ServerCluster is set.

  7. The plug-in now checks the request to see if any session identification has been passed to the server (7). See 5.5, Session management for more information about this. Our request does not contain any session information.

  8. The plug-in chooses a cluster member to manage the request (8). See 5.4.4, Plug-in workload management and failover policies for more information. A server is chosen to handle the request. If there is a session identifier and a CloneID associated with it, the plug-in will choose a server based on the CloneID (9).

  9. This cluster member has two transports associated to it; HTTP and HTTPS are defined. As this request is HTTP, the cluster member uses the HTTP transport definition (10).

  10. In box 11 the term stream is used. A stream is a persistent connection to the Web container. Since HTTP 1.1 is used for persistent connections between plug-in and Web container, it is possible to maintain a connection (stream) over a number of requests. In our example, no previous connection has been created from the plug-in to the Web container, so a new stream is created (12). If a stream is already established, the plug-in uses the existing stream (13).

  11. The request is sent to the cluster member(14) and successfully processed. The plug-in passes the response on to the Web server (15), which in turn passes it back to the user's browser.

  Prev | Home | Next

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.