Creating web werver definition in WAS Admin console

During the installation of the plug-in, the Plug-ins installation wizard creates a Web server configuration script named configure<Web_server_name>. This configuration script is used to create the Web server definition and, if necessary, the node definition in the configuration of the application server.

Each stand-alone application server can have only one Web server definition. A distributed server environment, on the other hand, can have multiple Web server definitions. The script creates a new Web server definition unless the Web server name is the same.
The Plug-ins installation wizard stores the script in the <plug-in_home>/bin
directory on the Web server machine. If the plug-in is installed locally (on the same machine as the application server), the configuration script will be run automatically. For remote installations, you must copy the script from the Web server machine to the <was_home>/bin directory on the application server machine for execution. The script runs against the default profile. If one machine is running under Linux or UNIX and the other machine is running under Windows, use the
script created in the <plug-in_home>/bin/crossPlatformScripts directory.

I tried this in my local environment, after installing plug-in i copied the configurewebserve1.bat from plug-in _home/bin directory and to the DMGR_HOME/bin directory and executed it. It took few minutes to execute and i could see this output



After that i logged into the WAS Admin Console and went to Servers - Web Servers, i could see webserver1 being added in there



When i clicked on the webserver1 i could see the details on the webserver1, such as location of web server installation, location of httpd.conf file,



If i click on the Plug-in properties link on the web server definition i can see the plugin related details, such as location of plugin installation, location of plugin-cfg.xml,..

Work load management for EJB

Workload management for EJB containers can be performed by configuring the Web container and EJB containers on separate application servers. Multiple application servers with the EJB containers can be clustered, enabling the distribution of EJB requests between the EJB containers

In this configuration, EJB client requests are routed to available EJB containers in a round-robin fashion based on assigned server weights. The EJB clients can be servlets operating within a Web container, stand-alone Java programs using RMI/IIOP, or other EJBs.

The server-weighted, round-robin routing policy ensures a distribution based on the set of server weights that have been assigned to the members of a cluster. For example, if all servers in the cluster have the same weight, the expected distribution for the cluster is that all servers receive the same number of requests. If the weights for the servers are not equal, the distribution mechanism sends more requests to the higher weight value servers than the lower weight value servers. The policy ensures the desired distribution based on the weights assigned to the cluster members.

You can also choose to have requests sent to the node on which the client resides as the preferred routing. In this case, only cluster members on that node are chosen (using the round-robin weight method). Cluster members on remote nodes are chosen only if a local server is not available.

When planning for clustering, determine the number of application servers and
their physical location. Determine the server weights to assign for application servers based on considerations such as system stability and speed. When creating the cluster, consider using the prefer local setting to ensure that when a client (for example, a servlet) calls an EJB, WLM will attempt to select the EJB on the same system as the client, eliminating network communication.

Local to a federated application server (managed node)

In this scenario, the Web server is installed on a machine that also has a managed node. Note that this scenario would also be the same if the deployment manager was also installed on machine A.

Assume that the application server is already installed, configured, and federated to the deployment manager cell. Perform the following tasks:

• Install the Web server on machine A.


• Install the Web server plug-in on machine A by performing the following steps:
  
  
  
  • Select Local installation.
  
  
  • Enter a name for the Web server definition. The default is webserver1.
  
  
  • Select the location for the plug-in configuration file. By default, the file will be placed in the directory that contains the server's configuration. For example, when the name specified for the Web server definition in the previous step is webserver1, the default location for the plug-in file is:
    <profile_home>/config/cells/<cell_name>/nodes/<AppSrv_node>/serve
    rs/webserver1/plugin-cfg.xml
  
  
  
  During the installation, the following tasks are performed:
  
  
  
  • The plug-in configuration file is created and placed in the location specified.
  
  
  • The Web server configuration file is updated with the plug-in configuration, including the location of the plug-in configuration file.
  
  
  • A script is generated to define the Web server and an unmanaged node to
    WebSphere Application Server. The script is located in:
    /Plugins/bin/configure
  
  
  
  


• At the end of the plug-in installation, you need to execute the script to define the Web server from the location the wizard stored it in on machine A. Make sure that the deployment manager is running on Machine B. The deployment manager configuration will be updated and propagated back to machine A at node synchronization.
  

The plug-in configuration file is generated automatically and propagated at the next node synchronization

Remote Web server on an unmanaged node

The deployment manager and the Web server are on separate machines. The script that defines the Web server is run against the deployment manager and you will see an unmanaged node created for the Web server node. In this case there wont be a node agent on the web server machine

Assuming that the Deployment manager is already installed on Machine B follow these steps

1. Install the Web server on machine B.


