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
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.
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.
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:
- Install WebSphere Application Server. During the installation, do not create a default
configuration.
- After installation, change to the in the product_installation_root/bin
directory and make a backup copy of the admin.config file.
- 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
- 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
- Save your changes and close the file.
- Start the WebSphere administrative server on Machine B.
- Start the administrative server agent on Machine A.
- 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.
|
|