Scalability refers to the capability to expand the capacity of an application hosted on the middle tier without interruption or degradation of the Quality of Service (QoS) to an increasing number of users. As a rule, an application server must always be available to service requests from a client.

As you may have discovered through experience, however, if a single server becomes over-subscribed, a connecting client can experience a Denial of Service (DoS) or performance degradation. This could be caused by a computer’s network interface, which has a built-in limit to the amount of information the server can distribute regardless of the processor’s capability of higher throughput, or because the J2EE server is too busy servicing existing processing requests.

As client requests continue to increase, the J2EE server environment must be scaled accordingly. There are two approaches to scaling:

By applying conventional wisdom, the most logical method for achieving scalability is though the implementation of a clustering solution.

High availability refers to the capability to ensure applications hosted in the middle tier remain consistently accessible and operational to their clients.

High availability is achieved through the redundancy of multiple Web and application servers within the cluster and is implemented by the cluster’s “failover” mechanisms. If an application component (an object) fails processing its task, the cluster’s failover mechanism reroutes the task and any supporting information to a copy of the object on another server to continue the task. If you want to enable failover:

In the event of a failure to one of the J2EE servers in a cluster, the load-balancing service, in conjunction with the failover mechanism, should seamlessly reroute requests to other servers, thus preventing any interruption to the middle-tier service.

For a server cluster to achieve its high-availability, high-scalability, and high-performance potential, load balancing is required. Load balancing refers to the capability to optimally partition inbound client processing requests across all the J2EE servers that constitute a cluster based on factors such as capacity, availability, response time, current load, historical performance, and also administrative weights (priority) placed on the clustered servers.

A load balancer, which can be software or hardware based, sits between the Internet and the physical server cluster, also acting as a virtual server. As each client request arrives, the load balancer makes near-instantaneous intelligent decisions about the J2EE server best able to satisfy each incoming request. Software-based load balancers can come in the form of computers, routers, or switches with integrated load-balancing software or load-balancing capabilities. Hardware load balancers are separate pieces of equipment that provide advanced load-balancing features and additional reliability features such as automatic failover to a redundant unit.

For a clustering solution to be realized for both J2EE Web and enterprise applications, the WebLogic cluster provides scalability (via load balancing) and high-availability (via failover mechanisms) support for the following J2EE objects:

The mechanisms the WebLogic cluster implements to ensure failover and load balancing for these objects vary in their implementation and are discussed in their respective sections later in this chapter.

The deployment restrictions differ between WebLogic Server 7 and WebLogic Server 7 SP1 (Service Pack 1) as follows:

IP Multicast is a network bandwidth-conserving broadcasting technology that reduces network traffic by efficiently delivering a single stream of information to a group of servers, known as a multicast group. In the context of the WebLogic cluster, the cluster itself is the multicast group, and the group’s membership or subscription to receive broadcast information is determined by the IP Multicast address specified for the cluster. For this reason, all WebLogic Server instances that constitute a WebLogic cluster share the same IP Multicast address. The Internet Assigned Numbers Authority (IANA), which controls the assignment of IP Multicast addresses, specifies an IP Multicast address must fall in the range of 224.0.0.0 to 239.255.255.255.

You specify the IP Multicast address when you create or configure a WebLogic cluster, as described later in this chapter.

Clustered WebLogic Servers use the IP Multicast address in conjunction with their TCP listen port to announce and listen for clusterwide communications, such as the following:

Because IP Multicast communications are critical to the operation of a WebLogic cluster, BEA recommends the following guidelines for avoiding transmission and reception problems with Multicast communication in a cluster:

In general, WebLogic Server uses IP sockets for all Remote Method Invocation (RMI) communications. However, in the context of a WebLogic cluster, WebLogic Server also uses IP sockets for the following types of inter-cluster communications:

Because these activities are critical, the type of IP socket reader you use has to be performance based. WebLogic Server can be configured to use the following IP socket reader implementations:

In general, for best performance, you should always use the native socket reader if possible. You should do so because, with the Java socket reader, you will always have to assess the potential socket usage of each managed server in a cluster based on peak usage of your cluster and then set the number of socket reader threads accordingly.

You can configure WebLogic Server easily to use the native socket reader thread implementation by following these steps in the Administration Console:

If you are new to the concept of clustering, it is imperative for you to understand what constitutes a typical WebLogic clustering environment before you even begin to design an architecture for your WebLogic cluster.

As illustrated in Figure 25.4, a typical WebLogic cluster environment can consist of the following logical software tiers and services, which do not necessarily imply a division in hardware in the overall clustering architecture.

