Conclusion and Outlook

  This paper describes a case study for the dynamic management and monitoring of SLAs based on JDMK and ARM. We have discussed our implementation concept with flexible and extensible agents which operate at the customer site. Our work was motivated by the increasing demand for scalable and reliable solutions which allow the extension of management agents at runtime. The experiences gained in this project allow an evaluation of the applicability of JDMK for managing large-scale enterprise networks and can be summarized as follows:

The development environment permits rapid prototyping and is easy to use; the transfer of lightweight applications (implemented as JavaBeans) to management agents at runtime works very well: JDMK supports both push and pull models and enables agents to acquire additional functionality, thus improving their (albeit limited) autonomy. JDMK is best described as a development framework for Java-based Management by Delegation. At its current stage (Version 3.0 beta 2), JDMK is a powerful toolkit for the development of management agents that can be accessed and modified through several different communication mechanisms (RMI, HTTP, SNMP, HTTPS, CORBA/IIOP).

The usability of management systems - especially in an enterprise-wide context - depends to a high degree on the security features of the underlying middleware. However, the JDMK security mechanisms are yet unsatisfactory because the different mechanisms of the underlying communication protocols/infrastructures have not yet been integrated into a common security architecture. It therefore depends on the type of the underlying protocol whether e.g., encryption is available and how access control is handled. Another critical issue is the absence of services to obtain meta-information on the deployed agents (like a ``global'' interface repository and naming services): The services to obtain information regarding the whole set of agents in a JDMK environment lack scalability because they can only be applied to a single Core Management Framework, thus preventing a global view on the agents.

JDMK is not positioned as a stand-alone management framework but serves as the communication infrastructure of Java Management API (JMAPI) version 2, Sun Microsystems' emerging Java-based management framework. Consequently, the Sun management system Solstice will make extensive use of JDMK. It is therefore expected that the future development of JDMK will eliminate the current weaknesses.

The experiences of the project further allow an evaluation of how ARM can be used for the monitoring of service levels of client/server applications. Section 5.4 mentioned pros and cons of the ARM API. As the benefits of ARM outweigh the disadvantages by far there is hope that it will increasingly be adopted by vendors.

Currently the ARM Working Group is developing version 2.1 of the API [8] which e.g. will address the following topics:

• Allow applications to provide unique transaction identifiers to the agent. This is especially important when instrumenting server subsystems and middleware components which often already have their own unique IDs for transactions.
• Define an API call for legacy applications which already provide some kind of performance monitoring. An arm_complete_transaction call will be defined that enables an agent to receive information about a complete transaction.
• An object oriented version will be provided that uses the benefits of object orientation while still permitting full interoperability with other (non-OO) ARM implementations.
• A solution for the monitoring of Java applets will be provided. Applets face the problem that they cannot call local libraries, so the measurement agent has to be included into the applet.

Growing customer demand for applications ready for management will lead to a growing number of instrumented applications. A number of management tool vendors already offer solutions that implement the ARM API. The Desktop Management Task Force (DMTF) in 1998 formed a new subgroup called ``Distributed Application Performance''. It is developing a model for application performance that should be consistent with other CIM models and with the ARM API. This will further improve acceptance of the ARM as the standard for application response time measurement.