In-Process REST at the BBC
Although REST is usually defined as an architectural style for distributed applications, we show how REST principles were adapted to in-process use for a feed processing application generating significant parts of the BBC Sport website and Ceefax (Videote
- PDF / 806,442 Bytes
- 17 Pages / 439 x 666 pts Page_size
- 34 Downloads / 224 Views
In-Process REST at the BBC Marcel Weiher and Craig Dowie
11.1
Introduction
In the summer of 2003, the authors were hired by BBC News Interactive as team leader and technical architect to head up the so-called Sport Stats team and improve or replace the system the team was responsible for, a feeds processing platform for transforming structured XML information of live sporting events to HTML output for the BBC website in soft1 real time. The reasons for replacing the existing system were manifold: it was quite resource intensive, effectively unmaintainable, extremely unreliable with usually several failures per day and not capable of actually keeping up with the feeds in real time, sometimes getting backlogged by several hours or failing completely. In addition the team itself, consisting primarily of junior level programmers, was shell shocked by working on a system where every code change would almost invariably lead to new failures, and of course the BBC Sports Interactive editorial team was also not happy with the services provided, and though there were requirements for new services, new sports and new output media such as the UK Teletext system Ceefax or Wireless Application Protocol (WAP) for pre-smartphone mobile phones, achieving those goals with the current system seemed impossible. In the process of replacing the system, we discovered that our design principles drove us away from the very typical enterprise architecture we had originally envisaged towards an architecture that appeared very REST-like, despite not being ∗
The bibliography that accompanies this chapter appears at the end of this volume and is also available as a free download as Back Matter on SpringerLink, with online reference linking.
1
Results degrade significantly in value if they are late, but lateness does not constitute total system failure (hard real-time) or reduce the value of results to zero (firm real-time).
M. Weiher () Metaobject Ltd., 26 York Street, London W1U 6PZ, United Kingdom e-mail: [email protected] C. Dowie Betfair, The Waterfront Winslow Road London, London W6, United Kingdom e-mail: [email protected] C. Pautasso et al. (eds.), REST: Advanced Research Topics and Practical Applications, DOI 10.1007/978-1-4614-9299-3_11, © Springer Science+Business Media New York 2014
193
194
M. Weiher and C. Dowie
distributed. As we embraced some of these REST-like qualities, our system became simpler, faster and more robust. The remainder of this chapter will describe the task to be solved, describe the original system and analyze its shortcomings (Sect. 11.2). Then we describe the overall architecture (Sect. 11.3) and implementation (Sect. 11.4) of our replacement system. After presenting the results we got in Sect. 11.5 and performing a more in-depth evaluation in Sect. 11.6. we conclude with a look at related work and a look at possible implications of our work.
11.2 The Task and Its First Solution The BBC uses feeds from different sports data providers to deliver basic sports information such as schedules,
Data Loading...
