Real-Time Sports Scores as a Service
- Defining the Problem
- Passing the Data
- The User Interface
- Analysis
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
To illustrate the power afforded by the Web services way of thinking without having to adopt cumbersome new software or standards, we will attack the plaguing problem of so many sporting events taking place with but one pair of eyes.
With only so much screen real estate, we can create a Web service to deliver real-time sports scores to users. We'll keep that service sufficiently limited because users will use their machines for other things while receiving the updates. To explain my goal with this basic framework, I will use an analogy of the "picture-in-picture" technology that has revolutionized the lives of many surfing couch potatoes.
Of course, we could use many tools in creating this application. Not surprisingly, a number of possibilities put forth by very intelligent groups of individuals are vying for adoption by some or all of the Web community. Partly because of the newness of the technologies, partly because of strengths and weaknesses of each platform, and partly because of the limits of space and time, I will not endorse one solution. Instead, I will deal with the creation of Web services using only the rudimentary tools of ASP and HTML. This is not magic; it is merely a new way of examining a common problem.
Take, for instance, the notion of a component. The component infrastructure lies at the heart of any services platform, but what constitutes a component is no longer clear. Unlike previous distinctions between executables and libraries, distinctions can be made in a Web platform among interface, middleware, and data layers, or along the lines of applications, creatable units, and scripting pages, for example. After the units are defined, a method of communication must still be chosen. Only through this lens can an ASP be defined as a component.
Defining the Problem
To get this concept of real-time sports scores off the ground, the first edition of this application will not feature any fancy performance-enhancing or browser-specific technologies. In other words, it will perform its function of providing almost live updates and not much else.
Let's start by providing the boundaries for this problem.
First, why is someone proposing this project? This will not be a consumer product, so let's assume that our initiators are employees of a major corporation intent on following the results of the office pool that they run to supplement their income. Naturally, their employer has attempted to crack down on any non–work-related activities by restricting access to a number of Web sites and not allowing even the most benign of binary data to pass through the firewall.
Next, sporting events are taking place, but the users need a source of information and a place to put it. Continuing in the simple vein, let's limit our sources to trusted people either attending or watching the game. It is the nature of Web services that components handling data receipt and components passing the data may be completely unrelated. Even with that in mind, any data provider must provide the data in a format understood by our consuming ASP. Initially, we will allow the passing of four pieces of data: the sport, the teams, the scores, and a summary of how the teams got to those scores.