The past seems to be popular these days. From VH1's nostalgia-laced "I Love the 70's, 80's, and 90's" shows to the popularity of "classic" musical artists (U2, Bruce Springsteen and the Rolling Stones coming soon to a city near you), retro is in. They're feeling a wave of nostalgia up at Microsoft too. But in Redmond, this wave marks the return of the rich client.
No, not the rich client you're familiar with—rich clients now have gotten "smart." How? In part, by the lessons learned in thin-client development. Over the past 10 years, Web application development has become the de facto standard for most programmers. "Thin was in," and we developers responded by dutifully learning our ASPs, J2EEs and PHPs.
So What's Wrong with Thin Clients?
In a traditional thin-client application, users navigate through a series of Web pages to perform tasks, and these tasks are realized primarily through server-side business logic.
What's wrong with this picture? Well, two things, really. First of all, despite the amazing things that we've been able to accomplish inside the browser, we still have to operate inside the browser. This creates some fundamental limitations to creating a rich user interface.
Secondly, the fact that our business logic exists on the server means that connectivity is essential. Lose the connection and the application is unavailable -- and work doesn't get done. Sure, we can focus our attention on improving server uptime, but typically some parts of the connectivity story are beyond our control (ever have your ISP decide to perform maintenance on your connection right before a deadline?) Besides, what about predictable situations in which connectivity is not present, as when a user wants to continue working while on a plane or at a remote job site?
But I Like Thin Clients!
Despite the browser/connectivity dependencies, Web applications have thrived. Certainly, they have some important benefits. First of all, thin-client solutions are very good at presenting a shared view of back-end data. By working in a connected environment where all logic resides on the server, users receive "fresh" information. And it is easier to apply security and transactional logic to protect the data. Also, the deployment story is extremely simple—you just point your users to a specific URL. Finally, Web pages offer a familiar interface to users grown accustomed to hyperlinks and forward/back navigation.
Enter the Smart Client Solution
As of today, the term "smart client" is more than a little nebulous. After all, it doesn't refer to any particular protocol or product—no acronyms or specifications on which we can hang our hat. There is just the rather vague notion of "client" that has been used to describe many paradigms over the past thirty years. In the near feature, however, the term "smart client" may become as familiar and comfortable to us as "Web client."
Generally speaking, smart clients exhibit four distinct characteristics: They do not require a full-time connection; they are easy to deploy and update; they use Web services to access backend data; and they can be deployed to different types of devices.
Look Ma, No Connection!
Thanks to the explosion in Wi-Fi and the increasing affordability of broadband Internet access, we are more connected than ever. However, to assume that our users will never be disconnected from our network is still foolish. And even if users are connected when away from the office, security considerations or bandwidth limitations may hamper their access. So smart clients are network aware—they know how to grab "fresh" data when they've got a good connection, but they also know how to cache this data so that it is still available when the user is offline.
Fortunately, smart-client developers have a head start when it comes to providing this functionality. The Offline Application Block (available from Microsoft's Patterns and Practices website) contains the fundamental code required to detect network status, cache application data, and synchronize data with the server once connectivity is restored.
One-Step Deployment
In order for smart clients to be an attractive alternative to their Web-based brethren, they have to be just as easy to deploy. A typical smart client will be made available from a centralized server, with "one-touch" installation. Once installed, a smart client is able to perform maintenance and updates on itself. Of course, since it is network aware it can intelligently make decisions as to when and how often these updates are made.
A great example of this behavior is the ClickOnce feature coming in this year's release of the .NET 2.0 Framework. With ClickOnce, the user simply follows a link to a Web or file server. Automatically, the application is downloaded and executed. What's more, the application is executed in a sandbox provided by .NET's Code Access Security, so the user is protected against malicious behavior.
Web Services, Now and Forever
Web services have survived their own hype and have settled into ubiquity. For most developers, whether or not to use Web services is no longer the question—instead, they are deciding which toolkit to use and what protocols to support. With ever-increasing support for the WS-I Basic Profile and the WS-* specifications, even these questions will soon become less relevant. The benefits of Web services are well-documented elsewhere—suffice to say, Web services are the tool of choice when it comes to data access from smart clients.
Independence Day for Devices?
Well, sort of… Most smart client applications themselves are not, in fact, device-independent. An application written for a small form factor such as the Smartphone is fundamentally different than an application for a typical PC. However, the smart client technology exhibited by both may be exactly the same. In other words, all types and manner of devices can run smart clients.
For a clearer picture, consider the evolution of mobile-device development on the Windows platform. In the past, a developer writing a mobile application had to use a host of specialized tools and APIs. With Visual Studio 2005 and SQL Server 2005, the mobile platform is highly integrated.
It's All About the Data
One key to understanding smart clients is to recognize the benefits to the information worker. Technology aside, the purpose of smart clients is to provide the most relevant information in the most relevant context (and do it without requiring the user to have multiple applications open at the same time!)
The smart client application will be able to access data from widely disparate data sources—Microsoft SQL Server and other RDBMS solutions, ERP and CRM systems, and of course anything exposed as a Web service. Even more interesting are new tools that allow smart clients to access "unstructured data," that is, spreadsheets, documents, notebooks, etc. Visual Studio 2005 Tools for Office provides developers with the ability to create custom solutions based on Office technology (and usable from within Office products.) The Information Bridge Framework provides a standardized mechanism for users to access (and act upon) enterprise business objects—again, directly from within the familiar Office environment.
What Next?
As you've probably noticed, it's an exciting time to be a Microsoft developer. This year marks a quantum shift in tools and technologies, with new versions of the .NET Framework, Visual Studio, and SQL Server all arriving soon.
It certainly can be overwhelming, so don't get too distracted by the details. Sure, I like generics as much as the next guy but are they the key to the next killer app? Probably not...
It would be cliché to say that "smart clients are the future" but hey, how else do you put it? Smart clients represent a new, intelligent application paradigm with a rich user interface and the ease of the Web…
Sounds like a pretty good future to me!
Remember to check out the Get Smart About Smart Clients Webcast Series. Click here to register.
Print
Dzone.com
Digg.com
Slashdot.org
Reddit.com
Del.icio.us
