Home

Try it

HTTP test forms

RMI client

Documentation

Installation

Javadocs

Configuration

Overview

Sample files

Webapp

Middleware

Bucket99 driver

Query translator

RMI proxy driver

APIs

Client API

Collection API

DTDs

Query language

Collection metadata

Bucket report

Browse report

Access report

Download

Complete webapp

JAR only

Python modules

3rd-party software

Source code

Other

Servlet URLs

RMI registry names

Change log

Terms of use

Here we describe the interface between an ADL middleware server and collections hosted by the server. This interface can be appreciated only in the context of the middleware's client interfaces, and thus that document, and the server-side architecture diagram, should be visited first.

Conceptually, an ADL collection is 1) a set of items, each of which has item-level metadata and an identifier that is unique within the collection; together with 2) collection-level metadata. Functionally speaking, an ADL collection is a set of services that return collection-level metadata; that return the identifiers of all items in the collection; that return various standard views of item-level metadata; and that, most significantly, query the collection and return items matching one or more constraints placed against item-level metadata. Although not required logically, it is expected that collections respond to requests quickly, consistently, and reliably, and that identifiers have relatively long-term persistence.

The interface to a collection is implemented by a driver, or more precisely, by four drivers, which respectively implement the middleware's collection, identifiers, metadata, and query services for that collection. The middleware dynamically and independently loads drivers on demand, and may unload a driver at any time. (The query driver should anticipate that it may be unloaded while there are outstanding query threads.) Drivers must be threadsafe.

The middleware refers to collections by short names, e.g., "adl_catalog". Item identifiers are arbitrary strings. A qualified identifier globally identifies an item I in collection C using the syntax C:I, e.g., "adl_catalog:1001652". The collection name is defined in the middleware configuration and is generally independent of the collection except that it must be embedded in the <internal-name> element in the collection-level metadata and in all qualified identifiers that appear in item-level metadata.

ADL has specified a content standard and XML encoding for collection-level metadata. By contrast, collections are generally free to use any item-level metadata, the only requirement being that item-level metadata must be mapped to the ADL search buckets and to the standard ADL metadata views. Collections may also return other views of item-level metadata not defined by ADL.

The Java interfaces that the three drivers must implement are as follows:

CollectionDriver

The interface between the middleware's collection service and the collection. On request, the driver must return the collection-level metadata for the collection in the form of an XML document that adheres to the ADL-collection-metadata.dtd DTD.

IdentifiersDriver

The interface between the middleware's identifiers service and the collection. The driver must return the identifiers of all items in the collection.

MetadataDriver

The interface between the middleware's metadata service and the collection. Given the identifier of an item in the collection, the driver must return a specified view of item-level metadata for the item. The metadata must be returned as an XML document that adheres to the appropriate DTD.

QueryDriver

The interface between the middleware's query service and the collection. Given a middleware query, the driver must return a thread that, when started, will perform the query against the collection and add results (in the form of triplets of standard ADL metadata views) to the query's result accumulator.