End-to-End e-business Transaction Management Made Easy

Chapter 3. IBM TMTP architecture 67

TMTP will also automatically collect instance data if a transaction breaches

specified thresholds. This second feature of TMTP is very useful, as it means

that TMTP does not have to keep redundant instance data, yet has relevant

instance data should a transaction problem be recognized.

3.3 Key technologies utilized by WTP

This section describes some of the technologies used in this release of TMTP

and elaborates on some of the changes introduced to how some previously

implemented technologies are utilized.

3.3.1 ARM

The Application Response Measurement (ARM) API is the key technology

utilized by TMTP to capture transaction performance information. The ARM

standard describes a common method for integrating enterprise applications as

manageable entities. It allows users to extend their enterprise management tools

directly to applications, creating a comprehensive end-to-end management

capability that includes measuring application availability, application

performance, application usage, and end-to-end transaction response time. The

ARM API defines a small set of functions that can be used to instrument an

application in order to identify the start and stop of important transactions. TMTP

provides an ARM engine in order to collect the data from ARM instrumented

applications.

The ARM standard has been utilized by several releases of TMTP, so it will not

be discussed in great depth here. If the reader wishes to explore ARM in detail,

the authors recommend the following Redbooks, as well as the ARM standard

documents maintained by the Open Source Group (available at

http://www.opengroup.org):

򐂰 Introducing Tivoli Application Performance Management, SG24-5508

򐂰 Tivoli Application Performance Management Version 2.0 and Beyond,

SG24-6048

򐂰 Unveil Your e-business Transaction Performance with IBM TMTP 5.1,

SG24-6912

The TMTP ARM engine is a multithreaded application implemented as the

tapmagent (tapmagent.exe on Windows based platforms). The ARM engine

exchanges data though an IPC channel, using the libarm library (libarm32.dll on

Windows based platforms), with ARM instrumented applications. The data

collected is then aggregated in order to generate useful information, correlated

with other transactions, and thresholds are measured based upon user

68 End-to-End e-business Transaction Management Made Easy

requirements. This information is then rolled up to the Management Server and

placed into the database for reporting purposes.

The majority of the changes to the ARM Engine pertain to measurement of

transactions. In the TMTP 5.1 version of the ARM Engine, each and every

transaction was measured for either aggregate information or instance data. In

this version of this component, the Engine will be notified as to which

transactions need to be measured. This is done via new APIs to the ARM Engine

that allows callers to identify transactions, either explicitly or as a pattern.

Measurement can be defined for “edge” transactions, which will result in

response measurement of the edge and all its subtransactions.

Another large change in the functionality of the ARM Engine is monitoring for

threshold violations of a given transaction. Once a transaction is defined to be

measured by the ARM Engine, it can also be defined to be monitored for

threshold violations. A threshold violation is defined in this release of this

component to be completing the transaction (i.e. arm_stop) and having a

unsuccessful return code or having a duration greater than a MAX threshold or

less than a MIN threshold.

The ARM Engine will also communicate with the Monitoring Engine to inform it of

transaction violations, new edge transactions appearing, and edge transaction

status changes.

ARM correlation

ARM correlation is the method by which parent transactions are mapped to their

respective child transactions across multiple processes and multiple servers.

This release of the TMTP WTP component provides far greater automatic

support for the ARM correlator. Each of the components of WTP is automatically

ARM instrumented and will generate a correlator. The initial root/parent or “edge”

transaction will be the only transaction that does not have a parent correlator.

From there, WTP can automatically connect parent correlators with child

correlators in order to trace the path of a distributed transaction through the

infrastructure and provides the mechanisms to easily visualize this via the

topology views. This is a great step forward from previous versions of TMTP,

where it was possible to generate the correlator, but the visualization was not an

automatic process and could be quite difficult.