The ADL architecture is a 3-tier client-server architecture:
Figure 3: The logical architecture of the testbed system.
The crux of the architecture is a middleware layer with standard interfaces for metadata queries, metadata retrieval (in various formats), and digital object retrieval. These interfaces are intended to support arbitrary clients, of which the ADL client is the first sample implementation. The interfaces allow the clients to either ignore, or selectively explore, the idiosyncratic schemata of the underlying catalog databases.
The ADL client is a graphical interface designed to support interactive queries by ADL users. In the context of the overall ADL architecture, the salient feature of the ADL client is that the ADL client-server interfaces have been designed on the assumption that the ADL client is a program. Specifically, the client is assumed to be capable of maintaining enough local state to support the notion of a ``session'', as well as supporting complex real-time user interactions (e.g. rollover help). Thus, the ADL client thus requires less support from the rest of the ADL architecture than did its predecessor ``Web Prototype'' client, which was implemented entirely with server-generated HTML pages.
The current version of the ADL client is implemented entirely in Java. It may be run either as a stand alone application, or as an ``applet'' in the context of a Java-enabled Web browser (Netscape Navigator, Microsoft Internet Explorer, etc.)
The ADL client communicates with an ADL middleware layer via HTTP. We selected HTTP as the basic protocol owing to its ubiquity, simplicity, and the ease with which current HTTP servers can be extended to support the level of functionality we require. (As CORBA object brokers become ubiquitous, this decision will be revisited.)
Each family of interfaces supported by the ADL middleware is bound to a particular URL. This eliminates the need for top-level switch logic to vector requests to the appropriate handlers, but does require that the client be aware of which URL implements which interface.
Five standard interfaces are currently supported
A sixth interface, the map browser, allows a client to request a base map for a particular portion of the Earth's surface, specifying projection and feature layers (coastlines, highways, etc.). Although this service is unrelated to the contents of ADL, it simplifies the development of graphical clients that display maps as navigational tools.
Unless otherwise specified, all ADL interfaces are implemented as HTTP POSTs to the interface's URL. Method names and parameters are passed as the contents of the post, in KNF (Kevin's Normal Form), a LISP-like syntax that supports both method invocation and simple boolean expressions. Return values are provided as ASCII text (MIME type ``text/plain'' with name-value pairs separated by CR-LFs. An error message may be returned in lieu of whatever other return values the method supports.
Session Interface
The session interface exposes two methods, get-session-id and
get-session-info.
get-session-id accepts user data and client data, and returns
a unique session-id:
(get-session-id user-data client-data)
The user data are any information required to identify the user to the rest of the ADL system, such as a name and a password. The client data are any information required to identify the client software, such as client version. The session-id is used in all subsequent calls to ADL interfaces.
The get-session-info method returns a number of session-specific parameters:
(get-session-info session-id)
This should be used to set parameters in the client, such as the URLs associated with the ADL interfaces, that would otherwise have to be hard-coded.
Query Interface
The query interface exposes two methods, start-query and
stop-query.
start-query accepts a session-id, a maximum number of results to return, and a query expression, and returns a query-id and minimal standard metadata for each object that satisfies the query expression:
(start-query (session-id session-id)
(maximum-results maximum-number-of-results)
(expression query-expression) )
The query-id, returned immediately, may be used by the stop-query
method to terminate a query that appears to be hung or otherwise
taking ``too long'' to complete.
The query-expression specifies boolean constraints on, and/or combinations of, the ADL search buckets, a standard set of high-level search metadata. Each collection supported by ADL must specify a mapping from its own metadata into the search bucket attributes. This mapping will almost always be many-to-one; i.e., there will inevitably be a loss of precision in querying the search buckets versus querying the collection-specific metadata directly. However, by exposing only a single high-level set of searchable metadata, the ADL middleware allows clients to be built that can both exploit search bucket semantics (e.g. spatially manipulate the ``location'' bucket), and can search all of ADL via a single connection.
Result Interface
The result interface accepts a session identifier and a list of
object identifiers, and returns a list of object metadata. The
metadata are formatted according to the XML subset of SGML. XML
tags are used to delineate:
Groups and name-value pairs are collection-specific; their semantics need not be known to ADL clients.
Browse Graphic Interface
The browse graphic interface accepts a session identifier and a single
object identifier, and returns a MIME-typed ``browse graphic''
representation of the object (usually a GIF, JPEG, or PNG image).
If no specific browse graphic representation of the object is
available, then a default image (e.g., a ``not available'' icon)
is returned.
Map Browser Interface
The map browser interface accepts a detailed map specification
(footprint, projection, etc.) and returns a GIF image of a map of
the corresponding Earth surface area.
The map browser interface is provided for the convenience of ADL clients that may need to generate arbitrary maps as visual navigational aids. Clients which do not require these maps (or which generate them by other means) may safely ignore this interface.
Unlike the other ADL interfaces, the map browser interface is implemented as a CGI GET, with the map parameters encoded in the interface URL. This is a historical artifact which we intend to update.