Here’s some excerpts from webspere redbook:
Although Web servers are independent products, they can be defined to the WebSphere Application Server administration process. The primary purpose for this is to enable the administrator to associate applications with one or more defined Web servers in order to generate the proper routing information for Web server plug-ins if multiple servers are used.
Web servers are associated with nodes. These nodes can be managed or
1)Managed nodes have a node agent on the Web server machine that allows the deployment manager to administer the Web server. You can start or stop the Web server from the deployment manager, generate the Web server plug-in for the node, and automatically push it to the Web server. In most installations, you have managed Web server nodes behind the firewall with the WebSphere Application Server installations.
2)Unmanaged nodes are not managed by WebSphere. You usually find these outside the firewall or in the demilitarized zone. You have to manually transfer the Web server plug-in configuration file to the Web server on an unmanaged node. In a z/OS environment, you have to use unmanaged nodes if the Web server is not running on the z/OS platform.
Special case: If the unmanaged Web server is an IBM HTTP Server, you can administer it from the Integrated Solutions Console. This allows you to automatically push the plug-in configuration file to the Web server with the deployment manager using HTTP commands to the IBM HTTP Server administration process. This configuration does not require a node agent.
The IBM HTTP Server is shipped with all WebSphere Application Server packages.
Web server plug-ins
A Web server can serve static contents and requests, like HTML pages. However, when a request requires dynamic content, such as JSP or servlet processing, it must be forwarded to WebSphere Application Server for handling.
To forward a request, you use a Web server plug-in that is included with the WebSphere Application Server packages for installation on a Web server. You transfer (manually or automatically with the deployment manager) an Extensible Markup Language (XML) configuration file, configured on the WebSphere Application Server, to the Web server plug-in directory. The plug-in uses the configuration file to determine whether a request should be handled by the Web server or an application server. When WebSphere Application Server receives a request for an application server, it forwards the request to the appropriate Web container in the application server. The plug-in can use HTTP or HTTPS to transmit the request (Figure3-10).
The plug-in is used for routing requests to one of multiple application servers.
OK, now let’s take my system for demonstrating:
I’ve websphere 5.1 for windows installed, and the install_root is C:\Program Files\IBM\WebSphere\AppServer, node name & cell name are both user. The plug in file locates at C:\Program Files\IBM\WebSphere\AppServer\config\cells\plugin-cfg.xml.
Now let’s take http://localhost:9080/PlantsByWebSphere for example(This is an app attached with installation of websphere 5.1).
In file C:\Program Files\IBM\WebSphere\AppServer\config\cells\plugin-cfg.xml we can see there’re lines below:
This means that all requests end with PlantsByWebSphere/*, PlantsByWebSphere/docs/, PlantsByWebSphere/docs/* are passed to websphere app servers for handling, and after that, websphere app server will give the results back to web server.
For more obvious example, we can see in plugin-cfg.xml these lines:
Which means only requests end with *.jsp, *.jsv, *.jsw are handled by websphere app server, others are directly handled by http server.
If you want to see the servlet class, servlet mapping and ejb etc definition, you can view C:\Program Files\IBM\WebSphere\AppServer\installedApps\user\PlantsByWebSphere.ear\PlantsByWebSphere.war\WEB-INF\web.xml for more information.