Developing Web Applications in a Clustered Environment Using WLST and BEA Workshop

Step 2: Start

In this step you start the clustered domain, and then deploy the application to the cluster.

Starting the clustered domain

To start the cluster, you use a script called startcluster.py. Since starting servers with WLST utilizes the WLS Node Manager, first you start the node manager and connect to it. Then, you start the Admin Server, and connect to it. Finally, you start the cluster.

The following code is from the startcluster.py script:

# set the following values if your installation is different
bea_home='c:\wls9'
weblogic_home='c:\\wls9\\weblogic90'
# nmhome and domaindir are based on the above settings
nmhome = weblogic_home + '\\common\\nodemanager'
domaindir = bea_home + '\\user_projects\\domains\\' + sys.argv[2]
# Start the node manager process
startNodeManager(verbose='true', NodeManagerHome=nmhome)
#Connect to the node manager
nmConnect(domainName='myclusterdomain',domainDir=domaindir)
# Start the Admin Server
nmStart('AdminServer')
# Connect to the Admin Server
connect('weblogic','weblogic', sys.argv[1])
# Start the cluster comprising of ms1 and ms2
start(sys.argv[3],'Cluster')
exit()

To run the script, type:

wlst.cmd startcluster.py t3://localhost:9001 
                         myclusterdomain wlsCluster

Deploying the application

To deploy the application, you use the script called deploy.py. Here I am assuming you use the demonstration application, helloApp, which is part of the wlst-scripts.zip download accompanying this tutorial (see the helloApp directory).

The key command in the deploy script is:

deploy(appName='workshop_cluster_deployment',path=sys.argv[2],
       targets=sys.argv[3])

Note that since the WLST deploy command is an online command, the deploy script first connects to the Admin Server. The deploy.py script assumes you'll pass in the following information:

• Path to the application
• Target server or cluster
• URL to run the application