Figure 25.4. The typical software tiers and services that can constitute a WebLogic cluster environment.

Generally, whenever an architectural discussion on how to design a WebLogic cluster occurs, the primary topics that influence the design directly relate to the way the cluster can guarantee the hosted application is very scalable and highly available. However, a WebLogic cluster in conjunction with a load-balancing mechanism, by default, provides a very scalable solution; WebLogic Servers can be added and removed from the cluster transparently to the clients.

Even though clustering is synonymous with both high availability and scalability, your architectural thoughts should be primarily aligned with ensuring a performance-oriented, highly available clustering solution. The following sections discuss two such clustering architectures you can consider: the combined-tier and multi-tier architectures, which differ based on the physical location of the presentation and object tiers.

The Combined-Tier Architecture

The combined-tier architecture, as illustrated in Figure 25.5, combines the Presentation and Object tiers of a J2EE application into a single WebLogic cluster. If a Web Proxy server is not used, the Web tier is also introduced into the cluster.

Figure 25.5. The combined-tier WebLogic cluster architecture.

This clustering architecture meets the high-availability and scalability requirements for most J2EE applications, with the addition of the following advantages:

• Ease of administration of the WebLogic cluster because a J2EE application needs to be deployed/undeployed only to and from the same WebLogic cluster using the Administration Console.

• Optimized local method calls between the Presentation and Object tier. WebLogic Server uses a collocation strategy to optimize method calls to clustered objects (EJB or RMI classes), which prioritizes method calls to objects that are hosted on the same WebLogic Server instance as their replica-aware stub and avoids incurring any additional network overhead. Because all application objects are available locally to each WebLogic Server in the same cluster, the combined-tier architecture presents the best performance for J2EE applications where there is a high frequency of method invocations in the Object tier by the Presentation tier.

The limitation of the combined-tier architecture is that it does not provide an opportunity for introducing load balancing between the Presentation and Object tiers, which may be necessary if the method calls to the Object tier become unbalanced between the servers in the cluster. In such a scenario, the appropriate approach would be to split the Presentation and Object tiers of the J2EE application onto separate physical clusters as in the multi-tier architecture.

The Multi-Tier Architecture

The primary purpose of the multi-tier architecture is to introduce load balancing between the Presentation and Object tiers of a clustered J2EE application. As illustrated in Figure 25.6, this load balancing is achieved by deploying the Presentation and Objects tiers of a J2EE application onto two different clustered servers.

Figure 25.6. The multi-tier WebLogic cluster architecture.

By hosting the Object tier on a dedicated clustered server, WebLogic Servers in the Presentation tier cannot use the collocation optimization strategy for accessing clustered objects.

As depicted in Figure 25.6, however, the Presentation tier does gain the capability to load-balance each method call to a clustered object. In the multi-tier architecture, a servlet acts as the client to the clustered objects. When requests are made to invoke an EJB, the servlet performs a JNDI lookup for the EJB and obtains a replica-aware stub for that bean, which contains the addresses of all servers that host the bean, as well as the load-balancing logic for accessing bean replicas.

Note

EJB replica-aware stubs and EJB home load algorithms are specified using elements of the EJB deployment descriptor.

The following are additional benefits for using the multi-tier architecture:

• You have more options for load balancing the entire WebLogic cluster without having to scale the Presentation and Object tiers in tandem. For example, if you have a higher frequency of client access to the Presentation tier than the Object tier, you can increase (scale) the number of WebLogic Servers hosting the Presentation tier to a smaller number of Object tier WebLogic Servers.

• Two clusters present a higher availability option for a J2EE application than just one, as in the case of the combined-tier architecture.

Although the multi-tier clustering architecture provides greater scalability and high-availability options, it does impose the following disadvantages when compared to the combined-tier architecture:

• Whenever you have to deploy and manage an application over two clusters, it requires twice as much effort as just using one cluster.

• There is a network overhead for all method calls to clustered objects. You also utilize more IP sockets in the Presentation tier to replicate sessions and connect to WebLogic Servers that host the clustered objects.

• If you create a DMZ for the Presentation tier by placing a firewall between the Presentation and Object tiers, you will need to bind all WebLogic Servers in the Object tier to public DNS names as opposed to IP addresses because IP address translation problems can occur between the two tiers.

Tip

You can use the Administration Console to set the ExternalDNSName attribute for a WebLogic Server instance, which defines its external DNS name.

The primary tools you have available to create or configure a WebLogic cluster are the Domain Configuration Wizard and the Administration Console. Which tool you use depends on the type of clustering architecture you want to employ and the capabilities of these tools to support your efforts.

