Generic Performance Instrumentation of EJB Applications ... - CiteSeerX

Generic Performance Instrumentation of EJB Applications for Service-Level Management M. Debusmann, M. Schmid, R. Kroeger Fachhochschule Wiesbaden - University of Applied Sciences Department of Computer Science, Distributed Systems Laboratory Kurt-Schumacher-Ring 18, D-65197 Wiesbaden, Germany {debusmann schmid kroeger}@informatik.fh-wiesbaden.de http://wwwvs.informatik.fh-wiesbaden.de

Abstract Enterprise Java Bean (EJB) application servers are gaining more and more importance for implementing business-critical applications. For an effective service-level management (SLM), an instrumentation must offer a fine-grained picture of the real system performance. For reasons of efficiency and practicability, the instrumentation has to be performed automatically in order to assure complete and comparable measurements. This paper presents a new approach for an automatic and generic performance instrumentation of EJB applications by instrumenting the EJB server. The approach defines a generic CIM model for EJB applications. From an application developer’s point of view, the instrumentation is completely transparent. It is realised using the Java Management Extensions (JMX). The performance measurements are implemented using Application Response Measurement (ARM). The prototype is integrated into a WBEM/CIM object manager.

Keywords Performance Management, Monitoring, EJB, CIM, WBEM, JMX, ARM

1. Introduction Business processes in enterprises are more and more dependent upon a vital IT (Information Technology) infrastructure. The steady growth of enterprise networks provides a basis for the widespread use of distributed application architectures. Multitier applications offer the necessary flexibility for adapting business processes to changing requirements. These applications often have a very similar architecture. On the client side, they typically use standard Web browsers to access the services. On the server side, a Web server provides a service access point, behind which application logic, databases, and legacy applications are located. These multi-tier applications are often implemented using components that separate their application

logic from the underlying technology and services used. Application servers offer an execution environment for such components providing persistency, transaction management, and a Web-based interface. The Enterprise Java Bean (EJB) standard [15] defined by Sun specifies an architecture for components, termed enterprise beans, for the development of such business processes. The trend for outsourcing and application service providing (ASP) increases the need for service-level management. Quality-of-service parameters agreed on by providers and customers are laid down in a contract, called service-level agreement (SLA) [9, 14]. Typical quality-of-service parameters specified in SLAs define availability criteria and performance-related metrics, e.g. response times. The fulfilment of the SLA has to be monitored by both the customer and the provider. Customers are primarily interested in short end-user response times and high service availability. Providers are interested in a finer-grained view of the interrelated performance metrics of the components constituting their services, especially when using the same service infrastructure for different customers at the same time. One important approach for measuring application response times is the Application Response Measurement (ARM) interface [11] defined by the Computer Measurement Group (CMG). ARM defines an API for instrumenting applications at the source-code level. The API supports measurements of units of work within a distributed application, called ARM transactions. ARM provides correlators to handle nested ARM transactions, even across hosts. From an application developer’s point of view, the ARM instrumentation approach is not satisfactory because it induces additional effort for the programmer. Furthermore, this explicit source-code instrumentation may lead to incomparable monitoring results because components may have been instrumented incompletely or in different manners. Thus, a generic instrumentation that is transparent for the application developers is the basis for an efficient monitoring of components that delivers comparable results. The need for managing Java-based applications has been addressed by Sun Microsystems with the Java Management Extensions (JMX) [16], which introduce the concept of Manageable Beans (MBeans). These MBeans represent the management view of managed resources. MBeans register at a JMX agent that consists of an MBean server and zero or more protocol adaptors. The MBean server is responsible for managing its associated MBeans. Protocol adaptors ensure integration into a certain management architecture, e.g. SNMP. The Common Information Model (CIM) [2] defined by the Distributed Management Task Force (DMTF) is a powerful object-oriented information model for management purposes. CIM is based on UML and is independent of any hardware architecture, operating system, and programming language. CIM consists of a number of schemas that cover different aspects of managed systems. These schemas can be extended to one’s own needs. Web-Based Enterprise Management (WBEM), defined by the DMTF as well, is an architecture for integrated management using CIM as the underlying information model. The CIM Object Manager (CIMOM) is its central component. It offers management information to a manager application. The CIMOM is accessed via HTTP

