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.

Servers

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=//globec.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 //globec.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 dictionarys which tell the outside world what objects are available on this machine. In addition, other information about the object is provided, usually with loinks 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