No consensus on line dividing client, server; trial-and-error application partitioning leads field as vendors catch up to need

Software Magazine, June, 1993 by Paul Korzeniowski

ABSTRACT

Data integrity and network bottlenecks top performance concerns for developers as they decide where to locate application processing -- on the client or on the server. Mortgage Guaranty Insurance Corp., Milwaukee, keeps new policy data on its mainframe, but has cut mainframe usage by a third by moving the processing functions to client workstations.

Trial-and-error application partitioning leads field as vendors catch up to need

The client/server model promises to allow firms to use their computer resources more efficiently, save money by replacing expensive mainframe systems with inexpensive PCs, and more easily design applications or reports to help them complete their daily chores.

Unfortunately, technical advances typically raise new and often troublesome questions. The client/server revolution is no exception. The essence of the model -- the ability to place application functions on any computer -- is also its bane.

"Determining the best way to divide client/server applications is a major problem for many companies," said Hal Steger, director of product marketing at Uniface Corp., an Alameda, Calif., application development tool supplier.

Problems arise for many reasons. When too much data is placed on a client, limitations in desktop backup and recovery procedures can be exposed. When too little data is placed on a client, networks can grind to a halt as users ship records between clients and servers. If the application architecture builds many small transactions between the client and server, that can also generate excess network traffic.

In addition to the location of data, developers must decide where application functions execute. Putting lots of procedural code on a client might give individual users the best response, but it may be too complex from a software distribution standpoint. Storing more procedural code as triggers in a relational database is getting to be a more popular approach. However, this is sure to pose program maintenance challenges.

Often, the source of a problem comes into focus only after an application has been built. Tools to help users prevent the wasted energy are rare. Observers expect design problems to intensify during the next few years as customers combine operating systems, networks, DBMSs, tools and applications in an ever increasing variety of ways. Observers also expect the arrival of planning and modeling tools to minimize development guesswork.

While not two applications are likely to have the same dividing lines between client- and server-based functions, observers and experienced users provided some general rules of thumb for partitioning client/server applications. One obvious choice is to move user interface functions from central systems to client computers.

Once customers get beyond the offloading of presentation services to client systems, partitioning questions begin to mount. In theory, firms would like to cut costs by moving data from expensive central servers to less expensive client workstations. However, such changes raise data integrity issues, a multifaceted problem that firms have wrestled with for years.

Storing data centrally and having all users work with one copy of a database minimizes data integrity problems. A number of companies are following this course.

Mortgage Guaranty Insurance Corp., Milwaukee, for example, began to build client/server applications in 1990 to speed processing of mortgage loans. "The applications deal with new policy data, which is vital to our company," said John Seaman, director of business systems. "We felt most comfortable keeping that information in one place: our mainframe."

The company's design goal, though, was to offload as much other processing as possible to the PC. Mortgage Guaranty selected a PC-based expert system development tool from Aion Systems, Inc. as the base for the client portion of the application. (Aion has since merged with AICorp, Inc. to form Trinzic Corp., Palo Alto, Calif.) At the time, said Seaman, the product was one of few tools available that ran on IBM's OS/2 operating system. They also found the application development environment easy to use. In this way, users could get at customer records stored on the mainframe in IBM's DB2 database management system (DBMS) via LU6.2 communication.

In 1992, Mortgage Guaranty added Foundation for Cooperative Processing Version 1.0 from Andersen Consulting, Chicago, to help build its client/server applications. "When we started building the application, there were literally no tools available," noted Mortgage Guaranty's Seaman. "When the Foundation package became available, we immediately were interested. The product helped us identify probable bottle-necks before we coded the software rather than after that process was completed."

The company's original plan was to put all the expert system and data validation functions required by the application on the PCs. They anticipated needing 8Mb of RAM. The Foundation tool indicated, however, that based on the functions planned, they should have 12Mb on each client machine.