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.
W
hile 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 much more 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 http://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.
Share or Bookmark this post…