Shared Services Testbed

Introduction

The aim of this exercise is to produce a testbed for the JISC Information Environment and Shared Services. The idea is to make it possible for:

1. JISC to demonstrate how its vision of the IE-based future can work;
2. Institute personnel to experiment with using and managing such services;
3. Projects to test and demonstrate interoperability with other IE components.

Goals

The primary goal of this effort is to support the Shared Services programme. A suite of common services can only be proved to work if they are installed in such a way that applications can be deployed which make use of them. As a minimum, this will require that each service is itself deployed in a realistic way: each service ought to have appropriate and comprehensive (in the sense of covering all functional requirements rather than mirroring real-world volumes) data and connections to the outside world. The next level of requirement will be that the common services deployed separately will recognise and make use of each other where appropriate: so, where a test service might have dummy calls to a resource search service in the stand-alone state, in this interoperable state it ought to be linked to one of the Shared search services. Finally, the testbed service ought to emulate a real-life environment: so, commmon services, multiply deployed in different locations, each interoperating and accessible by applications also deployed in different locations.

Secondary goals will be:

• to then do the same to other IE components, again with the same levels of provision as above, but in this case with each component interacting with the shared services;
• and to provide a mock-up institute, with sufficient 'internal' applications to demonstrate the working of the IE in conjunction with institute-type applications. This will allow institute staff to experiment and get an idea of the effort involved in adapting their own applications to the IE.

Side benefits

The main goal of this effort is to demonstrate working services but it will have additional side benefits:

• developers will be able to deploy their services in a risk-free environment and test interoperability with other services and components;
• service providers, likewise, can deploy their services in the testbed to test interoperability with JISC developments and offerings from other providers;
• ...

Use Cases

To get a better idea of what we want to achieve with this idea, we will list a few potential use cases. These will also help in determining the functional and technical requirements.

Developer tests new service

Scenario:template
aaa

Requirements:template
xxx

Scenario:perform federated search

A user wishes to find resources that actually sit in a number of different databases. The user does not care about this, they wish this fact about the network location of resources to be as transparent to them as possible. The user uses a federates search service to search many databases with the same search term i.e. author=jones. This results in the population of a single user interface with metadata records from many databases.

Requirements:federated search

1. The federated search is performed in compliance with a well recognised interoperability specification e.g. Z39.50, SRU, SRW, SQI, OSID

2. The results of the federated search are displayed in a well-designed user interface

3. The federated search is performed over a variety of useful production services

MIS links inst portal to discovery service

Scenario:
aaa

Requirements:
xxx

...

Functional requirements

This area will

• ...

Technical requirements

It is difficult to determine the exact technical requirements at this stage. Each service and component will have different needs.

One core requirement will be that the components and services actually allow this type of deployment. If they are built to only work in their current operational environment, perhaps even only on the specific servers or ip addresses, then this approach may not work.

Potential hw/sw architecture

...

Draft ITT

the ITT for consortium to provide this service

...

Action plan

Areas which need addressing before this document can even become a proposal are:

• list of existing shared services and their technical requirements, in particular
  • ability to be independently deployed
  • ability to be multiply deployed
• known compatibilities and incompatibilities
• ...