2. Install the Web server plug-in on machine B by performing the following
   steps:
   
   
   
   • Select Remote installation.
   
   
   • Enter a name for the Web server definition. The default is webserver1.
   
   
   • Select the location for the plug-in configuration file. By default, the file will be placed in the directory that contains the server's configuration. For example, when the name specified for the Web server definition in the previous step is webserver1, the default location for the plug-in file is:
     <plugin_home>/config/webserver1/plugin-cfg.xml
   
   
   
   During the installation, the following tasks are performed:
   
   
   
   • A temporary plug-in configuration file is created and placed in the location specified.
   
   
   • The Web server configuration file is updated with the plug-in configuration, including the location of the plug-in configuration file.
   
   
   • A script is generated to define the Web server and an unmanaged node to
     WebSphere Application Server. The script is located in: <plug-in_home>/bin/configure<web_server_name>
   
   
   
   


3. At the end of the plug-in installation, you need to copy the script to the
   /bin directory of the deployment manager machine (machine A),
   start the deployment manager, and execute the script.
   

When the Web server is defined to WebSphere Application Server, the plug-in configuration file is generated automatically. For IBM HTTP Server, the new plug-in file is propagated to the Web server automatically. For other Web server types, you need to propagate the new plug-in configuration file to the Web server.

Unmanaged web server

Unmanaed web servers reside on a System without a node agent. This is the only option in a standalone server environment and is a common option for Web Servers installed outside a firewall. The use of this topology requires that each time the plug-in configuration file is generated, it is copied from the machine where WebSphere Application Server is installed to machine where the server is running.

If the Web server is defined to an unmanaged node, you can do the following:

1. Check the status of the Web server.


2. Generate a plug-in configuration file for that Web server.


3. If the Web server is an IBM HTTP Server and the IHS Administration server is
   installed and properly configured, you can also:
   
   
   
   • Display the IBM HTTP Server Error log (error.log) and Access log (access.log) files.
   
   
   • Start and stop the server.
   
   
   • Display and edit the IBM HTTP Server configuration file (httpd.conf).
   
   
   • Propagate the plug-in configuration file after it is generated.
   
   
   
   

You cannot propagate an updated plug-in configuration file to a non-IHS Web server that is defined to an unmanaged node. You must install an updated plug-in configuration file manually to a Web server that is defined to an unmanaged node

Managed web server

Managed Web Server

In a distributed server environment, you can define multiple Web servers. These
Web servers can be defined on managed or unmanaged nodes. A managed node
has a node agent. If the Web server is defined to a managed node, you can do
the following:

1. Check the status of the Web server.


2. Generate a plug-in configuration file for that Web server.


3. Propagate the plug-in configuration file after it is generated.


4. If the Web server is an IBM HTTP Server (IHS) and the IHS Administration
   server is installed and properly configured, you can also:
   
   
   
   • Display the IBM HTTP Server Error log (error.log) and Access log
     (access.log) files.
   
   
   • Start and stop the server.
   
   
   • Display and edit the IBM HTTP Server configuration file (httpd.conf)
   
   
   
   

Web server support

WebSphere Application Server provides Web server plug-ins that work with a Web server to route requests for dynamic content, such as servlets, from the Web server to the proper application server. A Web server plug-in is specific to the type of Web server. It is installed on the Web server machine and configured in the Web server configuration.

A plug-in configuration file generated on the application server and placed on the Web server is used for routing information. In order to manage the generation and propagation of these plug-in configuration files, Web servers are defined to the WebSphere Application Server configuration repository. In some cases, Web server configuration and management features are also available from the WebSphere administrative tools.

The following are the supported Web servers for WebSphere Application Server
V6.1:

• Apache HTTP Server


• Domino Web Server


• IBM HTTP Server


• Microsoft Internet Information Services


•  Sun Java System Web Server (formerly Sun ONE and iPlanet)

Effect on JSESSIONID in case of Server failure

Server clusters provide a solution for failure of an application server. Sessions created by cluster members in the server cluster share a common persistent session store. Therefore, any cluster member in the server cluster has the ability to see any user’s session saved to persistent storage. If one of the cluster members fail, the user can continue to use session information from another cluster member in the server cluster. This is known as failover. Failover works regardless of whether the nodes reside on the same machine or several machines.

After a failure, WebSphere redirects the user to another cluster member, and the user’s session affinity switches to this replacement cluster member. After the initial read from the persistent store, the replacement cluster member places the user’s session object in the in-memory cache, assuming the cache has space available for additional entries.

The Web server plug-in maintains the cluster member list in order and picks the cluster member next in its list to avoid the breaking of session affinity. From then on, requests for that session go to the selected cluster member. The requests for the session go back to the failed cluster member when the failed cluster member restarts.

I tried this with my SessionAffinity.war, after establishing session with Server 2 i stopped that server and then i tried sending request to web server. The JSESSIONID was changed after 1 request and now the clone Id part was pointing to server 4

