Client definitions

Thin Clients

· Network dependency - required

o A thin client relies heavily on the ability to connect to the Intranet and/or the Internet in order to retrieve and display data to the user. Data is almost exclusively stored in a central repository and is retrieved by connecting to a SQL or Web service.

o The application itself (ASP(x), HTML, etc..) is loaded from a server.

o Performance can also be impacted by the round tripping to the server for additional functionality. Think about spell checking and round tripping to the server. The stateless nature of this model means that bits travel over the network very frequently.

o Developing ASP server solutions to render on the client add to the debugging and design complexities of an application.

· User experience - Limited

o Because a thin client is constrained to run within a Browser and can not take full advantage of the rich controls found in thicker client applications the user experience is limited. How many people have tried to write a robust Tree control (and I use control loosely here) that rivals the functionality of Windows Tree controls. The stateless nature of a Web application combined with the constraints around signing, trusting, and deploying a control to provide a rich end user experience all combine to limit the UI experience in the thin client model.

· Development - Complex

o But HTML is easy, isn’t it? Yes and No. As a flat form, display only presentation language it is fully functional. In developing an interactive, complex application, you often need a plethora of components like Java, (x)HTML, ActiveX controls, Flash, J/VB script, DHTML, .htc (behaviors), ASP/ASPX(.cs), CSS (cascading style sheets), XML, DOM, XSL(-T). Working around the stateless nature of a Web application means you rely on Cookies and or a data repository.

· Deployment – Simplified?

o The application itself (ASP(x), HTML, etc..) is loaded from a server. There is a strong argument that this eases deployment of the application. When a user connects to the server they load the latest version of the application.

o Configuring, maintaining, setting up security, etc.. on an HTML, IIS, and/or ASP server farm adds to the complexity of configuring the deployment install/loading location.

o Deployment complexities to the end user (Client) are simplified by throwing out new versions of application components onto the server.

· Foot print - Thin

o Runs in a browser and requires little client CPU processing and usually very little memory. Data is primarily round tripped from the server or static. On the client, the foot print is light due in part to the light functionality of a simple web application.

· Extensibility/Programmability - None

o Web applications are not written and arguably were never intended to be written with the idea that they may be extensible.

· Offline capable – None

o Web applications are stateless and require network connectivity.

Thick Clients

· Network dependency - Optional

o No dependency for the application to load/run since it is installed on the client machine.

o Unless you are connecting to a server for remote data access, all data may be retrieved from a local database or file system.

· User experience – Rich

o Complex controls, local processing, stateful functionality, immediate user interaction without the need to round trip to the server all provide a rich user experience.

· Development - RAD

o The VB and .Net development environment (RAD) is comprehensive and robust as compared to all the Web components needed to build a functional equivalent Windows application.

· Deployment – Complex

o Generally requires a setup installation (MSM, MSI) for user and/or machine wide install to include all the components in a package.

o Every client machine needs to be touched to get new versions. A central server service model is only available through applications like SMS.

o Patching and/or servicing is difficult due to the install/uninstall nature. DLL hell.

· Foot print - Thick

o Thick client applications take full advantage of local CPU, memory and Disk processing capabilities.

o Local disk intensive processing can add to the clients overhead but may in turn lighten the load on network packets and server costs.

· Extensibility/Programmability - optional

o A rich object model of a thick application like Word or Excel is designed and supported on the client to enable an application to automate the Word application itself via the OM, OLE, and customization extensibility (VBA, VSTO).

o Although there is no requirement for a rich application to support extensibility the environment supports the ability to enable this functionality.

· Offline capable – optional

o The ability to retrieve data from a Web service, database or file system and either cache or sync to a local store is possible given the access to local resources (Disk, memory structures, etc) on the client.

Smart Clients

· Network dependency – optional

o No dependency for the application to load/run since it is installed on the client machine.

· See deployment for more.

o Unless you are connecting to a server for remote data access, all data may be retrieved from a local data store (database or file system).

o Inherent in the notion of a Thick client being Smart, is the idea of handling data in a connected and disconnected (seamless) manner. Data is often cached locally and/or updated upon connection and disconnection to the server. An example of this can be found in the Outlook 2003 product for Offline email.

· User experience – Rich

o Complex controls, local processing, stateful functionality, immediate user interaction without the need to round trip to the server all provide a rich user experience.

o Takes full advantage of local processing, memory and disk.

· Development - RAD

o The VB and .Net development environment (RAD) is comprehensive and robust as compared to all the Web components needed to build a functional equivalent Windows application.

· Deployment – Simplified

o May require a one time setup installation (MSM, MSI) for user and/or machine wide install to include all the components in a package.

o Every client machine needs to be touched to get new versions of an application. A central server service model is available through applications like SMS, click-once, and/or the IE cache.

