5. Service Strategy

5.1 EDINA Team Structure

During 2008/2009 EDINA succeeded as an organisation geared to the delivery of high-quality online services. The operation of EDINA national services was undertaken by the appropriate team identified in EDINA's structure of management and operation:

Table 1: EDINA Team Structure

User Support (Helpdesk, Advisory, Outreach, Documentation & Training)	Support to users and their support staff, and feedback to the service delivery teams: promoting the EDINA services; providing a helpdesk and allied activities; learning from, and addressing the needs of, academic support staff and end users, through high-quality training, online documentation and presence at key conferences and events.
Service Delivery (Bibliographic and Multimedia Services; Geodata Services; Learning and Teaching)	Delivery of online services: developing, implementing and maintaining effective online data services, including the design and implementation of customised client software, server functionality and databases, and ensuring regular data updates.
IT Technical Infrastructure	Management of the IT platform: reliable and sufficient support of online services; planning and maintaining the underlying software and hardware platforms; network connections; effective liaison with the IT Infrastructure Division (within the University of Edinburgh's Information Services); specialist programming support as required.*
Business Development and Administrative Support	Business, projects and administration: co-ordination, facilitation and provision of administrative support; seeking out and evaluating new opportunities for collection and development; providing an overview of all project work.

*The IT Infrastructure Division provided EDINA with support in the installation, operation and maintenance of the hardware and operating system components of multiple SUN servers, the UNIX computing platforms used to host the EDINA services, and the connection to the Internet.

5.2 Technology

Software

EDINA has used both commercial and open-source solutions, with three purposes in mind: to host and manage content, to deliver services across the Web and to facilitate interoperability.

Commercial products used for hosting services included Laser-Scan, SAFE FME Software, Snowflake, ExLibris Aleph 500, Intrallect's intraLibrary, Oracle and Ingres. Laser-Scan was used for data processing and map generation. SAFE and Snowflake were used for data translation, formatting and data delivery. Aleph 500 was used to ingest and display data from contributing libraries to SUNCAT. IntraLibrary underpinned the delivery of Jorum. Oracle, Postgres and Ingres were relational database management systems used in the delivery of geospatial data, with Oracle also being used to support SUNCAT.

Use of the LaserScan software, which has underpinned the Digimap Service since 2000, ceased in September 2009 being replaced by Cadcorp software obtained through open procurement. While the OS collection has been migrated to use the Cadcorp software, with many benefits as a result, it will take another 12 months to migrate the other Digimap Collections to the new map production system. One consequence of the move to Cadcorp was the decision to replace Ingres by Postgres, an open source DBMS, for holding the geospatial data. The Postgres architecture is better suited for the service use required by Digimap.

Other open source software used by EDINA included Open SiteSearch, Apache::ASP, DSpace, ePrints, Zebra, PEARS, Solr, MySQL, Postgres, GeoServer and MapServer. Open SiteSearch and Apache::ASP were used for web application development (presentation layer, session management, database clients); DSpace and ePrints were used for repository applications; Zebra and PEARS were used for specialised text indexing and retrieval purposes; Solr, a search server built using Apache Lucene, was used for services in the multimedia and learning and teaching areas; and MySQL and Postgres were used where relational databases were required. In many instances the reliability and support offered for these products exceeded that of similar commercial products.

Apache was used as the World Wide Web server, sometimes in combination with Jakarta Tomcat, mod_perl or Apache::ASP. Perl and Java (mainly server-side) were used extensively for data processing, infrastructure services (interoperability), and in the implementation of user interfaces. Shibboleth is used for access management for those services that require it.

EDINA has implemented various established standards for interoperability in services and projects, including Z39.50, SRU/W, OpenURL and OAI/PMH. Z39.50 and SRU/W provided search and retrieval of metadata across bibliographic and multimedia services, and were very heavily used for federated searching. OpenURL provided context-sensitive linking from bibliographic services, and was heavily used for linking to institutional OpenURL resolvers (link servers). OAI/PMH provided metadata harvesting.

Web Services and RESTful services were used during project development, including the VSM portal and the HILT project, as a solution for interoperability requirements and were used in services, e.g. Digimap, UKBORDERS and Go-Geo! In the wider geospatial community, the Open Geospatial Consortium (OGC) is at the forefront of developing and promoting open standards for the exchange, discovery, exploitation and rights management of geographic information. These subsequently become ISO standards. EDINA has been an associate member of the OGC for several years, and is actively engaged in implementing OGC interoperability standards as well as contributing to the development of new standards or profiles of existing standards. (For example, staff within the geo-services team have been working with the leader of the OGC Security Working Group on an architecture for securing OGC Web Services using Shibboleth and GeoXACML.) One of the interesting challenges has been the integration of these standards with the others promoted and used within the JISC IIE and e-Infrastructure. However, by deploying services using these standards, EDINA will be in a position for these services to become components of the evolving UK spatial data infrastructure.

EDINA began looking at newer technologies including ontologies, knowledge-based infrastructures, and the use of third party APIs provided by the likes of Google and Geonames. Use of third party APIs allowed EDINA to exploit services whose content is global compared to the UK focus of most of the collections hosted by EDINA. As an example, the geoparser, part of GeoCrossWalk was upgraded to use georeference documents with place references outside of the UK, leveraging the Geonames API for geo-coding.

For internal services, flexibility and ease of maintenance are primary considerations. The EDINA helpdesk/licence maintenance system Helios was therefore re-implemented in a Windows VM environment, replacing CGI scripts by Cold Fusion as the application server with Microsoft's SQL-Server replacing Ingres for the database.

Hardware

EDINA has been carrying out a hardware replacement program funded by the JISC capital programme. Sun Fujitsu Sparc 64 servers were purchased to replace the existing Sun Enterprise servers which were purchased in 2003. The migration of Digimap to new hardware has largely been completed and migration of Bibliographic/Multimedia services is ongoing. New SAN based storage was purchased to replace older storage arrays and locally attached storage. Migration of service data to this new storage has largely been completed.

This hardware replacement has resulted in significant performance gains and increased resilience. Annual maintenance costs have also been reduced. Further capital spend to improve resilience is scheduled in the coming year.

JISC have also funded a separate EDINA development environment. This is being used along with Solaris container technology to cleanly separate development and service activity. This approach was used successfully for recent service development and also for the Digimap annual data load.

There has also been a move over the year to adopt virtualisation under VMWare, principally to support non-Solaris operating systems. This has currently been utilised for development and local EDINA projects but should become a fully supported enterprise environment next year.