The late 1990's saw growth in the Internet through the utilization of an underutilized network infrastructure and the browser wars. PC's were everywhere and they contained an application Host (IE, Netscape, Mozilla, etc..) for running code (script). Corporate IT departments were overburdened with the support off all the thick client application components. As upgrades for applications came, so did the headaches. Many longed for the day of the mainframe and a central server. Some (Oracle and IBM) still believe this is the only way to go. As is usually the case, the pendulum swung to the extreme and now it was swinging back toward center. The answer seemed to be somewhere in between the central server model and the Rich/Thick client model. But as usual the pendulum gains momentum and it usual passes center.
A Thin Client utilizes little or no processing capabilities on the Clients machine (be it a PC or Device like a pocket PC). It also relies on accessing data from a Server and may only support temporarily storing limited data on the client in memory and for the most part never persists (saves) data to the client. Web clients are very much akin to thin clients that have limited ability to store local data (on the client) in cookies, etc... As I pointed out, Thin clients and Web clients are often used synonymously. Web clients utilize browsers as a host for running applications that are primarily script based programs.
The thin client model is easily described simply as Client (underutilized) <--Network/Communications--> Server.
The advantages are in the central (singular) nature of the server which provides a single place of maintenance, storage, deployment, and single upgrade location. Copy a new version of your code (.ASPx, or .htm) to a server location and the next time a user visits or refreshes the page, they are running the new version. Simple deployment. The dependency on the server is readily apparent in the Thin Client model.
And so the HTML and client side development takes off with the blessing of IT. The nature of this thin model doesn't lend itself well to robust application functionality. It is a beautiful model for display and presentation but has its short comings in stateless-ness. It is burdened by the constraints of a Host application (IE, etc.. on the client and ASP on the server) for functionality and it doesn't participate as a component (control, etc..). As a singular page with limited functionality it serves a targeted niche. But as a living, interactive, statefull, rich application, it does not measure up. IT departments pushed to use this platform in the hopes of easing their burden and to allow non-corpnet access to information that didn't require direct corporate access.
As a development manager for the MSN content management platform service I was, of course, in support of the Internet and the sites with which I was responsible for building and hosting. But I also questioned the cost and complexity of using this same model for supplying in house applications. Sure, we used a multi-tier model for these rich (robust functionality) applications but developing these applications using the web development environment was a tremendous burden in cost and complexity. Where a simple VB Windows UI, a COM middle tier and a well designed SQL database provided a rich RAD environment for my developers and users, I now had the following complexities when trying to build a Web UI application. I stress application because I am not talking about a simple UI. The plethora of tools – (x)HTML, ActiveX, Flash, J/VB script, DHTML, .htc (behaviors), ASP/ASPX(.cs), CSS (cascading style sheets), XML, DOM, XSL(-T) - that was now required to produce a robust application experience that still pails in comparison to a rich client development environment and end user experience and the constant design decisions of the stateless nature wasn't the solution either. In fact, it was a plethora of problems as a result of the pendulum swinging to far.
The answer in my mind to the majority of application development is the Rich Client model. In my next posting I will discuss this model as I have touched on the other models. In the mean time, a picture is worth a thousand words. Here is a diagram (either borrowed from some doc's my current product group put together or relatively close). Either way, here is a link to my current passion and a link to the source of this diagram.