4.6 Client/Server Applications - Myths, Legends and Expectations

While the concept of client/server applications is no longer new, there is still a high level of unreal expectation from these applications. To avoid becoming a failed client/server statistic, it is recommended that you always keep, in the back of your mind, 3 of the greater myths of the 20th century:

• The cheque/check is in the mail.

• You can build a really effective and fast client/server based EIS over your existing 15 year old database simply by buying a generic EIS tool.

• That twinax and LAN attached communications subsystems have net data throughput rates close to that of channel/bus attached hard disk drives.

The last two points need some elaboration:

EIS (Executive Information Systems)

Everybody has seen the demonstration. The executive clicks on an icon and 2 seconds later a pan-dimensional chart of product sales, grouped by category, is shown, year to date, for the last 25 years. The graph is then used at the next board meeting and the executive receives much acclaim.

While every MIS department would like to provide this type of facility to their executives, without understanding and planning for some of the basic EIS requirements it will remain exactly what it is, a fairy story.

Unless you have planned, architected and designed EIS information into your database you will not be able to create results like this within reasonable time frames.

In other words, the previously mentioned EIS scenario may well be possible, but if you keep 300,000 rows of product line item information it may well take 90 minutes to extract and summarize the information required for the pan-dimensional graph. And, even worse, if the executive does not know the significance of the "Record Deleted (Y/N)" column in the database table, all he/she may receive at the next board meeting is severe embarrassment.

Some things you may care to think about:

• EIS systems need to be planned and carefully designed.

• EIS means summaries.

• Summaries mean reading lots of rows of data.

• Reading lots of rows takes time and consumes a lot of CPU power.

• Most useful and rapid EIS systems keep "pre-summarized" data.

• The end users actually query the summary data.

• The summary data may be updated dynamically or cyclically.

• Designing and maintaining summary data means extra design and programming effort independent of any generic tool being used.

Data throughput

This is really an extension of the previous point.

Don't go into client/server with unrealistic expectations.

You may design an application that "sucks up" 6,000 table rows into a spread sheet on your PC and then summarizes and sorts them.

However, you should then ask yourself some questions like these:

• How long will it take across a twinax connection?

• What will happen to the other twinax users while this is happening?

• What will happen to my server if 40 users try to do this at the same time?

• What will happen if one user requests this every 30 seconds?

• Would using an RPC (Remote Procedure Call) to summarize the 6,000 rows on the server and then sending the summarized results back to the client be a better solution?

• Should some sort of "drill down" approach be used? Maybe then you would only have to "suck up" 100 records? How can the "drill down" approach be used with this application?

There seems to be some sort of belief in some sections of the market that client/server applications work by magic. For instance:

• Many of the old DP rules about benchmarking and load testing, etc. seem to have been lost in the scramble for client/server applications.

• The old rules still do apply. If you ignore them until your application is complete then you are taking a large risk.

• Building client/server applications and using client/server tools may place a great deal more load on your LAN and twinax communication subsystems. Can they handle this increased load?

To Summarize:

• Spend a lot of time in design

• Use virtual fields to do dynamic "joins"

• Use triggers

• Put validation rules into the Repository and I/O Modules

• Distribute load/logic across the Client and Server

• Avoid pushing too much data through communication subsystems

• Do realistic tests/benchmarks before implementation

• Note that the amount of data transferred includes not just data from the database on the Server to the Client program but also from the Client program to the UIM (User Interface Manager).
  
  This is very important and often overlooked.