How to find out the WAS server handling request from JSESSIONID

Debugging problems in distributed environment is little more difficult then debugging problems in the Standalone environment, because how do you find out the server that is handling the request. The JSESSIONID cookie value contains the identifier of the server that is handling the request, take a look at Session Affinity for more details.

I wanted to try this so i created a simple SessionAffinityServlet like this

public class SessionAffinityServlet extends HttpServlet {
 private static final long serialVersionUID = 1L;
 protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
  response.setContentType("text/html");
  System.out.println("Inside SessionAffinity.doGet()");
  HttpSession httpSession = request.getSession();
  response.getWriter().println("Session Name " + ServerName.getFullName() +"
");
  response.getWriter().println("Session Id " + httpSession.getId() +"
");
  Cookie[] cookies = request.getCookies();
  for( int i = 0 ; i < cookies.length ;i++){
   response.getWriter().println(cookies[i].getName() + " " + cookies[i].getValue() +"
");
  }

 }
}

As you can see only thing that i am doing in the doGet() method is reading the value of all the cookies and writing them to output. I am also writing out name of the server handling the request in the output.

I deployed this code to server and when i tried hitting the server and i see values like this.




Now if i take the value of JSESSIONID the last part of the value is 14dtuu8g3. Now take this value and open the plugin-cfg.xml for web server plugin and search this value in it. You will find a Server element with value of CloneID matching the value from JSESSIONID that is the server dmgrNode01_server2 , handling the user request

<ServerCluster CloneSeparatorChange="false" GetDWLMTable="false" IgnoreAffinityRequests="true" LoadBalance="Round Robin" Name="cluster1" PostBufferSize="64" PostSizeLimit="-1" RemoveSpecialHeaders="true" RetryInterval="60">
<Server CloneID="14dtuu8g3" ConnectTimeout="0" ExtendedHandshake="false" LoadBalanceWeight="2" MaxConnections="-1" Name="dmgrNode01_server2" ServerIOTimeout="0" WaitForContinue="false">
<Transport Hostname="dmgr.webspherenotes.com" Port="9081" Protocol="http"/>
<Transport Hostname="dmgr.webspherenotes.com" Port="9444" Protocol="https">
<Property Name="keyring" Value="C:\Cert\HTTPServer\Plugins/config/webserver1/plugin-key.kdb"/>
<Property Name="stashfile" Value="C:\Cert\HTTPServer\Plugins/config/webserver1/plugin-key.sth"/>
</Transport>
</Server>
<Server CloneID="14dtuueci" ConnectTimeout="0" ExtendedHandshake="false" LoadBalanceWeight="2" MaxConnections="-1" Name="dmgrNode01_server4" ServerIOTimeout="0" WaitForContinue="false">
<Transport Hostname="dmgr.webspherenotes.com" Port="9082" Protocol="http"/>
<Transport Hostname="dmgr.webspherenotes.com" Port="9445" Protocol="https">
<Property Name="keyring" Value="C:\Cert\HTTPServer\Plugins/config/webserver1/plugin-key.kdb"/>
<Property Name="stashfile" Value="C:\Cert\HTTPServer\Plugins/config/webserver1/plugin-key.sth"/>
</Transport>
</Server>
<PrimaryServers>
<Server Name="dmgrNode01_server2"/>
<Server Name="dmgrNode01_server4"/>
</PrimaryServers>
</ServerCluster>


As you can see the plugin-cfg.xml has a ServerCluster element that has two Server child elements, that means the cluster has two servers and plugin will forward request to either of them

You can download the sample code from here

Managed Web Server

When defining Web servers to WebSphere Application Server, it is important to understand the concept of managed versus unmanaged nodes. A supported Web server can be on a managed node or an unmanaged node, depending on the environment on which you are running the Web server.

WebSphere Application Server supports basic administrative functions for all supported Web servers. For example, generation of a plug-in configuration can be performed for all Web servers. If the Web server is defined on a managed node, automatic propagation of the plug-in configuration can be performed using node synchronization. If the Web server is defined on an unmanaged node, automatic propagation of a plug-in configuration is only supported for IBM HTTP Servers.

WebSphere Application Server supports some additional administrative console tasks for IBM HTTP Servers on managed and unmanaged nodes. For example, you can start IBM HTTP Servers, stop them, terminate them, display their log files, and edit their configuration files.

Web Server in WAS Installation

The Web Servers are necessary in the WAS installation for directing traffic from browsers to the applications that run in WAS. The Web Servers use Web Server plug-ins that depend on plugin configuration file to determine whether a request is for dynamic content of static content, if the request is for static content web server will server it but if it is for dynamic content it will use the plugin configuration file to figure out how to route that request to web application.