InfoCenter Home >
7: Multimachine management >
7.1: Using WebSphere Application Server in a multimachine environment >
7.1.3: Multimachine topologies >
7.1.3.6: HTTP server separation sample topologies >
7.1.3.6.5: Thick servlet redirector with administrative agent sample topology

7.1.3.6.5: Thick servlet redirector with administrative agent sample topology

Overview

In a configuration for a thick servlet redirector with administrative agent, an administrative server agent provides administrative support for the servlet redirector. An agent is controlled by a full instance of an administrative server located on another machine. It provides all of the services of an administrative server, but does not require a direct connection to the administrative repository database. The agent can access the administrative server through a firewall.

The following figure shows a thick servlet redirector that is configured to run with an administrative server agent.

The thick servlet redirector is installed on Machine A with the Web server. Requests are forwarded from the Web server to the servlet redirector by using the Open Servlet Engine (OSE) transport. The servlet redirector then forwards the requests to the application server on Machine B by using Remote Method Invocation (RMI) and Internet Inter-ORB Protocol (IIOP). Encrypted requests can be forwarded by using the Secure Sockets Layer (SSL) protocol.

The administrative agent on Machine A communicates with the master administrative server on Machine B. The master administrative server handles all communication with the administrative repository database on Machine C. This eliminates the need to install a database client on Machine A.  To retrieve configuration information, the administrative agent communicates by using RMI/IIOP through the firewall.

Typical use

The advantages of using a thick servlet redirector with an administrative agent are as follows:

  • It does not require database access through a firewall, making it appropriate for use in many secure demilitarized zone (DMZ) configurations.
  • Communications between the servlet redirector and the remote application server can be encrypted by using SSL.
  • It does not require a database client on the Web server machine.
  • The administrative server agent can be easily configured though the administrative console, making maintenance easier.
  • A servlet redirector communicates with application servers through EJB client invocations and can participate in workload management.  This allows it to forward HTTP requests to cloned application servers and provides load balancing and failover support.  
  • It supports WebSphere Application Server product security.
  • Because it has fewer associated processes (no database client and administration through an agent instead of a full administrative server), this topology generally has better Web server performance than the thick servlet redirector.

The disadvantages of this configuration are as follows:

  • The remote administrative server can potentially be a single point of failure.   However, running administrative servers with workload management enabled eliminates this possibility.
  • It does not support Network Address Translation (NAT) firewalls.
  • It requires multiple ports in a firewall.
  • It requires the firewall to support IIOP.
  • It performs relatively slowly in a DMZ configuration compared to other servlet redirection mechanisms such as Remote OSE.

The thick servlet redirector with administrative agent is often used when an organization wants to maintain a Web server in one department and secure applications in another. The application server provides dynamic content (such as servlets and JSP files) to clients with minimal maintenance requirements for the Web server machines. It also isolates the back-end database from the Web server.

Article 7.1.4, Firewall and demilitarized zone (DMZ) configurations, compares the thick servlet redirector with administrative agent topology to other topologies that support a DMZ configuration.

Instructions

In order for an administrative agent to be set up, an administrative server must be installed and running. Record the host name of the administrative server. To set up an administrative server as an administrative agent:

  1. Install WebSphere Application Server. During the installation, do not create a default configuration.
  2. After installation, change to the in the product_installation_root/bin directory and make a backup copy of the admin.config file.
  3. Open the original admin.config file and delete the following lines:
    com.ibm.ejs.sm.adminServer.nameServiceJar=jar_file
    com.ibm.ejs.sm.adminServer.dbUser=user_name
    com.ibm.ejs.sm.adminServer.dbUrl=location
    com.ibm.ejs.sm.adminServer.dbPassword=password
  4. Add the following lines, where host_name is the host name of the administrative server.
    • These lines are required:
      com.ibm.ejs.sm.adminServer.bootstrapHost=host_name
      com.ibm.ejs.sm.adminServer.primaryNode=host_name
    • These lines are required if the administrative server is using nondefault port numbers.   Both nodes must use the same values.
      com.ibm.ejs.sm.adminServer.bootstrapPort=port_number
      com.ibm.ejs.sm.adminServer.lsdPort=port_number
    • These lines are optional:
      com.ibm.ejs.sm.adminServer.lsdHost=host_name
      com.ibm.CORBA.ListenerPort=port_number
  5. Save your changes and close the file.
  6. Start the WebSphere administrative server on Machine B.
  7. Start the administrative server agent on Machine A.
  8. Start the administrative console on Machine B and follow the directions for configuring virtual host aliases and the thick servlet redirector, as described in article 7.1.3.6.4, Thick servlet redirector sample topology.
Go to previous article: Thick servlet redirector sample topology Go to next article: Thin servlet redirector sample topology

 

 
Go to previous article: Thick servlet redirector sample topology Go to next article: Thin servlet redirector sample topology