The UVA defines three software standards targeted to address
issues specific to supporting data visualization. The three software
standards necessary to define the UVA are based upon the designs
of the Interaction Infrastructure (II)
and the Data Arbitration System (DAS).
The three software standards are:
By way of an example application, one can envision a set of modules
necessary to produce a simple distributed image viewer application:
Looking at each module for this sample application one can further
envision a list of corresponding data types that each module may
require as input or output. These data types can then be passed
between modules:
One could choose to break each high-level data type down into individual
fields (each with its own low-level base data type) and allow module
connections and data flow beteween modules to occur at that finer
level of data type granularity:
However, as will be discussed in the
Data Validation section of this document, to allow low-level
base data types to flow between modules would mean loosing the
semantec meaning of the data. This would lead to unacceptable
data validation problems.
NOTE: It is outside the scope of this document to enumerate all
possible visualization-specific data types. The data types discussed
here are meant simply to illustrate the need for a strict data model.
It is not good enough to validate base data types. This point is best
illustrated by examining a hypothetical question about our sample
application:
The answer is "NO". Although the base data types match
(both fields are Character Arrays), it does not make semantec
sense to intermingle these two field values.
Beyond validating interoperability of values based upon the semantec
meaning of the low-level base data types, there are also data consistency
issues to consider.
A value range is an example of a data consistency issue. For example,
it would not make sense to assign a negative value to a ConnObj.Port
field because it is not consistent with the expected value range of
a socket connection's port value.
Clearly, it is necessary to impose a consistant high-level data model
on the UVA in order to avoid data validation problems for data
manipulated within or passed between modules.
By again looking at our example application:
It may already be clear that ALL of the modules used in the image viewer
application could be considered core modules:
An example visualization application which illustrates this point is a
volume renderer application:
The key feature to note about this application is that it contains all
of the same modules used in the simple distributed image viewer
application but adds volume renderer interface modules.
Introduction
Description
The Uniform Visualization Architecture (UVA) is a set of software
standards which enable the construction of interoperable modules
for the purpose of visualizing disparate data sets accross a network
of heterogeneous computer systems.
Goals
The goals of the UVA are to:
Data Model
Data Types
In order to enable the development of interoperable modules, one must
first determine the basic data types that need to be manipulated within
and transfered between modules. In particular, it is necessary to produce
such a data standard for visualization-specific application modules.
NOTE: Distributed data storage is provided by the
Storage Resource Broker
(SRB) service.
Authentication
AuthObj
AuthObj
Connection
ConnObj
ConnObj
File Browser
AuthObj
URL
ConnObj
Image Viewer
URL
AuthObj
UserName
Character Array
Password
Character Array
Certificate
Byte Array
ConnObj
Host
Character Array
Port
Integer
URL
URL
Character Array
Image
Image
VFB
Data Validation
When it comes time to bind one module to another (at compile time)
or to transfer data from one module to another (at run time) one needs
to depend upon the strict definition of a consistant high-level data
model. Without such a high-level data model, one would not have enough
information to be able to validate any data values or validate the
semantec meaning of any data type.
Would it be valid to use a UserName field value from an AuthObj
object in place of a Host field value of a ConnObj object?
(ie: make the assignment ConnObj.Host = AuthObj.UserName)
Modules
Core Modules
Imagine building a set of modules which enable the construction of
a variety of different kinds of applications. It is natural to assume
that some subset of those modules would be basic, commonly used,
non-application-specific, and that they would be useful in the
construction of numerous and diverse applications. Call those core
modules.
Authentication
Could be used by any application which requires access to
resources that are restricted to a specific authenticated user.
Connection
Could be used by any application which must establish a
network connection to a specific host and port.
File Browser
Could be used by any application which needs to have access
to a large distributed data repository.
Image Viewer
Could be used by any application which needs to display
(static or rendered) raster image data.
Application Modules
The power in carefully designing a set of core modules is
in the leverage they provide by enabling the efficient production of
new application-specific modules which interoperate with the core modules.
This in turn enables quicker and easier design and construction of new
applications.
Demos
SrbTool
A proof-of-concept application has been built based upon the technologies
and standards discussed in this (and referenced) documents. This tool
makes use of the Authentication, Connection, and File Browser modules.
It adds a "Copy" control to enable the tool to perform data replication
operations:
DAS
A series of example applications have been built based upon the
technologies and standards discussed in this (and referenced) documents.
These examples are meant to verify the data model for several
visualization control modules: