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

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.

Mortgage Guaranty completed its client/server applications in May 1992. The software handles 250 users in 20 remote offices and walks them through the steps needed to write new policies and ship the data to the mainframe. It lets the PC perform housekeeping functions -- such as issuing new policies. IBM's DB2 operates as a central file server to workstations running OS/2 on IBM Token-Ring local-area networks (LANs) with IBM's LAN Server operating system.

By moving the processing functions to the client workstations, Mortgage Guaranty cut its mainframe usage by one-third. In addition, features such as walking users through the write-up process were previously unavailable and would have been difficult to build on a mainframe. "To run the applications on a mainframe, we would have had to double or triple our processing power," Seaman said.

DEALING WITH DATA INTEGRITY

Companies have other ways to deal with data integrity issues. Firms can limit user functions to reading but not updating data. This is common in Decision Support System (DSS) and Executive Information System (EIS) applications.

Navistar International Transportation Corp. of Oak Park, Ill., for example, built a complex DSS application for a handful of managers at the end of 1992, which took three months to create. (See Software Magazine, May 1993, p. 77). Jay Yusko, manager of systems integration at Navistar, said that the application does nightly extracts of financial, marketing and sales data stored in DB2 and IMS DBMSs, as well as in Vsam files on an IBM 3090 mainframe. The extracted information is then downloaded to an Informix DBMS from Informix Software, Inc., Menlo Park, Calif., running on a Sparc-station from Sun Microsystems, Inc., Mountain View, Calif.

Users outfitted with PCs running Windows from Microsoft Corp., Redmond, Wash., can pull desired information out of the Informix DBMS and load it onto their PCs. Managers use the Natural Language query language from Berkeley, Calif.-based Natural Language, Inc. (NLI) to perform ad hoc queries. Intelligent Query from IQ Software Corp., Norcross, Ga., is used to produce reports.

Yusko said dividing up the various processing functions was simple. Early on, Navistar decided to continue storing the data on its mainframe. "The extracted data is critical to many departments, so issues such as security and backup were major concerns," he explained. "We felt comfortable with mainframe features and found that PCs do not yet offer the same comfort level."

The company chose the Informix DBMS and Sparcstation because of large extracts. "The application generates 180,000 records and some tables can be 1 million characters long," Yusko noted. "We did not think that PCs were capable of crunching such large amounts of [data] so we opted for a Unix system."

When end users have direct access to data, various types of performance issues can arise. In some cases, novice users may construct incorrect or incomplete queries. Shipping data in response to a query across the network, only to have it returned with an error message, wastes precious network bandwidth.

Clever companies can solve that problem. Brewers Retail Inc. of Mississauga, Ontario, designed an EIS application that lets managers pull sales and marketing information from a Sybase DBMS from Sybase, Inc., Emeryville, Calif. After executives construct queries on PCs, the client software validates each query before shipping it to the server.

"We wanted to make sure we transmitted only necessary information over our network," noted Pompi Malik, manager of information technology at Brewers Retail. "So we added logic that examines each query and follows various rules to determine how well it was constructed. If there is an error, the user corrects it on the client rather than at the server."

U.S. Intelco Networks, Inc. of Olympia, Wash., offered a second reason why such checking should take place on the client system. To save money, the firm started moving new application development from its IBM 3090 mainframe to LANs two years ago, said Rik Brooks, a senior programmer/analyst.

U.S. Intelco Networks built a telephone billing application that connects 120 PC users with Microsoft Windows to Sybase's SQL Server running on a Sun Sparcstation. U.S. Intelco Networks' users can construct a wide range of queries. One consists of 512 different structured query language (SQL) statements. "We estimated that more than 45 minutes would be needed to execute that query on a PC," Brooks stated. "So we moved that function from the client to the server."

USING STORED PROCEDURES

To speed server processing, U.S. Intelco Networks used Sybase's stored procedure function for the long query. A stored procedure is a commonly used query that is constructed and stored on a server. Rather than building and checking the query each time it arrives at the server, the server pulls out the procedure and completes a canned set of steps, thus saving processing time.

