Web Service for Estimating Capacity and Performance of Service

Sonoma

Web Service for Estimating Capacity and Performance of Service-Oriented Architecture (SOA) Workloads

Authors: Eugene Hung, Qi He, Jinzy Zhu Technical contact: Eugene Hung [email protected]

Key contributors: Animesh Singh [email protected] Geetha Adinarayan [email protected]

Management contact: Noshir Wadia [email protected]

Date: 9 October 2006 Status: Version 1.0

Abstract: This paper describes Sonoma, a Web service for estimating the performance and capacity of service oriented architecture (SOA) workloads. Sonoma is built using the IBM-developed technology of the On Demand Performance Advisor (OPERA). OPERA is a time-tested capacity planning tool that employs queuing theory, advanced autonomic algorithms, and extensive measurements with IBM customers. Sonoma provides IT architects with performance modeling and hardware configuration recommendations by sizing four SOA workloads based on common usage scenarios such as travel booking, banking, and insurance claims handling.

Copyright IBM Corporation 2006

Copyright IBM Corporation 2006 Sonoma Web Service

2

Executive summary Service oriented architecture (SOA) helps clients create business value through the development of a more on demand IT infrastructure. A key component of the IBM On Demand Business Strategy, SOA is prominently featured in IBM’s portfolio of products. However, in order to effectively propose integrated IBM software and hardware solutions designed to meet customer performance targets, sales teams and IT specialists need some form of automated sizing support for SOA-based workloads. The High Performance On Demand Solutions (HiPODS) team, with team members from around the globe, addresses this need with the Sonoma Web service. Sonoma is based on the core engine of the HiPODS On Demand Performance Advisor (OPERA). OPERA is a performance analysis and solution sizing tool that is based on innovative applications of queuing theory, statistics, and autonomic algorithms. It supports IBM® WebSphere®, Lotus®, and Tivoli® software products, providing the ability to size a solution based on either predefined or user-defined workloads. OPERA has a large user community in IBM; IBM TechLine, Global Services, and sales teams use OPERA in customer engagements for presale sizing, performance projections, and configuration advice. Sonoma provides a powerful Web-based interface to the industry-leading OPERA tool for several common IBM® WebSphere® Process Server applications. WebSphere Process Server is an SOA integration platform that allows functional software modules to plug in and work together. WebSphere Process Server enables deployment of standards-based business patterns in an SOA environment, making it possible to implement business integration solutions independent of platform, protocols, and products. Users can use Sonoma to output project future workload performance or perform capacity planning to upgrade their IT infrastructure. The output of Sonoma is designed to break down resource usage to individual components, identifying potential bottlenecks and predicting service failures ahead of time, and thus accelerating SOA deployment. Following a discussion of the business value of providing a Web-based capacity planning tool, this paper describes the work behind the Sonoma service’s design and implementation. Appendixes describe the workloads supported and the basics of OPERA.


3

Contents Introduction ................................................................................................................................... 4 Business value ................................................................................................................................ 5 Architecture and use ..................................................................................................................... 6 Implementation.............................................................................................................................. 9 Summary ...................................................................................................................................... 10 Appendix A. Workload descriptions.......................................................................................... 11 Appendix B. Overview of OPERA............................................................................................ 15 Acknowledgments........................................................................................................................ 17 References .................................................................................................................................... 17 Notices........................................................................................................................................... 18


4

Introduction Service oriented architecture (SOA) is a conceptual description of the structure of a software system in terms of its components and the services they provide, without regard for the underlying implementation of these components, services, and connections between components. Loosely coupled integration applications that are based on SOA provide flexibility and agility. Performance modeling of SOA-based workloads is of particular interest because of certain characteristics of such workloads: • SOA is often deployed to build business-critical applications. Serious considerations need to

be put into response time/scalability. • SOA workloads can be distributed. The implication of this is that the impact of any

performance issue will propagate. • SOA workloads can be dynamic and heterogeneous. The implication of this is that one might

never have enough empirical data to help predict the performance of an application. What would help is a modeling tool that has built-in probability models.

