|
|
| |
Installing and Configuring the Microsoft Internet Information Server (ISAPI) Plug-In
The following sections describe how to install and configure the Microsoft Internet Information Server Plug-In.
Overview of the Microsoft Internet Information Server Plug-In
The Microsoft Internet Information Server Plug-In allows requests to be proxied from a Microsoft Internet Information Server (IIS) to WebLogic Server. The plug-in enhances an IIS installation by allowing WebLogic Server to handle those requests that require the dynamic functionality of WebLogic Server.
The Microsoft Internet Information Server Plug-In is intended for use in an environment where the Internet Information Server (IIS) serves static pages such as HTML pages, while dynamic pages such as HTTP Servlets or JavaServer Pages are served by WebLogic Server. The WebLogic Server may be operating in a different process, possibly on a different host. To the end user—the browser—the HTTP requests delegated to WebLogic Server still appear to be coming from IIS. The HTTP-tunneling facility of the WebLogic client-server protocol also operates through the plug-in, providing access to all WebLogic Server services.
As of WebLogic Server 6.1 SP6, 7.0 SP5, 8.1 SP2, the WebLogic Server plug-ins are now certified to proxy to any version of WebLogic Server, including 5.1.
Connection Pooling and Keep-Alive
The Microsoft Internet Information Server Plug-In improves performance by using a re-usable pool of connections from the plug-in to WebLogic Server. The plug-in implements HTTP 1.1 keep-alive connections between the plug-in and WebLogic Server by re-using the same connection for subsequent requests from the same client. If the connection is inactive for more than 30 seconds, (or a user-defined amount of time) the connection is closed. The connection with the client can be reused to connect to the same client at a later time if it has not timed out. You can disable this feature if desired. For more information, see KeepAliveEnabled.
Proxying Requests
The plug-in proxies requests to WebLogic Server based on a configuration that you specify. You can proxy requests either based on the URL of the request (or a portion of the URL). This is called proxying by path. You can also proxy a request based on the MIME type of the requested file, called proxying by file extension. You can also use a combination of both methods. If a request matches both criteria, the request is proxied by path. You can also specify additional parameters for each of these types of requests that define additional behavior of the plug-in. For more information, see Installing the Microsoft Internet Information Server Plug-In.
Platform Support
The Microsoft Internet Information Server Plug-In is supported on Windows. Plug-ins are not supported on all operating systems for all releases. For information on platform support for specific versions of Microsoft Internet Information Server Plug-In, see Platform Support for WebLogic Server Plug-ins and Web Servers in Supported Configurations for WebLogic Server 6.1.
Installing the Microsoft Internet Information Server Plug-In
To install the Microsoft Internet Information Server Plug-In:
iisproxy.dll
file from the /bin
directory of your WebLogic Server installation into a convenient directory that is accessible by IIS. This directory must also contain the iisproxy.ini
file. If you need to use 128 bit security with the Microsoft Internet Information Server plug-in, you must rename the iisproxy128.dllfile to iisproxy.dll. If you wish to keep both files you will need to change the name of the original iisproxy.dll file.
iisproxy.dll
" file.
Note: Any path information you add to the URL after the server and port is passed directly to WebLogic Server. For example, if you request a file from IIS with the URL:
http://myiis.com/jspfiles/myfile.jsp
it is proxied to WebLogic Server with a URL such as
http://mywebLogic:7001/jspfiles/myfile.jsp
Note: To avoid out-of-process errors, do not deselect the "Cache ISAPI Applications" check box.
iisproxy.ini
file.
The iisproxy.ini
file contains name=value pairs that define configuration parameters for the plug-in. The parameters are listed in General Parameters for Web Server Plug-Ins.
Note: Changes in the parameters will not go into effect until you restart the "IIS Admin Service" (under services, in the control panel).
BEA recommends that you locate the iisproxy.ini
file in the same directory that contains the iisproxy.dll
file. You can also use other locations. If you place the file elsewhere, note that WebLogic Server searches for iisproxy.ini
in the following directories, in the following order:
iisproxy.dll
is located.
iisproxy.ini
file there, it continues looking in the Windows Registry for older versions of WebLogic Server and looks for the iisproxy.ini
file in the home directories of those installations.
c:\weblogic
, if it exists.
iisproxy.ini
file. For example:
WebLogicHost=localhost WebLogicPort=7001
iisproxy.ini
file. For example:
WebLogicCluster=
myweblogic.com
:7001,
yourweblogic.com
:7001
Where myweblogic.com
and yourweblogic.com
are instances of Weblogic Server running in a cluster.
iisproxy.ini
file. Proxying by path takes precedence over proxying by MIME type.
You can also proxy multiple websites defined in IIS by path. For more information, see Proxying Multiple Virtual Websites from IIS.
To configure proxying by path:
iisforward.dll
file in the same directory as the iisproxy.dll
file and add the iisforward.dll
file as a filter service in IIS (WebSite Properties iisforward dll
).
.wlforward
as a special file type to be handled by iisproxy.dll
.
iisproxy.ini
. WlForwardPath
defines the path that is proxied to WebLogic Server, for example: WlForwardPath=/weblogic
.
WlForwardPath
when necessary. For example, using
WlForwardPath=/weblogic
PathTrim=/weblogic
trims a request from IIS to Weblogic Server. Therefore, /weblogic/session
is changed to /session
.
Debug=ON
parameter in iisproxy.ini
. A c:\tmp\iisforward.log
is generated containing a log of the plug-in's activity that you can use for debugging purposes.
WlForwardPath=*/HTTPClnt*
You do not need to use the PathTrim parameter.
Note: The only time you need to use HTTP-tunneling is when you connect through an applet through IIS/NES to WebLogic Server and and use http as the protocol instead of t3. (For example, http:// as the protocol in the provider URL instead of t3://.)
iisproxy.ini
file. A complete list of parameters is available in the appendix General Parameters for Web Server Plug-Ins.
Proxying Multiple Virtual Websites from IIS
To proxy multiple Websites (defined as virtual servers in IIS) to WebLogic Server:
dll
and ini
files used to define the proxy.
iisforward.dll
to each of the directories you created in step1.
iisforward.dll
for each Website with IIS.
iisforward.ini
. Place this file in the same directory that contains iisforward.dll
. This file should contain the following entry for each virtual website defined in IIS:
vhostN
=websiteName
:port websiteName
:port
=dll_directory
/iisproxy.ini
Where:
N
is an integer representing the virtual website. The first virtual website you define should use the integer 1 and each subsequent website should increment this number by 1.
websiteName
is the name of the virtual website as registered with IIS.
port
is the port number where IIS listens for HTTP requests.
dll_directory
is the path to the directory you created in step 1.
For example:
vhost1=strawberry.com:7001 strawberry.com:7001=c:\strawberry\iisproxy.ini vhost2=blueberry.com:7001 blueberry.com:7001=c:\blueberry\iisproxy.ini ...
iisproxy.ini
file for each virtual Website, as described in step 8. in Proxying Requests. For each virtual Website, copy this iispoxy.ini
file to the directory you created in step 1.
iisproxy.dll
to each directory you created in step 1.
Creating ACLs through IIS
ACLs will not work through the Microsoft Internet Information Server Plug-In if the Authorization header is not passed by IIS. Use the following information to ensure that the Authorization header is passed by IIS.
When using Basic Authentication, the user is logged on with local log-on rights. To enable the use of Basic Authentication, grant each user account the Log On Locally user right on the IIS server. Note the following two problems that may result from Basic Authentication's use of local logon.
To enable Basic Authentication, in the Directory Security tab of the console, ensure that the Allow Anonymous option is "on" and all other options are "off".
Here is a sample iisproxy.ini
file for use with a single, non-clustered WebLogic Server. Comment lines are denoted with the "#
" character.
# This file contains initialization name/value pairs # for the IIS/WebLogic plug-in.
WebLogicHost=localhost WebLogicPort=7001 ConnectTimeoutSecs=20 ConnectRetrySecs=2
Here is a sample iisproxy.ini
file with clustered WebLogic Servers. Comment lines are denoted with the "#
" character.
# This file contains initialization name/value pairs # for the IIS/WebLogic plug-in.
WebLogicCluster=myweblogic.com:7001,yourweblogic.com:7001 ConnectTimeoutSecs=20 ConnectRetrySecs=2
Note: If you are using SSL between the plug-in and WebLogic Server, the port number should be defined as the SSL listen port.
Using SSL with the Microsoft Internet Information Server Plug-In
You can use the Secure Sockets Layer (SSL) protocol to protect the connection between the WebLogic Server proxy plug-in and the Microsoft Internet Information Server. The SSL protocol provides confidentiality and integrity to the data passed between the Microsoft Internet Information Server Plug-In and WebLogic Server. In addition, the SSL protocol allows the WebLogic Server proxy plug-in to authenticate itself to the Microsoft Internet Information Server to ensure that information is passed to a trusted principal.
The Microsoft Internet Information Server Plug-In does not use the transport protocol (http
or https
) to determine whether or not the SSL protocol will be used to protect the connection between the proxy plug-in and the Microsoft Internet Information Server. In order to use the SSL protocol with the Microsoft Internet Information Server Plug-In, configure the WebLogic Server receiving the proxied requests to use the SSL protocol. The port on the WebLogic Server that is configured for secure SSL communication is used by the WebLogic Server proxy plug-in to communicate with the Microsoft Internet Information Server.
Note: You cannot configure a 2-way SSL between the Microsoft Internet Information Server and WebLogic Server. The SSL protocol is a point-to-point connection, cyptographically sealed end-to-end. Therefore, any type of proxy or firewall cannot see into the SSL socket. The Microsoft Internet Information Server acts as the server end-point in the SSL connection. The configuration is:
client-->2-way SSL-->IIS<--1-way SSL<--WebLogic Server
The Microsoft Internet Information Server cannot use the digital certificate from the first SSL connection in the second SSL connection because it cannot use the client's private key.
Configuring SSL
To use the SSL protocol between Microsoft Internet Information Server Plug-In and WebLogic Server:
WebLogicPort
parameter in the iisproxy.ini
file to the listen port configured in step 2.
SecureProxy
parameter in the iisproxy.ini
file to ON
.
iisproxy.ini
file that define the SSL connection. For a complete list of parameters, see SSL Parameters for Web Server Plug-Ins.
For example:
WebLogicHost=myweblogic.com WebLogicPort=7002 SecureProxy=ON
Specifying Trust of the WL-Proxy-Client-Cert Header
The plug-in can encode users' identity certifications in the WL-Proxy-Client-Cert
header and pass the header to WebLogic Server instances (see Proxying Requests to Another HTTP Server in the WebLogic Server Administration Guide). A WebLogic Server instance uses the certificate information from that header, trusting that it comes from a secure source (the Plug-In), to authenticate the user. In previous releases of WebLogic Server, the default behavior was to always trust the WL-Proxy-Client-Cert
header. Beginning with WebLogic Server 6.1 SP2, you need to explicitly define trust of the WL-Proxy-Client-Cert
header. A new parameter, clientCertProxy
, allows WebLogic Server to determine whether to trust the certificate header. For an additional level of security, use a connection filter to limit all connections into WebLogic Server (therefore allowing WebLogic Server to only accept connections from the machine on which the plug-in is running).
The clientCertProxy
parameter has been added to the HTTPClusterServlet
and Web applications.
For the HTTPClusterServlet
, add the parameter to the web.xml
file as follows:
<context-param>
<param-name>clientCertProxy</param-name>
<param-value>true</param-value>
</context-param>
For Web applications, add the parameter to the web.xml
file as follows:
ServletRequestImpl context-param
<context-param>
<param-name>weblogic.httpd.clientCertProxy</param-name>
<param-value>true</param-value>
</context-param>
You can also use this parameter in a cluster as follows:
<Cluster ClusterAddress="127.0.0.1" Name="MyCluster"
ClientCertProxyHeader="true"/>
Proxying Servlets from IIS to WebLogic Server
Servlets may be proxied by path if the iisforward.dll
is registered as a filter. You would then invoke your servlet with a URL similar to the following:
http://IISserver/weblogic/myServlet
To proxy servlets if iisforward.dll
is not registered as a filter, you must configure proxying by file type.To proxy servlets by file type:
http://www.myserver.com/
virtualName
/
anyfile
.
ext
where virtualName
is the URL pattern defined in the <servlet-mapping>
element of the Web Application deployment descriptor (web.xml
) for this servlet and ext
is a file type (extension) registered with IIS for proxying to WebLogic Server. The anyfile
part of the URL is ignored in this context.
Note:
.gif
and .jpg
) with IIS. You can, however, choose to serve these images directly from IIS if desired.
After you install and configure the Microsoft Internet Information Server Plug-In, follow these steps for deployment and testing:
filename.jsp
as shown in this example:
http://myii.server.com/filename.jsp
If filename.jsp
is displayed in your browser, the plug-in is functioning.
Connection Errors and Clustering Failover
When the Microsoft Internet Information Server Plug-In attempts to connect to WebLogic Server, the plug-in uses several configuration parameters to determine how long to wait for connections to the WebLogic Server host and, after a connection is established, how long the plug-in waits for a response. If the plug-in cannot connect or does not receive a response, the plug-in will attempt to connect and send the request to other WebLogic Servers in the cluster. If the connection fails or there is no response from any WebLogic Server in the cluster, an error message is sent.
Figure 12-1 demonstrates how the plug-in handles failover.
Connection Failures
Failure of the host to respond to a connection request could indicate possible problems with the host machine, networking problems, or other server failures.
Failure of WebLogic Server to respond, could indicate that WebLogic Server is not running or is unavailable, a hung server, a database problem, or other application failure.
Failover with a Single, Non-Clustered WebLogic Server
If you are running only a single WebLogic Server the same logic described here applies, except that the plug-in only attempts to connect to the server defined with the WebLogicHost parameter. If the attempt fails, an HTTP 503
error message is returned. The plug-in continues trying to connect to WebLogic Server until ConnectTimeoutSecs is exceeded.
The Dynamic Server List
When you specify a list of WebLogic Servers in the WebLogicCluster
parameter, the plug-in uses that list as a starting point for load balancing among the members of the cluster. After the first request is routed to one of these servers, a dynamic server list is returned containing an updated list of servers in the cluster. The updated list adds any new servers in the cluster and deletes any that are no longer part of the cluster or that have failed to respond to requests. This list is updated automatically with the HTTP response when a change in the cluster occurs.
To avoid traffic on a new server you need to test, wait until the newly added server is fully tested, target it to the cluster and it will become a node of the cluster. This node will get automatically begin to receive traffic from the proxy.
Failover, Cookies, and HTTP Sessions
When a request contains a session information stored in a cookie, in the POST data, or by URL encoding, the session ID contains a reference to the specific server in which the session was originally established (called the primary server) and a reference to an additional server where the original session is replicated (called the secondary server). A request containing a cookie attempts to connect to the primary server If that attempt fails, the request is routed to the secondary server. If both the primary and secondary servers fail, the session is lost and the plug-in attempts to make a fresh connection to another server in the dynamic cluster list. For more information see Figure 12-1 Connection Failover.
Note: If the POST data is larger than 64K, the plugin will not parse the POST data to obtain the session ID. Therefore, if you store the session ID in the POST data, the plugin cannot route the request to the correct primary or secondary server, resulting in possible loss of session data.
Figure 12-1 Connection Failover
*The Maximum number of retries allowed in the red loop is equal to ConnectTimeoutSecs
÷ ConnectRetrySecs.
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|