The following details how the WAS 4.0 HTTP Transport (the webserver
plugin) determines that a URI should be handled by a WebSphere 4.0
Application Server.
Basic Definitions
URIGroups:
A logical group of URIs.
VirtualHostGroups:
A logical group of hostnames.
ServerGroup:
A logical group of Application Servers.
Route:
A route associates a ServerGroup with a URIGroup and/or a
VirtualHostGroup. For a given URI and hostname combination, a group of
application servers are defined that can service the requests
More detailed information of the above terms is given in the WAS 4.0
InfoCenter:
http://www.ibm.com/software/webservers/appserv/library.html
HTTP Transport Request Handling
Resolving WebSphere URI's using the plugin-cfg.xml is a two step
process. For each URI submitted by a browser client, the webserver will
invoke a method in the HTTP Transport (i.e. call the WebSphere plugin
before trying serve a static page). On a very high level two steps are
performed.
Step 1: Determine if the URI is intended for a WebSphere Application
Server
- Search for a match on the client's URI
- Search for a match on the client's hostname
Step 2: Determine which Application Server should handle the request
Step 1: Determine if the URI is intended for a WebSphere Application
Server
An HTTP request is received by the webserver. The webserver plugin uses
the Route statements in the plugin-cfg.xml file and begins to search the
URI/VirtualHost groups defined by the designated route. The plugin-cfg.xml
file is traversed from the bottom up.
The following are the details taken to resolve the client's
request:
- The next route statement in the plugin-cfg.xml is selected. For the
first iteration, the last Route statement in the plugin-cfg.xml file is
selected. If all Route statements have been searched, the request is
rejected and programmatic control is passed to the webserver.
- The URIGroup defined in the Route statement is selected and searched.
If a match for the client's URI is found in the selected URIGroup, the
HTTP Transport proceeds to step 1.C. If a match is not found the HTTP
Transport returns to step 1.A.
- The VirtualHostGroup defined in the Route Statement is selected and
searched. If a match for the client's hostname is found then the request
is accepted and the HTTP Transport proceeds to step 2. If a match is not
found the HTTP Transport returns to step 1.A.
Step 2: Determine which Application Server should handle the
request.
- Once the HTTP Transport has determined the client's request is
intended for WebSphere application Server, internal structures and
information about the request is created.
- The Route statement that resolved the client's URI and hostname is
associated with a ServerGroup. The ServerGroup defines a set of
application servers that can handle the request. The Application Server
Clone that will ultimately serve the request is selected either in a Round
Robin or Random if session affinity is not configured.
|