[3]; the exchanged information is encoded in XML [4]. The interface between the CIMOM and managed objects is realised by the use of CIM providers. Their interface to the CIMOM is proprietary to each implementation. WBEM/CIM is receiving steadily increasing attention from industry. Sun Microsystems ships its version of a complete WBEM implementation with Solaris 8. Microsoft supports WBEM in Windows 2000; it is called Windows Management Instrumentation (WMI). This paper presents an approach for an automatic, generic performance instrumentation of EJB 1.1 application servers. The information model for representing an EJB server is described using CIM. The instrumentation is entirely transparent to application developers, i.e. no extra programming effort is required. Since the instrumentation is achieved fully automatically all components used are instrumented in the same manner. The measurements provided for each EJB are complete and comparable according to the defined management information model because equivalent measurement points are used in every component. The response time measurements are realised using ARM. Together, these approaches provide a solid basis for servicelevel monitoring. Section 2 describes the CIM-based information model for representing EJB servers and EJB applications. In Section 3, the technical details of the generic instrumentation approach are presented. Section 4 describes the implemented prototype and first performance measurements, while related work is discussed in Section 5. The paper closes with a conclusion and an outlook on future work in Section 6.

2. CIM Model for EJB Applications Figure 1 illustrates the architecture of an EJB server running EJB applications. The figure abstracts from any concrete implementation and only shows the three basic building blocks identified in the EJB standard. A Web server generally provides the interface for accessing the application server. In addition, clients may also connect to the application server directly via Java Remote Method Invocation (RMI) and

Application Server Web Server

Enterprise Bean Enterprise Bean EJB Application 1

DBMS

Enterprise Bean EJB Application 2

EJB Container

Figure 1: Architecture of an EJB server

Common Object Request Broker Architecture (CORBA)/Internet-Inter ORB Protocol (IIOP). An EJB server maintains one or more EJB containers. EJB applications always run within a container. An application comprises one or more deployed enterprise beans. A Database Management System (DBMS) provides mechanisms for data storage including bean persistency. Figure 2 depicts our generic information model for managing EJB servers. This CIM model (or schema, in DMTF parlance) covers the operational phase of an application and its reconfiguration during runtime. Earlier phases cannot be modelled generically since they are not standardised. For example, the architecture of the deployment tool is not specified, and the process of deploying a bean into a server is proprietary. CIM_System

CIM_SoftwareElement

CIM_SoftwareFeature

+CreationClassName: string [key] +Name: string [key] +...

+IdentifyingNumber: string [key] +ProductName: string [key] +Vendor: string [key] +Version: string [key] +Name: string [key] +... *

CIM_ManagedElement

+Name: string [key] +Version: string [key] +SoftwareElementState: uint16 [key] +SoftwareElementID: string [key] +TargetOperatingSystem: uint16 [key] +... *

CIM_ApplicationSystem

CIM_SoftwareFeatureElements

EJB_EJBContainer

EJB_EJBServer +Version: string +HostName: string +PortNumber: uint32 +AllocatedMemory: uint32 +stopServer(): boolean 1 EJB_EJBServerContainers

+BeanType: valuemap +AllocatedMemory: uint32 +NumberOfInstances: uint32 +PoolSize: uint32 +PassivationTimeout: uint32 +MeasurementPeriod: uint32 +undeployBean(): boolean 1 1 1..n

EJB_EJBApplication

+TimeOfDeployment: datetime +AllocatedMemory: uint32 +undeployApplication(): boolean * 1 EJB_EJBContainerApps EJB_ApplicationEJBs

EJB_EJBMethods

+Name: string [key] +Identifier: uint32 [key] +CreationTime: datetime +AllocatedMemory: uint32 +MeasurementPeriod: uint32 +Passivate(): boolean 1 EJB_InstanceMethod *

EJB_EJBMethodInstance

CIM_AssociationClass

extension to standard CIM classes and associations

*

1..n

EJB_EJBInstance

Inheritance

EJB_ReferencedEJBs

EJB_EJBInstances

*

Aggregation

1

EJB_EJB

+TimeOfInstanciation: datetime +AllocatedMemory: uint32 +removeContainer(): boolean * 1

+Name: string [key] +Identifier: uint32 [key] +MeasurementPeriod: uint32 +MeasurementTime: datetime +TotalAccessCount: uint32 +ResponseTimeOfLastInvocation: uint32 +AverageResponseTime: uint32 +MaximumResponseTime: uint32 +MimimumResponseTime: uint32 +Throughput: real64 +StandardDeviation: real64 +NumberOfSuccessfulInvocations: uint32 +NumberOfFailedInvocations: uint32

