|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 II is intended to address these problems within the context of interaction and visualization.
In order for a software infrastructure to address the stated problems, it must meet the following requirements:
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.
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.
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.
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.
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:
|Earth Systems Science||Bayview||John Helly|
|Molecular Science||MICE||Phil Bourne|