DesignFest'98 – A Thin Client Solution

Participants

Yping Guan, Arthur Young, Michael Dugan, Ben Lieberman, Preston Appel, Paula Matuszek, Danial Meyer, Ramesh Peri

Agenda

  • Determine Scope
  • Define Problem
  • Define Use Cases
  • Complete Object Model, Design Model

Problem Analysis

  • Excess client data retrieval (fat client) – Performance Issue
  • Limited Business Rule Reuse – Extensability
  • Cost of Deployment
  • Client data corruption – Concurrency Management
  • No Direct Cross-Client communication
  • Limited Scaleability
  • Large Bandwith Utilization
  • Extend and Adapt for different Communication Protocols
Of these issue only the following were determined to be inscope for this exercise:
  • Client Data Consistency / Concurrency – Data accuracy and timely refresh paramount
  • Data Handling and Control – Control of data flow to reduce client complexity
The following assumptions were made:
  • Large bandwith available

Assumptions

  • Clients will access a mid-level server to obtain all data (no direct data feed)
  • Clients will access only one server to gain information
  • Servers can obtain data from multiple datastores (external data source)
  • Clients will only view a portion of the total dataset at one time (e.g. screenfull)
  • Server (mid-tier) updates from external data source
  • Communication conduit exists from the Client to the Server (e.g. ethernet)

User Task Diagram

Data Flow Diagram

USER Task #1 – View Data USER Task #2 – Scroll Data
USER Task #2a – Refresh View USER Task #3 – Update Server Data
USER Task #4 – Sort View

The above flow diagrams show the desired client functionality for viewing a subset of the data (a to-be-determined amount of data, open issue). The Broadcast function is expected to be via an Observer Pattern combined with a Proxy pattern for communications between Client and Server. The Observer Pattern is used twice, once for the external datasource to announce updates to the Server side CacheManager (although this maybe out of scope), and once to update the ClientManager to changes that have occurred to the CacheManagers held data. The primary idea is to maintain a collection of caches on the CacheManager (implemented onto a server connected to the external data feed) for each Client. These caches may be implemented as indexes into a primary cache to conserve memory space (as opposed to multiple caches, one for each client). The indexes will allow each client to maintain a specific order to the data in the collection (see the last user task – Sort). The update function is not well defined and in fact may not need to have any kind of locking (if collisions occur the last to update wins). The broadcast mechanism will ensure that all clients are informed of a datachange and will order a refresh of the current view.

The Proxy pattern is used to encapsulate the communications path between the client and the server; this needs to support the correct communications protocol (out of scope for this design). We assume a mechanism to broadcast and receive messages between the server and client platforms.

Class diagrams are provided on a separate sheet.

Open Issues

  1. Amount of data to be retrieved on each call
  2. Communications Protocols supported
  3. Concurrency Locking scheme (optomestic/pessemistic)