2.2 Client ArchitectureTop4 Getting ready to write your client3 The DAP Architecture

3 The DAP Architecture

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

3.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.

3.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://www.unidata.ucar.edu/packages/dods/api/pguide-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.

COADS Climatology DAS DDS
NASA Scatterometer Data DAS DDS
Catalog of AVHRR Files DAS DDS

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 Implementing the DDS object in Writing an OPeNDAP Server.

3.3 The DAP also defines services

NOTE: Information of the DAP services is presented here for completeness and because using these can help speed and simplify development of you client. For example, you can use the HTML and ASCII services to look at a data source using only a web browser. Similarly, the INFO response can be used to look at the attributes and variables in a given data source.

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:

Data can be requested in CSV form.
Each server can return an HTML form that facilitates building URLs.
Each server can combine the DDS and DAS and present that as HTML.
Each server must be able to respond to a request for it's version and the version of the DAP it implements.
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:

COADS Climatology ASCII for the SST variable HTML INFO
NASA Scatterometer Data ASCII for wind speed and direction HTML INFO
Catalog of AVHRR Files day_num%3C170">ASCII for values within a date range HTML INFO

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

HELP: http://dodsdev.gso.uri.edu/dods-3.4/nph-dods/help
VERSION: http://dodsdev.gso.uri.edu/dods-3.4/nph-dods/version

3.4 Connecting to the server

To manage the connection between the client application and the remote server, the DAP uses two objects. The Connect class manages one connection to either a remote data server, or a local access. The Connections class is used to manage a set of instances to the class Connect. For each data source that the client opens, there must be exactly one instance of the Connect class. The The DODS Toolkit Programmer's Guide provides a description for the C++ toolkit's usage.

James Gallagher <jgallagher@gso.uri.edu>, 2004/04/24, Revision: 1.10

2.2 Client ArchitectureTop4 Getting ready to write your client3 The DAP Architecture