Multi-site

Heritage Multi-site Facilities

Heritage is designed to be operated across multiple sites which share a single, union catalogue. It provides facilities to allow a number of operations to be carried out independently on each site whilst still maintaining a common catalogue and borrower files. Overdues and other chaser letters may be created separately for each site; orders can be created and controlled from each site with budgets restricted to particular sites or users. Filters may be applied to searches in the OPAC so that only material on given site is searched.

For further information about Heritage's multi-site facilities please click here.

The basic requirement to run Heritage across multiple sites is the existance of a network between the sites. With this in place there are a number of ways of setting up the system which are described in more detail below.

Unified Catalogue

For those institutions without the IT infrastructure necessary to operate a single union catalogue across multiple sites, but who still wish to offer a single online catalogue for searching, we have developed the Unify module.

Performance on Wide Area Networks

Heritage is a network ready product. If more than one person needs to access the software simultaneously across a network then extra user licences may be purchased and added to the single user system without making any other changes.

The performance of a database application across a network is dependant on a number of factors: the amount of data that needs to be transferred when running the application; the speed of the file server; the speed of the workstation and the rate at which data can be transferred across the network. In many situations it is this last aspect that has the most impact, not least because the specification of modern PCs will exceed the capabilities of most networks, even when they are not busy with other traffic. An analogy to this might be to consider drinking through a straw - the speed at which you can drink and the size of the glass both have some impact on how quickly your thirst is quenched. However, the diameter of the straw will often be the limiting factor.

If there is no network connection between some of the Heritage sites that wish to contribute to a single union catalogue, then please see our information regarding the Heritage Unify Module.

There are several ways in which Heritage can be configured which will improve its network performance. These are (roughly in order of cost):

1. Local OPAC indexes
2. Server Performance Pack
3. Web Server OPAC and Z39.50
4. Thin client (terminal services) based configurations.

Loading the OPAC Indexes Locally

For many libraries the OPAC is the part of the software that is used the most. This can also be the part of the system that demands most of the network’s power because of the amount of traffic that using the OPAC index can generate. Furthermore, the index is most efficient when it has just been rebuilt and adding records to it will cause a gradual decrease in performance.

In order to address this problem, Heritage can be configured so that the OPAC index is stored and periodically updated on each workstation rather than on the server. This means that any OPAC station searching the index will use its own local copy rather than communicating over the network to the one on the server. Thus the speed of searching the index becomes almost independent of the network performance. The catalogue records that satisfy a search must still be retrieved from the fileserver, but this involves a lot less network traffic than the initial index search.

Local indexing can only be applied to workstations that will not be cataloguing and thus updating the index. If you would like to set up local indexing please contact support for details about how to configure your system in this way.

Server Performance Pack

The Server Performance Pack (or SPP) is an additional module for Heritage that is installed onto the fileserver. It can significantly improve the overall performance of Heritage on larger networks. Smaller network users can also benefit from the way that it reduces traffic, particularly where system use is intensive.

The SPP offers a client-server type approach to managing the filing and retrieval of data on the fileserver. It does this by managing much of the process on the server itself rather than each workstation being responsible for finding records and ensuring that they are filed in the right place. Thus, much of the workstation processing (and hence network traffic) is off-loaded to the server wherever possible.

An additional benefit of the SPP for all networks is that the off-loading of file management to the server means that the risk of accidental damage to files through the network, workstation or user is greatly reduced.

Heritage Online or Z39.50

Heritage Online reduces network traffic by transferring the whole task of searching and the retrieval of search results to a single Webserver. This means that only the search results themselves are transmitted over the network to the user’s workstation after a search is carried out on the server. It is also possible to use Heritage Online for circulation functions such as issues, returns, renewals etc.

Unlike the two solutions above, the workstation in this situation does not actually run Heritage, but instead uses a web browser such as Internet Explorer or Netscape. The search interface is very similar to that of the standard Heritage OPAC and includes the option of providing reader information and reservations.

