Reasons To Use Two-Tier Fat Client Instead of Browser-Based Application Deployment Technology

Netscape didn't say client/server is dead, we said the client/server application model that has traditionally been used (fat custom client connecting to dumb back-end database) is dead.

Applications from here on out, we believe, will use the universal client, plus an application server (a Web server or whatever), plus a database - in other words, basic three-tier, with the universal client twist. (And I'll even limit the claim to those applications that will benefit from running on a network - which over time is all applications, although that may not be the case right now.)

There's no reason - none - to develop an application using the old client/server two-tier application model of fat client and dumb database anymore. That model always had huge liabilities, and IS people tend to hate it these days (at least that the case with the ones we talk to), due to issues involving deployment, maintenance, user training, inflexibility, ease of use, platform and so forth.

Marc's claim in the last paragraph raises a red flag for me. In my experience, such an absolute position is simply untenable. Different solutions are appropriate depending on the circumstances, i.e. there may be business reasons to ignore technically superior options. Therefore, I immediately set out to create a list of reasons why I would develop an application using the old client/server two-tier application model of fat client and dumb database. (BTW, I don't know whether use of the term "dumb" is meant derogatorily or implies that stored procedures are not used.) In making this list, I specifically had in mind the alternative of a three-tier application with the universal client; other three-tier implementation options are ignored. In no particular order, the list is

• Exploit rich, native GUI. The widgets available in HTML forms are simply pitiful. Even with Java applets, not every standard Windows 95 widget is supported.
• Leverage existing skills. The people I work with today know fat client technologies cold. The world cannot stop while these people are retrained or new people hired.
• Reuse existing code. We have C++ and Visual Basic frameworks in place to maximize productivity and quality.
• Lack of universal client. I have two points here. First, not every desktop has a browser! Second, there are a great number of features in today's browsers that are not universal.
• OLE integration. We love to embed Word or Graph in VB forms, or control Excel with OLE Automation. Try that from your browser.
• User-defined queries and reports. Can a browser user change the order of columns on a report with a drag and drop?
• Non-TCP/IP networks. Not every SPX/IPX, NetBEUI or proprietary network has a gateway to access Web servers, and Java doesn't speak these natively.
• Non-GUI clients. Try viewing an icon bar or table with Lynx!
• Performance. Every screen must be loaded across the network from the server (even cached screens require verification of last modified date), and CGI, the lowest common denominator for connecting Web servers to database engines, is a pitifully inefficient user of server resources.
• Tools. VisualWave might be the only shipping tool that makes developing for the Web as simple as 2-tier C/S. Testing tools are just beginning to become available. Partitioned 4GLs (e.g. Forte and Dynasty) barely support Web technologies.
• Transactions running across multiple screens. Each CGI call establishes a new RDBMS connection, which is not too cool if you need to keep a database transaction going.
• Live, scrolling edits. We finally get scrollable engine cursors, but with three-tier Web solutions, we can't use them.
• Support for mobile users. Products like RemoteWare simply do not exist for Web-based implementations.