What is a Smart Client anyway?
And what makes it so smart?
The term Smart Client was coined to highlight the differences between the typical "Rich Client" applications of yesteryear and the next generation of client applications. To understand these differences, and to understand how they are likely to change the face of client-side computing, it is useful to take a trip down memory lane...
Client Applications: Then and Now
In the dim and distant past (that is, the mid 1990's) there was a dramatic increase in the number of client applications being developed for the Microsoft® Windows® platform. This increase occurred in large part due to the availability of high-quality developer tools and frameworks (such as Microsoft® Visual Basic®, Microsoft Visual Studio®, MFC, and so on) and because of the availability of a feature-rich client platform. Ah, developer heaven.
The majority of these applications were standalone and operated on the client machine with no regard to the environment in which they operated, both with respect to the other machines and services on the network, and with respect to the other applications on the user's machine. Very often, integration between applications was limited to using the cut-copy-paste features provided by Windows to transfer small amounts of data between applications. On the whole, though, users were pleased with the increasingly useful functionality that these applications now provided.
After a while, two-tier applications started to appear; these allowed multiple users to access common data that resided on the network. Shortly thereafter, DCOM allowed applications to become more distributed, with logic and state no longer tied to the client machine. Both of these developments were important and enabled a whole host of new scenarios and better functionality.
All of this increased flexibility and functionality, however, came at a price. Perhaps the biggest problem with rich client applications was that of deployment. As the complexity of the applications and the client platform had increased, so had the difficulty associated with deploying the application to the client machine in a reliable and secure way. One of the biggest problems was that of "DLL Hell," where one application could break another application by deploying an incompatible shared component or library.
In addition, the increasingly connected nature of applications brought with it many other problems. Connected applications were considerably more complex to develop, despite the availability of developer tools and frameworks. And as the size and complexity of these distributed applications grew, the tight coupling between the client application and the services it consumed became increasingly difficult to maintain, which in turn exacerbated the deployment and maintenance problems.
So, while rich clients typically provided a great user experience and had good developer support, they were still just too difficult to deploy and maintain.
Around this time, the Internet came along.
The Internet had very little effect on rich client applications. Some applications provided the ability to notify the user of available updates, or allowed additional content or features to be downloaded and installed, but on the whole, the Internet had little influence on how client applications were developed, deployed, and maintained.
The Internet did provide an alternative to the traditional rich client model, however, one which promised to solve all of the problems associated with application deployment and maintenance. Thin client browser-based applications allowed applications to be deployed and updated centrally, thereby reducing the problems (and therefore the cost) associated with deploying and maintaining an application. Also, thin client applications allowed companies to expose their applications to a large and diverse external audience.
Unfortunately, this brave new world was not without disadvantages.
Thin client applications at that time often represented the best way to expose a company's information and services to an external user base. But in many cases, internal applications that would have traditionally been implemented using a rich client application were also moved to the thin client model. While this movement had advantages in reducing deployment complexity, it did so at the cost of the user experience.
The usability of the applications was often much reduced and common features that the user had grown accustomed to, such as drag-and-drop, undo-redo, context sensitive help, and so on, were no longer available. Furthermore, the responsiveness of the application was diminished, especially for business applications, such as those in customer call centers, which demanded heavy data entry and navigation across multiple screens.
And of course, the browser was entirely dependent on having a network connection at all times. This meant that mobile workers had no access to the applications at all, requiring them to re-enter data when they returned to the office. And even when a connection was available, low bandwidth or high latency connections caused performance problems and a reduction in user efficiency.
Developers, too, suffered in the early days of thin clients. Tool support was lacking, and developers had to move from the cozy world of component-based development, with type safety and object-oriented design principles, to the harsh and unforgiving world of script and HTML. Only now can Web developers claim to have anything approaching the same level of support as client developers enjoyed 4 or 5 years ago. Even now, drag-and-drop, undo-redo, context sensitive help, and other common client-side features are still extremely challenging.
Despite these drawbacks, the deployment and management problems associated with rich clients were so big that the tradeoff seemed worth it. As a result, the thin client browser-based application model has dominated in recent years.
Client Applications: The Next Generation
Today we live in an information-based economy. In order to thrive in this hyper-competitive market, users must access and borrow information from many sources, including customers, partners, and suppliers. And users are now demanding more from their applications: they want to be empowered to act, plan, analyze, visualize, and explore the data, not just to read it.
Such concerns are not limited to a company's internal workforce. Leading companies are increasingly becoming aware that they have to build a digital relationship with their customers and partners, allowing them to provide faster and more accurate responses to customer requests and giving them easy access to purchasing, inventory, and shipping-status information. These users also need to be able to work with the data within their own applications.
Without question, the complexity of applications is increasing, and with it the expectations of the user. The thin client model is no longer able to provide the required levels of functionality, performance, flexibility, and integration. Users are now demanding fast and responsive applications to perform their daily work in a flexible and efficient manner. Add this to the explosion of devices and the increasing mobility of the workforce and it is clear that a new category of client application is required.
So, the pendulum has begun to swing back towards the rich client model. But what about application deployment and update? The TCO of an application is still as important as it ever was, probably more so. Do you sacrifice manageability for usability, or vice versa?
Happily, you don't need to sacrifice either. Key capabilities now exist which mean that we can take full advantage of the rich client model, providing the user with an excellent user experience, while at the same time reaping the benefits of centralized deployment and update. In short, this new generation of client applications, the so-called "smart" clients, provides the best of both worlds and adds the intelligence to manage data and connectivity to produce an extremely compelling user experience.
While smart clients provide the benefits of a rich client model with thin client manageability, they also provide much more flexibility than the traditional rich client applications. For example, smart clients need not be designed as monolithic desktop applications. Smart client solutions can be developed that are composed of functionality from more than one client application, with each application collaborating with the others to provide just the right functionality to the user. Such "composite" applications integrate client-side software resources into a coherent solution, or extend the functionality of an existing application to provide smart client features.
In addition, the client platform has moved on in the past few years and now includes many different types of client devices, not just desktop PCs. Such devices include PDA's, SmartPhones, Tablet PCs, Laptops, set-top boxes, automotive devices, retail terminals, and so on. Smart client applications can be built to take maximum advantage of the features provided by the host device and tuned to provide the best user experience for the typical users of these devices.
Smart Client Check List
Because of the high degree of flexibility and somewhat ambiguous nature of smart client applications, it is often useful to talk about the key characteristics of a smart client. These characteristics serve as a guide to the features typically provided by smart clients over and above those provided by traditional rich client applications. If a client application displays these characteristics, then it can be said to be smart:
Utilizes Local Resources
A smart client application always has code artifacts on the client that enable local resources to be utilized. What do we mean by local resources? We mean everything from hardware to software resources. A smart client may take advantage of the local CPU or GPU, local memory or disk, or any local devices connected to the client, such as a telephone, bar-code/RFID reader, and so on. But it may also take advantage of local software, such as Microsoft Office applications, or any installed line-of-business (LOB) applications that interact with it.Connected
Smart client applications are never standalone and always form part of a larger distributed solution. This could mean that the application interacts with a number of Web services that provide access to data or an LOB application. Very often, the application has access to specific services that help maintain the application and provide deployment and update services.Offline Capable
Because they are running on the local machine, one of the key benefits that smart client applications offer is that they can be made to work even when the user is not connected. For applications running in occasional or intermittent connectivity situations, such as those used by traveling workers or even those running on laptops, tablets, PDA's, and so on, where connectivity cannot be guaranteed at all times, being able to work while disconnected is essential. Even when the client is connected, the smart client application can improve performance and usability by caching data and managing the connection in an intelligent way.Intelligent Install and Update
Smart client applications manage their deployment and update in a muchmore intelligent way than traditional rich client applications. The .NET framework enables application artifacts to be deployed using a variety of techniques, including simple file copy or download over HTTP. Applications can be updated while running and can be deployed on demand by clicking on a URL. The Microsoft® .NET Framework provides a powerful security mechanism that guarantees the integrity of the application and its related assemblies. Assemblies can be given limited permissions in order to restrict their functionality in semi-trusted scenarios.Client Device Flexibility
The .NET Framework together with the .NET Compact Framework provides a common platform upon which smart client applications can be built. Often, there will be multiple versions of the smart client application, each targeting a specific device type and taking advantage of the devices unique features and providing functionality appropriate to its usage.
Smart Clients and the .NET Framework
So how does the .NET Framework enable all of these smart client benefits?
The .NET Framework provides a number of fundamental capabilities, which means that we no longer have to face the difficult usability versus manageability tradeoff. Let's look at some of the more important features...
The .NET Framework has very effectively solved the problem of version conflicts between assemblies shared by more than one application. A .NET application or assembly has a strong coupling to the assemblies and components they depend on. Assemblies are annotated with meta-data, which specifies both their exact version and the versions of all dependent assemblies. Multiple versions of the same assembly can be installed side-by-side so that all applications can be run with the exact same version of the assembly that they were built and tested against.
This assembly binding mechanism also provides important security safeguards. Assemblies can be cryptographically signed to prevent malicious code being run inadvertently, either through tampering or through luring attacks. In addition, .NET Code Access Security (CAS) allows assemblies to be granted specific permissions so that they can be used in semi-trusted scenarios. The .NET runtime ensures that assemblies can only carry out operations for which they have been granted permissions. The .NET Framework defines a flexible evidence based infrastructure for determining which permissions to grant an application or assembly.
These features effectively address application stability and predictability, but what about deployment? Assemblies do not need to be registered on the local machine so they can simply be copied to the machine before they are run. This greatly simplifies the deployment of the application. Alternatively, assemblies can be downloaded from a central server, either at install or at run time.
.NET also provides a deployment feature called No-Touch Deployment, which allows applications to be run on a URL. When the user clicks on the URL, the runtime automatically downloads the application, and all related assemblies, to a special download cache. This mechanism also checks for version updates so that the user never has to worry about whether they are running the latest version of the application or not.
Applications deployed in this way are only granted a very limited amount of permissions by default and are unable to access the local hard disk or access any network services, apart from the service from where they were downloaded. Additional permissions can be granted at the user, machine, or enterprise level if required.
Of course, the .NET Framework provides quite a few other features that affect how smart client applications can be designed and built. Of particular important are the Microsoft® .NET Windows Forms classes. These classes provide very rich user interface controls and give developers in all languages a common UI framework to work against, making development and testing much easier. The .NET Framework also provides many facilities for connecting to network services, such as SOAP-based Web services, and provides comprehensive XML support.
Smart Client Architecture
As .NET provides a number of key features that make the development of smart client applications easier, what are the architectural implications of all of these new features? It turns out that .NET goes beyond solving the problems that plagued rich clients and enables a whole host of new possibilities. The client platform now includes many different types of client device, and .NET supports them through the full and compact frameworks, but that's just the start.
The flexible binding, deployment, and security models provided by .NET allow smart client applications to be designed in much more interesting ways than traditional rich clients. For example, .NET provides a lot of flexibility in how the application can be "hosted": applications can be run as a traditional desktop application, or can be hosted within Microsoft® Office or Microsoft® Internet Explorer. Many combinations are possible. For instance, a Windows Forms application can host Internet Explorer or Office components and any host can subsume any other.
Application logic that is volatile, for example business rules governing volume order discounts, can be factored into assemblies that are downloaded on demand over HTTP, obviating the need to frequently "update" the client application in the traditional sense. Additional (or infrequently used) application features can adopt the same model so that initial application size is kept to a minimum with additional features installed on an as-needed basis.
Another popular model is the Composite Application model, where many applications combine to form a coherent solution. Such solutions can be formed by coupling together desktop applications, or by providing a generic "shell" application that houses multiple lightweight applications combining to form the solution.
The latter model has proven to be extremely useful in situations where the user has to deal with many applications to do their work. For example, customer service agents in call centers typically have to deal with many LOB applications, including desktop, browser-based, and terminal-based applications. All such LOB applications can be hosted within a generic Windows Forms application that provides integration between them, greatly simplifying the user's job and, most importantly, reducing the time spent on a particular call.
By providing a generic shell to host these LOB applications, common infrastructure features, such as security, deployment, window management, application integration, auditing, and so on, can be developed, tested, and re-used across different solutions, leaving the developers of the LOB applications to focus on business functionality.
Perhaps the most compelling example of a composite smart client application is Microsoft Office. Microsoft Office applications can be extended using SmartTags, SmartDocuments, or with Microsoft® Visual Studio® Tools for Office enabling powerful smart client solutions to be built.
Office smart client solutions can become an integral part of an organization's information infrastructure, accessing corporate data and services and providing a powerful and familiar working environment. Of course, Web services provide a natural way for companies to expose data and services, and smart client applications are the ultimate consumers of these Web services. And since Microsoft Office also provides XML support, data can easily be shared between both client and server and between the user's desktop applications.
Office smart client applications are capable of integrating data and services provided by multiple line-of-business (LOB) applications, each accessed through separate Web services. Such smart client applications can provide valuable Business Intelligence functionality, providing the user with access to critical business data in powerful desktop applications, such as Microsoft® Excel, where they can visualize, pivot, and analyze the data as much as required.
And finally, the advent of service-oriented architectures (SOA) means that there are huge opportunities for client applications to take advantage of the many and varied services available to them. All such services are provided in an industry standard way, which provides huge benefits in terms of interoperability, developer tool support, and the ease with which new features can be built into the smart client application.
Next Up: Whidbey and Longhorn
The above discussion focuses on the benefits that .NET currently brings to the area of smart clients. What about the future? The next release of the Microsoft .NET Framework, code-named "Whidbey," will bring a whole set of new features that build on the .NET Framework and make smart clients even more compelling: richer and more flexible user interface components, easier thread management, better tools, and a new deployment feature called click-once, which builds on the no-touch deployment mechanism described above.
Microsoft Windows, code-named "Longhorn," will take smart clients to a whole new level, with features like the presentation subsystem in Longhorn (code-named "Avalon") providing next generation meta-data driven user interfaces, and the storage subsystem in Longhorn (code-named "WinFS") providing huge integration opportunities between applications. Check out the Longhorn smart client demo for commercial real estate at msdn.microsoft.com/Longhorn/productinfo/default.aspx for a glimpse of the Longhorn smart client vision.
Many analysts have been predicting for a while now that the pendulum has swung back towards rich clients and away from browser-based applications. With .NET, and especially with Whidbey and Longhorn, it looks like the time of the smart client is well and truly upon us.
Copyright © David Hill, 2004.
THIS CODE AND INFORMATION ARE PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.
Comments
- Anonymous
February 03, 2004
David Hill has written a nice article that may be useful as an introduction to /explanation of the idea of Smart Clients. I like to keep documentation like this around so that I can use it to get my ideas across to C-levels, non-techs, etc. Getting people to read is extremely hard at times but these types of articles still work as good crib sheets and/or allow me to help organize my thoughts on the subjects. - Anonymous
February 03, 2004
Excellent article! - Anonymous
February 03, 2004
Thank you!!!!! Good job! - Anonymous
February 04, 2004
<David>
Even now, drag-and-drop, undo-redo, context sensitive help, and other common client-side features are still extremely challenging
</David>
IE support all these features and beyond...(databinding/XML datasources/AOP=attached behaviors/expando properties exists in IE for ages)
I'm more close to admit that web client is more feature rich(=flexible,powerful etc.) than windows client at present time(remember SVG/SMIL or gradients(filters) coming from?),it just another kind.
Seems Microsoft agreed with me because it expand her browser BOM to support .NET (Longhorn XAML=custom/extended HTML+.NET capabilities)
So smart client is simple hosted application-office or IE dosen't matter IMHO,more powerful host environment-more powerful application-that's all ;-) - Anonymous
February 05, 2004
What is a Smart Client anyway?... - Anonymous
February 10, 2004
Hi David!
Thank you for this very good introduction into smart clients!
i have a question concerning the check list: would you call a client, that fulfills all points, but communicates with .net remoting instead of web services, as a smart client, too?
Thanks for your reply!
Bye, Christoph - Anonymous
March 02, 2004
Last month Microsoft released a new application block. This application block of re-usable code and samples, can be used to model your own applications to allow them to detect the presence or absence of a network connection, cache data for use while offline, and re-synchronize data and tasks with the network once the application goes online. - Anonymous
March 15, 2004
Any thoughts on these two?
Macromedia Flex
http://www.macromedia.com/software/flex/
Curl
http://www.curl.com - Anonymous
March 23, 2004
An excellent article on smart clients. Do you have any idea how many enterprises are considering using smart client apps instead of browser-baseed apps? We are finding that many of the enterprises we talk to still mandate browser based solutions even for applications running behind firewalls. - Anonymous
March 29, 2004
some screen shots of smart client application would have made it much better. Anyway excellent! and thanks. - Anonymous
April 16, 2004
Christoph, since you haven't got an answer to you question, this is what I think (and I don't claim to be an expert here). I think that a smart client is alright if its getting its data through remoting instead of web services, what matters (data-wise) I suggest is that it is able to adapt to online and offline scenarios (by caching operations) and allow the users to work seamlessly 100% of the time. - Anonymous
May 10, 2004
Davuid,
What have you tested of Utopia ideas of Microsoft. No touch deployment in Microsoft envrironment has always been promisses, but never delivered. Why do I always have to restart my PC after a Patch download....?
I can imagine the .Net frame provided more descent software distribution features, but 'No touch' cann't be done with this technology. - Anonymous
May 25, 2004
It's a very good introduction into smart clients. Could you tell me where I can get an example code? - Anonymous
May 25, 2004
I am new to smart client and just attended David Hill's session. I am trying to understand the server side of the smart client. Why does it have to be a web server? Why does the client access web services? In other words, why can the client be accessing data via normal object instanciation on a normal WIN 2003 server, possibly running SQL server? I don't get the advantages of the web services? Thank you. - Anonymous
May 28, 2004
Hi!
i'v a little query... is there a way to run smart client without a .net framework ... i mean if .net CLR not installed on a client machine ..is there a way that smart client automatically detects it and downloaad CLR automatically.. this is very crucial for my app.. as my requirements are perfectly matched by SmartCLient but my client dont wana dowload anythng... so i'm considering to move towards ActiveX.
ur quick comments needed
Faraz - Anonymous
June 01, 2004
To detect if CLR runtime is installed on client machine, u can print value of
Request.Browser.ClrVersion.ToString()
and for download instructions check the link,
http://msdn.microsoft.com/netframework/using/building/windows/analystreports/smartclient.aspx - Anonymous
June 15, 2004
Seit Jahren schon rennen weite Teile der IT-Branche gegen das PC-Konzept an: Die bisher zumeist mit Windows ausgestatteten Fat Client-Desktops gelten als teuer, kompliziert und schwer zu administrieren. Doch mit dem lange gehypten Gegenentwurf, dem abgespeckten Thin Client auf Terminal-... - Anonymous
July 07, 2004
lets say i'm planning an information system with a database.
i'm doing a web application project, so where is the DB located ?
if its located at the server, how come a client can work offline and still update the main DB ? - Anonymous
July 07, 2004
With a thin client application the database would be located at the server side and the user interface is provided by a browser. You would not be able to access the application at all when offline. This is a fundamental limitation of the thin client model.
With a smart client application, the client part of the application can be run when the user is offline. You provide some form of client side storage for the data and then synchronize this with the main database on the server when the user goes back online. - Anonymous
July 07, 2004
With a thin client application the database would be located at the server side and the user interface is provided by a browser. You would not be able to access the application at all when offline. This is a fundamental limitation of the thin client model.
With a smart client application, the client part of the application can be run when the user is offline. You provide some form of client side storage for the data and then synchronize this with the main database on the server when the user goes back online. - Anonymous
July 21, 2004
Smart client, it seems intersting , but the problem will arise in the corruption of local data storage ,unless we use Oracle or SQL Server DB at teh client , and even if we assume we fixed the DB problem , we have another issue which the time needed to synchronize local Data with server data. - Anonymous
July 22, 2004
Maintaining data consistency on the client can be a problem if you need to account for reliability situations - such as power failures, application crashes etc. In these cases it is best to employ a local database and write to it using a local transaction. In this way, the data remains consistent even in the case of failure. You can use SQL Server, MSDE, SQL CE on the client for this. Local consistency is not usually such a problem - maintaining consistency of data between the client and server is more challenging.
With regard to the time taken to synchronize data, the key is to only synchronize data that has changed. This applies to data going to the client (for example, cached data) and data going to the server (data that the client has changed). There is rarely any need to send all of the data either way. And of course, the time taken to synchronize depends on the communication mechanism and network connection quality as well as the amount of data.
If you need to enable offline use, and expect that data synchronization will take a long time, say because of the volume of data or the speed of the connection, then the data should be synchronized in the background so that the user can carry on working. - Anonymous
July 26, 2004
Excellent article explaining smart clients and their differences with rich and thin Clients!
Thanks you David. - Anonymous
July 30, 2004
Dare Obasanjo - Anonymous
July 30, 2004
Dare Obasanjo - Anonymous
October 13, 2004
<p>
Worldwind is a live, 3D Earth globe with satellite and topographic data, backed by an extensive place names database. The zooming and panning effects are pretty neat on my laptop; tonight I'll hook it up to the projector and show the boys.
</p> - Anonymous
October 28, 2004
Smart Client Architecture and Design Guide Released - Anonymous
November 14, 2004
Seit Jahren schon rennen weite Teile der IT-Branche gegen das PC-Konzept an: Die bisher zumeist mit Windows ausgestatteten ¿Fat Client¿-Desktops gelten als teuer, kompliziert und schwer zu administrieren. Doch mit dem lange gehypten Gegenentwurf, dem abgespeckten Thin Client auf Terminal-... - Anonymous
March 27, 2005
Getting Started with the Offline Application Block for Smart Clients - Anonymous
September 08, 2006
PingBack from http://www.livejournal.com/users/lsp/71449.html - Anonymous
September 08, 2006
PingBack from http://www.ljseek.ru/whidbey_13791765.html - Anonymous
November 19, 2006
PingBack from http://service.ryarc.com/DasBlog/PermaLink,guid,aefd41aa-9f07-4754-8bbc-bdf8f48964b4.aspx