Building on BUILDER

Developing the Builder Products: Infrastructure

The project plan detailed a number of different products, or technology demonstrators, that BUILDER would develop as part of its researches into an ‘institutional hybrid library’. Initially each of these products was seen as a separate development having a unique set of needs and technological problems to solve. This view soon changed! As we started to look at implementation common strands started to appear. These strands included: authentication, profiled interfaces, secure delivery of files (Adobe Acrobat documents for example) and communication with databases.

With hindsight BUILDER has not so much produced a number of separate ‘products’ but rather developed a rich environment in which ‘web applications’ can be created. This environment contains many of the common elements required to host web based hybrid library services with facilities such as ‘authentication’ being simply ‘available for use’.

Using What Is Available (part one)

It was clear that many BUILDER hybrid library products would be data driven. Initially we imagined BUILDER creating, housing and being responsible for large amounts of data. This belief was so strong that end we even went so far as to set up an SQL Database server to meet our perceived data management needs.

As we got deeper into the project it became clear that we did not necessarily have to store the data. Much of the data we needed already existed in other institutional systems, the Library Management system for example. We also became aware of other ways of generating data - using search engine technology to create journal indexes for example.

An early project decision was to attempt connect and use data in existing systems rather than duplicate and modify existing datasets ourselves. This, initially, was a hard decision to take. Connecting to someone else’s data-set entails far more effort than ‘knocking up’ our own demonstration database. That said, we believe we made the right decision. Using BUILDER infrastructure as glue, joining and integrating information from other sources, rather than using BUILDER as a data source in its own right has paid dividends both in the experiences gained and the potential for scaling.

And what happened to our SQL server? We have not used it. Three years on we have found we can meet all our data needs by tapping into existing datasets and using harvester software.

Iterative Methodology

BUILDER has employed an iterative methodology. Rather than spending time developing a paper specification and defining the final product ‘on paper’ and before any code commences, BUILDER would create something quickly and show it to the customers. This initial demonstrator may not be fully functional or completely polished but would be sufficiently developed for people to look at and, more importantly, comment on. We would follow a process of consultation, development and user feedback. We would then repeat this process as many times as necessary. As the project progressed the development would become more solid to the point where it became releasable as a public demonstrator (or in some cases even a service in its own right).

This iterative approach has enabled BUILDER to create demonstrators relatively quickly. Our products have benefited from lots of user feedback which, we believe, are more focused and useable products through the use of this approach.

To be fair, the BUILDER products have complimented this approach being small and relatively well defined. Not all applications would fit this criteria where a full specification is an essential tool. That said, the approach has worked for BUILDER and arguably would have a place in institutional developments of similar scope.

Using What Is Available (part two)

Project member experience dictated that BUILDER would be developed using Microsoft Technology. We have had lots of previous experience with this platform and felt confident we could develop BUILDER products using it. Using the Windows NT platform and the Internet Information Server (IIS) provided much of the functionality we as a project required (for more details on the technology we have used see ‘BUILDER Architecture’ below). The IIS environment is relatively easy to set-up and is quite extensible.

The project did look at alternative platforms - Linux in particular - but given our tight schedule and limited experience with the platform it soon became clear we would not be able to consider seriously developing on Linux. Our central computing services were not to happy with us playing with Linux either. As inexperienced users we apparently could create all sorts of gateways into the campus. Given these issues, Linux was felt inappropriate for the needs of our project.

There is a lot of free software components available for IIS. You can also develop your own using Visual Basic, C++ and Java. We spent time looking at what was available for free and the potential of writing our own. Both were rejected. Using free and existing code modules, crafting these to meet our needs cost a lot of time and resource. In the end it turned out to be cheaper to simply purchase a professional ‘sixty dollar’ IIS component than spending a week constructing a similarly functional unit using ‘free software’ on our own.

We learned a lot from the sixty dollar component experience. since then the project has always looked to use ‘off the peg’ where possible. The most costly and scarce resource we had to hand was staff time.

Lessons Learned

Looking back at the project there are things that have worked well and things that have not worked so well. Some of these are described below:

Off the peg solutions

Windows NT and IIS provides a lot of the functionality required ‘out of the box’. It is possible to extend the already rich functionality by purchasing components. BUILDER comprises a virtually vanilla IIS installation coupled with two purchased components. This infrastructure has proved both robust and transferable. At its peak, our Exam Paper Database product delivered 2500 Adobe Acrobat papers in a day (most over lunchtime). Even under this extreme pressure the service was robust. Both the University of Birmingham (through the Academic Office) and the University of Oxford (through the OXAM service) have implemented the BUILDER solution. Transferring and adapting the technology in both these cases has proved straightforward.

Iterative development