The Domain Configuration Wizard is an excellent tool if you are creating a WebLogic cluster from scratch. This tool presents you with options on the type of WebLogic domain you want to create. One such option is a domain with an administration server and one or more managed servers that are clustered. However, this option creates the administration server and the clustered WebLogic Server instances on the same single server machine.

The Administration Console is a tool that you can use to configure a WebLogic cluster from existing managed servers in a domain. For example, if your clustering architecture warrants the clustered servers to be on separate server machines, the best approach would be to create the administration server and managed servers independently on each of those machines using the Domain Configuration Wizard. After the managed servers are created and registered with the domain’s administration server, you could use the Administration Console to graphically configure a cluster from the existing managed servers.

You can also use the Administration Console to do the following:

Before you start creating your WebLogic cluster, it is worth reviewing the following guidelines for creating a cluster:

This section provides a step-by-step guide showing how you can configure a WebLogic cluster using the Administration Console. The assumptions for this exercise are that you already have a WebLogic domain set up with two managed servers, and the network configuration for the WebLogic domain adheres to the clustering guidelines discussed in the preceding section. The name of the WebLogic domain, cluster and managed servers, and their network configurations can differ from those used in the example because the steps to configure the WebLogic cluster still remain the same.

As illustrated in Figure 25.8, the WebLogic cluster to be configured (mycluster) will be hosted on a single, non-multihomed server machine, which implies that the same IP address will be used for each managed server, with differing listen port numbers. The attributes of the managed servers that will be used to form the mycluster WebLogic cluster are described in Table 25.1.

Figure 25.8. The mycluster WebLogic cluster on a single, non-multihomed server machine.

To configure the mycluster WebLogic cluster using the Administration Console, follow these steps:

This completes the tasks related to configuring a WebLogic cluster using the Administration Console. The next section describes how you can now start your WebLogic cluster.

You can start a WebLogic cluster using the following methods:

To start any clustered managed server, you first need to start the administration server for the domain, which will copy the clustered configuration information to the clustered managed servers upon startup. The general steps for starting an administration server are as follows:

The following sections describe how to start the mycluster WebLogic cluster created previously using both of these methods.

Starting a WebLogic Cluster Using the Command Shell

You start managed servers that participate in a WebLogic cluster in the same manner as you would start them if they were not clustered. The command syntax for starting a managed server is

StartManagedWebLogic server_name address:port

where

• server_name is the name of the managed server you need to start

• address is the IP address or DNS name for the administration server for your domain

• port is the listen port for the administration server for the domain

For example, to start the clustered managed servers in mycluster, you enter the following commands in separate command shells:

StartManagedWebLogic NodeA EINSTEIN:7001

StartManagedWebLogic NodeB EINSTEIN:7001

As shown in Figure 25.12, during the startup process, a clustered managed server joins its WebLogic cluster and tries to synchronize information with other online managed servers in the cluster.

Figure 25.12. Starting the WebLogic cluster using the command shell.

Starting a WebLogic Cluster Using the Administration Console

The primary advantage of using the Administration Console to start a WebLogic cluster is that you can start all constituent clustered managed servers at the same time. Alternatively, you can start the clustered managed servers individually, if required.

The Administration Console can, by default, be used to kill managed servers without the Node Manager. However, the Administration Console can only start managed servers in conjunction with the Node Manager. For this reason, even if the clustered managed servers are located on the same machine as the administration server, you need to perform the following tasks to enable the Administration Console to start a clustered managed server or a cluster of managed servers:

• Configure and run the Node Manager on each server machine where a clustered managed server resides. For example, if you have configured a WebLogic cluster on a single non-multihomed machine (such as mycluster), you still need to configure and run the Node Manager on that machine.

• Configure machine definitions for each managed server in the WebLogic cluster.

• Configure the Node Manager’s listen address and port for each machine definition.

• Configure SSL communication for all managed servers in the WebLogic cluster. (Node Manager uses SSL for all communication between the administration server and managed servers.)

Even though these procedures may appear to be very complicated, they are relatively easy to perform and are methodically explained in Chapter 4.

After you configure your administration server to remotely start managed servers using the Node Manager, you can follow these steps to start a WebLogic cluster:

1. Expand the Clusters node in the left pane of the Administration Console.

2. Right-click the WebLogic cluster you want to start (mycluster) and select the Start This Cluster option.

3. On the next screen, confirm you want to start the WebLogic cluster.

As shown in Figure 25.13, this procedure initiates WebLogic tasks to start all the managed servers assigned to your WebLogic cluster.

Figure 25.13. The Tasks screen in the Administration Console illustrating the startup of all clustered managed servers in the mycluster WebLogic cluster.

