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.
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
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
Introducing Tivoli Application Performance Management, SG24-5508
Tivoli Application Performance Management Version 2.0 and Beyond,
Unveil Your e-business Transaction Performance with IBM TMTP 5.1,
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
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.