An iterative development methodology has worked for BUILDER. We have produced focused and useable products swiftly and effectively. We would argue that typical BUILDER scale web applications benefit from this approach. An interesting issue is now we are scaling there is a clear resistance to an iterative approach. Iterative is felt OK for ‘a project’ but a ‘proper service’ needs to be specified!

Using the simple solution

BUILDER has always attempted to find the simple solution. If there is an easy way of doing it we have attempted to do it that way. We have also been fairly ruthless about the scope of our projects. When brainstorming it is often easy to over-specify and get hooked into ‘special cases’. The iterative approach has allowed us to develop the obvious first and address special case issues ‘in the next release’. Our experience has shown that often perceived ‘issues’ disappear when confronted with a live and kicking iteration one product. Often implementing 10% of the grand scheme will satisfy 90% of our users needs!

Hybrid products flourish in a rich environment

In any hybrid library provision of a rich, available, infrastructure is essential. The BUILDER environment is rich and has allowed the easy development of hybrid library products. The issues we are facing now with scaling is the big institutional web servers are Unix and designed for static page serving. Although there are moves to provide richer interactive web spaces these do not exist now and will need investment to provide.

Skills

Although our BUILDER environment is a relatively straightforward arena, given the sophistication of what is achievable, it still requires appropriately skilled staff to work with. The role of the hybrid library technologist is not one readily found amongst traditional computing or library staff. If the University of Birmingham wanted to exploit BUILDER developments it would need to find or develop appropriately skilled staff - and that costs money.

Product Showcase

The Hybrid Library Demonstrator

So far this paper has talked about BUILDER as a collection of ‘products’. The project has always been tasked with creating a demonstrator of the Hybrid Library. The BUILDER Hybrid Library Demonstrator uses the experiences and techniques developed through the BUILDER technology demonstrator products to present a possible view of an institutional hybrid library. The library can be experienced as a number of different users: a fresher, a final year student, a medical student, a lecturer and a mature student.

The Hybrid Library can be found on: http://www.builder.bham.ac.uk/hld

Metadata Index

Built on the BUILDER developed Talis Toolbox, the Metadata Index looks to provide centrally stored and administered ‘subject resource lists’. Currently students are presented with all sorts of lists from all sorts of sources, subject librarians and tutors alike. Typically these resources will be presented on a web page, useful stuff for your course etc. There are many such pages and lots of duplication. Maintaining these resources takes a huge effort.

The Metadata Index provides a single collaborative application that uses and enhances actual catalogue records to provide subject resource lists. Subject librarians can identify and ‘mark-up’ useful resources. The index can then output suitable ‘lists’ for dynamic rendering into a number of applications. Our demonstrator includes a ‘select your department’ list and examples of a library resources page and an academic course support page. The big issue here is the data is all coming from the same central ‘expert’ resource. As resources change all the pages containing lists automatically reflect this.

The Metadata Index along with supporting documentation can be found on: http://builder.bham.ac.uk/mdi

More information on how we have extended the library Management System can be found on: http://builder.bham.ac.uk/ttd

Builder Architecture

The infrastructure that BUILDER has developed products is seen as key to the project. This technical section describes the BUILDER Infrastructure.

Hardware

BUILDER lives on a dedicated server box. This box was purchased at the beginning of the project and represents a medium powered server of the time. The server comprises an Intel Pentium II 233 processor, 128mb memory and two 4gb SCSI drives mirrored to yield 4gb of storage. The box has a DAT tape and uninterruptible power supply (UPS) to enable a clean shutdown in the event of power failure.

By today’s standards this box is obsolete. That said it still continues to serve us well. If we were to specify a server today we would consider spending around the same amount of money (in the order of £2000) which would buy us a similarly specified box but with a more powerful processor (probably an Intel Pentium III 750) and more memory (ideally 512mb). Improvements here would provide a box that was more robust under load and scale to serve an institutional user base.

Software

BUILDER is Microsoft Windows NT based. As well as the basic operating system we have added the NT Option Pack, which provides Internet Information Server 4.0 (IIS) and have applied Service Pack Six.

Again this system serves us well but if we were to develop a new server today we would specify Windows 2000 server which includes IIS 5.0 We would also apply Service Pack One. This new system provides a richer web serving environment with IIS 5.0 which includes more ‘objects’ (see below) that can provide additional functionality.

Environment

IIS provides an environment called ASP. As well as being able to serve traditional pages, ASP can support a number of scripting languages including VBScript, JScript, Perl and Python. The environment also contains a number of instantiatable objects that can provide functionality accessible through script control. Objects include: Session (for tracking and associating variables with a user on a trip through a web site) and database connectivity (enabling access to any ODBC compliant data sources).

BUILDER has also purchased two ServerObjects components that provide HTTP functionality and SOCKET functionality. For more details of ServerObjects components check out: http://www.serverobjects.com

Author Details