Sonoma is a Web-based service for evaluating performance and planning the capacity of SOA-based workloads. It is based on the core engine of the On Demand Performance Advisor (OPERA), which was developed by the IBM High Performance On Demand Solutions (HiPODS) team. OPERA is both a technology and a tool: it couples extensive customer and product-performance team measurements with the application of queuing theory and advanced autonomic algorithms. Sonoma addresses the challenges of SOA workload modeling with these technologies: • To address the distributed/heterogeneous system topology and configuration

• Advanced queuing models • Extensive hardware library • Network delay component • Advanced configuration model search algorithm

• To address the heterogeneous/dynamic workload composition • Stochastic model • Detailed component-based modeling

Sonoma offers these sizing services: • User specifies a workload with detailed parameters, a set of performance objectives, and the

target hardware and software platforms. Sonoma evaluates the performance of the system (including such metrics as server utilization, response time, and number of concurrent users). Sonoma reports a warning when all user-specified objectives cannot be met. This feature is called performance projection.

• User specifies a workload with a set of performance objectives. Sonoma estimates the hardware/software configuration required to meet the performance objectives of the specified workload. This feature is called capacity planning.

• User can specify multiple performance objectives including, for example, the throughput of business transactions, the limit on server CPU utilization, and the response time of a business transaction.


5

• User can select from a large library of server performance numbers. Sonoma supports hundreds of hardware platforms, covering several different brands.

This paper describes the first release of Sonoma. This release supports two types of SOA-related workloads (see workload details in Appendix A). 1) Workloads based on the WebSphere Process Server, an SOA integration platform. This

allows the user to size an arbitrary workload built on top of WebSphere Process Server. 2) SOA-based applications for motor insurance companies. The user can specify certain

business-related details of the application. The next section describes the business value behind developing a Web-based, capacity planning engine. The rest of the paper summarizes Sonoma design, architecture, and implementation.

Business value Capacity planning is a function of IT operations that provides guidance on how to plan, justify, and implement the appropriate level of resources needed for desired IT performance. Intelligent decisions on planning for capacity can help avoid wasted resources and unnecessary cost, and prevent poor performance or unavailability of an IT service resulting from an inadequate level of resources. A META Group study reveals that in 2005, capacity planning was the top critical issue for large enterprises, with 34 percent of respondents identifying this as a critical issue. This high priority will continue through consolidation and efficiency demands, with the CTO’s focus shifting from long-range planning to short-term optimization of applications and servers. Whereas companies have traditionally relied on expensive consulting expertise or imprecise guesswork to size their IT needs, Sonoma offers a cost-effective and efficient alternative for estimating Web performance. These two user scenarios describe how a capacity planner can save significant money by avoiding unnecessary hardware purchases and expensive service interruptions due to lack of IT resources: • A client needs to know what server configuration would support his critical business

application over the next three years and the impact the application would have on his existing infrastructure, specifically his network. The client is concerned about maintaining acceptable response times from a variety of users.

• An online shopping company develops a new Web-based shopping system for use by large corporate customers. They can use Sonoma to ensure this critical application would meet its performance requirements and validate the infrastructure decisions they need to make.

With predefined user workloads, Sonoma can help these organizations determine their infrastructure needs by recommending an optimal hardware configuration to meet performance objectives. Sonoma can also estimate the performance of a workload on a specific, perhaps current, hardware configuration. Furthermore, as a service delivered over the Web, Sonoma does not require an expensive investment in software licenses. This gives an organization more flexibility because it only has to subscribe to the service when needed. For a company that does planning exercises only a few times a year, this could amount to substantial savings.


6

To an organization, the economic impact of Sonoma can be captured from these benefits: • Avoiding capital cost through intelligent planning -- preventing excess capacity and over

provisioning • Increasing design efficiencies -- lowering forecasting cost by reducing the time required to

size infrastructure needs by as much as 60 percent • Reducing total cost of ownership – avoiding software licensing and maintenance costs for a

capacity planning tool

Architecture and use The Sonoma architecture has three design goals: 1) Provide a level of access control that permits only authorized users to use the OPERA

facilities 2) Provide a Web-based interface to the OPERA capacity planning tool 3) Provide a scalable, componentized implementation for future extensible development Figure 1 shows the high-level architecture that meets these design goals.

Figure 1. High-level Sonoma architecture

As shown, the architecture has three main parts: 1) An access control manager that authenticates users and determines which pages a user can

access (design goal 1). It can also audit user activity for security or collect data about user activity.