Once a rare capability, stored procedures are becoming a common DBMS function. But the emerging capability raises an interesting question: When is it desirable to put query functions on a server and when should they run on a client workstation? No clear-cut answer is at hand.

Even the Brewers Retail and U.S. Intelco Networks examples could potentially create problems. Each time users ship data in response to queries from client stations to servers, they use up part of the available network bandwidth. If users constantly generate complex queries and ship them back and forth to a server, the network could become a bottleneck.

"In many cases, desktop computers generate information faster than networks can move it," noted Hans Galldin, the Ottawa-based marketing director of distributed network computing for Cognos Corp., an application development tool supplier headquartered in Burlington, Mass.

Pinpointing network bottlenecks is difficult. In a common scenario, a user ships data to a server that uses a leased line and modem to send information to a front-end processor that ships the data to a mainframe. Any of these components could be the source of the bottleneck. "Networks are growing in size and complexity, so identifying problems is becoming more of a problem," noted Uniface's Steger.

The complexity of building client/server applications increases exponentially when firms decide to distribute data. Of chief concern is ensuring that distributed data remains in synch throughout the system. Distributed DBMSs, such as Informix's Informix; Sybase's Sybase; Ingres from Ingres Corp., Alameda, Calif.; and Oracle from Oracle Corp., Redwood Shores, Calif., include data integrity features. For instance, two-phase commit ensures that data is not changed in one DBMS unless it is altered in the second.

However, developers have not widely implemented two-phase commit protocols, according to research done by suppliers, including Sybase. In response, as an option to its System 10 release, Sybase recently announced the Replication Server, which enhances the ability of multiple SQL Server databases to stay synchronized.

When firms decide to distribute data to client workstations, they often use these products. "Sixty percent of our customers' client/server development is done with a distributed DBMS," said Uniface's Steger.

"When first examining client/server possibilities, users want to build 'fat' client applications" -- meaning more processing is assigned to the client than to the server -- noted Cognos' Galldin. This can require a hardware investment. For example, in building its application, Mortgage Guaranty had to outfit its users with Intel Corp. 80386-based PCs with 12Mb of RAM. "The initial investment was substantial, but we had to make sure that the PCs were powerful enough to run the application," Seaman said.

Support for an application built with components from multiple vendors is also a serious challenge. The Salt Lake City government has begun rewriting mainframe employee tracking and financial applications to operate on LANs with either Unix servers or PCs running Microsoft Windows and NetWare, from Novell, Inc., Provo, Utah.

"In building a PC client/server application, a user has to take software products from various suppliers and fit them together," said Michael Freeland, a software engineering manager for the city. "When problems arise, the vendors start pointing fingers, so pinpointing the source of the problem can be frustrating."

This was one reason Mortgage Guaranty selected almost all IBM equipment for its client/server applications. "We wanted to keep vendor issues to a minimum," said the company's Seaman. "When a problem arises, we know who to call."

TRIAL-AND-ERROR DESIGN

When faced with this dizzying array of often-conflicting issues, corporations typically move on a trial-and-error basis to determine how applications should be designed. Many companies build prototypes and observe how they function. They are often surprised at where problems crop up.

When U.S. Intelco Networks delivered the first release of its telephone billing application, it took 10 to 12 minutes to generate one report "The programmer who designed the application had a number of misconceptions about how Windows operated," said the firm's Brooks. "He kept loading the

application in and out of memory when he didn't have to. We made a few changes and cut the time down to eight to 10 seconds."

Common stereotypes can also prevent firms from taking full advantage of client/server functions. "When building their first client/server application, mainframe developers try to do a simple face-lift: They add a GUI [graphical user interface] but leave everything else the same," said Mortgage Guaranty's Seaman. "These programmers don't trust PCs and think they [PCs] cannot perform complicated functions. But the opposite is true; we have found them to be suited to complex tasks."

