Client-Server Technical Architecture

Incrementally Entering and Browsing Large Datasets with a Thin Client (1998 version)

[ Home | Problem Collection | Results for this problem ]

Prepared by

Ward Cunningham (Cunningham & Cunningham)

Background

Design Problem

Use Cases

Background

Financial markets are an example of an environment where sharing and maintaining large sets of complex information give the holder competitive advantage. Often queries to such databases are imprecise, producing large result sets that are visually scanned. Also, changing market conditions and positions within them demand that results be kept current while they are displayed.

In one version of a "fat client" 128-megabyte workstations cache nearly all business objects in local memory. Logic in the client maintains the coherency of cached persistent data and merges it with continuous streams of market information broadcast through a private network.

One possible interpretation of a "thin" alternative architecture would be to move these caches and coherency logic to a small number of large middle-level servers. Modest client computers could "browse" these servers using software and protocols suggested by the world-wide web.

Design Problem

Imagine a financial services company that is replacing 100 fat client workstations with thousands of thin clients computers. You are to design mechanisms that allow these modestly configured machines to view and control large sets of business objects cached on several dozen large servers. It is sufficient to design the objects that will supervise the incremental transmission and update of the business objects/data as the user scrolls through a large, tabular display. You need not design the business objects themselves, or the communication protocols that will carry them over the wire. However, you should be sure that your supervising objects on either side of the connection (thin-client and mid-level server) have all of the information they need to make best use of any suitable protocols.

Note that the web’s hypertext transfer protocol (http) would not be sufficient for this application without extension or augmentation since it doesn’t allow for the integration of real-time updates. Such data feeds are usually distributed by subscription to a broadcast server. Your design could consider having either the mid-level servers subscribe to relevant broadcasts or leave that to the thin clients. Either way you will have to reconcile the incremental transmission of data with it’s asynchronous revision.

Use Cases

Case 1:

A user opens a window viewing the first sixty of several thousand cached rows. After immediately recognizing that this isn’t the desired data the user then closes the window to look elsewhere.

Case 2:

A user opens a window viewing the first sixty of several thousand cached rows. He then scrolls the window to the desired records and then monitors real-time updates to several columns until the market closes an hour later.

Case 3:

A user opens a window viewing the first sixty of several thousand cached rows. He then scrolls through all thousand records looking for improperly entered fields and corrects them.

Case 4:

A user opens a window viewing the first sixty of several thousand cached rows. He clicks on the third column to request an ascending sort on its current contents. He then scrolls directly to the bottom of the table to see which rows have the largest values.

Last updated by Torsten Layda, SWX Swiss Exchange, DesignFest^® Webmaster.