Revision as of 15:21, 23 June 2008

Back to Data Reporting Design

Change History

Workload Estimation

'* - 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. Client applications can look at the meta data to determine the available visualizations. Consider the following pseudo schema.

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

Example Visualization Meta Data

The following example shows meta data that represents two visualization for a data manager that collects log events. The first entry represents a top 10 report. The second entry represents a report consisting of a table that lists the event. The user can submit a filter or sort criteria for the second report. Note that both visualizations produces HTML outputs as indicated by the outputFormat tag (i.e. text/html).

    <visualizationMetadata>
        <visualization>
            <visualizationDescription>            
                <displayName>Top 10 Log Report</displayName>
                <description>A report that shows the top 10 sub components with the most logging events</description>
            </visualizationDescription>
            <inputParameters/>
            <outputFormat xs:anyAttribute >
                <format>text/html</format>                
            </outputFormat>
            <visualizationId>
                <mdrId>org.eclipse.cosmos.samples.cdmbf.LoggingDM</mdrId>
                <localId>1</localId>
            </visualizationId>
        </visualization>
        <visualization>
            <visualizationDescription>            
                <displayName>Event Log Report</displayName>
                <description>A report that shows logging events in a table.  The end user can sort and filter the table by serverity</description>
            </visualizationDescription>
            <inputParameters>
               <input name="sort" type="String"/>
               <input name="filterCriteria" type="String" xs:anyAttribute/>
            </inputParameters>
            <outputFormat xs:anyAttribute >
                <format>text/html</format>                
            </outputFormat>
            <visualizaitonId>
                <mdrId>org.eclipse.cosmos.samples.cdmbf.LoggingDM</mdrId>
                <localId>2</localId>
            </visualizationId>
        </visualization>
    </visualizationMetadata>

Visualization Request

The second part of the service provides the ability to render the visualization. Client applications would construct a visualization document that contains the input parameter and the visualization id.

Visualization Request Document

The following is the pseudo schema of the visualization request.

    <visualize>
         <inputParameters>
            <input name="xs:string" xs:anyAttribute>
                xs:any*
            </input>?
         </inputParameters>
         <visualizaitonId>
             <mdrId>xs:anyURI</mdrId>
             <localId>xs:anyURI</localId>
         </visualizationId>
    </visualize>

Visualization Request Document Example

The following is a request used to visualize an event report based on some input parameters.

    <visualize>
         <inputParameters>
            <input name="sort">severity</input>
            <input name="filter">severity>20</input>
         </inputParameters>
         <visualizaitonId>
             <mdrId>org.eclipse.cosmos.samples.cdmbf.LoggingDM</mdrId>
             <localId>2</localId>
         </visualizationId>
    </visualize>

Future Direction

The above design allows for the possibility of data managers to publish their own web 2.0 mashups. It may be possible to provide a unified web console that can integrate web 2.0 mashups from different MDRs. If the web2.0 mashups were based on widget standards it would make the integration easier.

The design could support a new output format such as "application/iwidget". Note that iwidget signifies the widget standard.

Similarly we may define an output format such as "application/dojo" that signifies an application based on the dojo toolkit. Note there may be design implications such as cross domain loading.

Open Issues/Questions

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