Malik at Brewers Retail commented that no programming tool is suited to every application. "Vendors design their products to address one type of client/server application, so corporations may have to work with a number of different tools." Brewers Retail has used three tools for its client/server applications: NLI's Natural Language, PowerBuilder from Powersoft Corp., Burlington, Mass., and Uniface's Uniface.

Intellicorp of Mountain View, Calif., recently announced Kappa CommManager 1.0, which is meant to be used with its Kappa 3.0 object-oriented development tool. CommManager is said to allow a developer to build the user interface, application logic and database interface on one platform, then split up the components as appropriate without having to redesign the application. The 1.0 release allows communication between applications built with ProKappa 2.1 on Microsoft Windows PCs. The company said the next release will let Kappa applications refer to MVS/CICS services via object message passing. After beta testing this spring, the 1.0 release was scheduled for delivery in March.

The company positions its products as a new generation of computer-aided software engineering (Case) tools. "Traditional Case has failed. Some customers spend years in analysis and have nothing to show for it," said Gary Fine, director of product development. The Kappa tool can read in entities and relations from the ADW tool of KnowledgeWare, Inc., Atlanta, but not data flow diagrams, Fine said.

DATA MODEL, THEN PROTOTYPE

The question of whether client/server development, and the correct partitioning of applications, requires rewriting the book on application development methods is being hotly debated today.

Gary Ahwah, manager of advanced technology support for Disney Worldwide Services, Inc., Burbank, Calif., has concluded after moving down the path of client/server development that, "You still have to do requirement analysis and design. We demand that all client/server applications go through rigorous design and analysis before the developer builds the applications."

He noted, however, that "Client/server development is not yet fully supported by Case. The methodology does not accommodate GUI design, application partitioning and object-oriented programming. You must put together your best guess, and allow that you may have to build your application more than once." This will happen if a data model changes. "If we trash a database design, we trash code on the client," he said.

The Disney developers in Burbank use data modeling tools from Bachman Information Systems, Inc., Burlington, Mass., before any coding is done. Ahwah said the data modeling tool is pivotal toward development of a correct database update strategy, which is key to enforcing data integrity. "If a transaction breaks, you may need to back out data you've already committed to the database," he said. Ahwah said his developers are using Ellipse from Co-operative Solutions, San Jose, Calif., to help enforce database integrity in its "mission-critical" applications.

Ahwah has found that client/server shifts the application design burden toward the database. "Most of your processing is implemented in your database design," he said. Once the data model is 80% complete, the developers begin iterative development and rapid prototyping -- for example, using PowerBuilder. "We need a third normal database design, then we begin prototyping," he said. "We forward a logical, business-rule application design into the tool."

Ahwah recommended that developers use triggers and stored procedures in the server "to insulate from changes in the front-end tools." He suggested that client/server developers know something about database design, database modeling, GUI design and networks. "The complexity of these applications is being driven down to the developer," he said.

Disney developers also use: Toolbox from Asymetrix Corp., Bellevue, Wash., and Paradox for Windows from Borland International, Inc., Scotts Valley, Calif.

A pragmatic approach to developing distributed applications is recommended by Philip Teale, a technical architect with IBM Canada Ltd., Vancouver, B.C., who works directly with customers. He recommends that developers start off with a non-transaction, or non-mission-critical application. "The downside is you may trivialize the problems you have when you scale up," he noted.

Like Ahwah, Teal recommended against tying the application to any particular GUI tool. While he acknowledged the importance of a sound data model, he said, "People have focused on distributing data. Distributing functions is tougher."

As more users start tackling the distribution of functions, increasingly they will need development tools such as those mentioned above. Also, developers are expected to better understand partitioning issues as they gain more experience.

"Building the first application was difficult because we were moving into uncharted waters," noted Malik at Brewers Retail. "But we learned a lot and were able to put that knowledge to good use with subsequent applications."

COPYRIGHT 1993 Wiesner Publications, Inc.
COPYRIGHT 2004 Gale Group