Data Management

DDMS Overview


Basic Elements

Data Objects


User Applications

Manipulating Data


Further Info

Data Management

Detailed Information About the JGOFS Distributed Database Management System (DDMS)

Servers and Dictionaries


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


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 //<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.,
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

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
- P.Brewer
- Total carbon dioxide
- C.Davis
- Bio Optical Profiler Data
- H.Ducklow
- Particulate C, N
- This will contain good stuff



back to top