Skip to main content
Jump to: navigation, search

COSMOSBrokerSpecification

Revision as of 15:19, 20 August 2007 by Hkyleung.ca.ibm.com (Talk | contribs) (New page: ==Overview== The broker is the component in the COSMOS data collection framework that holds a registry of management data repositories (MDRs). The registry stores the addresses of the MDR...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Overview

The broker is the component in the COSMOS data collection framework that holds a registry of management data repositories (MDRs). The registry stores the addresses of the MDRs in the form of end point references, indexed according to the data classification and the data source type of the data. Each MDR provides the data classification and data source type information upon registration with the broker and maintains the relevant registry data over its life cycle. The broker provides interfaces for clients to make queries for the classifications and data source types available in the registry and for addresses of MDRs based on classifications and/or data source types. The interfaces are provided in the form of WSDM capabilities and Java interfaces.

The “broker” component is a logically centralized component in the COSMOS data collection framework. In practice, there can be multiple brokers, each responsible for a different group of management resources, for example, the distinction between data brokers and service brokers. However, the role and responsibilities of different kinds of brokers are the same. In the case where there are multiple brokers, there is a higher level lookup registry (the management domain) to find the address of the brokers.

Terminologies/Acronyms

Broker

Client

MDR

Broker Registry Indexes

The registry is a lookup table of the addresses of MDRs that have registered with the broker. The addresses are indexed with two pieces of information:

  1. Data Type Classification:
    • Data type classification (or simply “classification”) is a well-known identifier that represents data with a predefined structure and meaning. It is analogous to a Java class definition.
    • Examples:
      • Common Base Events (CBE): CBE is an OASIS standard of event data which has a predetermined structure.
      • Hardware asset data: The attributes of hardware asset data (such as CPU speed, machine model number, hard drive space, etc) can be defined in standards like CML.
      • The classification does not have to be a public standard. A classification can be defined for a specific system, as long as the definition is a common knowledge among all MDRs. The definition must be available globally with the COSMOS data collection system, and there is a way to introspect the data structure of the classification. For example, we can define “statistical data” as the tuple (HeapMemoryUsed, NonHeapMemoryUsed). The definition of the classification can be realized by using the SML facet concept.
  2. Data source type:
    • The data source type value specifies the type of hardware or software that generated the data.
    • The data source of CBE data can be a web server or a network router.
    • Data source type identifies the type of data source, but not the instance of the data source.

Notes:

  • Data classified by the same data type classification can originate from different data source types. (For example, CBE event data can be generated by web applications and network routers.)
  • Each MDR can provide one or more combinations of classification and data source type values to identify the data it can provide.


Broker Registry Structure

The registry can be composed of 4 database tables:

Classification(cid, name)

DataSourceType(did, name)

MDR(mid, epr, state)

Registry(cid, did, mid)


Example data

Classification
cid name
1 CBE
2 statistical data
3 SML

Back to the top