By David Zinman

A problem that often occurs in any software system is related to resource constraints or limitations; how do you make the best use of the resources that you have? This article will examine the challenge of designing a functional web user interface utilizing light server processing.

Modern hardware that handles copious amounts of sensitive data requires faultless processing, uninterruptible operation, and ease of use. The term ‘ease of use’ implies a user interface of some sort, in this case a web GUI. However, a highly interactive web interface can have an impact on the operation of the hardware if general processing is interrupted in order to handle user interface requests. In environments such as HTML: java script(.js), active server pages (.asp), or proprietary GUI development in C++, C# or Visual Basic, how do we maximize user interface functionality while minimizing processing on the server?

Maximize Client Processing

One solution is to limit the amount of processing on the data server that is devoted to the user interface. This may or may not be used with a third party user interface proxy server (UIPS) depending on the environment. A system that expects few concurrent users (typically 5 or less) can operate as:

UI client <--> data server

where there is not a huge demand on the processor.

A system that demands more concurrent users (6 or more) can benefit from a third party UI server operating as:

UI client <--> UIPS <--> data server

that will offload more processing power to the user interface proxy server.

Data Processing in the GUI

Giving some thought as to defining the structure of the data can be very significant in efficient data handling. Web Service Definition Language (WSDL) for SOAP, Management Information Base (MIB) for SNMP or other data syntax design for generic or specific data driven protocols should be given a high priority to assure non-redundant, efficient and light but complete coverage of information. Both the server and the web client will use the same data syntax for their respective communication layers, and as such, a data format that integrates to the system in an efficient way must be chosen.

One of the biggest burdens that is dumped on the server by data acquisition is table processing, especially large two dimensional lists. To alleviate as much overhead as possible make sure any sorting routines are carried out on the client. Table indexing in the data definition can be a big help in facilitating efficient data access.

Scripting languages can be slow and cumbersome. If possible, there should be no scripting engine residing on the server. The data is to be served in as raw a form as possible and all scripting should be carried out by the client.

Statistical data can pose a problem. Multiple server access for several statistics can put a heavy load on the server. Polling intervals should be set for a span that reports relevant information but does not overload the server.

Tradeoffs

These solutions do not come without a price. No server side scripting puts an extra effort on client development. Often the question of adding more data to a network request or supporting functionality on the server must be decided. The GUI itself must handle many of the routines easily handled on the server. This in turn can make the GUI slow and cumbersome. Consequently expert and efficient programming methods will help alleviate this issue.