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.
COSMOS Design 214158
Back to Data Reporting Design
Contents
Change History
| Name: | Date: | Revised Sections: |
|---|---|---|
| Sheldon Lee-Loy | 01/08/2008 |
|
Workload Estimation
| Process | Sizing | Names of people doing the work |
|---|---|---|
| Design | 1 | Sheldon Lee-Loy |
| Code | 2 | |
| Test | 1 | |
| Documentation | 1 | |
| Build and infrastructure | .5 | |
| Code review, etc.* | 5.5 | |
| TOTAL | 15 |
'* - includes other committer work (e.g. check-in, contribution tracking)
Requirement
A programming strategy is needed to associate a customized view with a particular graph response. A graph response is a generic structure that represents data from a data manager. Customized data is wrapped inside a graph response that an application may want to provide customized view to visualize the data. Deployers of the COSMOS UI may want to customize how the entire graph response is visualized or a specific fragment.
Design
There are two types of customization that is possible:
- application driven
- data driven customization
Application-Driven Customization
Tradionally, the application developer determines the view that will render the data. For example, if a cmdbf query is constructured to return statistical data for a particular web server the application developer may decide to render the statistical data as a line chart. In other cases, the application developer may want to render the data as a table depending on the application context.
In this case, a registry service is need to associate a view with a graph query instead of the graph response. Note that the view expects a certain graph response format that is dictated by the graph query.
The above mechanism requires a datafeed that accepts a graph query id and returns a graph response that tags the response with the graph query id. The graph query id will be used to lookup the registered view assoicated with the graph query.
Application-Driven Customization is already provided by the COSMOS UI framework
Data-Driven Customization
Consider we have a library of widgets that are able to visualize certain asset information. These widgets expect a specific data model. For example, I may have a table widget that show a list of applications installed on a particular machine. This table widget expects a specific JSON data structure to visualize the list of application. Now consider a MDR that contains that application and machine information. A query would be sent to this MDR to get that specific information and a CMDBf graph response would be returned. The graph response would embed the information in a <record> element. At this point when the graph response is recieved by the client. The client can not render the graph response as a table since it does not understand the graph response structure.
An additional step is needed to normalize the graph response to the JSON data structure that the table expects. This normalized model is the contract between the widget layer and the XML graph reponse. As a result a well-known model structure should be defined for each data element that requires a visualization. For example, a well-known model structure for a machine, and application should be defined.
Who will define these well-known model? What standard body will own these models? COSMOS? Who will promote these models.
Design Conclusion
This enhancement is not trivial. This enhancement entails creating a library of widgets that are specific to a particular domain (ie. asset configuration, statistical, loggging, etc). Furthermore this enhancement depends a set of well known data models that represent elements in each domain.
There is an open issue to determine which domain are we going to target to provide a library of widgets.