Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: for the plan.

Jump to: navigation, search

COSMOS Design 214153

Back to Data Reporting Design

Change History

Name: Date: Revised Sections:
Sheldon Lee-Loy 01/08/2008
  • Initial version

Workload Estimation

Rough workload estimate in person weeks
Process Sizing Names of people doing the work
Design 0.2 Sheldon Lee-Loy
Code 2
Test 0.5
Documentation 0.5
Build and infrastructure 0.3
Code review, etc.*

'* - includes other committer work (e.g. check-in, contribution tracking)


The COSMOS UI should provide the ability to create custom query user interfaces. These interfaces can be in the form of a dialog box or wizard. A strategy is needed to determine how exploiters can contribute their own customized query user interfaces to the COSMOS ui. Note that these query user interfaces can be initiated by selecting a menu item, selecting a node, etc. There are two parts of this customization:

  1. Exploiters will create dojo widgets in the form of dialog boxes or wizards that are binded using query objects. This customization is currently supported in the COSMOS UI framework.
  2. Exploiters will create CMDBf queries that will be submitted to an MDR. This is the focus of this ER. A mechanism is need to persist and deploy CMDBf queries within the COSMOS UI framework.


Query Templates

It should also be possible to create "CMDBf query templates" that uses some form of macro language to define input parameters for the query. For example, consider the following CDMBf query:

<registerResponse xmlns="">

Note that the above CDMBf query has a hard coded localId set to "http://mycomputer". If we use some form of macro language we can create a more dynamic query as follows:

<registerResponse xmlns="">

The above query defines a $localId input parameter that a user interface can bind to.

The value of the $localId parameter can be provided by the user interface via a data feed. The following url can be used to execute the data feed:


Note that the templateId variable signifies the query template file that is defined above.

CMDBf Query Service

A service is required that will execute the following steps:

  1. Read in the input parameters from a request
  2. Process the query template file
  3. Submit the query template file to the mdr
  4. Generate a JSON structure based on the cmdbf graph response received.

As stated in the previous section a request will be received by this service. The request will contain the following parameters.

  • templateId - an id that identifies the template file to process
  • MDR - the epr to the MDR
  • <input parameters> - parameters used to construct the query
  • formatter - id that identifies the component that will be used to format the XML graph structure to JSON

The following shows the various components to the query service and highlights configuration components.


There are three components that can be contributed by exploiters.

  1. Template Processor - There are numerous macro language processors on the market. This design allows one to interchange different template language processors such as apache "Velocity" COSMOS will provide a simple template engine that will provide simple parameter substitution.
  2. CMDBf Query Files - these files are CMDBf files that are deployed on the file system. The deployment model is explained in ER 214143.
  3. Fomatters - exploiters can also provide different formatters that will format the XML graph response. For example, one can define a formatter that will produce a JSON structure for a tree, while another formatter can be used to format a table.

Open Issues/Questions

All reviewer feedback should go in the Talk page for 214153.

Copyright © Eclipse Foundation, Inc. All Rights Reserved.