EJB_EJBMethod +Name: string [key] +TransactionAttributes: valuemap +MethodAttributes[]: string +ReturnType: string +MeasurementPeriod: uint32 +MeasurementTime: uint32 +TotalAccessCount: uint32 +ResponseTimeOfLastInvocation: uint32 +AverageResponseTime: uint32 +MaximumResponseTime: uint32 +MinimumResponseTime: uint32 +Throughput: real64 +StandardDeviation: real64 +NumberOfSuccessfulInvocations: uint32 +NumberOfFailedInvocations: uint32 1 * EJB_MethodInstances EJB_represents 1 1

1

CIM_UnitOfWorkDefinition EJB_collects

CIM_UnitOfWork *

+Id: sint64 [key] +UoWDefiId: string [key] +UserName: string +StartTime: datetime +ElapsedTime: datetime +Status: uint16

+Id: string [key] +Context: string +Name: string * w

CIM_StartedUoW

1

Figure 2: CIM model of an EJB server The CIM classes that were chosen for representing an EJB server (see light grey area in Figure 2) are derived from classes defined in the CIM Application Schema [5]. An EJB server (EJB_EJBServer) is derived from CIM_ApplicationSystem, which itself is derived from CIM_System. An EJB container (EJB_EJBContainer) inside an EJB Server

and EJB_EJBApplication are both derived from CIM_SoftwareFeature. An EJB_EJBServer may contain any number of EJB_EJBContainers that themselves may host any number of EJB_EJBApplications. The EJB_EJB class is derived from CIM_SoftwareElement and represents an EJB within an application. This class offers static information common to all instances of this bean, e.g. the number of instances of this bean. The EJB_EJBInstance class represents a particular EJB instance and provides information specific for this instance, e.g. the time of its creation. The EJB_EJBMethod class models a method of a bean and provides static information about this method, like its transactional behaviour, as well as a summary of performance characteristics of all its method instances. The EJB_MethodInstance class summarises performance information for a method of a certain EJB instance. This includes the min/max response times for the last method invocations, the average response time, etc. The indices themselves are modelled as separate CIM classes: CIM_UnitOfWorkDefinition and CIM_UnitOfWork of the CIM Metrics Schema [6]. The CIM_UnitOfWorkDefinition class defines a method of an EJB instance for which the execution time is measured. Thus, this class is associated with the EJB_EJBMethodInstance class. A concrete measurement of a method invocation time is represented by CIM_UnitOfWork, which is associated with EJB_EJBMethodInstance as well. The CIM classes of the information model were designed so as to allow for both a direct mapping of configuration information and a very fine-grained analysis of EJB application performance. With the model provided, even single method invocations on certain EJB instances can be observed. The information model supports the correlation of nested method invocations and integrates seamlessly with the measurement data provided by the ARM library (by using the CIM Metrics Schema). The genericity of the model ensures its usability by different EJB servers.

3. Instrumentation of EJB Applications For providing the information defined in Section 2, the EJB server and the EJB application have to be instrumented in an appropriate manner. The instrumentation can be subdivided into two parts: first, an instrumentation that provides the basic mechanisms for collecting management information from the application and for exporting it from the application server (see Section 3.1); and second, an instrumentation that computes performance indices within the application during runtime (see Section 3.2).

3.1. JMX Instrumentation The EJB server is instrumented using MBeans for providing information about containers, applications, EJBs, EJB instances, EJB methods, and instances of EJB methods. The instrumentation is responsible for providing all the characteristics defined

in the information model in Section 2. For EJB containers and EJB applications, MBean interfaces provide the class attributes described in Figure 2. JVM Proxy

EJB server

EJB EJB EJB

EJB EJB application

EJB container

EJB

EJB

EJB EJB application

EJB application

EJB container

JMX MBean JMX MBean server MBean registration