It is usual to set up Heritage Online module to use the same live data that is used by the library for its day-to-day operations. However, it is also permissible to set up the system so that a copy of this data is used either for security or other reasons. In either case sufficient user licences must be purchased to cover the expected number of users carrying out searches concurrently.

Heritage Online can be used for both internal (Intranet) and external (Internet) purposes. In the latter case it is necessary to have a permanent link from the Heritage Online server to the external network. Such a link would typically be a leased line such as a Megastream or possibly using ASDL linking into an Internet Service Provider (ISP). If a leased link to the Internet is available then it is possible to make your catalogue available to be searched by anyone with Internet access.

Z39.50 is a standard that has been developed to allow one or more library catalogues to be searched simultaneously using a single piece of search software. This searching is typically carried out across the Internet. The user can specify which library catalogues they wish to search and the results of the search are retrieved from all the different sources and collated into one list.

There are two elements to Z39.50: the client and the server. Each library that wishes to publish its catalogue must have the Z39.50 server running. Any end user wishing to search various catalogues must then run a client and tell it where to find the various catalogues that they wish to search.

Thin Clients (Terminal Services)

A thin client allows all of Heritage to be run from a shared central location over low bandwidth connections such as a kilostream leased line, broadband or even a modem. The term used by Microsoft to describe thin client technology is Terminal Services. It is similar to Heritage Online in that Heritage actually runs on a central server computer, but rather than using a web browser, a small piece of viewer software (or thin client) is run on the user’s workstation. However, unlike the fairly demanding machine requirements of web browser software the thin client technology can be used with relatively low specification client computers as it is the power of the central server that really matters.

Terminal Services are available for running Windows applications in Windows 2000 or 2003. The client machine must be running Windows 98, 2000 or XP.

In some cases it may be desirable to load an additional piece of software called Citrix Metaframe on top of Windows Terminal Server. The main reasons for using Metaframe are to provide a clearer interface for the user, improved management functionality such as printing, and managing systems with large numbers of concurrent users e.g. over 50. However, Metaframe does add significantly to the cost of installing Terminal Services.

It is possible to run all of Heritage using Terminal Services although there are some important provisions which apply to any Terminal Services implementation. Any images e.g. photographs attached to catalogue records, must be transferred in their entirety from the server to the client. Thus it is good practice to avoid large images being sent across the network e.g. by attaching then to catalogue records. Similarly, whilst it is not only possible, but relatively fast, to produce reports on large amounts of data from a remote location, if this results in a long report then printing will be slow at a remote site.

It is recommended that Windows based client machines for use with Terminal Services are suitable for running Windows 98 or later with a modern web-browser.such as Internet Explorer 6. They should provide a display size of at least 800x600 pixels and 64k colours or better. The speed of the network connection required from the client machine to the server will depend on the workload. For a single client somewhere in the region of 8kbytes per second should be allowed, but this reduces to nearer 2kbytes per second per client for over 10 workstations sharing a connection. The latency of the connection is important too, as too long a delay in gaining a response from the server can make the system difficult to use. It is recommended that latency should be of the order of 20ms, although up to 50ms is probably still usable for non-intensive operations.

The server specification is the most important element of a thin client installation. The final specification required for any installation will depend on the number of simultaneous users and their level of usage. For all but the smallest implementations (say, up to five users), a Xeon IV processor is recommended with 1G of RAM. The minimum RAM should be 512M with a further 16M allowed per concurrent user. A Xeon IV 2.8GHz system should be able to support in excess of 20 Terminal Services users.

Every client that will access Terminal Services must have a separate Microsoft client access licence as these licences are not counted as concurrent users. This is similar to the method of licensing that Microsoft applies to Windows 2000 or 2003 server editions.

A number of websites will give the cost for current pricing information although many institutions may already have special purchase agreements in place for Microsoft software.

Testing your network

IS Oxford has available a simple program for testing the performance of your network. Please contact us for further details.