Greg Janée > Documents > Object-oriented ADL Interface

Object-oriented ADL Interface

Currently, there are three interfaces by which an ADL client can access an ADL node (i.e., a middleware server): via HTTP, via RMI, and, if the client is running within the same Java VM as the node, via direct Java method calls. The HTTP interface is the most universally accessible of the three, but it is also the least convenient since it requires marshaling every interaction as a protocol request/response. The Java and RMI interfaces are more convenient— if the client is implemented in Java, of course. All three interfaces suffer from the fundamental inconvenience of information being represented in XML as opposed to more programmatically friendly data structures.

Here's a design for a fourth, object-oriented interface based on some earlier ideas by Dave Valentine and Peter Slaughter. The interface consists of a number of "client objects" (i.e., objects that run in the context of the client) that hide the remoteness of ADL nodes and that make ADL services available as native methods. It differs from the RMI interface in that it is not XML-based.

Some general comments about the interface:

• The client objects defined below (Collection, ResultSet, etc.) are proxies for library objects. They store the information necessary to connect to and stay synchronized with their library counterparts. They do so by employing existing middleware services via the middleware's HTTP and/or RMI interfaces.
• In certain cases client objects will need to cache retrieved library information to achieve acceptable performance. This presents little difficulty at the moment, but as ADL services become more dynamic in nature (for example, once they start supporting dynamic creation and deletion of collections and collection items), explicit synchronization mechanisms will probably have to be added.
• Client objects offer basic, XML-based methods that correspond directly to existing middleware services. But they also offer data structure-based methods; the latter have been designed to be easily implementable in terms of the former.
• Speaking of implementation, this interface has been designed with no implementation language in mind. Ideally, it would be nice to have multiple versions of it: Java, Python, Perl, etc.
• This document doesn't spell out the grungy details of object construction, simple accessor methods, error handling, etc.

Client object definitions follow.

• Library
• Collection
• QueryConstraint
• ResultSet
• Item
• BucketMapping
• BrowseRepresentation
• AccessPoint

Library

Represents an ADL node, i.e., an ADL middleware server. Stores:

• The node's HTTP base URL or RMI base address.

Methods:

getP()

Returns node configuration property P as an appropriately typed quantity. For example, the method for the node's collection list is described next.

getCollections()

Returns the node's collections as a list of Collection objects.

getStatus()

Returns the node's status as an HTML document. (This information should probably be converted to XML someday.)

query(query)

Asynchronously queries the node and immediately returns a reference to a ResultSet object. The query is specified in the ADL query language.

query(collections, constraint [, rankingMethod] [, maximumResults])

Identical to the preceding, but the collections to query are specified by a list of Collection objects and the query is specified by a QueryConstraint object representing the root constraint.

Collection

Represents a collection. Stores:

• A reference to the Library object representing the ADL node that hosts the collection.
• The collection's name.

Methods:

getMetadata()

Returns the collection's collection-level metadata as an XML document.

Additional methods return individual components of the collection's metadata represented as data structures, but specification of these methods is deferred until the ADL collection metadata standard has been upgraded to support the collection discovery service.

query(query)

Asynchronously queries the collection and immediately returns a reference to a ResultSet object. The query is specified in the ADL query language (the list of collections in query is ignored in this case).

query(constraint [, rankingMethod] [, maximumResults])

Identical to the preceding, but the query is specified by a QueryConstraint object representing the root constraint.

QueryConstraint

A query constraint. This class is an abstract base class; concrete subclasses (BooleanConstraint, SpatialConstraint, TemporalConstraint, etc.) represent the different kinds of query constraints as in middleware class Query.

ResultSet

Represents a result set. Stores:

• A reference to the Library object representing the ADL node that stores the result set.
• The result set's ID.

Methods:

cancelQuery()

Pre-emptively cancels the associated query.

getResult(index)

Returns an Item object representing the query result at index index.

getResults(from, to)

Returns a list of Item objects representing the query results between indices from (inclusive) and to (exclusive).

Additional methods follow those defined in middleware class ResultSet.

Item

Represents an item (a.k.a. resource or holding) in a collection. Stores:

• A reference to the Collection object representing the collection to which the item belongs.
• The item's collection-local identifier.

Methods:

getSupportedViews()

Returns a list of the metadata views the item supports.

getView(view)

Returns a specified view of the item as an XML document.

getAllBucketMappings()

Returns a list of BucketMapping objects representing the item's bucket mappings.

getBucketMappings(bucket)

Returns a list (possibly empty) of BucketMapping objects representing the item's mappings to a specified bucket.

getBrowseRepresentations()

Returns a list of BrowseRepresentation objects representing the item's browse representations.

getRootAccessPoint()

Returns an AccessPoint object representing the item's root access point.

BucketMapping

Represents one of an item's bucket mappings. This class is an abstract base class; concrete subclasses represent mappings to the different bucket types (SpatialBucketMapping, TemporalBucketMapping, etc.). Stores:

• A reference to the Item object representing the item to which the bucket mapping belongs.
• The name of the bucket.
• If available, the URI and name of the mapping's source metadata field.

Subclasses store additional information specific to the bucket type.

BrowseRepresentation

Represents one of an item's browse representations. This class is an abstract base class; concrete subclasses represent the different kinds of browse representations. Currently there is only one, BrowseImage. Stores:

• A reference to the Item object representing the item to which the browse representation belongs.

Subclasses store additional information specific to the kind of browse representation.

AccessPoint

Represents one of an item's access points. This class is an abstract base class; concrete subclasses (DownloadAccessPoint, ServiceAccessPoint, etc.) represent the different kinds of access points. Stores:

• A reference to the Item object representing the item to which the access point belongs.
• If available, the access point's title, description, and rights clause. The rights clause is necessarily XML since its format is not defined by ADL.

Subclasses store additional information specific to the kind of access point. In particular, MultipartAccessPoint and AlternativesAccessPoint store references to the multiple AccessPoint objects they comprise. The additional information stored by OfflineAccessPoint is necessarily XML since its format is not defined by ADL.

created 2003-06-24; last modified 2009-01-14 09:08