Client-Server Technical Architecture
Incrementally Entering and Browsing Large Datasets with a Thin Client (1998 version)
Ward Cunningham (Cunningham & Cunningham)
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.
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.