| | | 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.
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.
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 |
| AHVRR Image | 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.
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:
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:
| HELP: http://dodsdev.gso.uri.edu/dods-3.4/nph-dods/help |
| VERSION: http://dodsdev.gso.uri.edu/dods-3.4/nph-dods/version |
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.
| | | 3 The DAP Architecture |