Interaction Infrastructure (II)

John L. Moreland / SDSC
Last updated: Thu Apr 9 19:12:50 PDT 1998


Abstract

The Interaction Infrastructure (II) is a software infrastructure intended to alleviate one frustrating but consistent problem in the realm of the computational science and visualization process: complexity. The traditional process necessary to perform even the most simple computational science and visualization task is problematic at best. Too many steps are performed manually. Scientists must learn how to use different operating systems to run even a relatively small number of application packages. Scientists must constantly (and manually) battle data management issues including data storage, transport, and format conversion. The II intends to address these nagging issues by creating an application development framework which enables the integration and interoperability of network-enabled software components.

Disclaimer
The intent of the II is NOT to reinvent software which provides low-level distributed computing facilities. Instead it will leverage and apply existing technologies, wherever possible, to fulfill those needs. Specifically, the II will focus on development efforts in the domain of scientific data visualization and user interaction technologies which address the stated problem.


Table Of Contents

I. Introduction
What is the Interaction Infrastructure ?
Goals of the II
II Model
Distributed Services Introduction
Application Framework Introduction
Brokering Distributed Services
How To Enable The II
Leverage
Frameworks
II. Distributed Services Framework
Distributed Services
Distributed Service Integration Technology (DSIT)
DSIT Requirements
DSIT Justification
DSIT Functionality
DSIT Solutions
Service Classification
Service Classes
Core Services
Security Service
Resource Broker Service
Execution Service
System Services
Data Service
Collaboration Service
Application Services
III. Application Framework
Module Classification
Code Reusability & Portability
Java Beans Framework Example
AVS Framework Example
IV. APPENDICES
APPENDIX A: Sample Applications
Simple Sample Application
Trader Sample Application

Introduction

I. Introduction

What is the Interaction Infrastructure ?

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

Goals of the II

The primary goals of the II are to:

  1. Enable scientific software packages to leverage distributed services

    1. Enable network access to distributed services

    2. Enable scientific software packages to, in part or in whole, become distributed services

  2. Enable scientific software packages to leverage interoperable user interface modules within application frameworks

    1. Enable the design of user interface modules which provide access to distributed services

    2. Enable the integration of existing visualization, computational, and user interface modules (ie: modules that reside locally and run locally in an non-distributed fassion)

      NOTE: The idea here is not to produce modules which re-implement existing application framework functionality (eg: AVS or Java Beans). Rather, the idea is, "when necessary", to implement modules which perform some "vital and unique" functionality that does not work well as a distributed component but is still "generally useful in a broad range of applications". They are meant to simply leverage and enhance or even extend those environments.

II Model

It is the relationship between distributed services and application framework modules which serves to acheive the goals of the II model. The primary vision of the II model is to "couple" a platform-independent distributed service integration technology with modular application development environments. By "couple" two notions apply:

  1. Produce a set of "environment neutral APIs" which enable network ACCESS to distributed services.

  2. Produce data-interface standards which enable client-side user-interface modules (which may provide access distributed services) to INTEROPERATE.

If the goals of the II model are realized, it is expected to produce two coupled software infrastructures which greatly simplify the task of producing distributed applications from interoperable software components.

Since distributed services and application frameworks form the basis of the II model those concepts will be introduced in general terms now, but later (see Distributed Services Framework and Application Framework sections) the specific implementation technologies will be discussed in detail.

The following figure shows the basic components of the II model discussed so far. The details show in this figure (resource broker, network services, etc) are described in detail in subsequent sections.

How To Enable The II

There are two critical notions to enable the successful design and development of the II:

Distributed Services Framework

II. Distributed Services Framework

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 host space) of the application itself.

Why would an application want or need to depend upon a distributed service? Because a distributed service:

The following figure shows a representation of an application (at the top), and classes (see Service Classification) of distributed services the application might access (at the bottom). This application uses a resource broker service in order to discover the specific network services it requires.

In order to provide access to distributed services in such a consistant manner using one simple API (as implied by the figure above), a single network service software layer or integration technology is needed.

Distributed Service Integration Technology (DSIT)

It is envisioned that there will be many disparate network resources that should be offered as distributed services to scientific applications. Furthermore, those distributed services will run accross a highly heterogeneous collection of computer architectures. To simplify the application developer's job of making use of numerous disparate services (including ones that have not yet been envisioned), and to meet the stated goals for the II, it is necessary to either choose or develop a DSIT.

The comply with the II model, a DSIT must meet the following requirements:

A DSIT environment should provide a basic foundation of functionality:

Based upon the DSIT requirements and functionality constraints, a technology must be either designed and built or commercially obtained.

In addition to fulfulling the DSIT requirements and functionality constraints, CORBA has numerous additional benefits which further justify its selection as the DSIT.

Service Classification

There are numerous distributed services and network resources which one could envision building. As one goes through the process of building such a list, it quickly becomes clear that various services fall into three natural categories. First, there is a basic set of core services which all distributed applications must use. Core services provide very general services to which all applications require access in order to "play" within the common distributed computing infrastructure. Second, are system services which are not application-specific, but ones which any distributed application could use to add or improve functionality. Third, are application services which have singular use for one class of application.

Why bother to classify services in this manner?

Looking back at the examples refered to in the Distributed Services introduction paragraph and in the figure from that section, lets see how those services fall into the 3 classifications:

A volume renderer service might be a good candidate to migrate from an application service to a system service since volume rendering can be used by numerous different types of applications (from general data 3D visualization applications to 3D data aquisition device control applications)

Service Classes


Application Framework

III. Application Framework


IV. APPENDICES

APPENDIX A: Sample Applications