Developing Web Applications in a Clustered Environment Using WLST and BEA Workshop
Pages: 1, 2, 3

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
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
Figure 2: Invoking the Run command

Figure 3 shows the resulting screen.

Figure 3
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
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.

Pages: 1, 2, 3

Next Page »