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=//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