The ADL middleware is responsible for implementing the client-middleware interfaces described above, and mapping them into interactions with an arbitrary number of metadata catalogs. Additionally, the middleware implements whatever access controls ADL requires.
The current ADL middleware layer is implemented by an AOLserver (version 2.2) HTTP server. All ADL-specific functionality described in this section is implemented by Tcl scripts and C functions executing in the context of the AOLserver.
Access Control
The ADL middleware supports whatever access policy is dictated by ADL.
Two specific access controls are supported in the current
implementation: host-based and user-based.
Host-based access control is used to refuse connections from clients that are not running at an ADL-approved Internet address. This is currently used to limit access to ADL to only those hosts connected to an IP network managed by the University of California. To this end, the access-control module maintains an explicit list of network numbers from which it will entertain connections. This mechanism is inherently unscalable, although it suffices to meet the UC-only distribution restrictions imposed by third parties on some proprietary materials in the ADL collections (e.g., commercial remote sensing imagery).
User-based access control allows a client to specify a (username,password) tuple during its initial connection sequence. This mechanism is currently not being used for access control as such; rather, it is being used to associate ADL client ``sessions'' with specific users for evaluation purposes. Each client request is logged to an external database along with a unique session identifier, which includes the (username,password) tuple if it is available.
Query and Retrieval Mapping
The ADL middleware maps KNF queries and retrieval requests into SQL
queries specific to the underlying ADL servers. If multiple servers,
or multiple
databases on a single server, must be queried, this layer handles the
requisite fan-out/fan-in. Note that we currently assume that multiple
databases are disjoint; thus, the fan-in process is currently simple
collation, with no duplicate detection or other conflict resolution.
In the current implementation, a basic architectural assumption is that the underlying servers will expose views that are, as closely as the particular server allows, exact correlates to the ADL search buckets and retrieval sections. Thus, the translation functionality of the mapping layer is currently limited to ``transliterating'' KNF into various dialects of server query languages (e.g., SQL).
Database Connections
The ADL middleware maintains a pool of client connections to whatever
underlying servers are currently supported. The database connection
layer is responsible for presenting a single functional interface to
these shared connections. This serves to both localize whatever
special
knowledge (e.g. database client library) is needed to communicate with
a particular server, and to minimize the setup or teardown time
associated with making or breaking database client-server connection.