Catching Up On the Server Side
The Microsoft Advantage
Fat and Rich—Furthering the Lead
The Microsoft Mobility Mission
Forms, Clients, and Developer Kudos
End-User Productivity Really Does Matter
James Governor
September 24, 2002
This situation leaves Microsoft with a massive advantage in the tools for building rich-client applications—and the Windows runtimes to deploy them. Rich clients, despite the usefulness of browser-based thin-client models, are still incredibly important.
Rich in this context doesn't mean rich media per se, that is, multimedia-based applications, the kind of thing you might support using RealPlayer. No—by rich client we mean one that offers a highly interactive and self-contained user experience—one in which users aren't constantly clicking a "refresh" or "update" button. Rich-client, Windows-based apps are sophisticated, interactive, and not dependent on periodic updates from a remote server to operate. What is more they offer virtually instantaneous responses to changes in data or user input.
Almost all business transactions today include some human action—such as data entry by a clerk, sign-off by a senior manager, or acceptance of a supplier's prices by a procurement professional. The limited view that vendors and IT professionals have tended to use is that an update of a database record is a transaction (the old faithful two-phase commit). That is the model that has underpinned J2EE. However this notion of a transaction only goes so far.
A wider view of a business transaction includes human interaction with content, often rich content, to allow a decision to be made. This is not just "can we fulfill the order," but "do we want to fulfill the order?" It is here that client richness is required—can I see the business partner's eyes in the video conference, before signing off on a deal? Can I see a copy of the original contract, which was written on paper, then scanned, but has not been converted into an XML-based document that can be used programmatically?
This is not to say that this kind of richness can't be achieved using thin clients. With plug-ins and extensions you can accomplish these kinds of tasks. But, in general, doing so will be a workaround, and hacks don't come cheap—any organization should think very carefully before paying a lot of money to an integrator to build extensions into a thin-client platform to enable this kind of content-enabled application. The balance between functionality and ease of management is the key decision point in any choice concerning thick or thin clients. Fatter clients often offer a richer user experience, but they also tend to be harder to manage.
For certain classes of applications thin clients really are not appropriate—those, for example, that require sophisticated modeling or image manipulation. Thin client performance is rarely acceptable for these uses.
Which is where Visual Studio .NET comes in. From a developer perspective, rich clients provide functions such as client-side persistence and state management, and the ability to run sophisticated decision logic, including complex data models and representations on the client, which browser-based clients can't do nearly so well. Rich clients allow for a better user experience—with less latency and fewer user errors.
Although a developer can use JavaScript to run some logic within browser-based apps, these apps almost never have a complete or sophisticated model of the data the user is manipulating. This semantic gap between the browser-based user interface and "the application" (which runs back on the server) is the real gap we're talking about here. Rich clients have a much more complete view of "what's going on." This accounts for both their advantages and their fatter footprints.
 |
|
|
 |
|
|
|
|
|
|
|
|
|
||||||||||||