· Foot print – Thick or Thin

o Thicker clients applications take full advantage of local CPU processing cycles and as a result the memory footprint and usage of processing cycles add up to a heavier footprint.

o Local disk intensive processing can add to the clients overhead but may in turn lighten the load on network packets and server costs.

o A rich client model supports transient connectivity and therefore lends itself to devices (Pocket PC, smartphones, etc..) and although the functionality is limited on a device compared to a full blown O/S the foot print is much lighter weight. As an example, check out the .Net compact framework functionality and compare that to the .Net framework.

· Extensibility/Programmability – required/supported

o A rich object model of a thick application like Word or Excel is designed and supported on the client to enable an application to automate the Word application itself via the OM, OLE, and customization extensibility provided by environments like VBA and VSTO (Visual Studio Tools for Office).

o Although there is no requirement for a rich application to support extensibility the environment supports the ability to enable this functionality.

· Offline capable – required

o The ability to retrieve data from a Web service, database or file system and either cache or sync to a local store is possible given the access to local resources (Disk, memory structures, etc) on the client.

Comments

• Anonymous
  February 08, 2005
  The comment has been removed

• Anonymous
  February 14, 2005
  Hi Alex,
  Good questions.
  Re; 1) It is true that Thin Clients may offer offline services. As an example, IE offers some offline functionality. It is also possible to build a Thin Client application that may persist data to a local store. As you point out, considerations need to be made for handling the appropriate permissions and user interactions. However, the Thin Client model is not designed to naturally support this functionality. When you stray from the original target of the Web application model into the rich desktop application environment, you are adding functionality that was not intended to be supported. Vendors have continued to add support for richer thin client applications as the Web has become a prevalent network infrastructure. This was not the intended model of thin client application hosting. I believe the pendulum had swung to the extreme toward web development and that the natural tendency of the pendulum to seek equilibrium is now coming to pass.
  
  I can site many examples in my career where we created a web application that had desktop/thick client functionality. The complexity, cost of development, maintainability, and attempt to get feature parity with a Rich/Smart client application are all issues to seriously consider. I carefully factor into my application design decisions which paradigm meets the functionality required for the application that needs to be developed.
  
  Re; 2) As you mention with widgets, ActiveX controls, etc.. You may achieve a richer user experience, but imho this is not the design point of Thin Clients application but rather an attempt to get a richer experience into an environment that was not intended for this richer scenario. I am a big ASP.net fan as ASP certainly adds functionality but it also adds development complexity.
  
  Re; Windows only) There is nothing specific in the definition that locks you into Windows. It could be argued that Windows and the Microsoft tools and infrastructure built upon the O/S provide a robust environment for Rich application development.
  
  The Browser issue is something else of interest. I have debated many times the platform agnostic nature of Web applications. It is true that the ability for Web applications to be available to a larger potential audience that is not bound to a specific vendors O/S is a positive and driving factor when determining how the application should be designed. But if you intend to be ubiquitous you will need to target the lowest common denominator in Browser functionality (Mozilla, IE, Opera, Netscape, etc..) which will limit your rich user experience, or at the vary least add to your complexity of conditional code needed to support many targets. I would also add that most of these browsers are going to run on client work stations where CPU, hard disk, and memory are all available and should be utilized by the application developer.
  

• Anonymous
  July 21, 2006
  I have been spending the last few months doing research on ISV/VAR/SI applications.
  As part of my research,...

• Anonymous
  August 27, 2006
  i want to develop thin client application, i have to load all my win user controls in IE , and my controls will access data from remote database. For example, the datagrid will fetch data from remote database, when running in winform appllication it is working fine, but the same controls when loading in IE (thick client), it is throwing sql exception.
  
  My question is how to connect to remote sqlserver   from thick client. Can any one clarify me.

• Anonymous
  August 28, 2006
  Shiva, Just for clarity, a Winform application is a Thick Client application and a Web Applications (in IE) is a thin client appplication.
  There are a number of differences between the 2 types of applications and you have given a scenerio that shows this.  
  Internet applications have security requirements that by default do not allow System resource access, such as file system access, etc..  
  Your data access question is one that is common and also one in which web services were created.  There are ways to get your scenerio needs met within a Web application through security settings, using other controls, etc.. Winform controls are not meant to be fully supported outside of thier environment with which they were created (such as IE).  
  ActiveX controls were a close approximation to what you are asking for, but the overhead of signing these controls, deploying, installing/registering them, etc.. caused some of the lack of adoption and ubiquity.
  Your question is better answered by the IE team http://blogs.msdn.com/ie/

• Anonymous
  June 07, 2009
  PingBack from http://greenteafatburner.info/story.php?id=4572

• Anonymous
  June 09, 2009
  PingBack from http://toenailfungusite.info/story.php?id=3021