Figure 3: Overall JMX instrumentation architecture As depicted in Figure 3, several JMX MBean types are associated with the EJB server and all its constituent entities. From an application developer’s point of view, all MBeans are completely transparent. The EJB server itself is represented as a single MBean, the Proxy MBean, to the outside world. Within the scope of the EJB server an MBean server is responsible for managing all MBeans within the EJB server. MBeans are integrated into each container, application, and bean. The most straightforward way would be to implement one MBean per CIM class to realise a direct mapping. But this would be expensive in terms of memory usage and runtime overhead because a large number of MBeans would have to be instantiated. In addition, these MBeans would partly have to store redundant information. Thus, the CIM classes EJB_EJBInstance, EJB_EJBMethod, and EJB_EJBMethodInstance are all realised using a single MBean implementation class, located at the EJB level and managing the information for all three CIM classes. The implementation class EJB_EJBMBean is instantiated once for each EJB type; it manages its instances, methods, and method instances as internal data structures. The Proxy plays an important role within the instrumented EJB server. The Proxy is responsible for managing all MBeans within the server and for realising the communication with the outside world. All MBeans register themselves at the MBean server of the Proxy, which serves as a JMX agent with respect to the EJB server. Furthermore, the Proxy offers an MBean interface itself for connecting to a management entity via Java RMI (see Section 3.3). Thus, the Proxy provides a single access point to the collected management information which is more memory efficient than accessing every MBean directly from the outside: only the single RMI

stub of the Proxy is required. In addition, the Proxy implements all the attributes and methods supported by the EJB server, and also provides methods for listing containers, applications, and beans.

3.2. ARM Instrumentation For measuring the response times of EJB method invocations ARM version 3 [12] is used. The ARM instrumentation is responsible for computing the performance ratios described in Section 2. Each method invocation maps to an ARM transaction and is directly mapped to the class CIM_UnitOfWork, the CIM equivalent of an ARM transaction (see Figure 2). ARM 3 provides advanced support for measuring the performance of distributed systems and for correlating measurement results in a central management system. Version 3 currently has a draft status close to standardisation. Figure 4 depicts those parts of the ARM 3 API that are used for our measurements. The link between the instrumentation and the management system is realised by the singleton class ArmAgent. It is not specified in the ARM standard and thus corresponds to the developed solution of an ARM agent. «Interface»

«Interface»

ArmDefinitionFactory

ArmTranReportFactory

+newArmMetricDefinition(): ArmMetricDefinition +newArmTranDefinition(): ArmTranDefinition +newArmUserDefinition(): ArmUserDefinition

«Interface»

ArmDefinitionFactoryImpl

+newArmSystem(): ArmSystem +newArmTranReport(): ArmTranReport +newArmTranReportWithMetrics(): ArmTranReportWithMetrics

«Interface»

ArmTranDefinition +copyMetricUUID(): void +getApplName(): String +getMetricUUID(): byte[] +getUUID(): byte[] +getTranName(): String +process(): void

«Interface»

ArmUserDefinition +getUUID(): byte[] +getName(): String +process(): void

ArmTranDefinitionImpl is registered

ArmTranReport +getCorr(): byte[] +getParentCorr(): byte[] +getResponseTime(): long +getStatus(): int +getStopTime(): int +getTranHandle(): long +getTranUUID(): byte[] +getUserUUID(): byte[] +init(): void +initFromCorr(): void +initGenCorr(): byte[] +process(): void

«Interface»

ArmSystem +getAgentVersion(): short +getInstance(): short +getSystemId(): byte[] +getSystemIdFormat(): short +getVendorId(): short +initFromCorr(): void

ArmUserDefinitionImpl ArmAgent Standard ARM3 Interfaces Class implements interface

Factory - class relationship

+static getInstance(): ArmAgent +newCorrPoss(): void +delCorrPoss(): void +getCorr(): byte[] +newCorr(): void +delCorr(): void +genTranHandle(): long +newTranDefinition(): void +newTranReport(): void

ArmSystemImpl

Singleton

ArmTranReportImpl

ArmTranReportFactoryImpl

is registered

Figure 4: Elements of the ARM 3 API used in our measurements Response time measurements are performed by the application itself and are passed to the ARM library by invoking process on the ArmTranReport interface. Each EJB method is interpreted as an ARM transaction. Thus, the forwarding of the measurement data is done in the EJBObject and EJBHomeObject classes— interfaces that wrap method invocations on an EJB and are automatically generated by the server. Performance data is collected for each EJB method instance. The performance data is stored within the context of the corresponding EJB instance. When the instance dies, its associated performance information is deleted once it has been taken

into account at the EJB level. The association between instance and method name is realised via the optional ArmTranDefinition interface.

ArmTranReportFactoryImpl newArmTranReport()

ArmAgent

ArmTranReportImpl «create» newTranReport()