2) An application server that provides the user interface and communicates with a properly authenticated user (design goal 2).

3) A Web service server that publishes the OPERA capabilities as Web services to the application server. It contains the back-end database (includes such data as server

user

Access Control Manager

ApplicationServer

Web Services Server OPERA

Estimate Performance

Estimate Configuration

Get Hardware

Strings


7

performance information and workload measurements) necessary for computation. As shown Figure 1, the Web service server can be mirrored on multiple servers so that the service can be scaled to handle a large number of users.

While not implemented as such, the application and Web services servers can be run on separate machines, so that applications besides Sonoma can use the OPERA computation engine without going through the Sonoma interface (design goal 3). This follows the common model-view-controller architecture pattern that separates the logic (model) from its presentation (view). Sonoma uses three OPERA Web services based on OPERA functionality: 1) Estimate performance. The user specifies a workload with detailed parameters, a set of

performance objectives, and the target hardware and software platforms. Sonoma evaluates the performance of the system (including such metrics as server utilization, response time, and number of concurrent users). Sonoma reports a warning when all user-specified objectives cannot be met. This feature is called performance projection.

2) Estimate configuration. The user specifies a workload with a set of performance objectives.

Sonoma estimates the hardware/software configuration required to meet the performance objectives of the specified workload. This feature is called capacity planning.

3) Return available hardware. The user can select from a large library of server

performance numbers. Sonoma supports hundreds of hardware platforms, covering several different brands.

Scenario: SOA/insurance sizing In designing a solution, it helps to imagine real-life stories of how people would use it. Here is one scenario for the insurance industry. Sam wants to run an insurance claims service application on top of the IBM WebSphere Process Server. He intends to support a workload with two hundred business transactions per second, while maintaining the CPU utilization under 85%. Sam wants to know whether his two IBM® pSeries® p630-6E4 machines are sufficient to meet the performance target, and if not, he wants recommendations on what additional resources are required. Sam goes to Sonoma and chooses the SOA for Insurance workload. Using the Sonoma user interface (Figure 2), Sam describes his workload, his objectives of 200 transactions per second and 85% maximum CPU utilization, and his current hardware configuration (objective specification screen shown).


8

Figure 2. Sonoma objective specification screen

He clicks Get Performance to call the Estimate Performance Web Service and find out whether his current system can meet these objectives. Sam clicks Get Configuration to call the Estimate Configuration Web Service. He finds three configurations that would meet his desired objectives.

Figure 3. Results of configuration estimate

Sam chooses the high-end vertical solution and orders a few top-of-the-line machines that will enable him to serve customers at his desired rate without overloading his machines.


9

Implementation This section summarizes how the implementation of the three parts of Sonoma.

Access control manager The IBM® Tivoli® Access Manager (through its resource manager WebSEAL) is used to manage access control. The Tivoli Access Manager provides policy-based access control for business applications. Users who wish to use Sonoma must log into the Tivoli Access Manager server associated with Sonoma, and provide the relative path for Sonoma. If, for example, the Web address of the Sonoma home page was: www.sonoma.ibm.com/Opera/faces/sonoma.jsp

the address of sonoma.ibm.com could be hidden from a user by directing the user to go to: www.tamserver.ibm.com/Opera/faces/sonoma.jsp

At that address, the user has to pass an authentication check performed by the WebSEAL manager, using an LDAP server for lookup (Figure 4). When the check is passed, the user is associated with a specific policy, retrieved from the policy server, which allows for fine-grained access control on an individual user basis. This allows Sonoma to allow or deny access to specific Web pages (and thus specific workloads or functions).

Figure 4. Access control manager architecture

Application server and Web service server Figure 5 shows the implementation of the Sonoma application and Web service servers. Initially, we combined the application and Web service servers to deploy Sonoma on one machine, a 4-way IBM® BladeCenter® HS40 blade server with 4GB RAM and the IBM® WebSphere® Application Server v6.0.0.1 running in India. The user interface provided by the application server was implemented using Java™ servlets to build Java Server Pages (JSP™) that use the Java Server Faces (JSF) framework.

Tivoli Access Manager

Policy Server

LDAPServer

WebSEAL


10

Figure 5. Application and Web service server architecture

