Introduction  

In recent years a trend towards service orientation can be observed especially in the area of network and internet connectivity. Tasks outside the main focus of an enterprise have increasingly been outsourced to external service providers instead of accomplishing them internally. However, service orientation is by no means limited to the area of network connectivity and nowadays can also be found in different areas like e.g., business applications. More and more enterprises refrain from running their business applications themselves and rather prefer to outsource them to application service providers (ASP).

Along with the outsourcing of services comes the need to precisely describe not only the functionality of the service to be provided but also the quality of service (QoS) a customer can demand from a service provider. This is usually done in so-called service level agreements (SLAs). Obviously, simply defining QoS parameters is in no way sufficient. Instead, means to monitor the agreed QoS are necessary as well as means to guarantee proper fulfillment.

However, QoS monitoring for application services is still an unsolved problem. Due to the huge differences between existing application services, not even a common understanding about the parameters to monitor has been established yet. Furthermore, only a few tools are available to support the monitoring of "application-level parameters" and their use is cumbersome and costly.

As application services typically provide transactions that can be triggered by the service user, we believe that the most important requirement to prove proper SLA-fulfillment is the ability to monitor these transactions. If such a user transaction fails, additional means are necessary to quickly identify the root cause of the problem. This can be done by subdividing the user transaction into subtransactions and extending the monitoring to these subtransactions. Of course current application instrumentation techniques like the Application Response Measurement API (ARM) [#!arm!#] (see section ) can provide this kind of information. However, these techniques are hardly used today, because of the huge efforts required to instrument applications.

This paper introduces an architecture that greatly alleviates the task of instrumenting applications. This is accomplished in two ways: On the one hand, the management instrumentation of an application is completely automated based on the component based structure of future applications. On the other hand, the correlation of measurements is completely automated based on the control flows the application is running in. As these are the major drawbacks of current application instrumentation techniques, the proposed architecture lays the foundation for a widespread use of application instrumentation.

In case of component based application development, two roles must be distinguished: Component developers implement components that can be used later by application developers during assembly of an application. It must be stressed that our approach does not simply shift the efforts from the application developer to the component developer, but substantially reduces the overall efforts of application instrumentation by automation. Thus, the requirements our solution should satisfy are to provide a means to monitor the actual user transactions of an application service as well as their subtransactions. Furthermore, the additional development effort caused by the solution must be reduced to a minimum for both the application developer and the component developer.

The paper is organized as follows: Section  shows related work by giving an overview of techniques currently available for application management. The ARM API, which is the technique most closely related to the proposed architecture, is introduced in some more detail. In section , our architecture for the automation of management instrumentation is described. After a detailed explanation of our approach in section , the runtime architecture as well as the development architecture of the solution are introduced. A prototypical implementation of the architecture is shown in section . Based on the experiences gained with the prototype, a comparison of the proposed architecture with the ARM API is done in section . A short summary and a description of ongoing work conclude the paper in section .