getCorr() initGenCorr() genTranHandle()

process EJB method and measure response time

newCorr()

process() newTranReport()

delCorr()

Figure 5: Measuring EJB method invocations with ARM 3 The UML sequence diagram depicted in Figure 5 illustrates ARM interactions during an EJB method invocation. Before invoking a certain method, a new instance of ArmTranReport is generated using the ArmTranReportFactoryImpl. Afterwards, getCorr retrieves the parent correlator from the ArmAgent. Next, a new correlator is created by invoking initGenCorr on the ArmTranReportImpl interface. This interface calls genTranHandle on the ArmAgent to retrieve a unique transaction handle, which is returned as part of the correlator. The correlator is then used as parent correlator for sub-transactions. The newCorr call pushes the new correlator on the correlator stack of the ArmAgent. Subsequently, the start time is measured and the EJB method is invoked. After the method call returns, the corresponding end time stamp is taken. Both values are handed over to ArmTranReportImpl by calling process. Finally, the correlator generated by the ArmAgent is deleted from its correlator stack of the transaction. At first glance, the handling of ARM measurements for each method call may seem computationally intensive; but it provides several benefits. First, using a standardised API for performance measurements of distributed applications allows for simple upgrades of the ARM library. Second, ARM allows nested transactions to be measured by using ARM correlators, which is extremely useful for monitoring method calls within transactions. The computational overhead of using ARM is discussed in more detail in Section 4.

ArmTranReportImpl ArmAgent process() newTranReport() notify()

MBean

lookupTranDefinition() processDefinitionInformation() addInvocation()

Figure 6: Forwarding ARM performance data to the management system The forwarding of the measured performance data is performed asynchronously by the ArmAgent (see Figure 6). During the execution of process the ArmTranReportImpl informs the ArmAgent about new measurement data by calling newTranReport. Within the ArmAgent a separate thread is responsible for forwarding the measured data to the MBean managing the particular instance. Thus, it is possible to perform further measurements while previous measurement data is still being processed. The thread also performs the transformation of the internal transaction identifier into the information (container, application, EJB, instance, and method) that is stored in the Proxy in plain text format.

3.3. Integration into a WBEM/CIM Object Manager Figure 7 depicts the integration of the instrumented EJB server into a WBEM/CIM object manager that can be used by a management application to implement any desired management functionality. The information model described in Section 2 is published by the CIMOM. The CIMOM needs a suitable CIM provider that is responsible for retrieving the actual management data whenever the CIMOM is queried. The interface for querying the CIMOM from the outside is standardised: Queries are encoded as XML documents that are transported via HTTP. In the proposed approach, the proprietary interface between the CIMOM and the CIM EJB provider consists of two parts: a JMX agent and a CIMOM connector. The JMX agent is responsible for interfacing to one or more managed EJB servers. This is accomplished by registering the Proxy of each instrumented EJB server at the MBean server of the MBean server of the JMX agent. As a result, the instrumented EJB server can be used within a clean JMXbased management environment as well. The CIMOM connector is responsible for wrapping the JMX agent in order to implement the proprietary CIMOM provider interface. If the instrumentation solution has to be used with another CIMOM, only the CIMOM connector needs to be rewritten.

CIMOM references CIMOM connector implements

CIM information model

JMX agent JVM communication via CORBA or RMI

Proxy

JMX MBean JMX MBean server

EJB server

start/end of ARM transaction MBean registration

JVM

Figure 7: Integration of the instrumented EJB server into a WBEM/CIM object manager

4. Implementation and Measurements The prototypical implementation of the EJB server instrumentation was carried out under Linux using the Sun Java Development Kit (JDK) 1.3. Jonas 2.2.7 [10], an open source implementation of the EJB 1.1 standard, was used for the EJB server. Jonas can work with any relational DBMS for the persistent storage of its beans. Postgres-SQL 7.0.2-26 was applied in this scenario. The Jonas EJB server is completely implemented in Java. Thus, Jonas can run on a variety of different platforms. The instrumentation of the EJB server, as described in this paper, can be integrated seamlessly because the complete source code is available. The instrumentation was carried out using the Sun JMX 1.0 reference implementation. Performance measurements were implemented in Java using the interfaces defined in the ARM 3 API version 0.9. The CIMOM integration is based on the Sun WBEM SDK for Solaris 8. Due to the use of the Java Native Interface in parts of the WBEM environment, the CIMOM is currently only executable on Solaris 8. The full concept described in this paper has been successfully implemented in a prototype [13]. So far, simple tests were performed based on application examples shipped with Jonas. To determine the quality of our instrumentation approach, preliminary performance measurements have been carried out under laboratory conditions. The goal was to analyse the execution time overhead induced by the additional instrumentation code. The instrumenting code was developed in order to keep the runtime overhead low for executing normal business operations. This was achieved at the

