Below are some ideas on the format of the MDS
component software database schema/format.
We are basing this format on the following assumptions:
NOTE: the "official" response from ANL is here. and this was their answer to our reply.
complete information on where a component is AND how to start it up should be contained in the database; (potential problem: this information will need to be updated by the client/end user if any of it changes; it would be nicer/better if the server on which the component runs could "automatically" publish any changes to the MDS)
components live in a heterogenous world, and hence platform-specific information should be included in the database
the process creation mechanism may (or may not) use the component information in order to create the component processs; however, it should be included to cover all possible implementations of process creation (e.g., GRAM)
example: "ReadMatrix" purpose: to signify a generic name for the component rationale: we will use this as a generic identifier for the component; for example, in the CAT, an end user selects a component (represented by its identifier) from a list; all identifiers should be _unique_ within this list (i.e., within the MDS database component namespace); the CAT uses a selected identifier to generate a unique component instance ID; for example, if the component name is "ReadMatrix", then when the CAT creates an instance of "ReadMatrix", it assigns it a unique name, say "ReadMatrix-1"
example: "native binary", "java bytecode", "perl script", "C++ source" purpose: a generic description of the file type of the executable; could also use MIME descriptions rationale: this information might be useful to a user if he wishes to know MIME type of a component's "executable"; presently unused in the CAT
example: "Solaris2.6", "Java1.1.3", "Perl5.001" purpose: the type of OS/environment that the component will execute in rationale: this information might be useful to a user if he wishes to know the software environment in which the component will run; this, together with the component format allows a user to determine whether the component he wishes to use is "out of date" wrt the component's version (e.g., suppose the "ReadMatrix" component is "Java bytecode" which only runs under "JDK1.0.2"; the end user may not want to run it since he knows the numerics in "JDK1.0.2" suck in comparison to those in later releases (e.g., "JDK1.2"); presently unused in the CAT
example: "This component reads in a matrix from a file system and places it into memory." purpose: human-readable description of what the component does rationale: this is a human-readable description of what the component does; the description level can be as vague or detailed as the component developer chooses; this information is static; the CAT presents this information to the user before an instance of the component gets created; more dynamic information on a component can be obtained via a method call on the component (e.g., componentInstance.getDescription()); the compnent description could be split into "standard information" (e.g., component version number, author, date of last modification, etc.), and "semantic information" (e.g., isA matrix_solver, requires filename input, outputs a matrix data structure in Harwell-Boeing format, etc.)
scenario 1: inputs/outputs only example: "number of inputs=2 ; number of outputs=3; input of type integer; ..." purpose: to describe the inputs and outputs of the component; this should be in both textual form (e.g., "input is used for specifying matrix dimension") as well as some kind of generic type specification/instance if java, use class bytecode to represent an input or output if not java, use an IDL (textual) description scenario 2: functions only example: "number of functions=3, function 1: char* ReadMatrixFile(int i), ..." purpose: to describe the function prototypes of the component use IDL (textual) description for all function prototypes provide human-readable description of functions which explain what the functions do
NOTE: All components are assumed to have two sets of interfaces: system and user-defined. The system interfaces are required by the component framework, and MUST BE PROVIDED since they define membership in the component framework. The user-defined interfaces are optional. So, a list of each of these types of interfaces should be provided in the database.
scenario 3: combination of functions, their arguments, their return types, and descriptions of each ...
example: "/usr/local/bin/ReadMatrix" purpose: to indicate the complete path and name of the executable
example: "10MB RAM, 32MB Disk, 0.25 CPU LOAD" purpose: the estimated minimum/average/maximum resource requirements during execution
example: "/usr/local/lib/readmatrix" purpose: the directory containing resources used by the executable
example: "/tmp/readmatrix" purpose: directory in which to start the component from
example: "/tmp/user/foo" purpose: the working directory of the user to start the component in (is this necessary?)
And any more we can think of ...
Environment-specific component attributes should reside under the machine category in the current MDS format.
Environment-independent info resides in a separate branch of the tree, but is linked to environment-specifc info with distinguished name links.
Interface objects resides below their corresponding
component entry in the tree. There may or may not be "standard" interfaces
that do standard things. Also, a component can have any number of
interfaces, method prototypes.