After you set up a WebLogic cluster, the next administration task is to adopt a technique that allows you to monitor the number of active servers participating in it. This task is important because in a production environment the capability to provide performance-based high availability and workload load balancing is directly influenced by the number of active managed servers that constitute a WebLogic cluster.

The most immediate technique to accomplish this task is via the Administration Console using the following steps:

Alternatively, you can create a servlet or JavaServer Page to access WebLogic Server’s Runtime MBeans to display customized and consolidated information about your WebLogic domain and its managed resources, including nonclustered and clustered servers. To programmatically retrieve information about a WebLogic cluster, you must access the APIs of an instance of the ClusterRuntimeMBean, which are hosted only on those managed servers actively participating in a WebLogic cluster.

To assist you in creating such a servlet or JavaServer Page, Listing 25.1 provides the fully commented Java code for the infoCluster servlet, which performs the following tasks:

import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
import java.util.Set;
import java.util.Iterator;
import javax.naming.*;
import weblogic.jndi.Environment;
import weblogic.management.MBeanHome;
import weblogic.management.configuration.ServerMBean;
import weblogic.management.runtime.ClusterRuntimeMBean;
import weblogic.management.WebLogicObjectName;
public class infoCluster extends HttpServlet {

    public void service(HttpServletRequest req,
                      HttpServletResponse res)
       throws IOException {

   // Declare MBean and other variables

    MBeanHome home = null;
    ServerMBean server = null;
    ClusterRuntimeMBean clusterRuntime = null;
    String name="";

    String[] aliveServerArray = null;

   // Initialize
    Set mbeanSet = null;
    Iterator mbeanIterator = null;
   // Set the content type for the response
    res.setContentType("text/html");
   // Obtain a PrintWriter to insert HTML into
    PrintWriter out = res.getWriter();
   // Setup the start of the HTML page
    out.println("<HTML><HEAD><TITLE>infoCluster Servlet Example</TITLE>");
    out.println("<BODY><H1><strong><font size=5>Your WebLogic Cluster" +
                "Information:</font></strong></H1>");
   // Set the initial context
    try {
         Environment env = new Environment();
         Context ctx = env.getInitialContext();
   // Get the Administration MBeanHome
         home = (MBeanHome) ctx.lookup("weblogic.management.adminhome");
   } catch (Exception e) {
             out.println("<br>Exception caught: " + e);
      }
    try {
         out.println("<p><BR><strong><u>Your Active Domain is " +
                     "<font color=#000000>"+ home.getActiveDomain().getName() +
                     "</font></u></strong></p>");
    } catch (Exception e) {
          out.println("<br>Exception: " + e);
      }
    out.println("<p><strong> <u>The WebLogic Servers in your Domain are:" +
                "</u></strong></p>");
    try {
         mbeanSet = home.getMBeansByType("Server");
         mbeanIterator = mbeanSet.iterator();
         while(mbeanIterator.hasNext()) {
               server = (ServerMBean)mbeanIterator.next();
               out.println("<p><strong> <u> Server Name</u>:" +
                           "<font color=#000000>" + server.getName() +
                           "</font> <BR>");
               out.println("ListenAddress: " + server.getListenAddress() +
                           "<BR>");
               out.println("ListenPort: " + server.getListenPort() + "<BR>");
         }
    } catch (Exception e) {
          out.println("<br>Exception: " + e);
      }
   // Retrieving a list of ClusterRuntime MBeans in the domain.
    out.println("<p><strong><u>Your WebLogic Clustering Information:" +
                "</u> <BR>");
    try {
         mbeanSet = home.getMBeansByType("ClusterRuntime");
         mbeanIterator = mbeanSet.iterator();
          while(mbeanIterator.hasNext()) {
   // Retrieving one ClusterRuntime MBean from the list.
                clusterRuntime = (ClusterRuntimeMBean)mbeanIterator.next();
   // Get the name of the ClusterRuntime MBean.
                name = clusterRuntime.getName();
                out.println("Cluster information retrieved from the " +
                            "ClusterRuntime MBean on server " + name + "<BR>");
   // Using the current ClusterRuntimeMBean to retrieve the number
   // of servers in the cluster.
                out.println("Number of active servers in the cluster: " +
                             clusterRuntime.getAliveServerCount() + "<BR>");
   // Retrieving the names of servers in the cluster.
                aliveServerArray = clusterRuntime.getServerNames();
                break;
          }
    } catch (Exception e) {
              out.println("<br>Exception: " + e);
      }
    if(aliveServerArray == null) {
       out.println("<br>There are no running servers in the cluster");
    }
    else {
          out.println("The running Managed Servers in the cluster are: ");
           for (int i=0; i < aliveServerArray.length; i++) {
                out.println("("+ aliveServerArray[i] + ")" +"   ");
           }
         }
      out.println("</strong> </p></BODY></HTML>");
     }
}

