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 223270

Back to Data Reporting Design

Change History

Name: Date: Revised Sections:
Sheldon Lee-Loy 01/07/2008
  • Initial version
Martin Simmonds 05/08/2008
  • Added some Requirements

Workload Estimation

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

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

Purpose

The COSMOS UI provides a way to create queries to an MDR. However it does not provide a mechanism to manage these queries. Some of the management services are as follows:

  • Ability to persist newly created queries
  • Ability to rename queries
  • Ability to delete existing queries


Requirement

There are a number of use cases for this design.

Use Case : A Developer creates a Query

A developer wants to use the UI to develop a CMDBF query and to save it for re-use. Also the query can be shared.

In a development environment it is probable that the developer has his/her own installation of the COSMOSUI, and that they have full access and control of it.

The developer can use the query builder to build the CMDBF query, and can test it out against the MDR.

When the developer has generated the query, they want to be able to save this, so that they can recall the query and execute it again. They want to be able to give the query a name of their choice, and the ability to change that as and when required.

The developer may also wish to see the results of prior queries.

The Web browser can be terminated, started up again, and the COSMOSUI accessed again. The developer wants to see the queries that were created, and the responses that were created, without having to regenerate them.


  1. Right-Click on the query, show a menu that has the option to run/execute
  2. Left-Click on the Query, shows the cached query
  3. When an execute option is chosen, the query request and the query results should be persisted. The user should not have to make a decision as to whether to persist or not, it should just happen.
    1. Persist the files on the server machine in XML files. If the current mechanism is storing the requests and results in the dom, then the act of doing an execute will still update the dom, but will also create the XML files.
    2. If saving on the Server or Client side, where will the files go? How do you decide where? Do you decide within the UI, or outside of the UI? If you decide in the UI, how will that be implemented?
  4. We should not just save the last result set. Multiple query results should be displayed within the Query Node.
  5. The query node in the tree should have one or more optional child nodes for the query responses.
  6. To create a query node, you need to right-click on the MDR and select the Query Builder option. Then create the query in the query builder.
  7. Left-click on a query node to show the query result in the details view (Using the XML Outputter)
  8. Right-click on a query node and choose "execute" (or "delete").
  9. Left-Click on the query Result to show in the details view (Using the GraphResponseViewer)
  10. Right-Click on a query result and choose "delete" (or "register/deregister" configuration items").


Use Case : A User starts the UI, can execute saved queries, and see prior responses

Any user from any machine can access the COSMOSUI and view stored queries and responses that either, they, or a CMDBF developer (in the first use case) has created.

This use case is more geared to users having the ability to use shared queries and responses, whereas the first is geared to creating the queries.

How to implement this

  1. If we are persisting requests and results as XML files, they could be stored in <tomcat>\webapps\COSMOSUI\queries directory, which can be configured in the web.xml.
  2. Storing on the server means that you can pick the requests/queries up from anywhere.
  3. One thing to bare in mind is that, if the main reason for having this mechanism is to be able to easily create queries, store them, delete them and share them, then the developer probably has their own server running. I don't see the maintenance of the persisted files would be something that you do in production.
  4. There needs to be a mechanism that allows someone to put their xml files in a specific place that web.xml points to so that when the UI starts up, it checks that area and populates the UI nodes. In effect you could say that if this mechanism does exist, that deleting a node or deleting a request or response could be done by removing the xml file.
  5. So requests and responses as xml files are maintainable, but the structure of the nodes also needs to be persisted. So if for example you had a node called "All Students" then create a directory called "All students", and the xml files would go into that directory. Just to reiterate, you could as a first phase use the directory structure, with xml files in them, as a manual way of maintaining things, then add the menu options as a second phase.


COSMOS dm queries.jpg

--Marty 07:42, 8 May 2008 (EDT)

Design

Consider the current architecture that outlines how the client browsers interact with the COSMOS UI to show queries in the navigator. A set of predefined queries are stored in a repository. This repository is read and loaded when the client browser starts up.

D2232701.JPG

Solution 1

There are two methods to support user defined queries. Traditionally, user data is stored on the server side. However there are several services that are required to manage user data on the server side. Consider the following architecture change.

D2232702.JPG

Notice that the server now needs a mechanism to manage user data (ie. user profiles, user login services, etc.)

Solution 2

The second method does not make use of the server to store user data. Rather the client browser stores the user data using the "DOM storage" feature provide in HTML 5 spec. (Refer to http://www.w3.org/TR/html5/#storage).

Consider the following diagram.

D2232703.JPG

Dom storage is currently only available inf FireFox 2. In other cases the Google Gadget or Flash storage plugin is required in the browser.

Copyright © Eclipse Foundation, Inc. All Rights Reserved.