- 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
Passing the Data
For the first iteration, we will simply create a query string format that allows our remote data sources to pass basic information as follows:
http://[server page]?sport=baseball&team1=seattle%20Mariners&team2=Texas%20Rangers&mode=add
A mode variable is an ugly but common way of signaling to an ASP the type of transaction that the user wants to conduct. In this case, the user wants to begin supplying data by adding the game to the list of games tracked by the service. The first target for extending this example will be to capitalize on a more rigorous data format. Having said that, once the game begins, the data provider can update the scores from the initial 0–0 tie with the following submission:
http://url?sport=baseball&team=Texas%20Rangers&score=1
&description=Alex%Rodriguez%20hit%20by%20pitch%20advancing%20runners&mode=update
If we are to keep this booking operation below the corporate radar, data storage must be extremely limited. In a stroke of luck (or planning or antitrust violation—take your pick), Microsoft Active Data Objects (ADOs) are present on all NT servers. Two features of ADO make it especially important here. First, as a suite of COM objects, all database connections, record sets, and records can be easily constructed from within an ASP. Second, ADO has the overdue capability to treat a flat file as structured data. For those of you working in a Unix environment, just substitute the Perl MySQL API.
So, our back end consists of a single ASP responsible for adding, updating, and reporting sports scores stored within a flat file that a FileSystemObject will happily create for you if it does not already exist. It will accept five modes of request (add, update, report, end, and list) and will reside on a single Web server within the corporate farm.