Related Work  

As was already shown in [#!HaRa00!#] there essentially exist four basic techniques for application management. Two of them, the monitoring of network traffic (e.g., [#!rfc2722!#], [#!apmf00!#]) and the monitoring of system-level parameters (e.g., [#!rfc2287!#]) simply cannot deliver the user-oriented information required. The third technique, the client-side application monitoring can deliver this kind of information, but only shows the client-view of the application and thus fails to provide detailed information required for a root cause analysis in case of an error. Examples for client-side monitoring are use of synthetic transactions like done by Geyer & Weinig's GW-TEL INFRA-XS [#!gewe00!#] or GUI-based approaches like Candle ETEWatch [#!hurw98!#]. Only the fourth technique, the application-wide monitoring, is suited to completely deliver the required information. Application-wide monitoring comprises application description, like done by the Application Management Specification (AMS) [#!ams2!#] and the DMTF Application Model [#!applmof25!#], and application instrumentation, like the ARM API [#!arm!#]. The application-wide monitoring techniques suffer from high efforts posed on the application developer and thus are likewise not in widespread use today.

A lot of researchers are dealing with the topic of automating application management: [#!biaggi97!#] describes an approach for the automation of fault management of component based applications. However, the approach is constrained to so-called store-and-forward architectures and requires great efforts of the component developer because an instrumentation of all components is necessary. [#!kkc00!#] in contrast focuses on automatically determining the dependencies of applications and their underlying infrastructure. While this is a promising approach for the area of configuration and fault management, it does not cover user-oriented performance or accounting management. To achieve this, the authors again refer to classical instrumentation techniques. The approach introduced in [#!ETE99!#] suggests generating and mapping events to transactions instead of calling measurement agents. Thus, the transactions to be monitored can be defined more flexible. However, manual insertion of the code generating the events into the source code of the applications is still required.

 

Figure:  ARM API: Architecture

1#1

As already mentioned, application instrumentation is required to provide the information necessary for service-based application management. The instrumentation approach most widely used today is the ARM API. ARM defines a very simple API that can be called from the application to inform a management agent whenever a transaction begins or ends. Figure  shows the usage of the API. An application developer inserts calls to the API into the source code of the (possibly distributed) application. At runtime, a measurement agent integrated in the application's process is called, which determines the time of the call and typically forwards the information to a management application. To achieve correlation of measurements, ARM uses the following mechanism: Whenever an application informs the measurement agent about the start of a transaction, a unique identifier is generated and returned to the application. This parameter has to be passed through the application and back to the measurement agent when the transaction ends. For correlation of subtransactions a second identifier (called a correlator) can be requested and is used analogously. The basic problem of this approach is, that these identifiers must be passed through the entire application as additional parameters for each method invocation. Practical instrumentation experience shows that this mechanism is inconvenient for the developer and can lead to a great number of errors (especially when instrumenting code developed by a third party). Even worse, in case of component based application development, this approach would require an extension of all the methods of all components to allow passing of the respective identifier to the component which cannot be expected in practice.