Previous section.

Universal Measurement Architecture Guide
Copyright © 1997 The Open Group

Relationship of UMA to Other Technologies

This Chapter briefly consider the relationships that the UMA architecture and functionality have with other system management or measurement technologies in open system environments.

Relationship to Frameworks

In the context of distributed systems management frameworks, the UMA measurement model fits naturally into CORBA-based1 environments. The Measurement Application Programs are clients using the services provided by the Data Services Layer and this gives a number of administrative and functional benefits provided by these frameworks. These include:


UMA-CORBA Relationship illustrates a possible mapping of the UMA onto CORBA.

Figure: UMA-CORBA Relationship

SNMP and UMA

The Simple Network Management Protocol (SNMP) is based on an architectural model that consists of a number of network management stations and network elements. The management stations execute management applications which monitor and control the network elements. The network elements are devices such as hosts, gateways, terminal servers, which have management agents responsible for performing the network management functions requested by the network management stations. The SNMP protocol is used to communicate management information between the network management station and the agents in the network elements.

The Management Information Base (or MIB) is a virtual data store through which managed objects are accessed. Objects in the MIB are defined using Abstract Syntax Notation One (ASN.1) (which is how data objects are defined in the UMA DCI name space). Object types include integers, IP addresses and counters (non-negative integers).

Although the MIB has included some host level information, most of it is not of the fine granularity required for system performance management. The MIB focus has been primarily on network information, whereas the UMA Data Pool has focused extensively on the host with some network data included. In this sense, the MIB and the UMA Data Pool are mostly complementary.

SNMP as a protocol implies that the management station and the agent in a network element communicate via the network, thus data collection implies network load. In UMA, this is not necessarily true; one can have a local DCI or MLI consumer on a host that collects, analyzes and acts on data collected for that host, with no resulting network load. Furthermore, where data is to be exported from a host, UMA intrinsically provides mechanisms for data selection and threshold filtering, thus reducing network traffic to only the most essential.

Architecturally, UMA and SNMP can complement each other in the following two ways:

It is expected that a number of organisations will investigate and prototype implementations based on either or both of these approaches to the SNMP/UMA relationship.

DMI and UMA

The Desktop Management Interface (DMI) specification from the Desktop Management Task Force (DMTF) describes a general API for obtaining management information from system components. As a single system interface, it cannot really be compared with UMA which through its MLI and Data Services Layer gathers data from distributed nodes and archives it in a location-transparent fashion. Furthermore, DMI has no provision for maintenance of or access to historical data.

On cursory examination, the DMI may appear to have similar function to the DCI component of UMA. Both have the goal of providing component instrumentation to management applications. Both are single system interfaces. Both provide for polled data acquisition as well as component events.

However, there are substantial differences. These arise from the DCI having been designed specifically for performance management. This has resulted in a richer name space and navigation mechanism (consider, for example, the unrestricted name space depth and the wildcarding capability supported by the DCI); the ability to obtain large amounts of data spanning different system components with relatively small queries and to do so at a high rate - the DMI instead mandates the formulation of requests into small units making the requesting of large amounts of data require the issuing of many requests. Furthermore, the UMA interfaces and name space can support the notion of trace by use of high-speed events, for which substantial volumes of data can be directed to a file at a very high rate.

As for events (sometimes called indications in the DMI specification), the DMI requires that each management application that may wish to be notified of even just a single event receive all events, which requires management applications to filter for those events they wish to examine. In server environments, there will be many events occurring (say, for example, process terminations) and it would be most inefficient to notify all management applications of each and every one. The UMA interfaces allow consumers to specify event sensitivity so that the DCI and the Data Services Layer will selectively notify their consumers of only those events that were selected.

Considering next the DMI MIF file that describes a component's manageable characteristics, this file must be loaded (or reloaded) in its entirety into the MIF database each time there is a change to the availability of a characteristic. This approach to registration is far more suited to relatively static data such as represented by system configuration and availability information than it is to rapidly changing metric availability. Performance management requires (and the DCI provides) more dynamic registration right down to the metric and instance levels as might, for instance, be represented by the appearance and termination of a process thread.

It is therefore expected that systems will support both DMI and UMA. UMA (through the DCI) will provide access to the typically very dynamic and high volume performance data, while DMI will make configuration and vital product data available (for example). Where appropriate, DCI providers could make use of the DMI to obtain the configuration information required to support the UMA Data Pool. This would ensure a single source for this type of data.


Footnotes

1.
Common Object Request Broker Architecture, an approach for supporting distributed object-oriented applications, formulated by the OMG.


Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy of this publication.

Contents Next section Index