Client/Server Versus Web Server Development
With respect to client/server software systems, administrators typically must monitor file server utilization and capacity, configuring user drive mappings (for file-server access) and connect strings (for database-server access) to account for increased or revised usage patterns. They occasionally set up new file servers and database servers, install new software releases, and often are the first line of defense when application problems crop up. Administrators manage security by assigning logon accounts and passwords, inspecting log files and using those security tools the organization has deemed appropriate.
For Web-based environments, administrators have many of the same headaches. However, their helpdesk problem list is shorter because administrators spend less time helping users restart the client application when the client software fails.
A browser such as Microsoft Internet Explorer or Netscap e Navigator fails much less often than Visual Basic or Delphi fat-client software. Moreover, because a browser automatically pulls applet classes from the Web server, network administrators don't have to worry about distributing parts of an application onto local client hard disks.
Load-balancing also typically falls on the shoulders of network administrators. The balancing act involves adding file servers, database servers, application servers and Web servers as the user population increases, and configuring the application to recognize the new resources. If you use a middleware product, such as BEA Systems' TUXEDO, you have less work to do--the middleware is configured to recognize the new resources and it handles the balancing of the transaction workload.
For client/server and Web-based approaches, developers should make it easy for administrators to add processing capacity. Neither approach offers a significant advantage over the other when it comes to load-balancing.
Reliability Th e Web-based approach generally proves itself to be more reliable than client/server. Program maintenance--the process of adding data edits and changing old ones--produced somewhat unstable client/server software. Fat means added complexity. Changing and testing a client/server application were more difficult, we found, because each module contained many more interrelated language statements. On the other hand, when bugs did crop up in our testing, the fat-client bugs usually were readily apparent. Windows NT displayed screen messages letting us know the application couldn't continue.
In the Web environment, a crashed ISAPI-based DLL produced messages on the application server console but left the user staring at an unchanging browser screen. On occasion, a serious bug in the ISAPI-based DLL would cause NT to terminate the Microsoft Internet Information Server (IIS) Web server software along with the application. From a reliability perspective, vendors need to devise a better method of reflecting applicat ion server problems back to the person using the browser.
Segregating business logic into separate server processes resulted in easier-to-maintain programs. In contrast, maintaining a client/server application forced us to have to mentally shift gears every time we made a change.
After inserting a new data edit for a field we added to the screen, we'd then have to carefully consider how the change might affect other parts of the client/server program. Shifting gears yet again, we'd need to painstakingly ensure the business logic we inserted for the new field would work smoothly and correctly, without interfering with other business logic in the program. Visual Basic's inability to recognize a misspelled variable name made matters worse. Delphi didn't have this problem.
In one instance, we inadvertently introduced in the client/server program a maintenance bug that caused the wrong data edit to fire when someone entered a particular combination of data. The same programming error in the JavaScrip t or Java applet Web-based environment was easier to avoid, we noticed, because of the simplicity of the client-side code. Neither approach guarantees reliability, of course. However, it's clear that complexity breeds program bugs like the Everglades breeds mosquitoes. The client/server approach requires greater programming skill levels and closer attention to detail.
And the Winner IsÉ The trade-offs between the client/server and Web-based approaches give the edge to the latter. From a networking perspective, a Web-based application means less complicated software, better performance and the possibility of bringing some interesting new technologies, such as NCs, into your company. A client/server application, on the other hand, puts computing power on the desktop and lets users have a clearer view of how the application is behaving. Unless you have a corporate strategy that mandates one approach or the other, we think your company will want to at least experiment with a Web-based architecture t o discover whether it's appropriate for you.
Barry Nance, a computer analyst and consultant for 25 years, is the author of Introduction to Networking, 4th Edition (Que, 1997), Using OS/2 Warp (Que, 1994), and Client/Server LAN Programming (Que, 1994). He can be reached at email@example.com.
By Peter Morrissey
Updated August 23, 1997