# Presentation: 548843

## DAP4, SOAP and THREDDS

- James Gallagher
- OPeNDAP
- Presented by Steve Hankin

**Notes:**
Thanks very much Steve and please express my regrets for not being able to make it.

## Overview

- DAP2 and DAP4: Caveat, DAP4 is still in development.
- DAP4 SOAP interfaces
- SOAP and binary data
- SOAP and REST

## DAP 2 versus DAP 4

- Metadata in two responses: DAS & DDS
- Encoded using ‘unique’ notation
- Data returned in non-standard document mixing text and binary
- REST interface only

- Metadata in one response: DDX
- Encoded using XML
- Data returned in a Multipart-MIME document; text/xml and binary
- Both SOAP and REST interfaces

## Other Responses

- Most DAP servers support additional responses such as: ASCII, HTML interface for data requests, version information, directory browsing
- These ‘other responses’ will be documented more formally.
- The ad hoc directory response will be replaced by THREDDS in OPeNDAP’s servers.

**Notes:**
While the DAP (both version 2 and 4) are useful, most server support quite a bit more because that’s what users want. Once the software to generate the DAP responses is written, it’s pretty easy to build general interfaces (like and ASCII output) that can be used with all of the data, regardless of format.
A serious problem with DAP2 is that the non-DAP responses were never documented well at all. With DAP4 we can leverage off of the existing DAP2 document and get these ‘extra features’ described in detail.
I talk about THREDDS a bit later, but the key point is that the response is no longer completely dependent on the physical layout of files and on the DAP server’s underlying httpd.

## THREDDS

- The DAP2 servers from OPeNDAP (and most other sources) supported a very limited ‘directory browsing feature:’
- Tied to the file system which held data files
- Unable to support data in databases
- Dependent on a web daemon to provide the HTML directory listing; varied from server to server
- THREDDS improves this by:
- Supports provider-defined organizations for data
- No longer dependent on files and file systems
- Uniform across different servers

**Notes:**
The thing I like most about THREDDS is that it’s an effort championed by another group! And it’s uniform. And it’s simple and useful.

## About the SOAP Interface

- Requests:
- GetVersion: DAP protocol version
- GetDDX: Metadata
- GetData: Data
- GetTHREDDSCatalog: Machine readable catalog
- Responses:
- Version, DDX, DataDDX, ErrorX, THREDDS
- Each response contains the matching request
- Pooling: Each request includes a Request ID and several requests can be sent to the server in one SOAP envelope.
- DAP4 uses ‘SOAP with Attachments’ (SWA)

**Notes:**
All requests and responses are XML documents except the DataDDX which is multipart-MIME document. By including the request document in the response, it becomes much easier to support subscription systems in the future. In other words, even though we are currently just looking at the case where a request generates an immediate response, this can support the subscription model, too, and we might add that later on.
Pooling is great for machines. The Request ID figures big here, as does the part about responses being returned with their originating requests.
SWA: SOAP with Attachments: discussed on the next slide.

## SOAP and Binary Data

- There are two general ways to send binary data and XML:
- “Out-of-band transmissions” (embed a URL)
- SWA
- Out-of-band is simple, but not standard
- SWA: briefly, this uses a multipart MIME document where the XML is in the ‘main’ part and zero or more binary parts are in attachments.
- SWA is as efficient as Out-of-band because:
- once the SOAP envelope is closed, the response can be sent, which provides a way to stream the binary data.
- Non-xml information is never seen by the XML parser.

## SOAP versus REST

- SOAP:
- Standard
- Integrated discovery mechanism
- Good for machine-to-machine interactions
- REST/GET:
- Entire request encoded in URL - Simple
- Integrates well with web browsers
- Works well with hypertext/human interfaces
- Strategy: Support both
- design systems so that’s easy

**Notes:**
We found that by looking at how we design our REST/GET interface and keeping the implementation sane, we were easily able to implement the SOAP interface with very little extra effort. Nathan can provide the exact details, but I think it took him about two weeks to get working, and that includes the time spent looking over the AXIS documentation (he decided AXIS was a waste of time in the end; the SOAP specs are hard, but the protocol really is pretty simple).

## Slide 9

## Slide 10