4 The DAP Architecture

The DAP can be thought of as a layered protocol composed of MIME, HTTP, basic objects, and complex, presentation-style, responses.

4.1 The DAP uses HTTP which in turn uses MIME

Clients use HTTP when they make requests of DAP servers. HTTP is a fairly straightforward protocol (for general information on HTTP see http://www.w3.org/Protocols/, and for the HTTP/1.1 specification, see http://www.w3.org/Protocols/rfc2616/rfc2616.html). It uses pseudo-MIME documents to encapsulate both the request sent from client to server and the response sent back. This is important for the DAP because the DAP uses headers in both the request and response documents to transfer information. However, for a programmer who intends to write a DAP server, exactly what gets written into those headers and how it gets written is not important. Both the C++ and Java class libraries will handle these tasks for you (look at the DODSFilter class to see how). It's important to know about, however, because if you decide not to use the libraries, or the parts that automate generating the correct MIME documents, then your server will have to generate the correct headers itself.

4.2 The DAP defines three objects

To transfer information from servers to clients, the DAP uses three objects. Whenever a client asks a server for information, it does so by requesting one of these three objects (note: this is not strictly true, but the whole truth will be told in just a bit. For now, assume it's true). These are the Dataset Descriptor Structure (DDS), Dataset Attribute Structure (DAS), and Data object (DataDDS). These are described in considerable detail in other documentation. The Programmer's Guide contains a description of the DDS and DAS objects (see http://opendap.org/api/pguide-html//pguide_6.html). These objects contain the name and types of the variables in a dataset, along with any attributes (name-value pairs) bound to the variables. The DataDDS contains data values. We have implemented the SDKs so that the DataDDS is a subclass of the DDS object that adds the capacity to store values with each variable.

The DAP models all datasets as collections of variables. The DDS and DataDDS objects are containers for those variables. How you represent your dataset using the three objects and the DAP's data type hierarchy is covered in section 7.

4.3 The DAP also defines services

In the previous section we said that the DAP defined three objects and all interaction with the server involved those three objects. In fact, the DAP also defines other responses. They are:

ASCII

Data can be requested in CSV form.

HTML

Each server can return an HTML form that facilitates building URLs.

INFO

Each server can combine the DDS and DAS and present that as HTML.

VERSION

Each server must be able to respond to a request for it's version and the version of the DAP it implements.

HELP

Each server must be able to provide a rudimentary help response.

In each case the server's response to these requests is built using one or more of the basic three objects. Here are some links to various datasets' ASCII, HTML and INFO responses:

The VERSION and HELP responses can be see by appending help or version to the end of the server's base URL. For example:

4.4 Parts of the server you don't have to write

You do not have to write handlers for the ASCII, HTML or INFO responses because the OPeNDAP server includes software that generates these using the DAS, DDS and DataDDS objects. In addition, if you follow a simple rule about how you name the programs that generate the object responses, you'll be able to fit these within the existing dispatch software and can avoid writing that as well. The rule is that the three objects are generated by programs named name_das, name_dds and name_dods (the last one generates the DataDDS object). The name can be any text. In practice, it should be short and describe the data with which it's designed to work.

Below is a snapshot of the directory which holds the programs that make up the OPeNDAP servers on my development computer. The ASCII response is generated by the asciival program, The HTML and INFO responses are generated by the www_int and usage programs. You can also see the dispatch program (nph-dods) as well as the DAS, DDS and DataDDS handlers for the netCDF (nc), HDF (hdf), Matlab (mat), JGOFS (jg) and FreeForm (ff) servers.

[jimg@zanzibar etc]$ ls
aclocal.m4            ftp_dods_source.html   MIME/
asciival*             handler_name.pm        nc_das*
ChangeLog             hdf_das@               nc_dds*
check_perl.sh*        hdf_dds@               nc_dods*
common_tests.exp      hdf_dods*              nightly_dods_build.conf
config.guess*         HTML/
nightly_dods_build.conf.example
config.sub*           HTTP/                  nightly_dods_build.sh*
COPYRIGHT             INSTALL-clients        nph-dods*
CVS/                  INSTALL-matlab-client  nph-dods.in*
cvsdate*              installServers         printenv*
def*                  INSTALL-servers        README
deflate*              install-sh*            README-Matlab-GUI
depend.sh*            jg_das*                tar-builder.pl*
DODS_Cache.pm         jg_dds*                test-dispatch.sh*
DODS_Dispatch.pm      jg_dods*               ud_aclocal.m4
dods.ini              jgofs_objects_readme*  update-manifest.pl*
ff_das*               localize.sh*           update-manifest.pl~*
ff_dds*               LWP/                   usage*
ff_dods*              Makefile.common        usage~*
FilterDirHTML.pm      mat_das*               usage-jg*
ftp_dods_binary.html  mat_dds*               www_int*
ftp_dods_ml_gui.html  mat_dods*
[jimg@zanzibar etc]$