QoS-aware model driven architecture through the UML and CIM

(1)

DOI 10.1007/s10796-007-9033-8

QoS-aware model driven architecture through the UML and CIM

Kenneth Chan· Iman Poernomo

Published online: 26 May 2007

Abstract The specification of Quality of Service (QoS) constraints over software design requires measures that ensure such requirements are met by the delivered product. Achieving this goal is non-trivial, as it involves, at least, identifying how QoS constraint specifications should be checked at the runtime. In this paper we present an implementation of a Model Driven Archi- tecture (MDA) based framework for the runtime monitoring of QoS properties. We incorporate the UML2 superstructure and the UML profile for Quality of Service to provide abstract descriptions of component- and-connector systems. We then define transformations that refine the UML2 models to conform with the Distributed Management Taskforce (DMTF) Common Information Model (CIM) (Distributed Management Task Force Inc.2006), a schema standard for management and instrumentation of hardware and software.

Finally, we provide a mapping the CIM metamodel to a .NET-based metamodel for implementation of the monitoring infrastructure utilising various .NET features including the Windows Management Instru- mentation (WMI) interface.

Keywords Model driven architecture· QoS · Monitoring· Instrumentation

K. Chan (

B

⁾· I. Poernomo

Department of Computer Science, King’s College London, Strand, London, UK WC2R2LS

e-mail: [email protected] I. Poernomo

e-mail: [email protected]

1 Introduction

Enterprise systems are mission-critical: they must run quickly and reliably, and, while unexpected component failure is accepted as a possibility, it is imperative that these systems are able to recover efficiently from failure. Best practice involves the use of an external runtime monitoring and management framework, operating external to the system, able to inspect, track, trace and respond to deviation from optimal quality of service. In order to communicate relevant properties to the monitoring framework, developers are currently required to manually add instrumentation code throughout the implementation. This is often fa- cilitated by an event-based instrumentation middleware, such as the Novell Open-WBEM or Microsoft Windows Management Instrumentation (WMI) implementations of the Distributed Management Taskforce’s WBEM standard.

This paper describes an approach to the automated synthesis of instrumentation code for monitoring quality of service. The approach is model-driven. It begins with an abstract, platform independent system model and uses transformations to produce interrelating system and instrumentation code. For example, if we specify a model in which a system component should always respond to a service request with an average of less than 10 s, then our transformation produces code that will intercept calls to the component, count response time, compute the average time given a log of previous response times and send a notification if the average has fallen below the requirement. Our choice of management standards (the WBEM CIM) and

(2)

the use of aspect-oriented-style instrumentation architectures (using .NET contexts) results in a low monitoring overhead.

1.1 The problem

Our approach provides a solution to a serious problem in software engineering.

The current practice of manually instrumentation is error prone, like all unguided programming activi- ties. In the worst case, the instrumentation might have errors that will result in failure, and the QoS management infrastructure will itself have zero QoS. However, even if the instrumentation does not fail, there is a danger that it will provide the wrong kind of QoS data to monitoring tools. This happens when the semantics of the instrumentation is inconsistent with respect to the semantics of the system’s QoS requirements.

When a designer specifies Quality of Service (QoS) requirements over software design, he/she hopes that these requirements will be met by the delivered product. Much academic work has been dedicated to verifying constraints hold over a design’s semantics.

This work, while useful for improving designs, does not solve the problem that discrepancies can arise between specification terminologies and instrumentation. For example, the meaning of the response time metric in a design might differ from the semantics of the instrumentation used to monitor response time during testing. Costly manual effort is demanded of developers and testers to check for and eliminate such discrepancies. While feasible for smaller systems, manual checks are inadequate for large scale enterprise systems, due to regular modifications and extensions, a reconfigurable deployment environment and regular subsystem over- hauls. Furthermore, small changes in hardware and software contexts of a deployed systems will often violate testing results obtained under the assumption of a constant execution environment.

It is therefore important that QoS requirements are handled consistently and automatically across the software development lifecycle. The major obstacle to automating consistency of requirements is that abstract representations of QoS employed at analysis and design phases are usually semantically different from, or, at best, have orthogonal purposes to, component properties that should be tested or instrumented in a runtime implementation. For example, it is common with such specification to contain references to contextual properties which are difficult to capture without explicit support from the operating platform.

1.2 Model Driven Architecture

We employ Model Driven Architecture (MDA) (Warmer et al.2003) ideas to overcome this problem.

Model Driven Architecture is a way of developing complex software systems that has generated significant attention from both academia and industry. The Ob- ject Management Group (OMG) have promoted the approach through a suite of standards (Mukerji and Miller 2003) that build upon and extend their UML standard. Major industry players such as IBM, Oracle and Rational Software are actively supporting to the standards, while Microsoft has recently incorporated similar ideas within the Visual Studio tool. The method enables integrated development of systems from heterogeneous models. A key component in the process involves the notion of refining transformations between Platform Independent Models (PIMs) and Platform Specific Models (PSMs). The PIMs provide abstract architectural and process specifications of systems, independent of the choice implementation technologies.

The composition of a collection of MDA transforma- tions define how PIM specifications should be imple- mented as PSMs using the middleware and platforms of a particular enterprise.

A typical MDA scenario is depicted in Fig. 1. A range of PIMs specify different aspects of an enterprise application: UML2 for a components-and-connectors view of the modular architecture, the EDOC for specifying overall business processes and workflow between main modules of the system and E–R diagrams for specifying the types of data to be stored and manip- ulated. A set of transformations are defined in some kind of modular model transformation programming

Fig. 1 Typical MDA scenario

(3)

language and composed to refine the PIMs with platform-specific information, providing a number of interrelated PSMs that are then used to implement the system.

The intention of MDA is to enable designers to focus most of their work on providing robust and architecturally sound PIMs. An abstract specification is obtained through a standard requirements analysis phase. Then refining model transformations assist the the engineer in the implementation and integration of different aspects of a system across the heterogeneous technologies and platforms of the target enterprise. In this way, MDA eliminates some of the effort spent on making implementation decisions at the specification level, and, ideally, results in a better set of integrated PSMs than might be obtained from a manual process.

1.3 MDA and QoS management

In and of itself, MDA does not solve the problem of managing QoS in a way that is consistent with system design. Conformance to QoS constraints, even though verified at a certain level of abstraction, will not be automatically preserved by model transformations to a lower level. Figure2illustrates the problem.

A theoretic ideal would be to prove QoS requirement conformance for an abstract model of system

PIM

PSM

MDA Transfrmation

Abstract Model Satisfies QoS Constraints

Code neration

QoS Model Checker Theorem Prover

QoS Constraints still satisfied?

Transformation doing what it is supposed to?

Are QoS Constraints REALLY satisfied

during rumtime?

Is it possible to verifty the QoS properties of generated components?

Architecture Description with QoS Constraints

Actual Implementation

Model

Implementation

Ge

Fig. 2 The problem of QoS consistency within the MDA process

execution (using, for example, probabilistic model checking) and then apply provably consistent transformations over this model to an implementation. QoS satisfaction would then be formally guaranteed by the transformation. However, in practice, this would require heavy use of formal methods and is too costly to be feasible for the typical enterprise.

This paper advocates a pragmatic remedy: we transform architectures into implementations together with instrumentation for monitoring and management.

Instead of proving QoS properties hold over the transformed code, we simply instrument the system for runtime conformance checks to design-level QoS requirements. While not proving a formal proof that requirements are met, the approach provides a level of trust by automatically supplying the means to ver- ify whether QoS requirements are being met by the deployed system.

1.4 Metamodels, transformations and the WMI

We use three metamodels as part of our model driven instrumentation process: specifically, the OMG UML2 superstructure (OMG2003), the UML Profile for Qual- ity of Service (OMG 2005) and the Distributed Man- agement Taskforce (DMTF) Common Information Model (CIM) (Distributed Management Task Force Inc.2006). The CIM is a platform independent standard for event-based system management and instrumentation. CIM-compliant management middleware use cus- tomised CIM schemas as type libraries to enable data exchange of instrumentation information.

We consider model transformations whose target is the .NET platform, as this provides an interface to the Windows Management Instrumentation (WMI), a Microsoft implementation of the CIM.

Our approach to instrumentation is as follows. We generate a .NET based PSM that includes QoS instrumentation, to monitor QoS constraints required of a UML-based PIM. The instrumentation itself is enabled using the Windows Management Instrumen- tation (WMI) API, a Microsoft implementation of the CIM. Our instrumentation publishes information to a WMI repository, which contains data formatted according to a CIM-compliant schema. The CIM schema itself is platform independent, and so information published in it can be understood by any CIM compliant monitoring tool.

The paper proceeds as follows.

(1) Section2summarizes the framework and provides relevant background information.

(4)

(2) We then define our three metamodels, of decreas- ing levels of abstraction:

– Section3defines the integration of the UML2 superstructure and the UML Profile for QoS.

– Section 4 presents the CIM schema based metamodel, explaining how we have adapted it to address component-oriented QoS issues.

– Section5explains the .NET/WMI metamodel for code instrumentation.

(3) Section6outlines our approach to transformation of models between the three levels, starting from the topmost abstract specification level all the way down to code generation at the implementation level.

(4) Section 7 describes related work and discusses future research directions.

2 Background

We assume the reader is acquainted with the UML2 superstructure, metamodelling with the Meta-Object Facility (MOF) (OMG 2000) and the basic princi- ples of MDA. In order to understand the details of our approach, the following background is provided on the CIM, the WMI and .NET context-based interception.

2.1 Instrumentation through WBEM standards

The Distributed Management Task Force (DMTF) is a group concerned with standardising distributed management protocols to enable better enterprise in- teroperability. The group includes vendors such as Microsoft, HP and Cisco. The DMTF’s Web-Based Enterprise Management (WBEM) comprises a suite of management and Internet standard technologies which aim in unifying the management of enterprise computing environments. WBEM enables the management of a system through the use of web-based technologies.

The Common Information Model (CIM) serves as the inventory model within the WBEM. It uses object- oriented, class-based schemata to define the types of information necessary for instrumenting and managing applications. The two most important kinds of typing entity that are defined in a CIM schema are

– CIM classes, whose instance objects represent aspects of a system that can be managed, by calls

to object methods, or inspected, by querying object properties. Depending on the schema, CIM objects can be defined for computer systems, hardware devices, files, applications, networks, protocol endpoints, policies, and, in the case of this paper, QoS views of an application.

– CIM indications, representing push-based events that are fired when interesting aspects of a system change. Depending on the schema, indication objects might signify a service’s status changing from up to down, an uncaught exception from an application, a hard disk approaching full capacity or, in the case of this paper, instrumentation necessary in order to compute QoS metric values for an application.

CIM schema can also define more complex relationships between classes and indications, by means of associations.

The DMTF have defined a metamodel for CIM schema, called the CIM metaschema. (The upper part of Fig.7shows the full CIM metaschema.) It formally defines the relationships between CIM schema typing entities.

The WBEM provides a set of standard CIM schemata that define the types of information common to specific management domains, independent of particular technologies or implementations. These

“Common Models” of the WBEM include schemata for systems, devices, applications and networks.

However, it is also possible to define application specific schemata by means of the CIM metaschema’s extension mechanism. This is the approach generally advocated for QoS instrumentation of applications: a schema is defined for an application, with classes and indications specifically developed to provide required QoS information about the components of the application. The main problem with this approach is that schemas need to be manually designed for each application. Our approach generates application-specific schemas automatically via model transformations. We define transformation in terms mappings from models of the UML metamodel and to schema of the CIM metaschema.

The Windows Management Instrumentation (WMI) is a kernel-level instrumentation technology developed for the Microsoft Windows Platform. It is Microsoft’s implementation of CIM and it is integrated in every Microsoft Windows Platform from Windows 98 on- wards. A WMI library has been developed for the .NET platform. The WMI provides a repository, called the CIM Object Manager (CIMOM), for storing both CIM schemas and CIM schema instances.

(5)

Fig. 3 Relationships between WBEM compliant

monitoring tools, instrumented implementations and a CIM repository

CIM Object Manager (CIMOM)

CIM Repository CIM schema instance Implementation CIM object providers

WBEM compliant monitoring tool

Syste m

Subscription based notification

Data queries CIM Class

Object Provider

CIM Indication Object Provider

CIM object providers publish information to repository as instances of schema classes and indications System components

can send notification of important changes by firing Indication provider events

System components publish information and are managed by method calls from CIM object providers

CIM schema instance CIM Class

instance

CIM In dication instance

CIM Class

CIM Indication

The CIMOM acts as an intermediary between instrumented .NET applications and WBEM-compliant monitoring and management tools, as depicted in Fig.3

– The WMI library enables .NET classes and events to be used as CIM schema object and indication

“providers,” respectively, publishing information and events to the CIMOM. For example, a service can be instrumented with an object provider, so that its status (e.g., busy, idle, up, down) is visible as a CIM object in the repository. Similarly, a service can be instrumented with an indication provider, to notify the CIMOM of a change in the service’s status.

– The WMI allows developers to program or use standard management tools to obtain management data information from a computer system, a net- work or an enterprise by subscribing to indication events or querying CIM objects stored in the

CIMOM repository. For example, a WBEM compliant tool can inspect the CIMOM to query a service’s status or to be notified of service status change.

2.2 Contexts and .NET

Ultimately, we are interested in using MDA to develop instrumented applications in object oriented .NET.

We will utilize the WMI library for .NET to define QoS instrumentation based on class and indication providers.

Our approach maintains encapsulation of function- ality from instrumentation by means of context-based interception. A context in the .NET Framework is used as an object’s execution scope and to intercept calls going to and from the object.

For the purposes of this paper, we ignore the implementation details and consider the following con-

Fig. 4 Simplified semantics of context-based interception

(6)

ceptual semantics of a simple context, as illustrated in Fig.4.¹We can consider a context as a type of container for .NET class objects. Contexts are associated with two kinds of methods, a pre-call process and a post-call process. When clients, external to the context, invoke a contained class object, the context will execute the pre- call process. Immediately after the class object returns a value, and prior to returning control to the calling client, the context executes the post-call process. Calls to any components contained within the context will be treated in the same way, while calls within the context are not intercepted. In this way, a range of functions can be implemented as pre- and post-call processes that “cut across” the methods of all contained objects.

The principle is therefore a form of aspect-oriented programming.

For our purposes, context-based interception will be used to separate the business logic from instrumentation plumbing, by utilizing pre- and post-calls to provide information about a class object’s behaviour without having to directly add instrumentation code to the class definition.

3 UML2QOS: A Platform Independent Metamodel There are a range of architecture description languages (ADLs) for specifying coarse grain, component- and-connector based views of the structure of a system (Medvidovic and Taylor 2000). The Ob- ject Management Group (OMG) recently included a

1Our semantics is a simplified abstraction of how context- based interception is implemented in .NET with theSystem.

Runtime.Remoting namespace. In .NET, contexts are implemented as custom attribute classes, providing the ICon- textProperty and IContributeServerContextSink interfaces. Interception code is associated with a context via message sinks, classes which implement the IMessageSink interface. Interception of sychronous method invocations is achieved by refining the SyncProcessMessage method of the following abstract sink class,GenericSick:

We implement diversions to pre-call processing and post- call processing within the SyncProcessMessagemethod, by calling the class’sPreCallProcessingandPostCallPro- cessingmethods, respectively prior to, and immediately after invoking the requested class. It is possible to build a context that has a chain of such sinks, to combine sets of cross-cutting functions. Contexts can then be associated with classes using .NET’s declarative custom attribute syntax. For more details, see Mavrides (2006).

components-and-connectors ADL as part of the UML2 superstructure. However, quality of service does not form an inherent part of this. Instead, the OMG sepa- rately (and earlier) provided the UML Profile for QoS (OMG2005) The profile is a specialisation of the UML infrastructure metamodel that enables us to define and constrain a set of commonly used quality of service attributes. The profile is intended for use with the UML infrastructure. For example, it can be used to specify QoS constraints over classes. It is not immediately clear how the profile should be used with a components-and- connectors style metamodel.

Our Uml2QoS metamodel, depicted in Fig. 5with- out attributes and operations, attempts to marry the two standards. The metamodel takes two elements, QoS Constraint and QoS characteristic, from the UML Profile of QoS and associates them with the Compo- nent, Interface, Operation and Connection elements of the UML2 superstructure. We shall assume the reader is familiar with these elements of the superstructure.²

The remaining elements of the UML Profile for QoS do not have a direct association with elements of the UML2. We briefly summarize their meaning and intended usage.

QoS Characteristic defines a type of QoS property that may be observed over either a component or one of its operations. The QoS properties that have been included in our metamodel are quantifiable and observ- able, with a semantics derived from the UML profile and, consequently, the ISO 9126 standard for software QoS (International Standards Organization2001) (see also International Standards Organization (1998)). The following relationships warrant some explanation:

– Characteristics belong to various QoS Categories within the profile. Categories serve the purpose of categorising the characteristics in some mean- ingful way for use in, for example, a hierarchical repository. For example, following the ISO 9126 with the obvious interpretation, the QoS Charac- teristic Response Time belongs to the Performance category.

– Each characteristic is associated with a particular QoS Dimension, which defines the metric notions for measuring that particular characteristic. Each QoS Characteristic may be specialised further if we require a complicated metric. The statisticalQual- ifier property identifies how the metric is being measured over time (e.g., Minimum, Maximum and Average values explain that the metric is computed

2Their meaning and purpose is usually clear from their names.

(7)

+name:string Component Interface

1

-provided 0..*

-name:string Operation

1

*

-Qualification:QualificationType -value: QoSValue

-logicalOperator: logicalOperators QoS Constraint

0..1

-e 0..*

0..1

-a

0..* QoS Characteristic

Connection -Source

1 *

-Target 1

1 -required

0..* 1

QosRequired QosProvided

0..1

-d 0..*

-b 1..*

0..*

0..1 0..* -c

QosContract

Environmental Characteristic 0..*

0..*

1

<<QoS Characteristic>>

Fault Tolerance

Availability

Response Time

Resource Utilization -<<QoSDimension>>

-rate:real

Throughput

QoSCategory

1..*

1

-statisticalQualifier:QoSStatisticalAttribute -Direction:Directionkind

-unit: string

QoSDimension

1

<<QoS Category>>

Performance <<QoS Category>>

Dependability

{Context Operation invariant:

a->forall(q:QoSConstraint|c-> includes(q.b))}

{Context Component { invariant:

d->forall(q:QoSConstraint|e-> includes(q.b))}}

Fig. 5 The Uml2QoS metamodel, consisting of the UML2 superstructure integrated with the UML Profile for QoS

as a minimum, maximum or average, respectively, over time), the Direction property defines what is considered a “good” value for the metric (for example, if direction is greaterthan, then higher values of the metric are more desirable than lower values), and a unit of measurement should also be specified (for example, milliseconds, minutes, percentages).

The metamodel in Fig.5displays the following important QoS characteristics taken from the ISO 9126:

1. Fault Tolerance, the number of avoided fault pat- terns compared with the number of fault patterns to be considered.

2. Availability, defined by the formula [To/(To + Tr)], where To is the operation time and Tr is the time where the system is under repair and non- operational.

3. Response Time, a measure of the time it takes to complete a specified task.

4. Resource Utilisation, the average percentage of use a resource undergoes during operation.

5. Throughput, the amount of task successfully per- formed over a given period of time.

The full metamodel includes all performance and dependability qualities from the ISO 9126.

Quality of Service constraints are defined in the metamodel according to Fig. 6. QoS constraint is an abstract metaclass. Instantanting meta-objects of spe- cialised QoS constraints requires a QoS Context, which, in our case, consists of (1) a constrained UML2 superstructure element and (2) the QoS characteristic involved. There are three types of concrete constraint metaclasses:

– QoSOffered (subclassed in the metamodel as QoSProvided). These constraints impose a limita- tion on accepted values for the implementation of a component, or one of the operations exposed by its provided interface.

– QoSRequired constraints restrict the accepted QoS values provided by any component which is con- nected to the component through instantiation of its required interface.

(8)

Fig. 6 QoS constraints relationship with OCL in the UML Profile for QoS

– QoSContract is a combination of provided and re- quired constraints, using required QoS constraints as a “pre-condition” clause that, assumed to be satisfied, entails that provided QoS constraints must be satisfied, as a “post-condition.”

The constraints represented in the metamodel are atomic, but, as constraints inherit from the UML’s OCL Constraint element (Warmer et al.2003), it is straight- forward to compose constraints using OCL proposi- tional functions. Further extensions will be needed to accommodate more complicated constraints, such as constraints that involve conditionals and patterns.

4 CIM-based intermediate metamodel

We intend to generate CIM schemata (Distributed Management Task Force Inc. 2006) from Uml2QoS models. A generated schema will provide an application-specific instrumentation type specification, al- lowing the publication of data that will inform any WBEM-compliant monitoring tool if QoS requirements are being maintained by an implementation of the design.

The metamodel, hereafter abbreviated CimQoS, ex- tends the CIM metaschema, and, as such, provides explicit representation metadata necessary for instrumentation and management.

The standard metaschema is represented at the top of our metamodel in Fig.7. The primary architectural building block is the CIM Class element—this is essen- tially a composable component, representing an important, monitorable aspect of a system. A service has CIM Method operations and CIM Property attributes. An

essential element of the metamodel is Indication, which represents management and monitoring events that can be sent and subscribed to.

The main specialisation we make to the standard CIM metaschema, presented at the bottom of the metamodel in Fig. 7, is achieved by subclassing the Class element by QoS Property and its descendants, and subclassing the Indication element by Probe and its descendants.

4.1 QoS Properties

The purpose of the QoS Property is to designate a set of CIM classes that can be used to expose the values of QoS properties for monitored elements through a CIM repository, such as the CIMOM. An instance of a QoS Property is a CIM class that types QoS property information in a schema. Schema instances of this class will provide QoS information.

Each subclass of QoS property classifies QoS proper- ties that should be monitored for particular application schemata. There is therefore a one-to-one mapping from QoS characteristics in the Uml2QoS and properties in the CimQoS,

4.2 Probes

The Probe element subclasses the CIM Indication. It is intended that Probe instances are CIM indications that provide push-based information about system changes that are relevant to computing QoS values. The inten- tion is that schema instances of QoS Property classes will have their values computed via subscriptions to specialized Probe elements. In order to make the sub- scription explicit at the modelling level, we provide an association style metaclass Subscription, that references probes and QoS properties.

Because indication probes are to be used to compute values of properties, the semantics of the CimQoS, and the semantics of its instance schemata, is more specific than in the UML. Essentially we use the informal semantics of the UML profile and the ISO standards (International Standards Organization 1998, 2001) in order to determine the types of Probe instances are necessary to calculate the QoS values.

Here is how the five QoS characteristics described above for the Uml2QoS now correspond to QoS Property instances with specially designated Indication instances

1. Fault Tolerance. Since patterns do not exist explic- itly, we can only monitor the occurrence of faults,

(9)

Fig. 7 QoS extension of the CIM metaschema, represented as a metamodel in the Meta-object Facility. See Fig.8 for associated constraints on model instances

and then deduce their patterns. In order to count the number of faults, we only need a single type of Indication notifying the occurrence of a fault.

2. Availability. To monitor availability we will need two types of Indication, a first type to indicate that the monitored subject has failed and a second type to indicate that it is recovered.

3. Response Time. To monitor that we also need two types of Indication, one to notify the start of a task and one for the finishing of the task.

4. Resource Utilisation. The CIM provides elements that represent a range of common software and

hardware resources, stored as Property instances.

For example, physical media elements have a max- imum capacity property MaxCapacity specified in the CIM_Hardware schema. We use this informa- tion to compute utilisation for specific resources.

5. Throughput. We further specialize the throughput property to offer two ways to compute throughput using metadata from the CimQoS: (1) Utilise the DMTF’s CIM_Metrics schema, which has explicit definitions for a unit of work or (2) Employ a single Indication element to notify the successful completion of named tasks.

(10)

As with the Uml2QoS metamodel, we have only included a limited set of attributes into our metamodel, but an arbitrary number can be added via subclassing of CIM QoS property.

4.3 Meta-constraints for schemas

We emphasise that the metamodel is a metaschema:

instances of its elements form actual CIM schemata.

It is the classifiers of these schemata that provide the typing information for QoS data. In order to discuss the form of this typing information at the metamodelling level, we must employ meta-constraints of the form given in Fig.8. Meta-constraints to define how schemas should be formed for typing application specific QoS data. The constraints presented here define two things:

(1) What attributes are necessary for a particular QoS Property (for example, any CIM class that instanti- ates Response Time should have a resTime variable to store the value of the response time), and (2) Naming conventions for related elements (for example, the a Response Time class must subscribe to two probes that have the same name as the class, concatenated with

“_start” and “_end,” respectively.

The utilisation of the CIM allows specification of messaging elements that are usually not first class entities in component models, and the explicit representations of various system environmental elements also prove to be very helpful in extending the scope of our monitoring context. Using our CIM-intermediate metamodel, we may define transformations to any platform dependent metamodel, provided that the target platform also implements the CIM. Since our monitoring

infrastructure is generic, we may synthesize our monitoring instruments on any of these platforms. This opens up the potential for a cross-platform monitoring infrastructure over heterogeneous enterprise systems.

However, for the purposes of our current research, we have investigated how this works in the .NET context only, considering a .NET/WMI metamodel, now defined.

5 .NET implementation level (PSM)

A final mapping is defined to produce a platform specific implementation in .NET, Net, together with WMI instrumentation code. Implementations are represented within a simple .NET metamodel, used to describe the structure of these deliverables, based on the probes and gauges paradigm of Garlan et al. (2001).

An important aspect of our framework is that transformations pass through an intermediate metamodel, used to define instrumentation information via the CIM schema. This information is then used within the final PSM by virtue of .NET use of the CIM to structure WMI instrumentation code. The main reason for em- ploying a middle metamodel that there are a range of monitoring and management implementations that conform to the CIM schema. We can therefore reuse the transformation mapping between the UML and the CIM metamodels to generate intermediate instrumentation metadata that may be then used in other transformations to non-.NET PSMs or even, potentially, a heterogeneous architecture involving a range of CIM instrumentation enabled platforms.

Fig. 8 Example constraints on the QoS extension of the CIM metaschema given in Fig.7

context QoS_Property

{ self.properties.exists(p|p.name="sourceInstance" and p.type=string) self.properties.exists(p|p.name="direction" and p.type=string)

self.name = sourceComponent.name.concat("_").concat(statType).

concat("_").concat(self.Type.name) } context Response_Time

{ self.properties.exists(p|p.name="resTime" and p.type=real64) and self.subscribedTo.exists(s,e|s.name=self.name.concat("_start") and

and e.name=self.name.concat("_end")) } context Method_Response_Time

{ self.properties.exists(p|p.name="methodName" and p.type=string) and

self.subscribedTo.forall(s|s.subscribes.exists(p|p.isTypeOf(Method Probe))) } context Availability

{ self.properties.exists(p|p.name="availability" and p.type=real64) and self.subscribedTo.exists(s,e|s.name=self.name.concat("_up")

and e.name=self.name.concat("_down")) } context Probe

{ self.properties.exists(p|p.name="ID" and p.type=real64) } context Method_Probe

{ self.properties.exists(p|p.name="methodName" and p.type=string) and self.properties.exists(p|p.name="TimeStamp" and p.type=DateTime) }

(11)

Fig. 9 Metamodel for instrumented .NET systems

Class <<.NET>>

Method <<.NET>>

1

*

-timeStamp -identifier:string

ManagementEvent <<.NET>>

-identifier:string

EventClass <<.NET>>

-Qualification:string -statisticalQualifier:string -direction:string -logicalOperator:string -target: Type

Gauge <<.NET>>

-subscriptions *

*

Method-Pre

Method-Post 1

* 1

*

0..1

-initiates 0..*

0..1 -initiates

0..*

Environment 1

0..*

ManagementClass <<.NET>>

Management Property <<.NET>>

1

1..*

Context

*

The .NET framework is a good final target domain for us to explore generation of instrumented code, as it provides a widely used CIM-based monitoring and management middleware, the Windows Management Instrumentation. In fact, by virtue of the fact that the WMI is based on the CIM, we need not only monitor Windows-based services: we can use WMI to monitor services on any platform, provided they publish management and instrumentation information in the CIM format.

The relevant part of Net is given in Fig.9. The Class and Method properties should have an obvious inter- pretation.³The intended semantics of Context, Method- pre and Method-post is to represent .NET contexts, and associated pre- and post-call functionality, respectively.

We use the WMI to build a probes-and-gauges (Garlan et al. 2001) instrumentation and monitoring infrastructure. The infrastructure considers .NET architectures that conform to the metamodel of Fig. 9. It contains the obvious elements necessary to represent the structure of a .NET program (e.g., Class and Method elements). The novel aspect of the metamodel

3In terms of implementation, we must consider Class elements, not as basic .NET classes, but as inheriting from ContextBound- Object, in order to be associated with contexts.

is the inclusion of entities that are necessary for instrumenting .NET classes.

The EventClass entity represents the WMI’s abstract event class, a means of providing indications to the CIMOM.

The interception elements, Method-Pre and Method- Post, denote instrumentation code that must be exe- cuted prior to, and immediately after, respectively, the execution of a method. We interpret an association between either of these elements and an EventClass to signify that the EventClass will be fired as a result of executing the interception element. In this way, we represent how CIM Probe providers are to be are woven into the method of a component, instrumenting the necessary information required for computation of QoS characteristics in relation to that particular .NET method.

For our purposes, the Method-Pre and Method-Post elements can be considered as restrictive in the type of instrumentation code they contain, effectively only permitting the firing of events classes.

Classes are probed using Event Class objects, which, as indication providers, publish information to the CIMOM. This instrumentation data is then subscribed to by instances of the Gauges metaclass. Gauges are responsible for computing QoS characteristics as well as checking them against the value specified by

(12)

a constraint. Necessary data is generally obtained through push-based subscription to either Manage- ment Event objects, but may also be accessed though pull- based queries to the WMI repository (partic- ularly information that may only be observed by the platform, such as memory capacity). For such queries, .NET provides an API of ManagementClass which represents much of the system related entities in the form of accessible classes. The various ManagementProperty is contained within these class, and includes all properties specified in the CIM standard, providing a rich source of contextual information of executing components. The Net metamodel sup- ports all Operation-related monitoring for Uml2Qos Provided Constraint constraints.

6 Transformations

We now sketch our approach to QoS instrumentation generation through two kinds of model transformations across the three metamodels. We use three model transformations: UML2CIM, generating CIM schemas from UML models, UML2NET, generating .NET skeleton code from UML models, and CIM2NET, generating .NET instrumentation code from CIM schemas.

The CIM2NET transformation involves both developing WMI providers for a given schema and ensuring the providers instrument appropriate .NET components. The relationship between the transformations and metamodels is given in Fig. 10. The idea is to take a given QoS requirement for a UML2 component, determine the QoS characteristics involved, generate a schema that will be used to type probe and gauge data for these characteristics, and associate probe and gauge providers with the corresponding .NET component via contexts.

We have implemented a beta version of our translations using the INRIA Triskell group’s Kermeta

Alternative WBEM metamodel .NET metamodel

UML2 + UML QoS Profile

PIM

PSM ^CIM2NET

(UML2CIM(U)):

Instruments (CIM schema

instance providers) UML2NET(U):

.NET classes

Instruments (CIM schema

instance providers) Other platform implementation U:

Abstract model with QoS constraints

CIM metaschema + QoS Profile UML2CIM(U):

CIM schema containing types of QoS properties to be instrumented

UML2CIM

UML2NET CIM2NET CIM2Other

Fig. 10 QoS-aware MDA framework

transformation language. In this language, model transformations are defined as meta-operations of M2 metaclasses, whose input types are PIM metaclasses and whose output types are PSM metaclasses. This has the advantage of providing a unifying MOF-style framework for understanding both metamodels and model transformations.

We omit the full description of the transformations and instead describe their behaviour informally.

As a motivating example for our transformations, we define a simple application of model transformation, involving a single average response time constraint im- posed over method calls to a component. Using the syntax of the UML2 superstructure, the single component model and its constraint is given in Fig.11a. Our transformations operate on a meta-object representation of the model, shown in Fig.11b.

The application of UML2CIM will result in a CimQoS model for the system, as depicted in Fig. 12.

This model provides an application specific schema for typing QoS information about components of an implementation. The schema identifies two Indication elements that must be used to count response time.

A final, further transformation is then applied to obtain the .NET implementation model of the component alongside the probe for instrumenting and gauge for monitoring the specified constraint. This is depicted in Fig. 12. The two indications of the CIM are transformed into corresponding .NET Event Class elements. The generated probe defines exactly how response time should be computed, as instrumentation that should be woven into the component. It involves a Method-Pre instance—its purpose is to fire a Manage- mentEvent corresponding to starting the response time count. The probe’s Method-Post instance defines code to fire an event corresponding to ending the response time count.

6.1 UML2CIM

The transformation from Uml2QoS to CimQoS is a horizontal transformation that maps elements from the UML2 based specification into a CIM compati- ble form. The structural properties of functional elements in the model is preserved, and the focus on our transformations are on the realisation of a monitoring infrastructure.

The main architectural elements in our Uml2Qos metamodel (components, connections, methods, etc) are transformed into their obvious analogs in the CimQoS, preserving their structural composition.

In particular, Uml2Qos Component elements are

(13)

Fig. 11 Example Uml2QoS model, used as the input PIM for the UML2CIM and UML2NET transformations

mapped to CimQoS Service elements, with the ob- vious preservation (names are preserved, and operations and attributes are mapped to CimQoS methods and properties, respectively). Notably, we do not pre- serve required interfaces explicitly, as, from the CIM (and, later, .NET) perspective, these are implicit usage notions.

We map Uml2Qos provided constraints to Provided Constraint Monitor instances in the CimQoS. The map- ping implies that each constraint specified will have a corresponding monitoring instrument to check for constraint satisfaction. These instruments will, later, at the Net stage of transformation, eventually generate gauge type components that run alongside the

Fig. 12 The CIM schema generated by applying the transformation UML2CIM to the ConvertSys UML model. a A class based representation of the schema. b The meta-object representation that is immediately generated by the transformation. Figure13 illustrates how the schema and its instances are

represented using the WBEM managed object format within the CIMOM

(14)

component system. Composite constraints are viewed as the union of a set of constraints, in this paper we only consider for the transformation of atomic QoS Pro- vided constraints and their respective QoS property.

6.2 Generating .NET

We require two mappings in order to obtain the .NET model—a transformation UML2NET from the original UML2 model to generate class definitions from components in the obvious way. Then, using the CIM schema, the transformation CIM2NET should generate the ap- propriate contexts, interception, Probe providers and QoS Property providers to expose required properties to the CIMOM.

From our CIM intermediate metamodel we may apply further transformations to obtain a platform- specific model for component systems. In our case we have chosen the .NET framework as our target platform, so that we may utilise WMI through the API of the .NET framework. The transformation from CimQoS to Net involves mapping CIM schema to actual platform specific features provided by .NET.

Through these transformations we map all QoS related elements to an actual probes-and-gauges. Associations between probes and gauges are realised by their identifier attributes, with their values set either during com- pilation or dynamically during runtime.

We make use of custom Event Classes to realise our CIM Indications. These events are instantiated and

fired by probing code that are weaved into relevant positions within the target component implementation.

All ManagementEvents contain a TimeStamp attribute by default which we may utilised for the computation of time related QoS properties. Gauges subscribe to these events using ManagementEventListeners, and the types of ManagementEvent each gauge subscribes to can be determined solely by the type of the gauge. Both Gauge and Probe elements in our metamodel encap- sulate the essential information required for their code synthesis.

Figure13represents how the final, PSM .NET ver- sion of EConvert and its instrumentation operate in re- lation to the generated CIM schema, represented using the WBEM managed object format in the CIMOM.

The combination of the WMI and an interception architecture ensures and efficient instrumentation and monitoring framework. Besides being standards compliant, due to its native OS support, the WMI has the advantage of efficiency over an alternative custom- built solution. The use of interception does have some impact on performance, if overused in an architecture.

Our case studies have shown that QoS constraints are typically not given over every component in a system, but rather over key service providers, with the resulting interception has a negligible performance impact. How- ever, in general, it is important to ensure that designs are not so fine grained in QoS constraints as to lead to inefficient systems that are “bloated” with monitoring interception code.

Fig. 13 Representation of the how the final, PSM .NET version of EConvert and its instrumentation operate in relation to the generated CIM schema, represented using the WBEM managed object format in the CIMOM

(15)

7 Related work and conclusions

This paper described a means of reducing development expense by automatically generating system instrumentation. Our techniques, being model-driven, permit us to exploit the trend for quality of service requirements to be integrated early into best practice architectural design.

This work has its history in the model-based runtime component assembly work conducted by Poernomo with the TrustME group at Monash University and the DSTC (Poernomo et al.2003). That work provided a runtime configuration tool for Microsoft COM+ component architectures, based on defining architectural models written in the Component Collaboration Ar- chitecture part of the OMG EDOC enterprise distributed computing metamodel (OMG1999). The Monash system also employed a CIM schema as a means of monitoring systems for conformance to quality of service constraints expressed as formulae of a probabilistic temporal logic (Poernomo et al.2005,2006). Our OCL- based approach to specifying QoS is simpler, following first order logic, and, consequently, more widely understood by potential users. The primary deficiency with the Monash system was the lack of automated instrumentation development for constraint monitoring. This problem is remedied by our model-driven approach.

A much simplified version of this metamodel was used in Chan et al. (2005) as a means of structuring metadata about instrumentation and monitoring code (but not within an MDA context).

We have shown how to generate platform-specific system instrumentation from platform-independent architectural models, annotated with quality of service constraints. We use the Distributed Management TaskforceŠs CIM and WBEM standards to generate schemas for instrumentation and monitoring. Instru- mentation is then utilized within a monitoring, prediction and adaptation infrastructure to ensure optimal quality of service. A prototype implementation is being developed using the CIM compliant WMI API under Microsoft .NET.

Combining the UML2 superstructure and the QoS profile is sufficient for defining components-and- connector architectures with QoS requirements. Other QoS constraints languages like the QML could also be integrable with UML (Frolund and Koistinen 1998).

The UML Profile was chosen for its simplicity, its basis in the ISO 9126 standard for QoS, and the fact that it is a specialisation of the core UML. The last point readily lends the profile to be integrated with the superstructure through the MOF, as we have described.

The use of contexts to demarcate instrumentation from ordinary code has precident in the instrumentation literature. An AspectJ-based instrumentation architecture is described in Brunner and Keller (2003).

Aspects are used in a similar way to our contexts in order to take Application Response Measurement (ARM) timing. Benefit could be gained by adapting our approach to the automatic generation of this kind of aspect oriented instrumentation.

There are a range of promising MDA oriented ap- proaches to QoS checking currently. However, none of this research considers the CIM standard, nor work with WMI and the .NET context. Solberg et al.

(2003) argues that there is no viable way to provide guarantees on QoS consistency between levels unless actual model transformations are made QoS-aware.

Researchers such as Wang et al. (2005) have argued that heterogeneous QoS-oriented monitoring is a key aspect of component deployment and system management: MDA is a way of getting closer to that goal. Yang et al. attempt to address this problem with a language for specifying QoS parameters (Yang et al.2003). The language is can be transformed into OCL-augmented UML models as well as executable, instrumented code.

Merilinna (2005) defines a range of horizontal MDA transformations (transformations involving the same abstract modelling language) that systematically con- struct QoS-oriented system designs from basic specifications. Jezequel et al. (2004) provide one of the most advanced attempts to automatically generate and integrate QoS contracts into system models throughout the MDA process. QoS contracts may be attached to the provided interfaces of a component given the QoS contracts on its required interfaces. MDA transformations generate a testing infrastructure for actual implementations, based on weaving instrumentation code into component code.

Through the use of MDA transformations we provide an automated process for assembling the monitoring infrastructure that is required for the runtime monitoring of QoS constraints for software components and component services. Our approach also has the ad- vantages of being compliant to OMG and DMTF technologies, ensuring easier integration with other tools and methodologies that comply to similar standards.

By conforming to standards, our approach has an ad- ditional advantage of being readily interoperable with other tools and techniques. Our UML platform independent models can be developed within any UML- based tool that offers a Meta-object Facility export. The CIM schemata we generate can be used as type libraries for instrumentation of any implementation platform

(16)

with the ability to provide CIM-based managed objects.

Also, the instrumentation we generate can be monitored by any WMI-based monitoring tool, besides the MPA system.

References

Brunner, M., & Keller, A. (eds). (2003). Efficient and trans- parent instrumentation of application components using an aspect-oriented approach. Lecture Notes in Computer Science, vol. 2867. Berlin: Springer.

Chan, K., Poernomo, I., Schmidt, H. W., & Jayaputera, J.

(2005). A model-oriented framework for runtime monitor- ing of nonfunctional properties. In QoSA/SOQUA. LNCS, vol. 3712 (pp. 38–52). Berlin: Springer.

Distributed Management Task Force Inc. (2006). Common Information Model (CIM) standard.

Frolund, S., & Koistinen, J. (1998). Quality-of-service spec- ification in distributed object systems. Technical Report HPL-98-159, Software Technology Laboratory. Palo Alto, CA: Hewlett-Packard.

Garlan, D., Schmerl, B., & Chang, J. (2001). Using gauges for architecture-based monitoring and adaptation. In Working conference on complex and dynamic systems archi- tecture Brisbane, Australia, 12–14 December, 2001. Australia:

DSTC.

International Standards Organization (1998). ISO/IEC 13236:1998 information technology—Quality of service:

Framework.

International Standards Organization (2001). ISO/IEC 9126 1-4:2001 information technology—Software product quality.

Jezequel, J. M., Defour, O., & Plouzeau, N. (2004). An MDA approach to tame component based software development.

In Formal methods for components and objects, second inter- national symposium, FMCO 2003, Leiden, The Netherlands, November 4–7, 2003, Revised Lectures. LNCS, vol. 3188 (p. 260).

Mavrides, A. (2006). .NET non-functional constraint processing. Master’s thesis, King’s College London. Available at http://palab.dcs.kcl.ac.uk/publications/mavrides-2006a.pdf.

Medvidovic, N., & Taylor, R. N. (2000). A classification and comparison framework for software architecture description languages. IEEE transactions on software engineering, 26(1), 70–93.

Merilinna, J. (2005). A tool for quality-driven architecture model transformation. PhD thesis, VTT Electronics, VTT Techni- cal Research Centre of Finland, Vuorimiehentie 5, P.O.Box 2000, FI-02044 VTT, Finland.

Mukerji, J., & Miller, J. (2003). MDA Guide Version 1.0.1.

Object Management Group. Available at http://www.

omg.org/docs/omg/03-06-01.pdf.

OMG (1999). UML profile for enterprise distributed object computing (‘) RFP. Technical report, Object Manage- ment Group. Available at ftp://ftp.omg.org/pub/docs/ad/

99-03-10.pdf.

OMG (2000). Meta Object Facility (MOF) Specification. Object Management Group.

OMG (2003). UML Superstructure v2.0. Technical report, Object Management Group. Available at http://www.

omg.org/cgi–bin/doc?ptc/2003-08-02.

OMG (2005). UML profile for modeling quality of service and fault tolerance characteristics and mechanisms. (2005).

Poernomo, I., Reussner, R., & Schmidt, H. (2003). Architectural configuration with edoc and .net component services. In 29th EUROMICRO conference 2003, new waves in system archi- tecture, 3–5 September 2003, Belek-Antalya, Turkey (pp. 61–

69). Los Alamitos, CA: IEEE Computer Society.

Poernomo, I., Schmidt, H., & Jayaputera, J. (2005) Timed probabilistic constraints over the DMTF common informa- tion model. In The 9th IEEE international EDOC confer- ence (EDOC 2005), 19–23 September 2005, Enschede, The Netherlands (pp. 261–273). Los Alamitos, CA: IEEE Com- puter Society.

Poernomo, I., Schmidt, H., & Jayaputera, J. (2006). Verification and prediction of timed probabilistic properties over the distributed management taskforce common information model.

International Journal of Cooperative Information Systems, 15(4), 633–658.

Solberg, A., Husa, K. E., Aagedal, J. O., & Abrahamsen, E.

(2003). QoS-aware MDA (2003). In Electronic publication from model driven architecture in the specification, imple- mentation and validation of object-oriented embedded sys- tems (SIVOES-MDA’2003) in conjunction with UML’2003.

Wang, G., Wang, C., Chen, A., Wang, H., Fung, C., Uczekaj, S., et al. (2005). Service level management using qos monitoring, diagnostics, and adaptation for networked enterprise systems. In ninth IEEE international EDOC enterprise computing (pp. 239–247). Los Alamitos, CA:

IEEE.

Warmer, J., Bast, W., & Kleppe, A. (2003). The object constraint language: Getting your models ready for MDA. Reading, MA: Addison-Wesley.

Warmer, J., Bast, W., Pinkley, D., Herrera, M., & Kleppe, A.

(2003). MDA explained: The model driven architecture: prac- tice and promise. Reading, MA: Addison-Wesley.

Yang, C., Bryant, B. R., Burt, C. C., Raje, R. R., Olson, A. M.,

& Auguston, M. (2003). Formal methods for quality of service analysis in component-based distributed computing. In 7th world conference on integrated design and process tech- nology. Grandview, TX: Society for Design and Process Science (SDPS).

Iman Poernomo works at King’s College London, where he heads the Predictable Assembly Laboratory research group. His interests range over dependent type theory, algebraic specification, enterprise software development and model driven architecture. Together with John Crossley and Martin Wirsing, he is co-author of the book “Adapting Proofs-as-Program”. Prior to joining King’s, he was Senior Research Scientist at the Distrib- uted Systems Technology Centre (DSTC) and an IT Research Fellow at Monash University, where he also completed his PhD.

Kenneth Chan is a PhD student at King’s College London under the supervision of Iman Poernomo at the Predictable Assembly Laboratory. His PhD research focuses on using model driven architecture to support the automated development of instrumentation for quality of service management. He completed a BSc in Computer Science at King’s College London in 2005.