Introduction

From a business perspective, the goal of business performance management (BPM) is to quantify the effectiveness of business operations using a well-defined set of metrics and to continually optimize the operations based on the value of those metrics. Performance optimization can only be achieved through effective information collection. IBM's On Demand Operating Environment (ODOE) provides many integration points for applications to implement BPM. Tivoli Monitoring for Transaction Performance (TMTP) integrates with the ODOE and provides an organization the ability to manage the performance of transactions, including those running in the J2EE environment. The IBM ODOE is based on open standards and so is TMTP, which uses the ARM standard for measuring transaction performance.

This article discusses the performance monitoring of IT services using TMTP 5.3. As in previous articles in this series, the scenario is based on the PersonalLoan Business Process Execution Language (BPEL) application.

Back to top

Defining ARM

TMTP uses the ARM API to measure application response time. ARM is an open-standard API that describes a common method for integrating enterprise applications as manageable entities. The ARM standard is managed by the Open Group and has three versions: ARM 2.0, ARM 3.0, and ARM 4.0. (See Resources for more on the ARM protocol.)

TMTP supports ARM 2.0 and 4.0, and uses the ARM API to measure application response time. It comes with a set of configuration capabilities that lets you automatically ARM-enable your J2EE application without having to modify your code. TMTP uses ARM 2.0 for J2EE monitoring in all current versions of the product. The current major version is 5.3.

It is important to differentiate between ARM and the Common Base Events used by the Tivoli Common Event Infrastructure. ARM is used for collecting information specifically for showing application response times. Common Base Events are used for higher-level business events, and are not intended to be used for the micro events required to effectively measure performance-sensitive components. See Resources for more about Common Base Events and the Common Event Infrastructure.

In this article, we'll discuss ARM 2.0. The ARM 2.0 API is very simple, consisting of six operations that are placed at well-defined points in an application management cycle, as shown in Figure 1. There are operations for defining transactional entities and delimiting the transaction instances and status.

Every transaction monitored by ARM must name its transaction templates using the arm_getid() operation. This operation provides an identifier that can be used for each transaction instance that corresponds to this transaction template. Each instance of a transaction is delimited by start and stop operations. At any point during a transaction, it is possible to also update its status using the update operation.

Because ARM is intended to be shared across multiple component providers within a multiuser solution, each tool using ARM must first initialize itself using the arm_init() operation. This operation lets you define your application and the current user, and it constructs a unique identifier for that application for use in subsequent arm_getid() operations.

The last operation defined by ARM is arm_end(), which allows all the resources associated with an application and user to be released by the runtime.

Back to top

Applying TMTP to PersonalLoan

In this section you get a comprehensive overview of the TMTP management cycle; that is, the general process and methodology of how to use TMTP. We illustrate the discussion using the PersonalLoan BPEL application scenario.

The PersonalLoan

We introduced a modification to the PersonalLoan business process to include an activity that replaces the doCreditCheck activity. The new activity, called validatePolicy, is implemented as a Web service operation using Simple Object Access Protocol/Hypertext Transfer Protocol (SOAP/HTTP) binding. Figure 2 shows the topology of our work.

The Web service application called PolicyApp is installed in a WebSphere Business Integration Server Foundation (Server Foundation) 5.1.1 server on host helene. Thus, helene is the endpoint of our Web services. Meanwhile, the PersonalLoan application is also installed in a Server Foundation server on a separate host called dione. Atlas is another host that the management server manages, but it does not have the PolicyApp Web service.

During execution of the PersonalLoan application, the validatePolicy operation executes, resulting in a Web service call to helene. The validatePolicy performs a credit check and other background check of the applicant. In this scenario, we're interested in monitoring all Web service calls to the validatePolicy service. The following sections discuss the management server and management agent.

Back to top

Viewing the TMTP management cycle

The TMTP usage paradigm is centered on the concept of management policies that define the set of transactions to be monitored using the ARM protocol. Figure 3 shows a high-level view of the management cycle.

Installing the management server and management agents

