IBM WebSphere sMash is a popular Web 2.0-based, SOA-oriented platform, based on Project Zero, that facilitates rapid deployment of applications and mashups. WebSphere sMash is designed to eliminate complexity and enable developers to focus on getting the problem solved. However, there is a trade-off for eliminating complexity. By making the application development and run time platform simple, things like high-availability and clustering are sacrificed. The good news is that this void can be filled by using the concept of generic server clusters in IBM WebSphere Virtual Enterprise, in conjunction with special routing policies for the On Demand Router.
A generic server cluster is a representation of a server endpoint that is not part of the WebSphere-managed cell environment. Defining a generic server cluster is fairly straightforward and consists of creating a new cluster, naming it, and defining a list of host/port combinations that will be used to serve HTTP requests. After defining the cluster, the On Demand Router (ODR) must be configured with special routing policies, specifically designed to work with generic server clusters, to define how requests are to be routed to the generic endpoints. These routing policies are every bit as robust as the policies that can be defined on Java™ EE applications running elsewhere in WebSphere Virtual Enterprise; you can even use your existing transaction classes and work classes, or you can create new ones.
In this article, you will explore a simple PHP-based WebSphere sMash application called "helloworld," create several instances of the application, and go through the process of defining the generic server cluster and associated routing policy. You will then test out the ODR to make sure that requests are routed correctly. The environment used in this example consists of WebSphere Virtual Enterprise V6.1.0.3 installed on top of WebSphere Application Server V6.1.0.17 for the Microsoft® Windows® 32-bit platform.
Before looking at the WebSphere Virtual Enterprise side of this setup, let’s review what you have on the WebSphere sMash side. The helloworld application is a PHP-based application that consists of a single Web page called index.php. Listing 1 shows the source for the index.php file.
Listing 1. index.php source
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Hello World!!!</title>
<style type="text/css">
@import "/dijit/themes/soria/soria.css";
@import "/dojo/resources/dojo.css";
</style>
<script type="text/javascript" src="/dojo/dojo.js" djConfig="parseOnLoad:
true"></script>
<script type="text/javascript">dojo.require("dojo.parser");</script>
</head>
<body class="soria">
<h1>Welcome to PHP Hello World</h1>
<hr>
Brought to you in part by, IBM WebSphere sMash (Silverstone)
<br><br><br>
<?php echo "This request (" . $_SERVER['REQUEST_URI'] . ") was serviced by
" . $_SERVER['SERVER_NAME'] . ":" . $_SERVER['SERVER_PORT']; ?>
</body>
</html> |
When run, the output will look like Figure 1.
Figure 1. Sample output from index.php
Other than changing a configuration value in zero.config to have the application
listen on port 10080 and configuring a context root of
/hw, there are no other changes to the blank
application you get when you create a new WebSphere sMash application using the
AppBuilder tool. To deploy the application as a fully-capable, standalone
application, simply use the Package option available to you via the AppBuilder
GUI. The Package option is accessible from the main AppBuilder screen; the mouse
arrow is pointing to the Package icon in Figure 2. After clicking the
Package icon, Figure 3 displays.
Figure 2. Package icon in AppBuilder
Figure 3. Package the application for standalone runtime
When you click the Package button, a .zip file is generated at the path shown in bold type on the file system (Figure 3). This file can be moved to any other run time platform that WebSphere sMash supports, and then extracted and run.
Setting up the cluster in WebSphere Virtual Enterprise
Now that you have a WebSphere sMash application to test with, you just need to “deploy†it and start it up.
-
Extract the .zip file you obtained from the WebSphere sMash AppBuilder tool into a fresh directory on your test server. In the example shown here, application instances will be run on ports 10080 and 10081, so extract the .zip file into a directory structure that helps you keep track of which port the applications are running on. Figure 4 shows the directory structure for this example.
Figure 4. Proposed directory structure
-
The helloworld folders that appear under each port-named folder (that is, 10080 and 10081 folders) are the directories created by expanding the .zip file in each port number folder. After extracting the application .zip file under the 10081 folder, you need to revisit the zero.config file that is included in the application directory structure. Specifically, you need to change the port that the application is going to listen on from
10080to10081(to match the directory structure you created for it). To do this, simply change this line in the zero.config file located at C:\u\WebSphere\zero\ports\10081\helloworld\config:/config/http/port = 10080
to this:br />/config/http/port = 10081.Now, when the applications are started, they will listen for incoming HTTP requests on ports 10080 and 10081.
-
Next, you need to create the generic server cluster definition on the deployment manager for the WebSphere Virtual Enterprise cell. To access the generic server cluster configuration panel, expand the Servers listing on the left side of the administration console and select Generic Server Clusters (Figure 5). Figure 6 will then display, listing the configured generic server cluster definitions for the cell.
Figure 5. Generic Server Clusters option in administration console
Figure 6. Listing of generic server clusters in the cell
-
Click the New button to create a new definition, then enter the name of the cluster; in this example, the name is
HelloWorld_sMash_Cluster. Click the Apply button. The panel should look like Figure 7.
Figure 7. Creating the HelloWorld_sMash_Cluster definition
Important: If you plan on having more than one generic server cluster member server representation on the same host, you must create a custom property named “server†for each server. The value of this property can be anything you want, but it should be unique in the cell.
-
You now need to add the actual member definitions to this cluster. You can do this by clicking on the Ports link located under Additional Properties. On the next panel, you should see an empty listing of port numbers for servers in this cluster. Click the New button to create a new entry. Complete the panel by entering the hostname of the server on which the WebSphere sMash applications will run, and the port number you configured for the instance. Figure 8 shows the configuration from our test environment. This server representation corresponds to the WebSphere sMash application instance you configured to listen on port 10080. Do the same thing for the other application instance you configured for port 10081, as well.
Figure 8. Creating the port for 10080
As mentioned, since you plan on running both of your WebSphere sMash application instances on the same host, you must configure the server custom property for each member (host/port definition) that you define for the generic server cluster. Figure 9 shows an example of the "server" custom property, which can have any value as long as it is unique for the cell.
Figure 9. The server custom property
-
Finally, create another server definition for the generic server cluster to represent the application running on port 10081. Be sure to add the server property to the representation, as you did for the first server.
-
Save all of the changes and synchronize the changes with the cell (manually or automatically). After completing these steps, you should see your new generic server cluster displayed in the generic server cluster listing shown in Figure 10.
Figure 10. Successful creation of a new generic server cluster
So far, you’ve deployed your WebSphere sMash applications and configured a new generic server cluster in WebSphere Virtual Enterprise. The last step required to be able to route requests to the WebSphere sMash application via the ODR is to define a routing policy on the ODR.
-
To begin, navigate to the ODR definition that you want to route the requests. In this example, the ODR is named ODR01. Under the On Demand Router Settings header, click on the Generic Server Cluster Routing Policies link to begin configuring a new routing policy. Figure 11 shows the location of the Generic Server Cluster Routing Policies link.
Figure 11. Configure the generic server cluster routing policy
-
On the next panel (Figure 12), expand Work classes for HTTP requests and click the New button to create a new work class specific to your helloworld application; name the new work class something meaningful. Figure 12 shows a new work class named HelloWorld_WC.
Figure 12. Create the HelloWorld_WC work class
-
Expand the HelloWorld_WC work class definition to see the policy criteria, shown in Figure 13. Add the
/hw/*pattern to the URI patterns section of the policy definition. This indicates that this policy should be enacted on any requests that come to this ODR and meet the URI pattern specified.
Figure 13. The HelloWorld_WC work class routing policy criteria
-
Although you have not yet configured the virtual hosts to include the two port numbers that the WebSphere sMash application will listen on, you will define these on the default_host virtual host definition, so make sure that default_host is selected for the virtual host option for the policy. Finally, in the If no routing rules apply section of the definition, make sure that either the action is set to Permit Routing To, or that the Permit Routing With Affinity to option is selected. This directive tells the ODR how to handle the request once received. Since you have selected an action that results in the routing of the request, you must specify a target cluster or server to send the request. Select the generic server cluster you created earlier. The example in Figure 13 depicts a generic server cluster named "HelloWorld_sMash_Cluster."
-
After making all of the changes and additions, scroll back up to the top of the routing policy configuration panel and click Apply, then save all the changes and synchronize the changes with the nodes of the cell (again manually or automatically).
You have created a generic server cluster and defined a routing policy to get requests to the WebSphere sMash applications you have deployed. Now, you can test it all out.
Begin by starting up the WebSphere sMash applications. In a command prompt (shell
session), navigate to the helloworld directory under the ports/10080 directory
structure you created earlier. To start the application, enter the command:
zero start. Wait for the command to return and make
sure that you receive output similar to that shown in Figure 14.
Figure 14. Start the WebSphere sMash application
Repeat the zero start command for the second helloworld application in the ports/10081 directory. Once both applications are running, start the ODR instance where the generic server cluster routing policy was configured.
In this example, you only configured the routing policy on a single ODR instance, but is it entirely possible to configure multiple ODRs with the policy as well. Once the ODR is up and ready to service requests, open a browser and navigate to http://<odr_hostname>:<odr_proxy_port>/hw.
After a moment, you should see the same output as before (Figure 1) in your browser. This confirms that the routing policy is working as designed, because you requested the /hw context root via the ODR, and the appropriate routing policy activated and pushed the request through to one of the two configured endpoints for the HelloWorld_sMash_Cluster. If you issue the same request again via the ODR, you should see the response coming from the WebSphere sMash application listening on port 10081.
Figure 15. Response from application on 10081, proxied by the ODR
If you continue to request the URL, notice that the ODR will alternate requests to each of the servers, provided that you selected the Permit routing to option and not the Permit routing with affinity to option in the routing policy definition. If you chose to route with affinity you should see the requests stick to the first application instance accessed via the ODR.
If you stop the WebSphere sMash application running on port 10080 and then re-try the URL again on the ODR, you will see that the requests route only to the application on 10081 until the application on 10080 is available again. Thus, you have successfully created a clustered group of servers accessible via the ODR in WebSphere Virtual Enterprise.
This article described a scenario in which a newly developed IBM WebSphere sMash application needed to be deployed to your infrastructure resources. You were able to deploy the application to a host of your choosing and then leverage IBM WebSphere Virtual Enterprise assets to provide access to these applications, even though they are not part of the WebSphere-managed cell environment. This means that, using generic server clusters, you are able to take almost any number of HTTP-style endpoints and represent them as WebSphere Virtual Enterprise assets, and target requests at them using specialized routing policies. You could have also defined service policies for the generic server cluster and utilized the On Demand Router’s ability to regulate request volumes to the cluster, as you would for a WebSphere Application Server (or other middleware) cluster.
The author thanks the following people for their time in reviewing this article:
- Ann Black, WebSphere Virtual Enterprise Architecture and Development
- Ben Parees, WebSphere Extended Development
- Nitin Gaur, WebSphere IT Specialist, TechWorks Americas
-
WebSphere sMash
product information
-
WebSphere sMash
documentation
-
WebSphere Virtual
Enterprise product information
-
WebSphere Virtual Enterprise V6.1
Information Center
-
WebSphere Virtual Enterprise Wiki
-
Project Zero
-
IBM
developerWorks WebSphere sMash zone
-
IBM
developerWorks WebSphere Extended Deployment zone
John Pape currently works with the WebSphere SWAT Team and focuses on crit-sit support for clients who utilize WebSphere Application Server, WebSphere Portal Server, and WebSphere Extended Deployment. This role requires attention to detail as well and maintaining a “think-out-of-the-box” innovative mindset, all the while assuring IBM customers get the best support possible!
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
