|
This document applies only to the following language
version(s):
US English |
|
Problem(Abstract) |
You can configure your web server to route requests to
both WebSphere® Application Server V3.5 and V4.0 or V5.0. By loading the
plug-in for both versions, a single web server can handle requests for
both application servers. This document outlines the considerations and
limitations for a plug-in coexistence configuration. |
|
|
|
Cause |
You want to configure a single web server to route
requests to both a V3.5 application server and a V4.0 or V5.0 application
server. |
|
|
Resolving the
problem |
Statement of Support
IBM supports WebSphere Application Server V3.5.4-3.5.7 and V4.0.2-4.0.7 or
V3.5.4-3.5.7 and V5.0-5.0.2 plug-in coexistence configuration when
WebSphere Cumulative Plugin fix PQ76785 (or any of its future
replacements) and WebSphere 4.0 Cumulative plug-in fix dated Oct 1,2003 or
later are installed.
IBM supports V3.5.4-3.5.7 and V5.0-5.0.2 plug-in coexistence configuration
when WebSphere Cumulative Plugin fix PQ76785 (or any of its future
replacements) and V5.0 Cumulative plug-in fix dated Sep 3, 2003 or later
are installed.
Minimum recommended web server versions for V3.5 and V4.0 plug-in
coexistence:
- IHS 1.3.19.5
- IHS 1.3.26.2
- iPlanet 4.1 SP7
- iPlanet 6.0 SP1
- Domino 5.0.9a
- IIS 4 on Windows NT
- IIS 5 on Windows 2000
Minimum recommended web server versions for V3.5 and V5.0 plug-in
coexistence:
- IHS 1.3.26.2
- iPlanet 6.0.4
- Domino 5.0.9a
- Domino 6.0.2
- IIS 4 on Windows NT
- IIS 5 on Windows 2000
- Apache 1.3.26
For more information on prerequisites, review this Web site:
http://www-3.ibm.com/software/webservers/appserv/doc/latest/prereq.html
Features that are present in V3.5.6 and PQ76785 plug-in that must be
considered:
In the V3.5.4 and 3.5.5 plug-in, the VirtualHost matching is done against
the port number of the web server that the request was received on. In the
V3.5.6 and later plug-in, the VirtualHost matching is done against the
port number that is parsed from the host header. This behavior fully
complies with HTTP 1.1 spec and there is not any available parameter in
the plug-in that can set the old behavior. PQ76785 is built on top of
WebSphere 3.5.7 code. It means, that after you install the Cumulative
Plug-in fix PQ76785, the algorithm of how the plugin matches the port
number of the incoming http request, is changed. This is important to
remember, that the plug-in matching algorithm has changed, after you
install PQ76785 to V3.5.4 or 3.5.5 configurations (PQ76785 is not
available for V3.5.3 and below). IBM strongly recommends that you test
this fix on your test system before you apply it to your production
system, so that you can learn what other additional changes in VirtualHost
mappings are needed.
Features of the V4.0 plug-in that may need to be considered:
VHostMatchingCompat flag - this parameter sets how the
VirtualHost matching algorithm in the plug-in works. In V4.0 the
VirtualHost matching can be done against the port number that the request
was received on, or against the port number that is parsed from the host
header. In V5.0 plug-in the VirtualHost matching is done only against the
port number that is parsed from the host header. This behavior complies
with HTTP 1.1 spec. This flag is supported only in V4.0 and currently not
applicable in V5.0. There is a plan to support this flag in a future V5.0
Cumulative plug-in fix.
AppServerPortPreference flag - this option allows you to
choose the behavior of what port number the Application server uses in
building URI's for a sendRedirect. In V4.0 it can be the port number from
the host header of the http request coming in, or the port number that the
web server received the request on. In the V5.0 plug-in, it is only the
port number from the host header of the http request coming in, which
fully complies with HTTP 1.1 spec. This flag is supported only in V4.0 and
currently not applicable in V5.0. There is a plan to support this flag in
a future V5.0 Cumulative plug-in fix.
Decide whether you will use the same domain name or separate domain
names for the V3.5 instance and the V4.0 or V5.0 instance
This is probably the most important step before you configure the V3.5 and
V4.0 or V5.0 plug-in for coexistence. It is not required, but IBM
recommends that you configure a separate domain name in the web server for
each instance of WebSphere Application Server. If this is not possible, or
if it does not fit your business need, both instances of WebSphere can be
configured with the same domain name to access V3.5 and V4.0 or V5.0
applications, but some additional configuration steps may be needed.
Example assumptions:
All of the plug-in examples provided in this document assume the use of
IBM HTTP Server 1.3 (such as IHS 1.3.19.x or IHS 1.3.26.x) web server.
This approach should be applicable to any web server that is supported for
V3.5 and V4.0 or V3.5 and V5.0 plug-in coexistence.
For the sake of simplicity, the examples below will use myApp35 which is a
WebModule (Web Application) deployed in V3.5 with a ContextRoot (Web
Application Path) myApp35. The myApp40 is WebModule of the Enterprise
Application deployed in V40 with a ContextRoot myApp40. You can use a
similar approach when you configure V5.0 for plug-in coexistence with
V3.5.
Example #1: Each instance of WebSphere will be accessed thru its own
domain name in the web server
Configure two IP Based VirtualHosts in IHS (httpd.conf), each with a
unique IP address.
For Example:
Listen 80
<VirtualHost 10.10.10.1:80>
ServerName mysite35.com
DocumentRoot /www/docs/mysite35
ErrorLog logs/mysite35-error.log
CustomLog logs/mysite35-access.log common
</VirtualHost>
<VirtualHost 10.10.10.2:80>
ServerName mysite40.com
DocumentRoot /www/docs/mysite40
ErrorLog logs/mysite40-error.log
CustomLog logs/mysite40-access.log common
</VirtualHost>
or if you prefer NameBased VirtualHosting (there are some restrictions for
SSL VirtualHosts in IBM HTTP Server):
Listen 80
NameVirtualHost 10.10.10.1
<VirtualHost 10.10.10.1:80>
ServerName mysite35.com
DocumentRoot /www/docs/mysite35
ErrorLog logs/mysite35-error.log
CustomLog logs/mysite35-access.log common
</VirtualHost>
<VirtualHost 10.10.10.1:80>
ServerName mysite40.com
DocumentRoot /www/docs/mysite40
ErrorLog logs/mysite40-error.log
CustomLog logs/mysite40-access.log common
</VirtualHost>
Configure VirtualHost in V3.5 and VirtualHostsGroup in V4.0 with
corresponding aliases.
For Example:
a) In V3.5 configure VirtualHost_myApp35 VirtualHost
www.mysite35.com:80
10.10.10.1:80
b) In V4.0 configure VirtualHost_myApp40 VirtualHostGroup
www.mysite40.com:80
10.10.10.2:80
In the case of using NameBased VirtualHosts in IHS, do not add the IP
address alias in any VirtualHostGroup. Unexpected results may occur since
both VirtualHosts have the same IP address.
Example #2: Both instances of WebSphere have the same domain name in
the web server
When serving a request, the plug-in searches to match both VirtualHost
and URI (Servlet Web Path list) mappings. In this case the VirtualHost is
common to both the V3.5 and V4.0 environments, so the URI mapping must be
unique. Any overlap can cause unexpected results.
Configure IP Based VirtualHost in IHS.
For Example:
Listen 80
<VirtualHost 10.10.10.1:80>
ServerName mysite.com
DocumentRoot /www/docs/mysite
ErrorLog logs/mysite-error.log
CustomLog logs/mysite-access.log common
</VirtualHost>
Configure VirtualHostsGroup in V4.0 and V5.0 with corresponding aliases,
such as:
a) In V3.5 configure VirtualHost_myApp35 VirtualHost
www.mysite.com:80
10.10.10.1:80
b) In V4.0 configure VirtualHost_myApp40 VirtualHostGroup
VirtualHost_myApp40 with only one alias:
www.mysite.com:80
10.10.10.1:80
Additional considerations
There are two plug-ins loaded (V3.5 and V4.0 or V3.5 and V5.0) when
configuring plug-in coexistence.
The order in which the plug-in modules are loaded may be important for
performance reasons. For example, if most of the http requests are
directed to V4.0, then load the V4.0 plugin first. This orientation of
plugin loads will minimize the V3.5 involvement in handling requests. This
approach works in scenarios where most http requests (based on your
historical access statistics) should be routed to V4.0 instead of V3.5.
When serving a request, the WebSphere plug-in searches for the all
possible matches of VirtualHost and URI mappings. In V3.5 these mappings
are defined in the queues, rules and vhost properties files and some
important plug-in settings are also defined in the bootstrap property
file. In V4.0 or V5.0, all VirtualHost and URI mappings and other needed
definitions for the plug-in are set in the plugin-cfg.xml file, which is
called WebSphere plug-in configuration file. In this case, where the web
server is common for both V3.5 and V4.0 or V5.0 plug-ins, the combination
of VirtualHost and URI mappings must be unique across all V3.5 and V4.0 or
V5.0 plug-in configuration files. If not, you may get unexpected results,
such as the request that should be routed to V3.5 may be routed to V4.0 or
V5.0.
In the event of problems while running coexistence of plug-ins, IBM
recommends that you run additional tests with one plug-in temporarily
disabled. This helps to narrow down which plug-in is causing the problem.
Usually these problems are due to incorrectly configured URI and
VirtualHost mapping within the WebSphere plug-in configuration file(s).
Additional useful information regarding WebSphere plug-in coexistence
configurations can be found on the WebSphere Infocenter Web site:
http://www-3.ibm.com/software/webservers/appserv/infocenter.html
Conclusion
This document should be used as a guideline for configuring V3.5 and V4.0
or V5.0 plug-in coexistence using a common web server.
This document does not address the topic of configuring plug-in
coexistence for three versions of WebSphere Application Server, such as
V3.5, V4.0 and V5.0. See Technote #1113774 for information on this topic.
Plug_in/swg21113774.html |
|
|
|
|
Cross Reference information |
Segment |
Product |
Component |
Platform |
Version |
Edition |
Application Servers |
Runtimes for Java Technology |
Java SDK |
|
|
|
|
|
|