Java servlets are programs that run on a server and build Web pages dynamically. JSP technology allows the Web site designer to mix static HTML with dynamically-generated HTML, saving the designer from programming a servlet to output the static portion of the page every time. JSF provides a library of user interface components for building JSPs in an easier, and reusable fashion. The OPERA code has three components: the compute engine, the server library, and the workload library. The server and workload libraries contain data about server performance and workload performance, respectively – data collected from performance measurements made in the field using tools such as the IBM Tivoli Monitoring. The compute engine retrieves the data and uses it along with the user-specified input to estimate performance results. Sonoma does not yet support as many workloads as OPERA. Sonoma supports these SOA workloads: SOA for Insurance, SOA for Data Synchronization, SOA for Travel Booking, and SOA for Banking. Appendix A contains descriptions of the supported workloads.

Summary Sonoma is a Web-based service for evaluating performance and planning the capacity of SOA-based workloads. It features a scalable, componentized design that can support many concurrent users, and a centralized access control mechanism for security. With predefined user workloads, Sonoma can help organizations determine their infrastructure needs by recommending an optimal hardware configuration to meet performance objectives. Sonoma can also estimate the performance of a workload on a specific, perhaps current, hardware configuration. Sonoma is based on the core engine of the On Demand Performance Advisor (OPERA), which was developed by the IBM High Performance On Demand Solutions (HiPODS) team. OPERA is both a technology and a tool: it couples extensive customer and product-performance team measurements with the application of queuing theory and advanced autonomic algorithms.

Web Service Server

Server Library

Application Server

JSPs With JSF UI

OPERAWeb

Services

Compute Engine

WorkloadLibrary

Servlets


11

Appendix A. Workload descriptions The SOA workloads included in the current Sonoma release use the IBM WebSphere Process Server. WebSphere Process Server is an SOA integration platform built on a uniform invocation programming model and a uniform data representation model. This next-generation business process integration server has evolved from proven business integration concepts, application server technologies, and the latest open standards. WebSphere Process Server enables deployment of standards-based business applications in an SOA environment, making it possible to implement business integration solutions independent of platform, protocols, and products. This makes WebSphere Process Server the ideal platform for business applications that require business integration using different technologies. Figure A.1 shows an architectural overview of the WebSphere Process Server framework. WebSphere Process Server runs on WebSphere Application Server and uses many of its run-time features for transactions, security, etc. The three parts of WebSphere Process Server provide the following functionalities: • The SOA core provides uniform data representations, a uniform programming model, and a

universal interface for monitoring and managing applications running on WebSphere Process Server. In particular, the service component architecture encapsulates services with uniform programming model and invocations, business objects enable uniform data representations, and the common event infrastructure provides a common interface for management.

• Supporting services are essential to WebSphere Process Server because they provide mediating services between the source component and the target component of a transaction. The most important such functionalities include transformation and routing.

• The basic goal of WebSphere Process Server is to enable client modules to access service components (typically implemented as modules), or for service components to communicate with each other. Each service component implements certain business logic.

Figure A.1. Component-based framework of WebSphere Process Server

Some common WebSphere Process Server components include: • Macroflow is a typical long-running business process • Microflow is a relatively simple non-interruptible business process • Mediation flows intercept and modify messages that are passed between existing services

and clients

Business Processes

Human Tasks

Business State Machines

Business Rules

Mediation Flows

Selectors Interface Business Map Object Maps Relationships

Service Component Business Common Event Architecture Objects Infrastructure

Service Components

Supporting Services

SOA Core


12

• A relationship correlates two or more semantically equivalent business objects, which are represented in different physical formats

• Service invocation is the primary means of communication between components

SOA for insurance The SOA for Insurance workload is based on SOABench, an SOA macro benchmark modeled after a motor insurance company application. This benchmark application supports three usage scenarios: • Create Claim: provided to clients as Web services. This scenario mainly stresses the

services implementation within the SOA architecture. • Handle Claim: initiated as the customer representatives in the call center handle a customer

claim. This scenario is used to evaluate the business process functionality within the SOA architecture.

• Check Coverage: third party insurance companies check the coverage of a client. This scenario is primarily used to stress the integration functionality within the SOA architecture.

