Application instrumentation: Application instrumentation means insertion of specialized management code directly into the application's code. The required information is sent to management systems by using some kind of well-defined interface. This approach can deliver all the service-oriented information needed by an administrator. The actual status of the application and the actual duration of transactions is measured and any level of detail can be achieved. Subtransactions within the user transactions can be identified and measured.
However, application instrumentation is not very commonly used today. This is mainly due to the complexity and thus the additional effort posed on the application developer. The developer has to insert management code manually when building the application. Subtransactions have to be correlated manually to higher-level transactions. As the source code is needed for performing instrumentation, it definitely has to take place during development.
Examples for approaches using application instrumentation are the Application Response Measurement API (ARM) [#!c807!#] jointly developed by HP and Tivoli and the Application Instrumentation and Control API (AIC) [#!c910!#] developed by Computer Associates. Both approaches have recently been standardized by the Open Group. ARM defines a library that is to be called whenever a transaction starts or stops. Subtransactions can be correlated using so called correlators. Thus the duration of the transaction and all subordinate transactions can be measured. AIC in contrast was not explicitely developed for performance measurement but might be used in this area as well. It defines an application library to provide management objects that can transparently be queried using a client library. Additionally, a generic management function can be called through the library and thresholds of certain managed objects can be monitored regularly. Both ARM and AIC suffer from all the problems mentioned above and thus are not in wide-spread use today.
Application description: As most of the applications in use today somehow deliver status information but are not explicitely instrumented for management, application description techniques can be used. As opposed to the instrumentation approach, no well-defined interface for the provisioning of management information exists. The description therefore comprises where to find the relevant information and how to interpret it. Examples might be scanning of log files or capturing status events generated by the application.
The major advantage of application description techniques is that it can be applied to legacy applications without requiring access to the source code. It can be done by a third party after application development, while the reasonable approach again is to provide the description by the developer.
Application description faces two major problems: The information available typically is not easy to map to the information needed by the administrator. Especially in the area of performance management typically only little information is available. Moreover monitors are needed to extract the information from the application. Only very little information can be gathered by standard monitors and thus specialized monitors must be developed for every application.
The most prominent representative of application description suited for performance monitoring is the Application Management Specification (AMS) [#!ams2!#]. Most other approaches, like the CIM Application Schema [#!applmof25!#] mainly focus on configuration management. An example for a tool making use of application description is Tivoli Business System Manager [#!tbsm01!#], which reads in AMS based Application Description Files (ADF) to learn about the application or business system to be managed.