Introduction

In a typical customer/provider scenario a customer demands - and pays for - a certain Quality of Service (QoS) laid down in so-called Service Level Agreements (SLAs). In recent years growing demand from customers to monitor the performance of their network services can be realized. Poor performance is no longer tolerated. Instead customers now can receive discounts or even have the right to cancel the contract and choose a different provider. But network parameters like numbers of IP packets dropped or the available bandwidth at a certain point in time are not very meaningful to the vast majority of customers. So it seems preferable not to monitor network performance but service performance instead. In order to observe the quality of delivered services it is necessary to negotiate Quality of Service (QoS) parameters as well as means for the measurement and evaluation of these parameters. The monitoring of the QoS parameters has to be done by an agent running at the customer site, because this is the only way to monitor actual service usage of the customer. The fact that an agent belonging to a provider must be running at the site of a customer implies strong security requirements. Due to numerous changes to SLAs in course of time, the agent has to be flexible and extensible in order to allow easy updating.

The paper shows how concepts and services of the Java Dynamic Management Kit (JDMK) can be used for building such an architecture. It also points out weaknesses and deficiencies JDMK still has to deal with. As an example of how monitoring of QoS parameters can be done, a web browser was instrumented using the Application Response Measurement (ARM) API to deliver information about the actual response times a customer is experiencing.

The paper is structured as follows: Section  gives an overview about the scenario the paper deals with and shows the requirements a management solution for this scenario has to fulfill. In section  JDMK and the ARM API which are both used in building our solution are introduced. Section  describes how we applied JDMK and ARM to the problem domain. An example how actual QoS parameters can be obtained is shown. Section  summarizes our experiences and evaluates how JDMK and ARM are suitable for monitoring QoS parameters in large enterprise environments. The Java Management Extensions (JMX) specification is intended as a replacement for the Java Management API (JMAPI) and relies to a large extent on JDMK. We will therefore contrast JMX with JDMK in section  and discuss to what degree JMX alleviates the shortcomings of JDMK. Section  concludes the paper.