Bug #163
closed
need data repository interface for metacat
Added by Matt Jones about 24 years ago.
Updated over 16 years ago.
Description
Recent discussions have indicated that the metacat server should shield client
interaction from the SRB and other data storage systems (e.g., http servers).
Consequently, we need a new architecture for passing data to, and getting data
from, the metacat server. The metacat server would then look at the address for
the data object and dynamically load an adapter class that handles communication
with the appropriate backend data system (e.g., SRB, http). This could be
implemented as protocol handlers, or otherwise. The SRB adapter will require
extensions to the current srb RMI server to allow for streaming data objects.
All adapters will need to make use of the authentication and access control
interfaces, so there may be a need to extend those interfaces. At a minimum the
SRB adapter will need to query the authentication interface to find out the
proper MCAT username and password to use (which might differ from the original
if there is a user proxy system set up).
This proposed architecture assumes that the bottleneck introduced by passing all
data through a few servers is negligible. the alternative is to connect clients
directly to the SRB RMI server, which opens up possibilities of new clients
causing metadata/data synchronization problems.
Chad and Dan's initial implementation of this interface allows users to store
data on the Morpho server file system by opening a custom socket to the server.
We now need to generalize the backend interface to this system to allow Metacat
admins to configure the repositories used, either the local file store or the
SRB system, or others as developed. Consequently, we need to re-evaluate the
interface to generic repositories that we are using in the DataFileServer.java
and DataFileUploadInterface.java classes. Owne has agreed to take on this task,
and implement the SRB interface, and rewrite Metacat so that multiple
repositories can be running at one time (and are dynamically loaded as needed).
At the Santa Barbara meeting we agreed to create a generic RepositoryInterface
class that defines the set of methods used to access any backend data storage
system, and then implement a single adapter class (FSAdapter) that allows
stroage of objects on the file system. We have decided to hold off on the
SRBAdapter for now.
Postponing until a later release. SRB functionality is a useful addition but not
critical at this point. It would still be nice to have this modularity built in,
but isn't critical at this point.
In the process of hiring students to help work on this product
I don't think we need this feature anymore.
Original Bugzilla ID was 163
Also available in: Atom
PDF