InfoCenter Home >
6: Administer applications >
6.6: Tools and resources quick reference >
6.6.13: Administering transports

6.6.13: Administering transports

Transports define the characteristics of the connections between the Web server and the application server, across which requests for applications are routed. Specifically, they define the connection between the Web server plug-in and the Web container of the application server.

Use transport properties to specify:

  • How to manage the set of connections; for example, how many concurrent requests to allow
  • Whether to secure the connections with SSL
  • Host and IP information for the transport participants

Administering the transport is closely related to administering the WebSphere plug-ins for Web servers. Indeed, without the plug-in configuration, the transport configuration is of little use.

You might also need to perform special configuration tasks to redirect application requests from the Web server machine to the application server machine if the Web server is located on a machine remote from the application server. See section 7.3.

!-- AEE -->

The internal transport

For applications in a test or development environment (in other words, a non-production environment), you can use the internal HTTP transport system to serve servlets without an Web server plug-in. Simply use the internal HTTP transport port (typically on port 9080).

For example, to serve the "snoop" servlet without an HTTP server, use the URL:

http://your.server.name:port/servlet/snoop
with port being the internal transport port number (typically 9080) and your.server.name being localhost if the Application Server is on the local machine.

For a product environment, it is not recommended that you use the internal transport, because it lacks the performance available when using a Web server plug-in.

If you do plan to use the internal transport in a production environment, you need to consider the following limitations, requirements and areas of exposure.

Requirements:

A front-end solution, such as Network Dispatcher, is required to provide the WebSphere Application Server with workload balancing capability.


Limitations:

  • Support for Simple Network Management Protocol (SNMP) is not available.
  • Common Gateway Interface (CGI) support must be implemented through servlets. For example, your existing CGI programs must be converted to servlets.
  • Hostname lookup, for example, the capability to log the hostname or just the IP address is not available.
  • Workload balancing, for example Session Affinity, is not available without an upstream solution providing similar functionality.
  • Typical Web server functions must be provided through servlets instead of through the Web server's configuration file settings. Examples include, but are not limited to, cache negotiaton, access log, and redirection.
  • Some coexistence scenarios are not possible, including the use of one Web server to feed requests to two WebSphere Application Servers on the same machine. For example, if you are migrating from WebSphere Application Server Version 3.5.x to WebSphere Application Server Version 4.0 you cannot use one instance of IBM HTTP Server 1.3.19 to feed requests to both versions of the WebSphere product. Because each instance of WebSphere Application Server contains its own internal HTTP internal transport, using one single instance of the internal HTTP transport for this type of coexistence is not possible.


Areas of exposure:

  • Performance of static content is not benchmarked by the WebSphere performance development team. Therefore, there are not conclusive details on how the internal HTTP transport performs when comparing it to an external Web server.
  • An internal and external Web server is more susceptible to security exposures than an application server. If your environment includes an external Web server and an application server running on two separate machines, many of the Web server's security exposures are contained on the machine that only contains the Web server. In the case of an internal HTTP transport, because it always runs on the same machine as the WebSphere Application Server, there is potential for a security exposure to the Web server and application server environments.

Configuring access logging for internal Web server HTTP transport

In order to debug potential problems with using HTTP transport as an internal Web server, you may use the following access logging capabilities.

  1. To turn access logging on, add the following as an advanced custom property to the transport section through the administrative console, and set the value to false:
    Property name: AccessLogDisable
    Values: True/False
    Default: Access log is disabled by default
    Scope:  Virtual/Global

  2. To specify your own access log file, add the following as an advanced custom property to the transport section through the administrative console:
    Property name: AccessLog
    Value: <filename>

    Access log entries should have the format: <hostname or IP> <user agent> [<local time> -<status code>] <thread id> <http request> <status code> <bytecount>

  3. To turn access logging off, add the following as an advanced custom property to the transport section through the administrative console and set the value to true:
    Property name: AccessLogDisable
    Values: True/False
    Default: Access log is disabled by default
    Scope:  Virtual/Global
  4. Restart the server.

    If you have enabled access logging, there will be an access log in the location you specified.

Configuring error logging for internal Web server HTTP transport

In order to debug potential problems with using HTTP transport as an internal Web server, you may use the following error logging capabilities.

  1. To turn error logging on, add the following as an advanced custom property to the transport section through the administrative console and set the value to false:
    Property name: ErrorLogDisable
    Value: True/False
    Default: Error log is disabled by default
    Scope: Virtual/Global
  2. To specify your own error log file, add the following as an advanced custom property to the transport section through the administrative console:
    Property name: ErrorLog
    Value: <filename>
    

    The error log property is used to specify where to place the error log.

    Note:The error log should appear in each instance of the server.

  3. Add the LogLevel property as an advanced custom property to the transport section through the administrative console to specify the level of messages to log in error log file.
    Property name: LogLevel
    Value:  <level> (Levels include: debug, info, warn, error, crit)
    Default:  warn (warn includes error and crit; debug includes all levels)
    Scope:  Virtual/Global

    Log levels specify what type of message appears in the error log. The warn, error, and crit messages are logged by default.

  4. To disable error logging, add the ErrorLogDisable as an advanced custom property to the transport section through the administrative console and set the value to true:
    Property name: ErrorLogDisable
    Value: True/False
    Default: Error log is disabled by default
    Scope:  Virtual/Global
  5. Restart the server.

    If you have enabled error logging and encounter an error, there should be an error log message in the error log file you specified.

See Transport Properties for more information about the properties used.

At times, the transport might be configured to use a port other than 9080. (The transport configuration is a part of the Web container configuration. In such cases, you need adjust your virtual host alias and what you type into the Web browser, as described in the virtual host administrative overview.

Note that you cannot access the internal transport directly from a browser. However, you can open connections to the transport from another application server.

Regenerating the WebSphere plug-in for the Web server

It is suggested you review the information about administering WebSphere plug-ins for Web servers, because you will need to regenerate the plug-in configuration each time you specify or change an HTTP transport.

Go to previous article: Procedure for configuring persistent session support Go to next article: Properties of transports

 

 
Go to previous article: Procedure for configuring persistent session support Go to next article: Properties of transports