|
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
-
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.
Greg
Janée
Created: 2003-06-24
Last modified: 2004-10-18 10:03
|