> What may serve the need is a distributed software environment in which
> component capabilities run as separate programs, perhaps on different
> coputer systems. The components are built using a large, shared class
> library that defines the data types used by all the components. This
> class library defines the gaming table; you have to ante up (by learning
> how to use the big class library) in order to be allowed to play.
> The components interact via the network. The operation of the components
> is controlled by another distributed component that does *not* need to be
> built from the large class library, but rather simply communicates
> instructions to the computational components. These would include
> data manipulation instructions like "Ask *that* component to send you
> its third image" as well as computational instructions like "Take the FFT
> of your second image".
This sounds very similar to what we are working on as well. What is needed
is a standard framework for which distributed applications can be built.
These distributed applications are constructed of components (processes,
threads, or linked classes) communicating via the framework. The framework
provides a messaging system, probably based on a message bus, and facilities
for shared data objects which the components can operate upon. The
application is a program written in a high level scripting language which
ties all these distributed components together.
What goes on inside the components doesn't matter so long as they fit into
the framework. Hence the language, or class libraries used to build
components can vary from component to component. This is the only reason
that such a scheme has a hope of surviving rapid technological development,
standards evolution, and the different design decisions made by various
project groups.
In this scenario a data analysis system would consist of the framework and
a set of standard components. The framework (messaging system and shared
data objects) needs to be powerful enough to develop sophisticated real-
world applications, but open enough to allow anyone to build a new component.
Finally, since the binding of components is pretty high level, it should be
possible to deal with legacy software (such as IRAF) by putting object
wrappers around science software modules to make functional components.
Since this involves a layered interface building object (component) wrappers
should be possible without greatly changing the existing software at the
class library level, especially if the existing software is well structured,
with well isolated interfaces to the external world.
Time is short before it is time to leave for the ADASS so I probably won't
have any more to say about these issues until the BOF. Anyway, I do think
there is a common thread running through our various efforts. Don't
underestimate the size of this problem however.
- Doug