Client/Server Versus Web Server Development

By Barry Nance   Development teams are lucky: They don't have to live with the decisions they make. Even with the best of intentions, critical choices made during development can lead to unhappy, unproductive users and administrators. In particular, the choice of client/server or Web server environmentscould have a profound effect on the network, from both usability and administrative perspectives.

Client/server- and Web-based architectures represent the current state of the art in software technology, with client/server technology the more mature. The most significant difference between these two approaches lies in their promise for the future and how each adapts to industry directions and trends.

For example, client/server systems cannot easily take advantage of new technologies, such as network computers (NCs), intranets and J ava. Web-based applications (rendered in Java or ActiveX form) represent a retreat toward centralized computing, away from the empowering effect of desktop computing. Putting aside the intangible considerations for a moment, let's look at how these two approaches might fare in your company on your particular network.

The Gloves Are Off Influencing how any system will behave in production are its performance, reliability, network traffic, administrative workload, security and load-balancing characteristics. To complicate matters further, these factors are interrelated.

Additionally, the two architectural approaches aren't necessarily easy to categorize. A classic client/server application is a fat client, usually written in Visual Basic or Delphi. It's fat because it contains presentation and business logic. The client program accesses a relational database management sy stem (RDBMS), shared files on a file server or both. A classic Web-based application uses a browser for data presentation, application servers for business logic and database servers for storage.

However, you could have a client/server system that off-loads some of the business logic from the client onto a series of unattended computers--the extra processing tier gives the client/server application some of the attributes of a Web-based application. Or you could have a poorly designed Web-based application with a substantial or inappropriate amount of business logic rendered in JavaScript or as a Java applet.

Performance To evaluate the relative performance of these two approaches, we monitored with a stopwatch the screen-to-screen (window-to-window) response times for equivalent amounts of business logic rendered first in client-side Visual Basic and Delphi (fat clients) and then in server-side Visual Basic and Delphi, the latter running on a collection of application-server machines.

The business logic itself consisted of SQL database accesses interspersed with meaningless, CPU-consuming program statements. The fat-client versions contained both business and window management (data entry and data edit) functions, while the server-side versions were based on Microsoft Corp.'s Internet Server Application Programming Interface (ISAPI)-based Data Link Libraries (DLLs) containing the business logic along with functions for emitting HTML. Both client/server and Web-based versions used Open Database Connectivity (ODBC) to access database tables.

Our application and database server machines for the server-side programs were, naturally, faster and more powerful computers than the clients. Clearly, the ability of a three-tier environment to devote more horsepower to application logic and database storage/retrieval gives the Web approach the edge.

While running our home-grown Web-based application in the lab, we found Delphi-emitted server DLLs ran fa ster than Visual Basic DLLs, even when we didn't use Visual Basic's pseudocode com piler option. Delphi's performance surprised us because we used an extra layer of code, Borland International's WebBridge, to insulate us from the differences between Netscape Communications Corp.'s Netscape Application Programming Interface (NSAPI) and ISAPI.





Troubleshooting Next-Generation Architectures
By Peter Morrissey


Updated August 23, 1997


Valley View, Live!

Research and Reports

Storage Virtualization Guide
May 2012

Network Computing: May 2012

TechWeb Careers