Step 1 and step 2 in Figure 3 pertain to the installation of the two essential TMTP components: the management server and the management agents. (See Resources for details on installing these components.) A management agent must be installed in a host where incoming transactions are to be monitored, such as a call to a Web service running on that host. Each management agent is registered with one management server at installation time. The management server is the central point for all administration tasks of a TMTP installation. It provides a browser-based management console, as shown in Figure 4.

Configuring WebSphere Application Server with TMTP

In its current released version, TMTP is intended primarily to monitor J2EE-based applications, so it has well-defined points of integration with IBM's application servers, such as Server Foundation 5.1.1. Before TMTP can perform its job, the application server must be configured . You can do this by deploying the appropriate TMTP component in the target management agent host (step 3 in the TMTP management cycle in Figure 3). This process automatically updates the management agent installation and the configuration of the application server. For example, the Java virtual machine (JVM) entries in the server.xml file of the target server instance in Server Foundation will be modified with TMTP-specific information so that TMTP is loaded when the application server is started.

WebSphere Application Server uses Performance Monitoring Infrastructure (PMI) for transaction monitoring. When integrated with TMTP, ARM must be enabled in the application server so that PMI calls TMTP's ARM agent appropriately. Also, Request Metrics must be enabled when monitoring Web services. You can do this enablement using the Admin Console, as shown in Figure 5.

After deploying the TMTP component, the application server must be restarted for the changes to take effect. TMTP provides the option to automatically restart the application server. To verify that the deployment is successful, you can go to the managing server console's system administration and select Work with Agents. Figure 6 shows an example with the J2EE component deployed in both hosts atlas and helene, and that both application servers are running. The status of the management agent in both machines is also online.

Configuring management policies

Management agents are given information by the management server as to which transactions should be monitored (and which may be expressed as regular expressions), when they should be monitored, and for how long. These are called policies. Actual monitoring and performance data collection happen by creating the management policies and distributing them to the chosen agents, as shown in Figure 7.

Performance data are collected by a management agent and then later transmitted to the management server, which in turn saves them to the database. Given these data, a user can interact with the management console to view reports and drill down to obtain the details of a transaction's performance at an aggregate or instance level.

Policies may also specify performance thresholds so that any violation is shown in the management console's dashboard or published to other management software using the Tivoli Enterprise Console. An e-mail reporting the violation may be sent as well.

Using policies to discover transactions

There are two types of management policies: discovery and listening policies. Step 4 in the management cycle in Figure 3 involves discovering transactions. When the URL information of the transactions to be monitored is unknown initially, discovery policies can be used to get the URL information. An example of a discovery policy for Web services is shown in Figure 8. Notice that regular expressions are used for Port Name, Operation Name, Target Namespace, and Input Message Name. The regular expression .* means that any string can be matched to it. A more complicated regular expression can be used, depending on what you know about the transactions you're interested in.

As soon as discovery policies are given to the management agents, you can start submitting sample transactions to the application servers (step 5 in the management cycle in Figure 3). Typically, these transactions are inclusive of all possible transactions that will be directed to a server. The management agent keeps all transactions and their associated information that satisfy the regular expressions in the discovery policies.

After running some sample transactions, the collected information is sent to the management server. You can view these discovered transactions (step 6 in the management cycle in Figure 3). A sample list of discovered transactions is shown in Figure 9.

Information such as Transport Type, Port Name, Operation Name (in the case of Web services transactions), and the Average Time for each transaction is given. You can select from the list all transactions that you want to be monitored. A listening policy is then created for each of the chosen transactions (step 7 in the management cycle in Figure 3). The listening policies can also specify performance thresholds and availability criteria.

You can see an example of a listening policy in Figure 10. We created a listening policy for the validatePolicy operation and defined the performance thresholds. When actual transactions are processed by the application server, performance data are captured by the management agent and then rolled up to the management server later. When exceptions occur, such as when response time has violated the threshold, as previously mentioned, there are three possible actions.

Viewing TMTP dashboards and reports

Performance data are only useful if they can be viewed and analyzed. Data can be viewed in either aggregate or instance levels. Detailed information about each of the components that comprise the transaction can be viewed using the dashboard. Figure 11 shows an example of a topology view from the management console, which shows the actual response times of each subcomponent of the validatePolicy service.

