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.