The appName is hard-coded to workshop_cluster_deployment, to be consistent with Workshop (as you'll see later).

To run the script, type:

wlst.cmd deploy.py t3://localhost:9001 /wlst-workshop/helloApp 
            wlsCluster http://localhost:9101/helloApp/hello.html

Note that two other scripts are provided ( stopserver.py and startserver.py), which stop and start one of the two managed servers. I'll use this to show failover in the second part of this tutorial.

At this point you've used WLST to start the cluster and deploy the application to the cluster. Let's now run it!

Step 3: Running the Application

Let's now look at running the application from the browser. The script in Step 2 will invoke the browser with the URL below, or alternatively you can click here: http://localhost:9101/helloApp/hello.html.

Voila! You should see the application. You can now type in your name, and then click on "Submit name." A JSP (called hello.jsp) will be invoked that will say hello to you and print session information, which you'll use later.

You can also go to: http://localhost:9102/helloApp/hello.html and see the same application running on the other managed server. Of course, this setup is not very useful in practice; what you really want is for client requests to be automatically load balanced across the two servers, thereby achieving better scalability. To do this, you need to introduce a load balancer to front end the HTTP requests. The Apache Web Server, with the WebLogic Apache plug-in, is one such load balancer.

Using Apache for Load Balancing

You'll first need to download and install the Apache Web server, and then install the Apache HTTP Server Plug-in. Note that the plug-in is not installed by default when you install WebLogic Server—you need to select Custom Install and select the plug-in check box.

You add the following snippet to the Apache http.conf configuration file, to configure the plug-in:

LoadModule weblogic_module    modules/mod_wl_20.so
<IfModule mod_weblogic.c>  
  WebLogicCluster localhost:9101,localhost:9102
    MatchExpression /hello 
</IfModule>

This tells the plug-in to look for URLs with the string /hello and to redirect such requests to the cluster, represented by localhost:9101 and localhost:9102. When both servers are available, the HTTP Server will load balance requests. When only one of the servers is available, all the traffic will be routed to that server.

Now bring up a browser and simply type:

http://localhost/helloApp/hello.html

The request will now go to the Apache HTTP Server (set up using the default Port 80), which then routes to one of the available managed servers. To see which managed server serviced the request, you can use the getstatus.py script. Note that if you are using WebLogic Server 9.1 you'll need to copy the supplied getstatus.py.91 script into getstatus.py, to account for runtime MBeans changes between the two releases. This script uses the runtime MBean InvocationTotalCount for the hello.jsp service on each managed server to report how many times the hello.jsp service was invoked. The output will look something like:

ms1 count: 1
ms2 count: 0

This tells you that ms1 serviced the request.

At this point, you have used WLST to create a fully functional clustered environment for testing the application. You can now iteratively make changes to the app, redeploy the app to the cluster and test. WLST and the scripts provided here do all the hard work, so you as a developer can focus on your application, and quite easily test in a clustered environment.

Let's take a look at these three steps again: create, start, run—this time, right from the BEA Workshop IDE. I'll primarily use JSP functionality in the example. Workshop provides a professional JSP source editor, code completion, custom tag library support, simultaneous two-way source and visual JSP editors, JSP 2.0 (including EL), JSTL, a graphical editor for TLDs, and a graphical editor for web.xml.

To get started, first you'll need to extract the workshop-scripts.zip into your Workshop workspace, under \.metadata\.plugins\org.eclipse.debug.core\.launches.

Now, you'll need to bring the helloApp application into Workshop. You can accomplish this by typing File->New->Web Application Project, and then selecting Existing Web Application. You'll then see a screen similar to that shown in Figure 1.

Figure 1: Bringing an existing application into Workshop

Now browse to the location of the helloApp directory (under c:\wlst-workshop), and click Finish. You'll be asked whether to create a default source folder; click Yes.

The traditional way to run Web apps in Workshop is to deploy against a single-server environment. To do this, first you create an empty domain using the Configuration Wizard, which is available from the Start Menu->All Programs->BEA Products->Tools->Configuration Wizard. Select all defaults, except when prompted for username and password; use weblogic for both. Also, when prompted to name the domain, call it singleserver.

Note that you could also create this domain using WLST; however, for a basic domain such as this one, the Configuration Wizard does a nice job at getting you up and running quickly.

After creating the domain, go back to Workshop and invoke the Run command:

Figure 2: Invoking the Run command

Figure 3 shows the resulting screen.

Figure 3: Running helloApp using the Workshop Run command

Select the helloApp project and then specify your Server Configuration by going to the Run with server entry and clicking on New. You now need to populate the server configuration. Figure 4 shows the values that you used.

Figure 4: Entering server information for Weblogic Server

Now click Run on the previous screen. Workshop will ask you if you want it to create the weblogic.xml file, since helloApp does not have one; select Yes. The server instance will then be started with helloApp deployed. The script will also invoke the browser with the URL below, or alternatively, you can click here: http://localhost:7001/hello.html. Note also that you no longer need to put helloApp in the URL as the weblogic.xml file specifies this app as belonging to the root context (/).

When Workshop deploys the application, it uses a hard-coded application name of __nitrox_autoconfig_deployment. If you go to the Admin Console and click on deployments, this is the name you'll see. You follow a similar paradigm for cluster deployment but to avoid conflict you use workshop_cluster_deployment.

Step 1: Create

Now let's look at deploying to a cluster from Workshop. Since the Workshop Run command assumes deployment to a single server, you won't use the Run command to deploy to a cluster. Instead, you'll use the External Tools feature of Workshop to invoke the WLST scripts.

To create the cluster, go to External Tools as shown in Figure 5.

Figure 5: Invoking External Tools

Now select wlst-createcluster in the left panel, as shown in Figure 6.

Figure 6: Looking at wlst-createcluster in External Tools

This screen specifies the name of the program to run ( wlst.cmd), the Working Directory ( wlst-workshop), and the arguments that will be passed to WLST ( createcluster.py and myclusterdomain). The first argument passed to WLST is always the name of the script; subsequent argument(s) represent any inputs the script expects. In this case, the createcluster.py script expects the name of the domain, which I've named myclusterdomain. Click on the Run button at the bottom of the screen to create the domain.

At this point you've used Workshop and WLST to create an administration server and two managed servers, and placed the managed servers into a cluster.

Step 2: Start

In this step you start the clustered domain and then deploy the application to the cluster. These steps are analogous to those described in Part 1.

To start the cluster, select the program called wlst-startcluster in the External Tools panel. This will invoke the same script that ran in Part 1.

Similarly, to start the application first click on hello.html and bring it up in the main window. This will ensure that the right application is deployed. Then, select the program called wlst-deploy in the External Tools panel. This will invoke the deploy.py script, which deploys the helloApp application to the cluster.

In each case, you may need to adjust the parameters on the External Tools screen if you are not using the defaults. Note that the last parameter in the deploy arguments is http://localhost/hello.html. This will automatically invoke the browser with this URL. You can change this depending on your settings if not using the HTTP Server with port 80. At this point you've used WLST and Workshop to start the cluster and deploy the application to the cluster. Let's now run it!

Step 3: Run

Running the application is again identical to Part 1—just enter the appropriate URL into your browser (or use the browser that was invoked at the end of Step 2). Using Apache as a load balancer, type: http://localhost/hello.html.

Type in your name and click on Submit. Now, let's run the getstatus.py command from External Tools. This will tell you which server (ms1 or ms2) is serving the requests. Now, hit refresh on the browser, and then run getstatus again. Notice that the same server is invoked, using the same session.

Now, let's see what happens if one of your servers goes down. Let's kill the server (ms1 or ms2) that is serving these requests. To kill it, use the stopserver.py command from External Tools. Make sure to change ms1 to ms2 in the arguments window if you need to stop ms2. Now, hit the refresh button again. Notice two things:

1. The request is now served by the other managed server (as can be observed by running the getstatus script).
2. The session ID has changed!

The first behavior is desirable, as clustering is designed to enable high availability; in the event of a server crash, another server in the cluster should pick up the load. However, the second behavior may not be desirable, as you may expect the surviving managed server to use the same session as was used by the first server. This is what is known as session replication. So what happened here?

What you need to do is configure the application to use session persistence. Bring up the helloApp application in Workshop, and edit the weblogic.xml file, which is located under the WEB-INF directory. You need to add the following snippet to enable session replication:

<session-descriptor>
  <persistent-store-type>replicated</persistent-store-type>
  </session-descriptor>

The default setting (persistent store type of memory) does not replicate session across clustered servers. Setting the parameter above to replicated allows sessions to be replicated across servers in a cluster. Therefore, when the managed server serving the session goes down, the surviving server takes over the sessions. The end user continues working as if there was no system failure.

Now, restart the failed managed server by running wlst-startserver from External Tools, and then redeploy helloApp by executing wlst-redeploy.

Now, retry the above experiment. You'll see that when the surviving server takes over, it uses the same session ID!

You've now used Workshop with WLST to create a fully functional clustered environment for testing the application. You can now iteratively make changes to the application, redeploy the application to the cluster, and test. The Workshop and the WLST scripts provided here do all the hard work, so you as a developer can focus on your application and quite easily test in a clustered environment.

The Big Picture

In this article I focused on developer productivity, and in particular, how developers can test their applications in a clustered environment, facilitating easy testing. Once the developer has completed the development phase (with sufficient unit/cluster testing), the application is typically handed off to other teams for different stages, such as: integration, QA/staging, and production. WLST can also be leveraged in these stages to automate domain and application provisioning and further reduce the time required to deliver the application into production. For more information on how WLST can be leveraged in these stages, see Automating WebLogic Platform Application Provisioning: A Case Study (Dev2Dev, August 2005).

Conclusion

As applications move through the lifecycle stages from development to production, the environments become increasing more complex at each stage. One such area of complexity is clustering. Since developers typically test exclusively in a single-server environment, the chances of encountering problems in later stages is increased. By providing the means for developers to try their applications in a cluster with minimal overhead, many of these problems can be fixed early in the lifecycle of the project.

This tutorial presented the means for developers to run their applications in a clustered domain. By leveraging the power of WLST and Workshop, I was able to show how developers can create, deploy, and start their applications right from the same environment they use to develop and run the application on a single-server domain. Giving this power to developers will shorten the project life cycle and enable projects to be more rapidly deployed into production.

Download

The sample code used in this article can be downloaded here.

Resources

• Apache HTTP Server - a secure, efficient and extensible server that provides HTTP services in sync with the current HTTP standards

Michael Meiner is an Engineering Manager at BEA Systems, Inc. for the Platform Engineering team.