In the Topology view, you can see three panels:

• Tree-structured, component-by-component breakdown that includes response times
• Graphical view of components, showing what component calls what and the response times
• Data about the transaction (instance or aggregate), which is comprised of the inspector and the transaction stack

A red, inverted triangle indicates an error condition. In this case, we can drill down the problem to the findByPrimaryKey() call. Typically, this type of information is of interest to software architects and developers.

General reports are also available in TMTP, as shown in Figure 12. These reports are more related to performance of aggregate data over a given time period (except for the Topology report), as opposed to individual transactions, which is useful for solution engineers and line-of-business executives.

TMTP includes other features not mentioned here. However, this repeated process of creating discovery and listening policies to viewing reports is the core of the TMTP management cycle. Policies can be removed at any time, while agents can be added or deleted.

Back to top

Summary

Three major elements are integrated in a business performance management system: people, processes, and IT systems. A fundamental facet of BPM is the ability to monitor the performance of these entities and to analyze how they affect each other, which allows you to provide the quality of service expected for a given transaction. It's also critical to be able to locate problem areas in each of these entities, either in an integrated or independent fashion or both.

In this article you were presented with a framework for monitoring IT services using IBM Tivoli Monitoring for Transaction Performance 5.3, which is based on the ARM protocol. Our example uses a BPEL application with Web services running on IBM WebSphere Business Integration Server Foundation 5.1.1. With IBM Tivoli Monitoring for Transaction Performance, you can drill down to the detailed components of a given IT service and pinpoint bottlenecks and problem areas, enabling you to improve response times. And through reports and historical data, you can perform additional in-depth analysis.

Back to top

Acknowledgments

The authors wish to thank Christina Lau and Nduwuisi Emuchay for reviewing this article. Thanks also to Bryan Chagoly and Howard McKinney for additional assistance with the content.

Resources

• The Application Response Measurement Protocol by the Open Group explains the common method for integrating enterprise applications as manageable entities.
  
  
• The IBM Tivoli Measurement for Transaction Monitoring Information Center contains the product documentation for the IBM Tivoli Monitoring for Transaction Performance version 5.3.
  
  
• Download the specifications for the Common Base Events.
  
  
• Learn more about the Common Event Infrastructure, intelligent automation that saves time and improves resource utilization.
  
  
• The WebSphere Application Server 5.1 and WebSphere Business Integration Server Foundation 5.1. Information Center displays documentation for several WebSphere Application Server products.
  
  
• Read the Tivoli Enterprise Console documentation. For PDF versions, click here.
  
  
• Innovate your business with other IBM products. Try IBM trial downloads to find out how.
  
  

About the authors

Dr. Jamison currently works with the IBM On Demand Software Development team and is heavily involved with many projects pertaining to business performance management and service-oriented architecture (SOA). His expertise also includes J2EE application servers, performance analysis, Tivoli Monitoring for Transaction Performance, Web services, and more. He is a contributor of the book, Performance Tuning for Linux Servers. Contact Dr. Jamison at wjamison@us.ibm.com.

Richard Duggan currently works with the IBM On Demand Software Development team, where he is focused on architecting and developing assets for managing service-oriented architectures (SOAs). He has also worked on several assets for measuring and managing performance of Java applications, including many capabilities included in the Eclipse Test and Performance Tools Project. Contact Richard at rduggan@ca.ibm.com.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Defining ARM
• Applying TMTP to PersonalLoan
• Viewing the TMTP management cycle
• Summary
• Acknowledgments
• Resources
• About the authors
• Comments

Next steps from IBM

Rational Application Developer features provide the comprehensive Integrated Development Environment (IDE) used to develop J2EE applications requiring Servlets and JavaServer Pages (JSPs).

---

• Try: Try the free Rational Application Developer, which helps developers quickly design, develop, test, analyze, and deploy high-quality Java, Javaserver pages, and J2EE applications.
• Article: Learn how you can deliver accurate, higher-quality J2EE apps with Rational Application Developer, open source JUnit and JUnitEE test frameworks.
• Tutorial: Build a Facebook application using PHP, the Spring framework, and J2EE.
• Buy: Rational Application Developer

My developerWorks community