The infoCluster servlet should be deployed to your administration server to ensure you are monitoring your WebLogic cluster from an external server. The output of the infoCluster servlet is shown in Figure 25.15.

Figure 25.15. The output of the infoCluster servlet in a browser.

The WebLogic proxy plug-in is an ideal solution if you want to leverage an existing Web tier composed of Netscape, Microsoft, or Apache Web servers to proxy (forward) connection requests to the WebLogic cluster. Alternatively, you can also use WebLogic Server with the HttpClusterServlet as a proxy server.

In a proxy server load-balancing scenario, when an HTTP client requests a servlet or JSP, the proxy plug-in or HttpClusterServlet proxies the request to a managed server in the WebLogic Server cluster. The accessed servlet or JSP maintains data on behalf of a connecting client by using a dedicated HttpSession object, which is created on a per-session basis. When the HTTP response is sent back to a client via the proxy server, the client’s browser is instructed to write a cookie that lists the primary and secondary locations of the session’s HttpSession object.

The primary location is the address of the managed server that received and processed the initial HTTP connection request. For subsequent HTTP requests, the proxy plug-in or HttpClusterServlet automatically maintains a “sticky” connection between the client and its primary HttpSession object location. The secondary location is the address of a managed server that maintains a replica of the HttpSession object that is used for in-memory session state failover purposes only; this object is discussed later in this chapter.

The limitation for using a proxy server load-balancing solution is that you are currently constrained to using a round-robin strategy for distributing client requests to the managed servers in a WebLogic cluster.

To showcase the load-balancing capabilities of the WebLogic proxy plug-in, as well as set up a WebLogic environment for subsequent examples in this chapter, the following section discusses how you can easily configure an HttpClusterServlet load-balancing solution.

Configuring the HttpClusterServlet As a Load-Balancing Solution

By default, the HttpClusterServlet is included with every WebLogic Server installation. However, for it to be able to function, the servlet must be deployed as the default application to WebLogic Server that will serve as the proxy server for a domain. Previously in this chapter, you configured the mycluster WebLogic cluster in your WebLogic domain. To demonstrate the load-balancing capabilities of the WebLogic proxy plug-in, you can deploy the HttpClusterServlet as the proxyApp default Web application on the administration server (AdminServer) of your WebLogic domain, which will serve as the proxy server, as illustrated in Figure 25.16.

Figure 25.16. Load balancing the mycluster WebLogic cluster using the HttpClusterServlet.

Caution

This configuration is used for demonstration purposes only. In a production environment, you should use a dedicated managed server as a proxy server and ensure the administration server is used only for administration tasks.

Follow these steps to create and deploy the proxyApp Web application to the administration server of your WebLogic domain:

Note

If you use different names for your domain, administration server, and WebLogic cluster, substitute those names where appropriate.

1. Create a directory named proxyApp in the root of your %BEA_Home%objectminduser_projects directory. Within this directory, create another directory called WEB-INF.

2. Create a file called web.xml in the WEB-INF directory and open it with any text editor.

3. Enter the text shown in Listing 25.2, ensuring you modify the names and port numbers of the managed servers you specified when you created your WebLogic cluster.

   Example 25.2. The web.xml File for the proxyApp Application

   <web-app>
       <servlet>
           <servlet-name>HttpClusterServlet</servlet-name>
           <servlet-class>weblogic.servlet.proxy.HttpClusterServlet</servlet-class>
           <init-param>
               <param-name>WebLogicCluster</param-name>
               <param-value>EINSTEIN:7003|EINSTEINt:7005</param-value>
           </init-param>
           <init-param>
               <param-name>DebugConfigInfo</param-name>
               <param-value>ON</param-value>
           </init-param>
       </servlet>
       <servlet-mapping>
           <servlet-name>HttpClusterServlet</servlet-name>
           <url-pattern>/</url-pattern>
       </servlet-mapping>
       <servlet-mapping>
           <servlet-name>HttpClusterServlet</servlet-name>
           <url-pattern>*.jsp</url-pattern>
       </servlet-mapping>
       <servlet-mapping>
           <servlet-name>HttpClusterServlet</servlet-name>
           <url-pattern>*.htm</url-pattern>
       </servlet-mapping>
       <servlet-mapping>
           <servlet-name>HttpClusterServlet</servlet-name>
           <url-pattern>*.html</url-pattern>
       </servlet-mapping>
   <web-mapping>
   

   You can also include the following useful parameter, which creates a proxy log file under the default temp directory:

   <init-param>
       <param-name>Debug</param-name>
       <param-value>ALL</param-value>
   </init-param>
   

