A request for data made to the client OPeNDAP library will result in three different requests for data to an OPeNDAP server. The user simply enters a single URL, as described in Section 2.1. The core OPeNDAP software then modifies the URL into three slightly different forms, and makes three requests for data to the server. The first request is for the "shape" of the data, and consists of the dataset descriptor structure, described on here. The second request is for the attributes of the data types described in the DDS. This structure is described on here. The last request is actually for the data.
The response to the DDS and DAS request URLs is text formatted using the grammars in table 6.4.2 and table 6.4.1. This text can then be parsed by the caller to determine the structure of the dataset, types and sizes of each of its components and their attributes. Depending on the data access API used to access the data, these structures may be derived either from information contained in the dataset or from ancillary information supplied by the dataset maintainers in separate text files, or both. The data in these structures (which can be thought of as data about the real data) may be cached by the client system.
The OPeNDAP DAP is a stateless protocol. The protocol entry points may be thought of as the different messages to which an OPeNDAP server will respond. (A message is just a URL specifying a request.) Each of the protocol entry points does a single isolated job and they can be issued in any order. Of course, it may not make sense to the user to ask for the data before asking for the data description structure, but that is not the server's problem. This separability allows the user to cache data locally if need be, so that future accesses to the same dataset can skip the retrieval of these structures.
To understand the operation of the OPeNDAP server, it is useful to follow the actions taken to reply to a data request. The diagram in figure 5.1 lays out the relationship between the various entities. Consider an OPeNDAP URL such as the following:
http://dods.gso.uri.edu/cgi-bin/nph-nc/data/fnoc43.nc
When this URL is submitted to an OPeNDAP client, it will contact the Web
server (httpd) running on the platform, dods.gso.uri.edu. When
the connection has been established, the client will forward to the
server the remaining parts of the URL:
/cgi-bin/nph-nc/data/fnoc43.nc. As the server parses this
string, it will notice that cgi-bin corresponds to the name of
the directory where it keeps its CGI programs. (The actual directory
name is specific to the particular web server used, and the details of
its installation. Typically, the web server documnetation might call
it the ScriptAlias directory, and it might refer to something
like /usr/local/etc/httpd/cgi-bin.) It looks in that directory
to see whether there exists a CGI program called nph-nc, which
is the name of the netCDF OPeNDAP server packaged with OPeNDAP. Finally,
the server executes that program, specifying the rest of the URL
(data/fnoc43.nc in this case) for an argument. The standard
output of the CGI program is redirected to the output of the
httpd, so the client will receive the program output as the
reply to its request.
httpd configuration. On the dods.gso.uri.edu
server, for example, all CGI programs are executed native to the
directory /usr/local/spool/http. The last section of the URL,
then, specifies the file fnoc43.nc in the directory:
/usr/local/spool/http/data.
Several existing data APIs, such as JGOFS, are not designed with file access as their fundamental paradigm. The JGOFS system, for example, uses an arrangement of "dictionaries" that define the location and method of access for specified data "objects." A URL addressing a JGOFS object may appear to represent a file, like the netCDF URL above.
http://dods.gso.uri.edu/cgi-bin/nph-jg/station43
However, the identifier (station43) after the CGI program name
(nph-jg) represents, not a file, but an entry in the JGOFS data
dictionary. The entry will, in turn, identify a file or a database
index entry (possibly on yet another system) and a method to access
the data indicated. (The httpd server must be a valid JGOFS user to
have access to the dictionary.)
Note that the name and location of the cgi-bin directory, as
well as the name and location of the working directory used by the CGI
programs, are local configuration details of the particular web server
in use. The location of the JGOFS data dictionary is a configuration
issue of the JGOFS installation. That is to say these details will
probably be different on different machines.