Documents

Overview

The COSMOS project intends to produce a reference implementation of a CMDBf Management Data Repository (MDR). The project will demonstrate how a client can use multiple MDRs through the CMDBf query interfaces and registration services to display information from multiple management systems. COSMOS will also create any additional infrastructure required to support the basic use case.

Chris to update this section with business value and function positioning relative to commercial products

Basic End to End Use Case

The image below is an overview of the most basic use case.

Requirements

These are the high level requirements necessary to complete the implementation of CMDBf. We will break these down into bugzilla enhancement requests.

(Needs to be expanded on during the call... this is just a start....)

Query

Implement the CMDBf as a Muse capability. Bind to the CMDBf API

Start on Binding to Ali's API

Map CMDBf query to convenience APIs for SML repo, Stat repo, and CBE repo (this is the data set issues)

Registration

How do we reconcile the registration of MDRs vs. the item relationship

Do we need registration in the first round? Start with a focus on Query.

Need to make sure that the IDs line up or that we have only simplistic means of aligning the different resources

This gets into a bit of the taxonomies. May need simplistic mappings.

MDRs look like Data Managers

DataBroker/ProviderRegistry as MDR

Based on a discussion of the proposed DataBroker design, it appears that what is desired is a combination of an EPR registry for locating DataManagers and a repository of existing data sets that can be processed by those DataManagers. From the use case described above, it appears that the ProviderRegistry should act as an MDR to surface its knowledge of datasets and there attached metadata. If we are going to adopt the CMDBf query dialect as our lingua franca for communicating topology/metadata type information, then it makes sense to apply the CMDBf query capability to both the topology repository and the SDMX-style dataset/keyset repository of the ProviderRegistry.

Notes

The Data Broker is intended to be a simple component.

Clarification of Registration v. Query (Push vs. Pull).

MDR Negotiation: The handshake b/t the MDR and the Broker in order to facilitate Pull

Need to outline the use case of bootstrapping the MDR with the management domain.