4. Save the file.

5. Create the proxyApp Web application (WAR file) by executing the following command from within the root of the proxyApp directory:

   jar cfv proxyApp.war *.*
   

   Caution

   Ensure that only the WEB-INF directory and web.xml file exist in this directory before you create the proxyApp Web application.

6. From the left pane of the Administration Console, select Web Applications under the Deployments node and click the Configure a New Web Application link.

7. At the bottom of the screen, navigate until you find the proxyApp directory you created earlier. Click the proxyApp link and then click the Select link next to proxyApp.war, as shown in Figure 25.17.

   

   Figure 25.17. Selecting the proxyApp Web application for deployment.

8. On the Configure Application or Component screen, select your target proxy server (AdminServer) and click Configure and Deploy.

After you deploy the proxyApp Web application, the next task is to specify that it is the default Web application on your proxy server. To do this, follow these steps:

1. In the left pane of the Administration Console, open the Servers directory and select your proxy server’s (AdminServer) node.

2. Select the Connections, HTTP tab.

3. Select proxyApp as the Default Web Application and click Apply.

As you can see in Figure 25.18, you can test the HttpClusterServlet by using the following URL in a Web browser, substituting the correct IP address or DNS name and port for your proxy server:

http://EINSTEIN:7001/foo.jsp?__WebLogicBridgeConfig

Figure 25.18. Testing the functionality of the HttpClusterServlet.

From this point onward, you can access applications deployed on your WebLogic cluster via a single entry point, your proxy server, using the following URL:

http://ip_address_of_proxy_server:port_of_proxy_server/<Application>

If you require a more sophisticated HTTP connection distribution strategy than just purely a round-robin approach, you should opt to use a hardware load-balancing appliance solution.

In a load-balancing appliance scenario, when a client requests a servlet or JSP directly using an IP address, the load balancer routes the client’s connection request to any available managed server in the WebLogic cluster in accordance with a selected load-balancing algorithm supported by the appliance. The managed server that receives the client request serves as the primary location of the client’s HttpSession object. The secondary or replica HttpSession object is immediately created on another managed server. As a client initiates subsequent HTTP requests to the WebLogic cluster, the load-balancing appliance uses an identifier in the client-side cookie to ensure these requests are directed to the primary location of the client’s HttpSession object.

In its default configuration, WebLogic Server uses client-side cookies to keep track of the primary and secondary locations of the HttpSession object. Hence, to ensure a “sticky” connection between the client and its primary HttpSession object location using cookies, the load-balancing appliance must support a passive or active cookie persistence mechanism, as well as SSL persistence. If cookies are not supported by the client, as in the case of WAP-enabled devices, you must do the following:

With in-memory replication, a primary HttpSession object is created on the clustered managed server to which the client first connects and accesses a servlet or JSP. To support automatic failover for HTTP session states, a clustered managed server replicates the primary HttpSession object in memory to a secondary managed server in the same WebLogic cluster. The replicated HttpSession object is known as the replica or backup HttpSession object. As session data is modified in the primary HttpSession object, the managed server ensures the replica is kept up to date so that it may be used if the clustered managed server that hosts the primary HttpSession object fails.

If the managed server hosting a primary HttpSession object were to fail, the mechanism that a WebLogic cluster uses to provide transparent session state failover is dependent on the type of load-balancing solution that is being used: a WebLogic proxy plug-in or hardware appliance.

In the case of a load-balancing solution that uses a WebLogic proxy plug-in and client-side WebLogic Server cookies, the proxy plug-in uses the cookie information to automatically redirect subsequent HTTP requests to the clustered server hosting the replica HttpSession object. The replica HttpSession object is then upgraded to the primary HttpSession object, and a replica HttpSession object is created on another managed server in the WebLogic cluster. In the HTTP response, the proxy server updates the client’s cookie to reflect the new primary and secondary servers as a safeguard for subsequent HttpSession object failovers.

In the case of a load-balancing solution that uses a hardware appliance, the primary and replica HttpSession object locations in a cookie or URL serve only as a history for a client’s session state locations. Because the hardware appliance will redirect the failed HTTP request to any available managed server in a WebLogic cluster based on a certain algorithm, the WebLogic cluster uses the replica to create a new primary HttpSession object on the newly targeted managed server. Hence, the replica HttpSession object remains as the replica. The new information about the primary HttpSession object location is updated in the client’s cookie, or via URL rewriting.

