Introduction

This is Part 4 of a series of articles that tackles the implementation of on demand solutions. Part 3 demonstrated how you can use business process choreography to develop business applications such as the personal loan application of odFinance. It also provided a comprehensive discussion on BPEL and the WBI Server Foundation. This article continues by showing how resources, such as physical servers in a data center, can be provisioned to running business applications based on their current needs. In this article, IBM® Tivoli® Orchestrator (TO) (see Resources) manages the data center.

Back to top

Personal loan provisioning scenario

Business demands in the real world can fluctuate anytime depending upon many variables surrounding the business. During those times, such as when a workload soars to its peak, responsiveness of the system becomes critical to the business -- especially when there is an expectation as to the quality of service that must be provided. This article extends the scenario for the personal loan application to capture and address this type of situation. The remainder of this article shows how to design and develop an on demand solution to the case described above.

In this scenario, odFinance offers a promotion for a discount loan as part of its strategy to respond to competitive pressures. For the next seven days, a fixed annual interest rate of 3% will be available for a personal loan less than US$20,000. The expected turn-around time for loan applications during the promotion period is 24 hours. Since this is such an excellent but limited deal, odFinance expects a big spike in its workload. It needs to be responsive by ensuring that sufficient server capacity exists to meet the peak demands given the existing hardware resources.

Back to top

Basic topology

As the last article discussed, odFinance customers can use the portal to submit a loan request. Behind the scenes, a long-running business process is built using BPEL, which involves processing the application, validating that the customer has good credit rating, creating the loan application, and notifying the customers. The front-end application is built as a set of portlets that are deployed on IBM® WebSphere® Portal Server V5.0. A Web service call initiates the BPEL-based business process that is deployed on the IBM® WebSphere® Business Integration (WBI) Server Foundation V5.1. Figure 1 shows this basic topology.

Portal and WBI clusters

In a production environment, clusters typically balance workload and support failover. A cluster infrastructure is also very useful for automating provisioning. Therefore, the basic topology that Figure 1 shows has been updated to a more complicated topology that uses WebSphere cluster, as Figure 2 shows.

Two clusters are created, one for the WebSphere Portal Servers, and the other for the WBI Servers. Configuring the WebSphere Process Choreographer for a cluster environment is actually quite complicated, and you need to consider many options. In the example configuration, all the members of the cluster access the same Tivoli Directory Server, MQ server, and DB2® server. You can contrast this to a non-clustered environment whereby security can be enabled using the local operating system as the registry, and using WebSphere embedded messaging. The IBM HTTPServer plug-in is used to front-end the requests coming in to the members of the Portal and the WBI cluster. It acts as a simple workload manager by distributing incoming requests equally to the servers in each cluster. It intelligently intercepts the Web service call from the portlet that initiates the BPEL business process and redirects it to the next WBI Server without requiring any change to the existing code.

Back to top

Managing a data center using Tivoli Orchestrator

Tivoli Orchestrator (TI) and Tivoli Provisioning Manager (TPM) are automated resource management solutions for data centers. TPM is a stand-alone offering focusing only on resource provisioning. TO includes TPM and provides additional capabilities to anticipate when to start provisioning and what resources need to be provisioned to which applications in the data center. In this example, TO defines and manages the data center for odFinance. Figure 3 shows the odFinance data center managed by TO. The yellow-colored platform represents the personal loan application. Within the personal loan application, there are two clusters: a PortalServerCluster and a WBIServerCluster. A cluster in TO is a set of servers currently running the same application. Therefore, it maps very well to the cluster concepts in WebSphere. Also note the resource pools -- one resource pool contains servers that can be provisioned for the PortalServerCluster, and the second resource pool contains servers that can be provisioned for the WBIServerCluster.

Back to top

Triggering automatic provisioning

At the heart of TO is a MAPE engine. It monitors the resources to gather performance metrics, analyzes the data it collects, plans for what actions it should take, and finally executes the actions that are required. When an application is defined in the TO data center, the administrator must specify a Service Level Objective (SLO), specifying the priority of the application as well as the quality of service it expects, for example, the maximum response time, the percentage of time that the application must be available, and the CPU thresholds.

Listing 1 shows an XML fragment of the SLO. The CPU utilization for the WBIServerCluster is set to 80%. With the CPU utilization information and other information such as customer priority, TO monitors and analyzes for a possible breach whereby the defined objectives are not met. When that happens, TO can trigger some actions using workflow scripts that have been registered with the system. Workflow scripts have been created in this configuration that can automatically add WBI or Portal Servers to the corresponding cluster (see Resources).

