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 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.
