Introduction

Torus is a central component of the MasterKey software suite. It is used primarily as a registry for targets, user identities, authoritative (master) data and configuration in broad metasearch applications.

Torus was designed as a distributed, flexible and schema-free system to support wide ranging requirements.

The problem

To support the development of the MasterKey metasearch platform, Index Data needed a distributed, multi-level framework, available as a software service, capable of managing the target registry required to drive a full-scale discovery solution.

Requirements

For optimum flexibility and ease of administration, the registry solution needed to satisfy many desiderata:

  • The solution must work for hierarchies of entities like consortia, institutions, departments and even individuals, allowing configuration information at each level to build upon that of the higher levels.
  • Each entity (consortium, institution, etc.) must retain complete autonomy in maintaining its selection of target profiles.
  • Target profiles must be shareable both within and between entities.
  • Target profiles must be customizable on a per-entity basis.
  • It must be possible for independent service providers to maintain pools of target descriptions that are available for other organizations to use.
  • The solution must be accessible by means of web-services, both for searching and retrieval of target profiles and for updates when appropriately authorized, so that it is available for use by applications written in any programming language, and located anywhere on the network.
  • The solution must be deployable either in a vendor-hosted environment or hosted by a customer.
  • In a hosted environment, it must support multi-tenant operation, to enable SaaS-type applications.
  • Changes and updates made to target profiles at low levels need to bubble up through to the higher levels, but without overwriting the higher levels' customizations.

Usage scenarios

The registry solution should be able to address all of the following scenarios:

  1. A single library wants to provide a metasearching facility to its members, making use of existing target profiles.
  2. Another library wants to provide a metasearching facility to its members, providing its own target profiles.
  3. A third library wants to provide a metasearching facility to its members, using both existing and newly created target profiles, and modifying the existing profiles to customize them for its members.
  4. A consortium wants to provide metasearching facilities to its members, making different sets of targets available to different members by sharing some targets with all members and others to only a subset of the members, or just one.
  5. A consortium such as that in the previous scenario provides a target description record for its members, describing a commercial resource and specifying default authentication credentials to be used for public access. One member of the consortium has purchased a higher level of access to the resource, and needs to use alternative authentication tokens in order to use this access. It should be possible for that member to override the consortium's target profile for its own use only.
  6. A consortium provides a target description record for its members, describing a library catalog at otherhost.edu:210/catalog. Each consortium member uses different authentication credentials when accessing this resource, in order to enable usage tracking. The catalog server is moved to a new host, lib.otherhost.edu. The consortium administrator should be able to make this change to a single record at the consortium level, and have it immediately reflected at the level of the individual members, while those members continue to use the previously configured authentication credentials.

    Other, more complex, scenarios can be imagined: for example, one in which a “super-consortium” or network mediates metasearchable resources for a group of consortia, each consisting of multiple members.