Sonoma focuses on a reference implementation of SOABench using the IBM WebSphere product line, involving WebSphere Process Server, WebSphere Application Server, and IBM® WebSphere® Enterprise Service Bus. Each scenario is implemented in a couple of ways in the reference implementation, resulting in seven scenarios that are included in SOABench. Table A.1 illustrates the details of each scenario and the flow of each transaction through the system components, including benchmark driver, WebSphere Enterprise Service Bus, WebSphere Process Server, and WebSphere Application Server.


13

Table A.1. SOABench scenarios

Scenario Request path Details 1. Services (Create Claim) Simple Service Driver -> WAS One Web service call

Service Virtualization Driver -> WESB -> WAS

One Web service call + one mediation module

2. Integration (Check Coverage) Service Mediation (chained) Auth->Audit->Transform->Route: four modules

Driver -> WESB -> WAS

One Web service + four mediation modules

Service Mediation (composite) Auth + Audit + Transform + Route: one module

Driver -> WESB -> WAS

One Web service + one mediation module

3. Business Process (Handle Claim) Business Process Driver -> WPS ->

WAS Microflow: two Web Service calls + one SCA local + one Data map + six Attributes Assigns *Macroflow: five Web Service calls + two Human tasks + two SCA local + two Data map + twenty Attributes Assigns *Macro flow is asynchronously invoked by micro flow

Business Process w/ Service virtualization

Driver -> WPS -> WESB -> WAS

Microflow + 1 mediation Macroflow + 1 mediation

Business Process w/ Service & Process virtualization

Driver -> WESB -> WPS -> WESB -> WAS

Microflow + 2 mediations Macroflow + 2 mediations

SOA for banking The business process used in the banking workload is a simplification of a realistic business process used in a bank’s back office. It shows a subset of steps necessary to process a mortgage request. It used to be a semiautomatic flow with several manual tasks. In general the manual tasks are necessary for handling technical errors or business exceptions. This application is implemented as a macroflow. SOA for banking runs on a single WebSphere Process Server. Our modeling of the SOA for banking application is based on a detailed analysis of the WebSphere Process Server components used in its implementation.


14

SOA for travel booking The flow of activities of the travel booking process contains typical steps required to complete a travel reservation. Customers submit data about the travel arrangements they want to book and receive a confirmation number when the travel arrangements have been booked successfully. The travel booking process is implemented as a microflow and interacts with four different business partners: • Car reservation service • Credit card reservation service • Flight reservation service • Hotel reservation service

Similar to SOA for banking, SOA for travel booking runs on a single WebSphere Process Server. The modeling of this workload follows the same approach.

SOA for real-time data synchronization This workload models a common enterprise application integration scenario known as real-time data synchronization, where a consistent view of data is kept across multiple applications. In this scenario, key events (such as create, delete, and update) in the source application need to propagate to a destination application. The goal is to keep data consistent between the two applications and their associated data stores. The data synchronization workload measures the transaction throughput of the WebSphere Process Server as it synchronizes “contact” create events between two simulated enterprise applications. It typically uses a microflow as well as maps, mediations and relationships governing a moderate business object. Similar to SOA for banking, SOA for data synchronization runs on a single WebSphere Process Server. The modeling of this workload follows the same approach.


15

Appendix B. Overview of OPERA Since its debut in 2001, the OPERA tool has attracted a large community of users and has become the de facto standard for estimating multi-tier on demand infrastructures based on WebSphere. It is used worldwide by TechLine, IBM Sales, IBM Global Services, IT architects, and select customers, and has supported well over 1,000 engagements where it has been extensively validated. In addition to expanding the types of workloads that can be represented, including SOA and other application platforms such as Lotus and several Tivoli products, it has evolved from a tool to a Web service through the development of Sonoma. Customers come to IBM with an application framework and performance objectives. Traditionally, customers are over- or under-provisioned, because the relationships between several tier topologies and these performance objectives are not clear. This can become an increasingly difficult issue for dynamically changing workloads, priorities, and service level agreements (SLAs). OPERA provides a solution that models these complex relationships and can be used to either suggest a satisfying configuration, or to evaluate the performance of a given configuration. The overview of this approach is shown in Figure B.1.

Figure B.1. Overview of OPERA