<datacenter>
   <customer name="On Demand Finance Company">
      <application name="Personal Loan Application" priority="10">
         <service-level-objective internal="false" type="min-availability" value="0.75"/>
         <service-level-objective internal="false" type="max-response-time" value="0.167"/>
         <cluster name="WBIServerCluster" virtual-ipaddress="10.1.1.2" virtual=tcp-port="0" 
            min-servers="1" max-servers="5" pool="WBIServersResourcePool" vlan="100">
            <service-level-objective internal="false"
           type="critical-cpu-utilization" value="0.8"/>
            <with-load-balancer name="WBI Load Balance"/>
         </cluster>
      </application>
   </customer>
</datacenter>

TO provides a management console that shows the CPU utilization of the servers in the cluster as well as the list of available servers in the resource pool, as Figure 4 shows. The DedicatedServers are servers that do not participate in the provisioning. These are servers that must be up all the time. This applies, for example, when there is a minimum number of servers that should be allocated for a given application. Notice how the server utilization in the WBIServerCluster is exceeding 80% as indicated by the red progress indicator. This will cause TO to trigger automatic provisioning. TO will take a server from the resource pool and add it to the WBIServerCluster in order to meet the SLOs that are defined by the administrator. Conversely, if the servers in the cluster are under utilized, TO will remove them from the cluster and return them to the resource pool so that they can be used by other applications that have the demand.

This was mapped in WebSphere clustering so that one cluster is pre-configured for the WBI Servers and another for the Portal Servers. When a server in a cluster is not needed, its application server is simply shut down. This is equivalent to returning it to the resource pool. When a resource is needed or provisioned, TO checks the resource pool, and the application server of the chosen server is started. These procedures can be easily scripted in WebSphere. This approach can be leveraged by having several applications share the same cluster. In this case, when an application server has been shut down by one application, the same application server can be provisioned later to another application that has been deployed also in that application server. Another approach -- instead of shutting down the application server -- is to stop or start the application that needs to be unprovisioned or provisioned, respectively.

Back to top

Conclusion

This article discussed the patterns you can follow to deploy your business processes so that they react to changing demands automatically. It showed how orchestration and provisioning can help you create a more resilient environment that can react to occasional spikes without manual intervention or over provisioning. Provisioning resources is not a new concept, but it perfectly fits the on demand paradigm, and that is why it is now receiving a great deal of attention. With the orchestration capabilities in TO, you can increase the degree of automation and adaptability of your IT infrastructure and be on your way to becoming a more on demand enterprise.

Back to top

Download

Information about download methods

Resources

• Read the previous three parts in this series:
  • "Part 1: Best practices for using the thirteen capabilities of the IBM On Demand Operating Environment" (developerWorks, July 2004)
  • "Part 2: Use the Enterprise Service Bus to connect disparate applications" (developerWorks, September 2004)
  • "Part 3: Use BPEL to create business processes" (developerWorks, October 2004)
  
  
  
• Get access to information on the Tivoli Intelligent ThinkDynamic Orchestrator information center.
  
  
• Learn more about IBM Web infrastructure orchestration.
  
  
• Read the IBM Redbook on " Provisioning On Demand Introducing IBM Tivoli Intelligent ThinkDynamic Orchestrator " (IBM Red Book; 2003), by Edson Manoel, et. al.
  
  
• Learn how grid resource managers manage workload from requesters to available grid engines in "Orchestrating grid workloads -- neither feast nor famine: Move servers in and out of grids with IBM Tivoli Intelligent Orchestrator" (developerWorks, September 2004).
  
  

About the authors

Christina Lau is a Senior Technical Staff Member at IBM. Christina is an architect on the On Demand Development team focusing on the next generation technologies for the On Demand Operating Environment. You can reach Christina at clau@ca.ibm.com.

Dr. Jamison currently works on incubation projects for the IBM On Demand Development and Strategy team. He is an expert of Performance Analysis/Engineering for J2EE applications and has numerous publications and presentations on the subject matter. He also had extensive customer engagements involving the IBM WebSphere Application server including e-Bay and NYSE. You can reach him at wjamison@us.ibm.com.

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Personal loan provisioning scenario
• Basic topology
• Managing a data center using Tivoli Orchestrator
• Triggering automatic provisioning
• Conclusion
• Download
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: WebSphere Application Server
• Briefing: Building SOA solutions and managing the service lifecycle
• Buy: WebSphere Application Server