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:
- Enable scientific software packages to leverage distributed services
- Enable network access to distributed services
- Enable scientific software packages to, in part or in whole, become distributed services
- Enable network access to distributed services
- Enable scientific software packages to leverage interoperable user
interface modules within application frameworks
- Enable the design of user interface modules which provide access
to distributed services
- 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.
- Enable the design of user interface modules which provide access
to distributed services
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.
It does not make sense, however, to simply create N different "simple to
use" APIs with no thaught as to how the N different services might
interoperate within in an application. It makes more sense to put a bit
more thaught into the design of the set of services as a whole so that
both the job of the distributed service developer AND the job of the
end-user application developer are simplified and streamlined. One area
that is worth some thaught is the design or standardization of some common
data types. (The notion of a data model is discussed in more detail in the
Uniform Visualization Architecture
(UVA) document.)
By writting modules within a well defined application framework
the jobs of both producing and supporting application software are
greatly simplified.
One primary area of focus for II module production will initially be the
development of user interface modules which provide access to
core services.
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.
It is essential to leverage commercial environments in areas where
there would otherwise be high development and support cost but low
technological returns. It is equally essential to concentrate on
implementation details in areas where non-commercial approaches are
vital and necessary.
By taking advantage of the unique capabilities of custom
non-commercial software systems but simultaneously leveraging
commercial software systems, it will not only help maximize the use
of limited resources, but also make the goals more approachable and
as a result the task of enabling the II more manageable.
Nobody wants to reinvent the wheel - its neither fruitful nor
interesting. Nobody likes to spend time porting and supporting
numerous hardware and operating system architectures - its a waste
of precious resources. Everybody wants to do new and interesting work.
To provide a consistent cross-platform and cross-service network
interface as well as a consistent user interface experience, it
is vital to develop software systems within standardized development
frameworks.
The two distinct but related frameworks required to enable the successful
design and development of the II are:
The discussion of these two frameworks represent the bulk of the
remainder of this document.
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.
The comply with the II model, a DSIT must meet the following requirements:
A DSIT environment should provide a basic foundation of functionality:
Initialization methods for the DSIT environment should be minimal
and simple. As little setup state should be required as possible
(say a single argument list or parameter list). The DSIT environment
should be as "self bootstrapping" as possible.
Data types for arguments passed to a DSIT environment initialization
method should be "simple". Stick to base types or lists of base types
(ie: no structs).
Initialization for the DSIT environment should not (necessarily) rely
upon state data stored on local disk (eg: a preference file should
not be required, particularly one identified with a platform specific
path or file name).
The DSIT environment should enable access to remote objects
and appear as if they were local objects. Once an object
reference is obtained, operations (method invocations)
hide the fact that network communication is taking place.
The DSIT environment should at least supply simple name-to-object
registration and lookup methods. (See
Resource Broker Service for details).
The DSIT implementation should enable an application to
use the method call standard which matches that of the
application's native development language.
The DSIT implementation should allow the developer to use
native data types (both base types and stuctured data types)
as method parameters or as return values.
The DSIT implementation should transparently handle the mapping of
native data types for the application author when passed between
heterogeneous platforms. Byte ordering, word size, structure padding,
etc should all be handled.
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.
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:
System Services
Application Services
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)
Core services are services which all distributed applications need to
make use of. They provide very general services to which all
applications require access in order to "play" within the common
distributed computing infrastructure.
Here is a handful of the the most vital core services:
It is vital in a distributed computing environment to establish
and enforce a security policy in order to both protect as well
as provide access to the resources within the infrastructure.
The facilities necessary to establish "trust" in a distributed
computing environment are:
The creation and storage of identification information
(in the local Resource Broker Service)
for a user or service.
Registration is a one-time three-step setup procedure for the
purpose of:
A claim that an entity is a specific user or service.
Verification that a user or service is what it claims
to be. This process establishes "trust" between two entities.
Private Key
Certificate Authority Key
Allowing or preventing access to a service.
The term often used to describe the storage of
authorization information is ACLs (Access Control Lists).
The authorization information may minimally include simple
boolean pairings (eg: "yes/no, user X may/may-not access
service Y). But, the authorization information may describe
more detailed constrtaints (eg: "user X may read from service
Y, but not write to service Y), and so on.
NOTE: This database-like functionality can be accomplished
using either a central authorization repository, or, each service
may maintain its own independant authorization information.
Once trust between two entities has been established
(through the authentication process) "secure" bi-directional
transactions may take place by using a session key.
All user and service entities must register
with at least one resource broker services within the
distributed computing domain. Subsequently, applications may
then make lookup requests to find matching resource entries.
Entries are composed of an expandable list of key/value pairs.
Once an object reference is obtained, add, remove,
get, and set operations may be applied to specific
key/value pairs.
NOTE: The pseudo-code below is meant only to illustrate the
required Resource Broker capabilities. It is NOT intended to
define either a specific API or data model for describing
resources.
...of a user
NOTE: If a valid iors has been registered, then it
is returned by the getValue function. Otherwise,
the resource broker service will pass the resource entry
on to the local Execution Service
in order to have the requested service started up. Once
the execution service starts up the requested service
(and the requested service updates its own resource
entry) the new iors is then returned to the
application by the resource broker service.
...of a user
NOTE: Uniqueness of a user entry is determined
by the type and name key values.
Uniqueness of a service entry is determined
by the iors key value if the service is active,
and by the combination of ALL key value pairs otherwise.
If a component (ie: application or a service) requests access to
a resource (such as through a Resource Broker), but the resource
can not be obtained for imediate access, invocation of the requested
resource must then be scheduled or possibly even reserved for
future invocation. It is also possible that multiple resources
must be reserved and scheduled together (eg: staging of a large data
file and allocation of processors on a system that will read the data.)
The capabilities of an execution service should include:
NOTE: Some resources and assocated services are "always available"
while others need to be carefully scheduled. That is, services
can be viewed as fitting into two broad categories: Persistent
or Transient.
Transient Objects
Persistent Objects
* * *
System services are not application-specific, but ones which any
distributed application could use to add or improve functionality.
Application services are ones which are only useful for a single class
of application.
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:
Distributed Services Introduction
The distributed services that will be developed using the II model are
intended to provide access to unique network-based services to the
application developer. "Unique" means services which are specific
to a high-performance computing and ones which can play a
specific and vital role in advancing computational scientific research.
An example of such a service is remote access to to large data repositories
(or Data Service) via a high-level (simple to use)
API. Literally all scientific applications could make use of such a
service.
Application Framework Introduction
An application framework is a standardized software infrastructure which
enables the construction of applications from re-usable interoperable
software components, or modules.
How To Enable The II
There are two critical notions to enable the successful design and
development of the II:
Leverage
Frameworks
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.
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.
DSIT Requirements
DSIT Functionality
DSIT Solutions
Fortunately, there is an exsisting public and a commercially supported
integration technology standard which addresses all of the
DSIT requirements and functionality issues covered above.
The DSIT standard is called
CORBA.
The CORBA standard is maintained and overseen by the
Object Management Group
(OMG) with the support of over 800 companies
for the past 8 years. CORBA implementations are available for
for numerous hardware and operating system platforms, and
includes support for many programming language bindings
(including OMG approved
Java support backed by a SunSoft
JavaIDL ORB implementation.)
DSIT Justification
Service Classification
Core Services
Security (Identification, Authentication, Authorization)
Resource Broker (Registration, Lookup, Introspection ; Users, Services)
Execution (Reservation, Allocation, Execution, Accounting)
Distributed data repository
Collaboration
Volume renderer
Data aquisition device
Service Classes
In this section the three service classes
(Core Services,
System Services, and
Application Services)
are discussed. Along the way, specific examples of several key services
are outlined and examined.
Core Services
Security Service
Username
Password
Private Key
Public Key
Stored in a pubic Certificate Server
Locally stored and secured
Downloaded by user, and then
Locally stored and secured
Stores public keys
Resource Broker Service
...of a service
register(
type="service",
name="NetV",
long="SDSC Network Volume Renderer",
pubk="...",
host="scratchy.sdsc.edu",
vers="v2.1.0",
perf="100",
port="90210",
iors=obj,
ppid="123",
srvc="Volume Renderer",
idta="volume/vol,volume/vlm,volume/fld",
odta="image/rgb",
algt="splat" );
register(
type="user",
name="moreland",
long="John L. Moreland",
pubk="...",
host="postal.sdsc.edu" );
...of a service
resEnt = lookup( type=="service" && name=="NetV" );
netvObj = resEnt[0].getValue( "iors" );
user = lookup( type=="user" && name=="moreland" );
resEnt = lookup( srvc=="Volume Renderer" && idta=="vol" );
obj = resEnt[0].getValue( "iors" );
resEnt = lookup( srvc=="Volume Renderer" && max(perf) );
obj = resEnt[0].getValue( "iors" );
Execution Service
A transient object has the same lifetime as the execution of the
server process that creates it. When a server terminates, its
transient objects disappear with it and any object references held
by the client become invalid.
By contrast, a persistent object lives until it is explicitly
destroyed. If a client has a reference to a persistent object,
that reference can be used even if the object's server is not
running.
System Services
This paper is undergoing active development.
Please be patient as more content is forthcomming...
* * *
Application Services
TBD
Application Framework
III. Application Framework
Module Classification
