Data Management
Detailed Information About the JGOFS Distributed Database Management System (DDMS)
Servers and Dictionaries
Servers
Each JGOFS system which is providing data must have the HTTPD process running as a background task. When
a request for data comes in, HTTPD starts our server process.
This process consults the dictionary, starts up the method process and
passes it the requested subselections and other parameters.
The method analyzes the request, gets the information from the data
files or database, and writes out the results (in the JGOFS protocol). These pass through the communication
pathway to the application program. In this sense, the method acts
like an input subroutine which the main program calls to get data from
files. However, the the data can be gathered from across the network.Dictionaries: .objects files
The server works with two dictionaries, the user's (in the current
working directory) and a tree of system dictionaries (set up when the
software is built). These translate between a shorthand notation for
the object and the detailed description either of where the object is
[what machine it's on], or, if it's locally held, what method is used,
and what default arguments are to be passed to the method. Thus the
user can generally deal with brief names.
So users can specify objects in the following forms:
- 1. method(parameters)
- In this case, the software will use the method named as the
translator, passing it the parameters. Methods are stored in the
methods subdirectory of the JGOFS software directory. The
parameters are passed as command line arguments to the process.
- 2. datafilename or datafilename(parameters)
- In this case, the software assumes the default method, def, is being used.
- 3. nameindictionary or nameindictionary(parameters)
- The name is looked up in a file, .objects, in the
present directory and replaced with the information found therein. The
parameters are merged. For example, if the local .objects
file contains
stuff=nm(myfile)
farstuff=//jgofs.whoi.edu/test
Then a request for
stuff(press<100) will translate to
nm(myfile,press<100) and then be reinterpreted by the
first rule. A request for farstuff(press<100) will be
translated to //jgofs.whoi.edu/test(press<100) and
reinterpreted by the fifth rule below.
- 4. /path/nameindictionary or
/path/nameindictionary(parameters)
- The name is looked up in a file, .objects, in the JGOFS
system directory, following the path given. The ``root'' of the
objects tree is the subdirectory objects of the JGOFS
software directory. Replacement occurs as above.
- 5. //machinename/path/nameindictionary or
//machinename/path/nameindictionary(parameters)
- The
path, name, and parameters are transferred to the remote machine which
then follows the procedure outlined just above.
Dictionaries have two types of entries:
- Local entries
- These map the name to a method on this machine and (usually) some
required parameters: e.g.,
bot=jgbl2(/d5/glenn/bloom/bot)
- Remote entries
- Usually, these just map a name on this machine to a name on the
other machine. Thus if a data object on the remote machine is moved or
replaced, only the dictionary on that machine needs to be updated.
This also shields remote users from needing any details
about the remote filesystem, methods, or data locations. An entry of
this type looks like
bot=//puddle.mit.edu/jgofs/bloom/bot
Dictionaries: .remoteobjects files
In addition, the system supports a set of dictionaries which
tell the
outside world what objects are available on this machine. In addition,
other information about the object is provided, usually with links to
an HTML page giving textual description of the information in the
object, the variables, etc. Such a file looks like
tco2=//puddle.mit.edu/jgofs/bloom/tco2
- P.Brewer
- Total carbon dioxide
optics=//dataone.whoi.edu/jgofs/bloom/optics
- C.Davis
- Bio Optical Profiler Data
poc=//puddle.mit.edu/jgofs/bloom/poc
- H.Ducklow
- Particulate C, N
stuff=//puddle.mit.edu/test
-
- http://puddle.mit.edu/notready.html This will contain good stuff
|
|
