COSMOS Design 237655

Back to Data Reporting Design

Change History

Name:	Date:	Revised Sections:
Sheldon Lee-Loy	06/23/2008	Initial version

Workload Estimation

Rough workload estimate in person weeks

Process	Sizing	Names of people doing the work
Design	0.4	Sheldon Lee-Loy
Code	1.4
Test	0.5
Documentation	0.5
Build and infrastructure	0.2
Code review, etc.*
TOTAL	3

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

Requirement

A visualization service group can be associated with a data manager via Axis2. The service group will provide a management and a generate service. Assuming an agreeable exchange format, the client will be oblivious in terms of how the visualization are managed and generated.

The management visualization service will allow the client to determine available visualizations on a data manager. Once a visualization is selected, the service will indicate if any user input is required for the generation of the visualization.

Let us try to understand the value of providing a visualization service on a MDR by considering the current component architecture of COSMOS.

There are several key points that should be understood with the current architecture.

• The COSMOS UI utilizes the broker as a simple lookup service. The COSMOS UI initially gets all the data manager meta information such as a name and a list of services that the data manager provides.
• The COSMOS UI must make sense of the meta information to determine if certain icons should be associated with a particular data manager. Similarly the COSMOS UI must determine whether certain menu options are valid for a certain data manager. Finally, the COSMOS UI must determine if a particular report should be use to render data for a particular data manager. The COSMOS UI makes use of a mapping component that tells the COSMOS UI that a data manager is a statistical data manager, a logging data manager, or a asset data manager.
• If new data managers are present the logic of mapping component would have to change in order for the COSMOS UI to make sense of the data.
• If the meta data information of the data manager changes the mapping component would be broken and would have to be modified based on the meta data information changes.

Design

As seen from the requirement section the COSMOS UI is not very scalable as new data managers are registered or existing data managers are modified.

The main reason for this limitation is due to the fact that the visualization is loosely coupled from the data. This design proposes a tighter integration between the visualization and the data.

Consider the following architecture.

This design introduces a visualization service that is associated with a data manager. This design provides the following benefits.

• Visualizations of the data are readily made available to any client that makes requests to the data manager
• The rendering of the data can work with custom apis since the rendering service can be tightly coupled with the collected data.
• The COSMOS UI does not need mapping logic to associate a visualization to a particular data manager

The visualization service provides two main functions.

1. List the available visualization meta data
2. Render a specific visualization

Visualization meta data

The Visualization meta data describes a list of visualizations for a data manager.

    <visualizationMetadata>
        <visualization>
            <visualizationDescription>            
                <displayName>xs:string</displayName>
                <description>xs:string</description>
                xs:any*
            </visualizationDescription>
            <inputParameters>
               <input name="xs:string" type="xs:string" xs:anyAttribute/>?
            </inputParameers>
            <outputFormat xs:anyAttribute >
                xs:string
            </outputFormat>
            <visualizaitonId>xs:anyURI</visualizationId>
        </visualization> *
    </visualizationMetadata>

willThe http request received by the servlet will contain two pieces of information:

• meta data search parameters
• report parameters

Meta Data Search Parameters

The search parameters will be name value pairs that defines the search criteria used to select the report template. For example, the request may ask to generate a report that is associated with a namespace equal to "http://examplemdr/student". The servlet will search the report repository for the report template that matches the search criteria. Note the search parameters are logically "ANDED".

Report Parameters

This is a list of name value pairs that are required by the report template to generate the report. For more information refer to the BIRT documentation on report parameters.

Example request

The following is an example of a request. Notice that the meta search and report parameters are encoded in the request.

ReportServlet/?metasearch=namespace%2Fhttp%3F%2F%2Fexamplemdr%3Fstudent&reportparams=myparams=%2fhello

Datasource Management

The servlet will manage the datasource required by the report template. In the case where the datasource is provided by the request, the servlet will save the datasource in session. The datasource will be keyed on session id,template id and a datasource id. The combination of the session id,template id and datasource id will be used by the report template to select the datasource from session.

This mechanism may be used to provide other resources required by the report template. Resources such as image files, externalized property files, etc.

Report Template Repository

The report template repository will consist of a set of report templates and a catalog file. The catalog file will act as a lookup that will associate meta data information with a particular report. Applications can use the catalog file to search for a particular report template. The following is an example of the catalog file:

 <reports>
  <report>
	<metadata>
	<property name="type" value="CBE"/>
	<property name="namespace" value="http://logging/log"/>
        <property name="caption" value="Top 10 Log Report"/>
	</metadata>
        <template id="0" file="templates/LogReport.rptdesign"/>
  </report>
  <report>
	<metadata>
	<property name="type" value="TomcatSet"/>
	<property name="namespace" value="http://statistical/stat"/>
        <property name="caption" value="Statistical Report"/>
	</metadata>
        <template id="1" file="templates/StatReport.rptdesign"/>
  </report>
</reports>

Graph Response Report

The following shows a mockup of a basic graph response report template.

The above report groups the records by items and relationships. Notice that if a record is present a link is provided. The link will drill down to a report that can render the record schema. The report that is associated with the record namespace will be used to render the record information. Therefore, the report template will make a request to the report servlet describe above to render the appropriate report.

Open Issues/Questions

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