First, the user selects a workload, and then fine-tunes it, adjusting it to become closer to their desired environment. This fine tuning is geared toward defining the consistency of the traffic independent of the volume. Second, the user enters objectives that establish the performance goals of the workload. This sets parameters that depend on the volume of traffic, such as processor utilization, response time per request, and request throughput. Third, the user selects a

Workload Library

4. LOOKUP SERVERS • p/x/zSeries, Sun, HP

2. DEFINE OBJECTIVES

1. SELECT WORKLOAD • Measured data

• Response times • Transaction rates • Resource utilization 5. OBTAIN SOLUTION

• Analytic queuing models• Search algorithms • 12 patents

Tier nTier 1 Tier 2

3. SELECT SERVERS

Compute Engine

6. OPTIMIZE CONFIGURATION• Run multiple times

Workload

Performance Objectives

System Configuration

Estimated Performance

Server Library

…


16

system configuration where the specific hardware and general (workload-independent) software specifications can be defined. If the configuration is to be estimated by OPERA, the number of tiers, along with the brands for each tier (for example, IBM® xSeries®, IBM pSeries, Hewlett Packard 9000) can be set, along with the operating system. If the performance of a given configuration is desired, OPERA then refers to an extensive server library and looks up the models used within the topology. This then provides a relative performance factor for each model that is provided to OPERA’s back-end compute engine, which utilizes analytic queuing models for computing the performance of the given topology from the given workload and configuration parameters. If the system configuration is desired, OPERA estimates the performance of a few models and returns the minimal configuration that satisfies the performance objectives. The performance results of this configuration are also provided. Figure B.2 shows the customer-driven designed workloads supported by OPERA.

Figure B.2. Workloads supported by OPERA

Online Shopping Online Trading Online Banking Business to Business

Inventory Management Online Brokerage Online Auction WebSphere Portal 5.1

WebSphere Process Server WebSphere ESB WebSphere Message Broker

Tivoli Identity Manager Tivoli Access Manager Tivoli Monitoring

Workplace Workplace Services Express

Custom, User-Defined Workload Time Varying Workloads Parallel Computing Workload


17

Acknowledgments The authors would like to acknowledge the hard work of the Sonoma development team, a multinational effort that saw contributions from HiPODS India, HiPODS China, and HiPODS Silicon Valley: Geetha Adinarayan, Shelly Arora, Nirmala Hunagund, Makham Kumar, Jaydeep Parandekar, Sansan Sheng, and Animesh Singh. We would also like to thank the WebSphere Process Server performance team and the SOABench development team, in particular, Sambi Brekke, Jerry Burke, Farhad Fatahalian, Steve Garde, Edward Ng, Srini Rangaswamy, and Chris Richardson for providing data and helping us understand the IBM SOA product family and workloads. In review of the paper, the authors thank Willy Chiu and Noshir Wadia for their constructive suggestions and comments.

References HiPODS white paper: HiPODS Model: An eBay Case Study, June 2004 at www.ibm.com/developerworks/websphere/library/techarticles/hipods/hipods_model_ebay.

Other HiPODS white papers are available at: www.ibm.com/developerworks/websphere/zones/hipods/library.html Learn more about IBM Tivoli Access Manager for e-business at www.ibm.com/software/tivoli/products/access-mgr-e-bus/


18

Notices Trademarks The following are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both: IBM pSeries Tivoli xSeries WebSphere Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsoystems, Inc. in the United States and other countries. Other company, product, and service names may be trademarks or service marks of others. Special Notices The information contained in this document has not been submitted to any formal testing by or for IBM, and the document is therefore distributed "AS IS" by IBM to the fullest extent allowed by applicable law. Any use of the information or implementation of any of the techniques contained in this document is a responsibility of the user. The results of any such use will depend on the user's ability to evaluate and integrate the information and/or techniques contained in this document into the user’s operational environment. While IBM may have reviewed each item for accuracy in a specific situation, IBM offers no guarantee or warranty to any user that the same or similar results will be obtained elsewhere. Any person attempting to adapt the techniques contained in this document to their own environment(s) does so at their own risk. Any performance data contained in this document were determined in various controlled laboratory environments and are for reference purposes only. Customers should not adapt these performance numbers to their own environments as system performance standards. The results that may be obtained in other operating environments may vary significantly. Users of this document should verify the applicable data for their specific environment.

Documents

Web Service for Estimating Capacity and Performance of Service