Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

COSMOS Design 204921

Broker for COSMOS DC framework

This design document addresses COSMOS Bugzilla enhancement request 204921.

Change History:

Name: Date: Revised Sections:

Jimmy Mohsin 10/16/2007 Initial version; created from i6 ER 197867

Bill Muldoon 10/16/2007 Added Broker/CMDBf use cases

Overview

The Broker is the component in the COSMOS data collection framework that holds a registry of Data Managers (i.e. Management Data Repositories (MDRs)). The registry stores the addresses of the Data Managers in the form of end point references, indexed according to the data classification and the data source types of the data. Each Data Manager 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 perform queries according to the classifications and data source types available in the registry. The result of the queries is the endpoint references of the the Data Managers which match the classifications and/or data source types of the query selection.

The “Broker” component is a logically centralized component in the COSMOS data collection framework. In future iterations, 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 future case where there may be multiple Brokers, there is a higher level lookup registry (the Management Domain) to find the address of the Brokers. The Management Domain can be considered a "Broker of Brokers".

Implementation Stages and Corporate Use Cases

The Data Broker will evolve over time to accommodate the needs of the corporate use cases as follows:

Version 1 (i6) will satisfy the initial CA use cases.

Version 2 (i7) will support the data source types requirements of the IBM use cases.

Version 3 (i8) will support the CMDBf use cases from CA and IBM.

Note that Compuware has no use cases which require the Broker at this time.

Terminologies/Acronyms

The terminologies/acronyms below are commonly used throughout this document. The list below defines each term:

Term Definition

 Data Broker		This is the component where all the web services that share data register themselves
 Data Store		This is a physical software artifact that stores data, e.g. Oracle, a File System, etc
 Data Manager		Largely corporate implementation component that implements the SOA API for data exchange. A Data Manager can be an MDR.
 Service Broker		This is the component where all the web services that share functional behavior register themselves
 Management Domain    	A "Broker of Brokers"

Broker/CMDBf Use Cases

1. CMDBf initialization

a. CMDBf queries the MD to locate the Broker

b. CMDBf registers itself with the Broker using the classification value of "CMDBf"

c. CMDBf waits for clients (or MDRs)


2. MDR initialization with Broker

a. MDR queries the MD to locate the Broker

b. MDR registers itself with the Broker using the classification value of "MDR" and dialect (ie: "SML")


3. MDR initialization with CMDBf

a. MDR queries the Broker to locate the CMDBf (using classification of "CMDBf")

b. MDR registers itself with the CMDBf

c. MDR waits for clients (or CMDBfs)


4. Client application initialization

a. Client queries the MD to locate the Broker

b. Client queries the Broker to locate the CMDBf (using classification of "CMDBf") or MDR (using classification of "MDR")

c. Client queries the CMDBf or MDR


Note: need a diagram, WS-RC, and life cycle


See also:


Back to the top