<session-descriptor>
  <session-param>
    <param-name>PersistentStoreType</param-name>
    <param-value>replicated</param-value>
  </session-param>
</session-descriptor>

Configuring Replication Groups to Specify Replica Object Servers

When a primary HttpSession object is created, it is the responsibility of the hosting managed server to rank other managed servers within the same WebLogic cluster to determine which server will host the replica HttpSession object. By default, a managed server will attempt to create the replica HttpSession object on a different machine than the one that hosts the primary HttpSession object.

Through the configuration of replication groups, however, you can influence the location of the replica HttpSession objects. A replication group is a list of clustered managed servers within the same WebLogic cluster that serve as preferred locations for replica HttpSession objects.

You can use the Administration Console, as shown in Figure 25.19, to assign a clustered managed server to

Figure 25.19. Configuring replication groups using the Administration Console.

• A replication group, which defines a preferred logical group of clustered managed servers for hosting the replica HttpSession objects

• A preferred secondary group, which defines a secondary logical group of clustered managed servers that can be considered for hosting the replica HttpSession objects

How a managed server ranks other managed servers in a WebLogic cluster is described in Table 25.2.

Table 25.2. The Ranking Rules for Selecting a Host for a Replica HttpSession Object

Server Rank	Managed Server Resides Physically on Another Machine	Managed Server Is a Member of the Preferred Replication Group
1	Yes	Yes
2	No	Yes
3	Yes	No
4	No	No

Using the rules described in Table 25.2, the primary managed server ranks other members of the cluster and selects the highest-ranked server to host the replica HttpSession object.

Demonstrating the In-Memory Replication of Session State

The quickest way to verify whether your WebLogic cluster is providing session state failover using in-memory replication in conjunction with your load-balancing solution is to build and deploy the inmemrep Web application, which comes bundled with WebLogic Server if you opted to install the WebLogic Server examples during the server’s installation process.

Note

You need to install the WebLogic Server examples to deploy the inmemrep Web application code.

The following steps describe how to build and deploy the inmemrep Web application to the WebLogic cluster (mycluster) you configured earlier in this chapter:

1. Open a new command shell and set up your WebLogic environment by executing the setEnv command from the root of your domain’s (objectmind) directory.

2. Change directories to the following:

   %wl_home%samplesserversrcexamplesclustersessionrepinmemrep
   

3. Use the build script to compile the Web application by executing the ant command. This process builds both the JSP and deployment descriptors and packages them in a WAR file named InMemRepClient.war.

4. From the Administration Console, click the Application link under the Deployments node in the left pane and click the Configure a New Application link.

5. Use the links at the bottom of the page to navigate to the location of the InMemRepClient.war file and click the Select link next to the InMemRepClient.war filename.

6. Select the cluster that was previously created (mycluster) as your target for deployment and click Configure and Deploy.

When the InMemRepClient Web application is deployed, you can access it by navigating to the following URL in a Web browser:

http://ip_address_of_proxy:port_of_proxy /InMemRepClient/Session.jsp.

You can add some values to the JSP, as shown in Figure 25.20, and bring down the clustered server from which you just requested the JSP. Now you can refresh the browser to demonstrate in-memory session persistence. You will notice the session is now hosted on another machine.

Figure 25.20. The InMemRepClient Web application demonstrating in-memory session persistence.

File-based persistence implies that you will be using a system directory to store all the session information related to your Web application. The requirements for using this type of session persistence mechanism are as follows:

To specify file-based persistent session storage for a Web application, edit the associated weblogic.xml file using an XML editor and set the value of the PersistentStoreType and PersistentStoreDir parameters as follows:

<session-descriptor>
  <session-param>
    <param-name>PersistentStoreType</param-name>
    <param-value>file</param-value>
    <param-name>PersistentStoreDir</param-name>
    <param-value>your_shared_folder_name</param-value>
  </session-param>
</session-descriptor>

Here, your_shared_folder_name specifies the directory path where the clustered managed servers will write and retrieve their respective session’s data.

Using the file-based persistence approach allows all managed server instances in a WebLogic cluster to have access to all the generated session data. Hence, client HTTP requests can be serviced by any managed server in a WebLogic cluster. The HttpSession object can fail over to any clustered server in a WebLogic cluster and still have access to its session state data.

However, there is a significant reduction in the WebLogic cluster’s performance using this approach because session state is continuously being written to the disk system, and session data needs to be retrieved from the disk upon session failover. Also, an added concern is that if you lose the disk system where the session is persisted, you also lose all your session data.

