Interaction Technologies

White Paper

Abstract

SDSC's Interaction Technologies (IT) group is committed to designing and developing an Interaction Infrastructure (II). This infrastructure is meant to address deficiencies in the user's computational and visualization processes by linking the highest performance computers, data servers, and visualization systems over the network to enable easier use of the aggregate computing power. The goal is to create a software framework (which includes a collection of new network services) which will simplify access to and interoperation of these resources over the network.

The Problem

Traditional computational science and visualization involves the use of numerous hardware and software resources. Unfortunately, the process a user must endure to make use of these resources is often repetative, tedious, and inefficient. Among the most notable problems in a user's interaction with computational and visualization resources are:

Too many steps are done manually
Big applications must often run on specific hardware
Even "small" applications often run out of data storage space
Data must be manually transported from place to place
Data is often in the wrong format
Collaboration between colleagues at remote sites is problematic
Researchers often have limited budgets to buy local resources

The II is intended to address these problems within the context of interaction and visualization.

Requirements Analysis

In order to address the deficiencies in the computational science process, NPACI is committed to "developing a software infrastructure to link the highest performance computers, data servers, and archival storage systems to enable easier use of the aggregate computing power."

In order for a software infrastructure to address the stated problems, it must meet the following requirements:

Automate resource management and simplify their interoperation
Make running on a specific machine transparent to the user
Simplify access to large data storage repositories
Provide infrastructure for network service interaction
Provide data manipulation / conversion services
Provide collaboration services
Provide remote access to hardware services and resources (eg: HPC, LOM, etc.)

Development Strategy

In order to meet these requirements, there are numerous software development strategies one could undertake. Figure 1 shows several different development strategies. Some of the strategies attempt to extend existing applications without building a reusable infrastructure. Several attempt to develop all new technologies but also fail to build a reusable infrastructure. Others provide a means to both leverage existing technologies and integrate new technologies.

Figure 1

The stand-alone software development approaches simply do not achieve the goals of the software infrastructure. The third development strategy is intractable because it is not scalable. This leads the IT group to believe that the only viable strategy to develop a software infrastructure is the scalable strategy.

The scalable software infrastructure strategy represents a "bus-like" distributed computing architecture. That is, software components "plug into" a common integration framework to enable all software components to interoperate as equal partners - some components may both provide and use services, some may strictly provide services, and some may only use services.

Technology Resources

SDSC's IT group is designing an interaction infrastructure. In order to achieve this infrastructure, the IT group is leveraging a number of technology resources shown in Figure 2:

Figure 2

The labels inside the figure represent technology categories. The labels outside the figure represent specific development projects and human resources allocated to address the development of those technologies.

Some of the technologies that will be integrated into the infrastructure are being developed outside of the IT group (those shown in blue in the figure). Many of the technologies that may be integrated into this infrastructure will come from separately funded research projects within the IT group (those shown in green in the figure). Finally, the remainder of the development effort entails the design and production of the integration technologies themselves (shown in white in the figure). ALL of the technologies and resources in the figure collectively make up the II.

Interaction Infrastructure (II)

The II consists of two software frameworks for enabling, respectively, network access to and consistent interfaces for distributed services.

Distributed Services are network-accessible resources (such as data repositories), computational engines (such as volume renderers), and other services which can be accessed and possibly controlled (or even "steered") via a network connection (such as a collaboration service, or a remote data aquisition device). A distributed service can simply be thought of as just another software component required to construct an application, but it is a component which happens to execute outside of the process space (or even outside of the host space) of the application itself.

The primary goals of the II are to produce a set of "environment neutral APIs" which enable network ACCESS to distributed services, and, to produce data-interface standards which enable distributed services and applications to INTEROPERATE. The intent is not only to enable applications to use II services but to enable the integration of new or existing technologies to extend the II.

The development efforts of the IT group will focus on visualization software technologies. However, collaborations outside of the IT group will be undertaken in order to provide the remainder of the necessary technology resource components of the II (ie: the blue regions of Figure 2)

See the Interaction Infrastructure document for details.

Technology Migration Strategy

The IT group does not have sufficient funds from either SDSC or NPACI to develop from scratch all of the technologies necessary to create the II. Fortunately, it is niether the goal of NPACI nor the goal of SDSC's IT group to do so. Instead, the IT group has a technology migration strategy that will enable the delivery of the necessary software systems through a process of:

Development
Generalization
Integration

Figure 3 illustrates the IT group's technology migration strategy:

Figure 3

The bulk of the technology development efforts stem from leveraging externally funded projects (the green segments in Figure 2) and intra-thrust collaboration projects (the blue segments in Figure 2).

The migration process entails, first, the generalization of these II technologies. That is, minor shaping of the base technologies into a form that best suits the needs of the II infrastructure. Second, the generalized software components are then verified through the process of integration with a set of assay archetypal applications. These are applications chosen by the IT group in order to provide "best match" test cases for both verifying the technologies, and, for providing "thrust area" application certification test cases. It is this migration (generalization and integration) process which makes up the bulk of work represented by the white segment in Figure 2.

Finally, some basic infrastructure development must also occur. The integration technologies themselves (also represented by the white segment in Figure 2) must be supported because it is this infrastructure development work which forms the basis of interoperability for the services and application components.

Assay Archetypal Applications

Once sufficient infrastructure is designed and built, verification of the technologies is necessary within the context of "real" scientific applications. It is this last step of the technology migration process (discussed in the previous section) which affirms the development process. In other words, did the technologies solve the problems we set out to solve?

Several "real" scientific applications have been chosen by the IT group in order to provide "best match" test cases for both verifying the technologies, and, for providing a certification test within thrust area applications.

Table 1 contains information about each of these applications:

Thrust	Application	People	Funding
Earth Systems Science	Bayview	John Helly Todd Elvins Don Sutton	SDBIWQP US Navy
Neuroscience	Telemicroscopy	Mark Ellisman Doug Greer Steve Young	UCSD
Molecular Science	MICE	Phil Bourne John Moreland Greg Johnson	NSF
Engineering	Telemanufacturing	Mike Bailey Drew Clark	NSF

Table 1

IT Deliverables

Distributed Services Integration Technology (DSIT) library [IE]

Simple Resource Broker [DI,IT,IE]

Virtual File System (VFS) [DI,IE]

Simple Collaboration Service [IT,IE]

Visualization Data Model [IT,IE]

Visualization Data Manipulation Services [IT,IE]

Remote Video Service [IT,IE]

Volume Rendering Service [IT,IE]

Telemanufacturing Hardcopy service [IT,IE]