cost of a longer initialisation phase. The experiments therefore distinguish these two cases. In a first series of twenty experiments each, the invocation time of the initialisation phase (creation and removal of 5000 EJB instances) has been observed without instrumentation and with instrumentation in place, respectively. The measurements were carried out on an AMD Duron 700 MHz with 512 MB RAM under SuSE Linux 7.0 and JDK 1.3. The results are listed in Figure 8; they show a considerable overhead (more than 35%) in total execution time when the management instrumentation was activated.

mean (ms) std. dev. (ms) % increase

(1) without instrumentation 139523.90 146.33

(2) with instrumentation 190341.10 293.87 36.42%

Figure 8: Measurement of the performance overhead for initialisation In a second series of experiments, the overhead for executing the business methods of the application was considered. For each performance figure, as showed by Figure 9, twenty measurement series were taken. Each one was based on 5000 transactions with two business method invocations each, initiated by a client against the EJB server, and measured at the client side. Column (1) corresponds to no activated instrumentation, thus describing the baseline for the other cases. In column (2), the overhead of the pure ARM instrumentation for response time measurements becomes visible. With less than 2% increase in total execution time, this overhead is perfectly acceptable. Column (3) describes the case with full ARM and JMX instrumentation in place. Here, the total overhead is about 6% and thus still acceptable.

mean (ms) std. dev. (ms) % increase

(1) without instrumentation 198856.95 2189.65

(2) with ARM instrumentation only 202536.85 8210.00 1.85%

(3) with full instrumentation 210877.70 7921.07 6.04%

Figure 9: Measurement of the performance overhead for business methods

5. Related Work Achieving the manageability of modern component-based applications is a primary concern in industrial and academic research. A Java Community Process for specifying management extensions to the Java 2 Enterprise Edition (J2EE) [8] has been started. The specification request addresses server resource management and the

management of the application life-cycle. So far, for commercial EJB servers either a traditional approach is taken in managing the pure server functionality by an SNMP agent extension (e.g. IBM WebSphere), or companies are working on the integration of management capabilities into their products using a modern technique like JMX (e.g. see BEA WebLogic and IONA iPAS). So far, details are only visible partly, and the achieved degree of application-level management is not fully clear. Apart from ours, a few research projects also deal with the instrumentation of component-based applications. Asensio et.al. [1] describe an approach for managing a specific EJB-based application also using the Java Management Extensions. Their approach uses JMX Model MBeans to wrap application beans manually. At runtime, Model MBeans read an XML descriptor determining the management capabilities of the managed resource in order to adapt to its behavior. A disadvantage of this approach is that the instrumentation has no access to management information maintained in the EJB server. Furthermore, it does not describe any information model for integrating EJB applications into management platforms. Hauck [7] describes an approach for automatically instrumenting componentbased applications from an integrated development environment. To achieve this, the developer provides hints in the source code by identifying the relevant work units. From a functional point of view, the instrumentation API proposed in the thesis is similar to ARM, but it hides the correlation of transactions from the developer. No information model for integrating the approach into a management system is proposed. On the other hand, in addition to our approach, Hauck includes the client side by instrumenting GUI components as well.

6. Conclusion The increasing importance of EJB applications for the implementation of businesscritical processes implies the need for managing these applications. For management applications to support effective service-level management, performancerelated metrics such as response times are of special interest. In this paper, a new approach for a generic performance instrumentation of EJB applications has been presented. The application instrumentation is performed automatically and is completely transparent to the application developer. All components are instrumented in the same manner, which ensures complete instrumentation and comparable performance measurements. The whole architecture has been integrated into a CIM object manager. This is the basis for an effective service-level management in the future. The architecture of this generic instrumentation approach consists of three building blocks: a CIM model, a JMX instrumentation, and a performance measurement instrumentation based on ARM 3. The information model represents all relevant associations within an EJB application, as well as the important performance metrics. The JMX instrumentation is responsible for exporting all the real-time management data defined in the information model, i.e. for containers, applications, EJBs, EJB

methods, and instances of EJB methods. The performance measurements are realised using the ARM 3 API and its Java binding. The implemented prototype demonstrates the practicability of the approach. Preliminary results on measuring the overhead of the management instrumentation look promising. Future work will concentrate on evaluating the approach with a realworld application example together with a partner. Further optimisations will also be investigated. The concept will be adapted to EJB 2.0 as soon as the standard is finalised.

References [1] Juan I. Asensio, Victor A. Villagra, Jorge E. Lopez de Vergara, Roney Pignaton, and Julio J. Berrocal. Experiences in the management of an EJB-based e-commerce application. In HP OpenView University Association (HP-OVUA) 8th Annual Workshop, Jun 2001. [2] Distributed Management Task Force. Common Information Model (CIM) Specification, Jun 1999. Version 2.2. [3] Distributed Management Task Force. Specification for CIM Operations over HTTP, Aug 1999. Version 1.0. [4] Distributed Management Task Force. Specification for the Representation of CIM in XML, Jun 1999. Version 2.0. [5] Distributed Management Task Force. Application MOF specification 2.5, Jul 2001. http://www.dmtf.org/var/release/CIM_Schema25/CIM_Application25.mof. [6] Distributed Management Task Force. Metrics MOF specification 2.5, Jul 2001. http://www.dmtf.org/var/release/CIM_Schema25/CIM_Metrics25.mof. [7] Rainer Hauck. Architektur für die Automation der Managementinstrumentierung bausteinbasierter Anwendungen (Architecture for the Automation of Management Instrumentations in Component-Based Applications. PhD thesis, Ludwig-MaximiliansUniversität München, Jul 2001. (in German). [8] Java Community Process. J2EE Management. JSR-77. [9] Lundy Lewis. Service Level Management for Enterprise Management. Artech House Publishers, 1999. [10] Objectweb Group. Java Open Application Server (JOnAS) for EJB whitepaper, 2000. http://objectweb.org/jonas/jonas_root/foc/JOnASWP.html. [11] The Open Group. Systems Management: Application Response Time Measurement (ARM) API, 1998. [12] The Open Group. Specification (Company Review Draft): Application Response Time Measurement Issue 3.0 - Java Binding, Mar 2001. [13] Markus Schmid. Entwurf eines Management-Informationsmodells für EJBAnwendungen und seine Umsetzung auf der Basis von CIM/WBEM (Design of an Information Model for EJB Applications and its Implementation on the Basis of CIM/WBEM). Master’s thesis, University of Applied Sciences Wiesbaden, Aug 2001. (in German). [14] Rick Sturm, Wayne Morris, and Mary Jander. Foundations of Service Level Management. SAMS Publishing, Apr 2000. [15] Sun Microsystems, Inc. Enterprise JavaBeans Specification 1.1, Dec 1999. [16] Sun Microsystems, Inc. The Java Management Extensions Instrumentation and Agent Specification, v1.0, Jul 2000.

Biographies Markus Debusmann received a Diploma in Computer Science from Fachhochschule Wiesbaden - University of Applied Sciences, Germany, and an M.Sc. in Computer Science from Cork Institute of Technology (CIT), Ireland. Currently, he is a scientific staff member at Fachhochschule Wiesbaden and an external Ph.D. student at University of Technology Berlin, Germany. His research interests are application management and distributed systems. He is member of the IEEE Computer Society and the German Informatics Society (GI). Markus Schmid received a Diploma in Computer Science from Fachhochschule Wiesbaden University of Applied Sciences, Germany, in 2001. Currently, he is working on his M.Sc. at Cork Institute of Technology (CIT), Ireland, and is involved in a research project on e-learning. His research interests are management of distributed systems and e-learning environments. He is a member of IEEE Computer Society and the German Informatics Society (GI). Reinhold Kroeger received M.Sc. and Ph.D. degrees in Computer Science from University of Bonn, Germany. He has about 10 years of working experience as member and head of different research-oriented development projects on distributed systems. Since 1993, he is a Professor at Fachhochschule Wiesbaden - University of Applied Sciences teaching Operating Systems and Distributed Systems. His research interests are management of distributed systems, distributed automation systems, object technology, and performance measurements. He is an active member of the German Informatics Society (GI), the SIG on Operating Systems, and a member of ACM.