JDBC-based persistence is similar to file-based persistence because it also allows all managed server instances in a WebLogic cluster to have access to all the generated session data, with the exception that the session data is now persisted to database instead of a file system. The advantage of using a database for storing persistent session storage is that you can leverage the high-availability, scalability, and high-performance features of a database to safeguard as well as provide performance-based writing and retrieval of session data. However, this method of session persistence is still not as fast as in-memory replication.

To specify JDBC-based persistent session storage for a Web application, follow these steps:

Here, Connection_Pool_Name specifies the JDBC connection pool to be used for persistence storage.

When you deploy a clustered EJB to a clustered WebLogic Server, the replica-aware Home stub of the bean is bound to the server’s local JNDI tree. The clustered server then updates the clusterwide JNDI tree by sending a JNDI announcement to other server members of the WebLogic cluster via a multicast broadcast message.

When clients connect to a WebLogic cluster and look up a clustered EJB, they obtain a replica-aware stub for that EJBHome object. However, instead of representing a single EJBHome object, this replica-aware stub contains the following:

When a client invokes the create() method, the replica-aware Home stub routes the call to one of the EJBHome object replicas it is aware of via the replica handler. The replica then creates an instance of the bean and returns a replica-aware Remote (EJBObject) stub, which contains the logic to locate replicas (EJBObject objects) on any clustered server instance on which the EJB is deployed. However, unlike EJBHome objects, which can all use replica-aware Home stubs, only stateful and stateless session EJBs can leverage replica-aware Remote stubs.

Because all Home stubs are replica aware, the replica handler can provide the following load-balancing and failover algorithms for routing calls to the EJBHome object:

You can configure a cluster to use one of the preceding algorithms, with the exception of the parameter-based routing mechanism, using the Administration Console:

The algorithm you select is maintained within the replica-aware stubs obtained for the clustered EJB objects.

WebLogic Server does not always perform load balancing for an EJB method call because it is more efficient to use a replica that is collocated with the Remote stub itself. This prevents additional overhead for calling a replica located on a remote server.

By default, a stateless session bean’s Home stub provides load balancing and failover for its method invocations to any clustered server where the bean is deployed. Because stateless session beans hold no state on behalf of their clients, stateless beans of the same type are identical in a WebLogic cluster. For this reason, a replica-aware Remote stub can also load-balance its method invocations to any clustered server where the bean is deployed.

By default, the Remote stub supports automatic failover of only those methods that occur after a method completes or if the method fails to connect to a server. If a method incurs a failure before it completes, the Remote stub does not automatically fail over the method invocation from one replica to another. Preventing automatic failover in this manner ensures a recovered method call is never able to duplicate persistent information, which could have been modified when the method initially failed.

If your stateless session bean contains idempotent methods, however, you can force the replica handler to retry a failed call without knowing whether the method actually completed on the failed server. Idempotent methods are those methods that typically do not persist their results and can be called repeatedly with the same arguments to produce the same result, irrespective of the location of the bean.

You can specify that a stateless session bean contains idempotent methods via the following clustering-descriptors in the bean’s deployment descriptors:

By default, a stateful session bean’s Home stub provides load balancing and failover for its method invocations to any clustered server where the bean is deployed.

When the bean instance is created, however, the bean’s hosting WebLogic Server selects a secondary WebLogic Server instance to host the replicated state of the EJB using the same rules as defined in replication groups for the HTTP Session state. The primary WebLogic Server hosts the actual instance of the bean. To minimize resource overhead, the secondary server stores only the replicated state of the primary bean for failover purposes; the secondary server does not create an instance of the bean. Replication groups were discussed earlier in this chapter.

The client receives a Remote stub that maintains a list of the primary and secondary server locations of the bean’s state. However, all method calls to the bean are “pinned” to the primary state location; there is no load balancing of remote method calls. As a client modifies the primary state, the EJB container replicates the state from the primary to the secondary servers in the WebLogic cluster. This replication scheme is similar to that used by the HTTP session state and occurs immediately after the transaction commits or after each method invocation. To replicate the state of a stateful session EJB, ensure the bean is homogeneously deployed within the WebLogic cluster.

If the primary state location should fail, the secondary WebLogic Server creates a new bean instance using the replicated state, thus forming a new primary server location for the bean’s method calls. The replica handler redirects subsequent requests to the bean to this new primary state. At the same time, a WebLogic Server is selected to hold the bean’s replicated state (secondary), and the client’s replica-aware Remote stub is updated with the new primary and secondary bean locations.

By default, an entity bean’s Home stub provides load balancing and failover for its method invocations to any clustered server where the bean is deployed.

The load balancing and failover capabilities of the Remote stub depend on the read-write and read-only cache strategy employed by the entity bean as follows: