![]() | |
|
Web servers and WebSphere Application Server Plug-in
Most WebSphere Application Server topologies will have a Web server which receives HTTP-based requests from clients. For security reasons the Web server should be placed in a separate network zone secured by firewalls (a DMZ).
Usually the Web server, in conjunction with the WebSphere Application Server Plug-in, provides the following functionality in the topology:
Serves requests for static HTTP content like HTML files, images, and so forth.
Requests for dynamic content like Java Server Pages (JSPs), servlets, and portlets are forwarded to the appropriate WebSphere Application Server through the WebSphere Application Server Plug-in.
Allows caching of response fragments using the Edge Side Include (ESI) cache.
Breaks the secured socket layer (SSL) connection from the client (unless this is done by another device in the architecture) and optionally opens a separate secured connection from the Web server to the Web container on the application server system.
WebSphere Application Server comes with Web server plug-ins for all supported Web servers.
The plug-in uses a configuration file (plugin-cfg.xml
) that contains
settings describing how to pass requests to the application server. The configuration
file is generated on the application server. Each time a change on the application
server affects the request routing of requests (for example, a new application is
installed) the plug-in must be regenerated and propagated to the Web server
machine again.
Note: In a stand-alone topology, only unmanaged Web servers are possible. This means the plug-in must be manually pushed out to the Web server system. The exception to this is if you are using IBM HTTP Server. The application server can automatically propagate the plug-in configuration file to IBM HTTP Server, even though it is an unmanaged node, by using the administrative instance of IBM HTTP Server.
Web server configuration
Plug-in configuration involves configuring the Web server to use the binary plug-in module that WebSphere Application Server provides. Plug-in configuration also includes updating the plug-in XML configuration file to reflect the current application server configuration. The binary module uses the XML file to help route Web client requests.
After installing a supported Web server, you must install a binary plug-in module for the Web server. The plug-in module lets the Web server communicate with the application server. The Plug-ins installation wizard installs the Web server plug-in. The wizard configures the Web server. The wizard also creates a Web server definition in the configuration of the application server. The Plug-ins installation wizard uses the following files to configure a plug-in for the Web server that you select:
The Web server configuration file on the Web
server machine, such as the httpd.conf
file for IBM HTTP Server.
The Web server configuration file is installed as part of the Web server.
The wizard must reconfigure the configuration file for a supported Web server.
Configuration consists of adding directives that identify file locations of two files:
The binary plug-in file
The plugin-cfg.xml
configuration file
The binary Web server plug-in file that the Plug-ins installation Wizard installs on the Web server machine.
An example of a binary plug-in module is the mod_ibm_app_server_http.so
file for IBM HTTP Server on the Linux platform.
The binary plug-in file does not change. However, the configuration file for the binary plug-in is an XML file. The application server changes the configuration file when certain changes to your WebSphere Application Server configuration occur.
The binary module reads the XML file to adjust settings and to route requests to the application server.
The plug-in configuration file, plugin-cfg.xml
,
on the application server machine that you propagate (copy) to a Web server machine.
The plug-in configuration file is an XML file with settings that you can tune in the administrative console. The file lists all of the applications installed on the Web server definition. The binary module reads the XML file to adjust settings and to route requests to the application server.
The standalone application server regenerates the plugin-cfg.xml
file in the
profile_root/config/cells/cell_name /nodes/web_server_name _node/servers/web_server_name
directory. Regeneration occurs whenever a change occurs in the application server configuration that
affects deployed applications.
After regeneration, propagate (copy) the file to the Web server machine. The binary plug-in then has access to the most current copy of its configuration file.
The Web server plug-in configuration service automatically regenerates the plugin-cfg.xml
file after certain events that change the configuration. The configuration service automatically
propagates the plugin-cfg.xml
file to an IBM HTTP Server machine when the file is
regenerated. You must manually copy the file on other Web servers.
The default (temporary) plug-in configuration file,
plugin-cfg.xml
, on the Web server machine.
The Plug-ins installation wizard creates the temporary plugin-cfg.xml
file in the
plugins_root/config/web_server_name
directory. The wizard creates the file for every
remote installation scenario. The wizard creates the file at the same time that it installs the
binary plug-in module for the Web server.
The default file is a placeholder that you must replace with the plugin-cfg.xml
file
from the Web server definition on the application server. The default file is a replica of the file
that the application server creates for a default standalone application server that has the samples
installed.
Run the configureweb_server_name
script from the app_server_root/bin
directory
of the application server machine for a remote installation, or directly from the plugins_root/bin
directory for a local installation. The script creates the Web server definition in the configuration files
of the default profile. To configure a different profile than the default, edit the
configureweb_server_name
script. Use the -profileName
parameter to identify a
different profile than the default.
After the Web server definition is created, the Web server plug-in configuration service within the
application server creates the first plugin-cfg.xml
file in the Web server definition on the
application server machine. If you install an application, create a virtual host, or do anything that
changes the configuration, you must propagate the updated plugin-cfg.xml
file from the
application server machine to the Web server machine to replace the default file.
The configureweb_server_name
script that
you copy from the Web server machine to the application server machine.
The Plug-ins installation wizard creates the configureweb_server_name script
on the Web server
machine in the plugins_root/bin
directory. If one machine in a remote scenario is running under
an operating system like AIX or Linux and the other machine is running under Windows, use the script created
in the plugins_root/bin/crossPlatformScripts
directory. The script is created for remote
installation scenarios only.
Copy the script from the Web server machine to the app_server_root/bin
directory on a remote
application server machine. You do not have to copy the script on a local installation. Run the script to
create a Web server definition in the configuration of the application server.
When using the IBM HTTP Server, configure the IBM HTTP Administration Server also. The IBM HTTP Administration Server works with the administrative console to manage Web server definitions. Also, use the administrative console to update your Web server definition with remote Web server management options. Click Servers > Server Types > Web servers > web_server_name to see configuration options. For example, click "Remote Web server management" to change such properties as:
Host name
Administrative port
User ID
Password
Implementing a web server plug-in
Use the administrative console to change the settings in the plug-in configuration file.
When setting up your web server plug-in, you must decide whether to have the configuration automatically generated in response to a configuration change. When the web server plug-in configuration service is enabled and any of the following conditions occur, the plug-in configuration file is automatically generated:
When the web server is created or saved
When an application is installed
When an application is uninstalled
When the virtual host definition is updated
You can either use the administrative console, or issue the GenPluginCfg
command to
regenerate your plugin-cfg.xml file.
NOTE: You must delete the plugin-cfg.xml
file in the profile_root/config/cells
directory before you complete this task. Otherwise, configuration changes do not persist to the
plugin-cfg.xml
file.
Complete the following steps to regenerate your plugin-cfg.xml
file by using the administrative
console:
Select Servers > Server Types > Web Servers > web_server_name > Plug-in properties.
Select Automatically generate plug-in configuration file, or click one or more
of the following topics to manually configure the plugin-cfg.xml
file:
Caching
Request and response
Request routing
Custom Properties
NOTE: Do not manually update the plugin-cfg.xml
file. Any manual updates you make for a web server are
overridden whenever the plugin-cfg.xml
file for that web server is regenerated.
Click OK.
You might need to stop the application server, and then restart the application server for the web server to locate
the plugin-cfg.xml
file.
Propagate the plug-in configuration. The plug-in configuration file, plugin-cfg.xml
, is automatically propagated to
the web server if the web server plug-in configuration service is enabled, and one of the following conditions is true:
The web server is a local web server, which means that the web server is located on the same workstation as an application server.
The web server is a remote IBM HTTP Server Version 7.0 that has a running IBM HTTP Server administration server.
If neither of these conditions is true, you must manually copy the plugin-cfg.xml
file to the location of the installation
for the remote web server. Copy the plugin-cfg.xml
file in
app_server_root/profiles/profile_name/config/cells/../../nodes/../servers/web_server_name
to the web server host location, which is
Plugin_Install_Root/config/web_server_name/
.
NOTE: If you use the FTP function to copy the file, and the configuration reload fails, check the file permissions
on the plugin-cfg.xml
file, and make sure that they are set to rw-r--r--
. If the file permissions are
not correct, the web server is not able to access the new version of the file, which causes the configuration reload to fail.
If the file permissions are incorrect, issue the following command to change the file permissions to the appropriate settings:
chmod 644 plugin-cfg.xml
The remote web server installation location is the location you specified when you created the node for this web server.
Request routing using plug-in
The Web Server plug-in uses an XML configuration file to determine whether a request is for the Web Server of the Application Server.
When a request reaches the Web Server, the URL is compared to those managed by the plug-in. If a match is found, the plug-in configuration file contains the information needed to forward the request to the Application Server's web container using the web container inbound chain.
For example, lets say you make a request to http://localhost:80/snoop
URL, so the Web
Server Plugin will check the /snoop
URL to find out how it is should be handled.
It will check if there is matching UriGroup
element in plugin-cfg.xml
:
<UriGroup Name="default_host_cluster1_URIs"> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/snoop/*"/> </UriGroup>
In this case it knows that the /snoop/*
URL is for dynamic content, so the next part is how to route it
to correct server. It will read value of Name
attribute for the UriGroup
which is
default_host_cluster1_URIs
, and name of the cluster is cluster1
. It will use these values find out
virtual host and cluster:
<Route ServerCluster="cluster1" UriGroup="default_host_cluster1_URIs" VirtualHostGroup="default_host" /> <VirtualHostGroup Name="default_host"> <VirtualHost Name="*:9080"/> <VirtualHost Name="*:80"/> <VirtualHost Name="*:9443"/> <VirtualHost Name="*:5060"/> <VirtualHost Name="*:5061"/> <VirtualHost Name="*:443"/> <VirtualHost Name="*:9081"/> <VirtualHost Name="*:9082"/> </VirtualHostGroup> <ServerCluster CloneSeparatorChange="false" GetDWLMTable="false" IgnoreAffinityRequests="true" LoadBalance="Round Robin" Name="cluster1" PostBufferSize="64" PostSizeLimit="-1" RemoveSpecialHeaders="true" RetryInterval="60"> <Server CloneID="14dtuu8g3" ConnectTimeout="0" ExtendedHandshake="false" LoadBalanceWeight="2" MaxConnections="-1" Name="dmgrNode01_server2" ServerIOTimeout="0" WaitForContinue="false"> <Transport Hostname="dmgr.webspherenotes.com" Port="9081" Protocol="http"/> <Transport Hostname="dmgr.webspherenotes.com" Port="9444" Protocol="https"> <Property Name="keyring" Value="C:\Cert\HTTPServer\Plugins\config\webserver2\plugin-key.kdb"/> <Property Name="stashfile" Value="C:\Cert\HTTPServer\Plugins\config\webserver2\plugin-key.sth"/> </Transport> </Server> <Server CloneID="14dtuueci" ConnectTimeout="0" ExtendedHandshake="false" LoadBalanceWeight="2" MaxConnections="-1" Name="dmgrNode01_server4" ServerIOTimeout="0" WaitForContinue="false"> <Transport Hostname="dmgr.webspherenotes.com" Port="9082" Protocol="http"/> <Transport Hostname="dmgr.webspherenotes.com" Port="9445" Protocol="https"> <Property Name="keyring" Value="C:\Cert\HTTPServer\Plugins\config\webserver2\plugin-key.kdb"/> <Property Name="stashfile" Value="C:\Cert\HTTPServer\Plugins\config\webserver2\plugin-key.sth"/> </Transport> </Server> <PrimaryServers> <Server Name="dmgrNode01_server2"/> <Server Name="dmgrNode01_server4"/> </PrimaryServers> </ServerCluster>
It knows that the cluster1
has two servers dmgrNode01_server2
and dmgrNode01_server4
and from the
cluster definition it can find out the http and https port and then forward request to either of the server. The cluster definition also
says that the load balancing algorithm is Round Robin.
![]() ![]() ![]() |