Smart Clients: Essential Requirements and Candidate Services


August 2006

Applies to:
   Application Architecture
   Smart client applications

Summary: The architecture and design of smart client solutions begins with a comprehensive understanding of the unique requirements for this versatile model that leverages the rich and dedicated resources of the user's own computer and, when connected, the far reaches of the network. Drawing on the experiences of an international and independent group of architects who build smart client and Web-based applications on heterogeneous platforms for several diverse markets, we catalog several major requirements unique to smart client applications and the personal devices that host them. The requirements identified are considered essential yet common to a broad range of smart client applications, and for each requirement we suggest one or more provisioning strategies we call candidate services. (20 printed pages)


Essential Requirements
Operational Category
User Interface Category
Business Logic Category
Data Category
Deployment Category
Acknowledgements and Contributors


In this article, we will first review the scope and purpose of smart clients, and the unique challenges this application model poses to the architect. The primary drivers that suggest a smart client implementation are the need for high-performance data entry based on rich user interfaces that are adaptable and dynamic; the need for integration with other desktop applications and workflow; the need for connected and disconnected capabilities; and the need for automated software deployment. However, each of these requirements can point us to different strategies for solutions with widely varying results.

The Smart Client Development Center states that "Smart clients are easily deployed and managed client applications that provide an adaptive, responsive, and rich interactive experience by leveraging local resources and intelligently connecting to distributed data sources." We can say more simply that smart clients bridge the gap between rich and thin clients, combining the benefits of both.

Rich clients, typified by classical desktop applications, take advantage of the local hardware resources and the features of the client operating system platform. Despite the impressive functionality of many of these applications, they have severe limitations in today's world. Many of these applications are isolated on the user's computer with little or no awareness of the surrounding digital environment (peer computers, network services, even other applications on the same computer).

On the other end of the configuration spectrum are thin clients, browser-based applications deployed and updated on a central Web server. This deployment model either greatly reduces or totally eliminates the need to deploy software to the individual machines of the user community, thereby providing a highly efficient means for distributing software. The most apparent dependency of the thin client is its complete reliance on an always-on network connection. This dependency is reasonable for a broad range of applications and environments, but is an unacceptable liability for many others. Consider the health care worker who must have ready access to critical information, regardless of the environment and the availability of the network.

We recognize that just as thick clients are extending their functionality through network connections in interesting and productive ways, thin clients are doing similarly from the other direction, as evidenced by the so-called Web 2.0 innovations. We see this blurring of the process-execution space as necessary. The more we can engineer computing resources and services into the fabric of our existence, the more extensively we can apply their productive benefits at the point of greatest need.

Our position is that the smart client model is optimal for certain applications that must be readily available using dedicated, personal resources (such as laptop, tablet, or PDA). Smart client applications combine the benefits of a rich client with the deployment and manageability strengths of a thin client, although the precise nature of the balance between the two strategies depends on many factors relating to the application's specific requirements. Smart client applications often have very diverse requirements, and so vary greatly in design and implementation. Nevertheless, all smart clients share some or all of the following characteristics:

  • Use local resources
  • Use network resources
  • Support variable connectivity levels
  • Provide intelligent installation and update
  • Provide platform flexibility

Consequently, we see value in identifying essential requirements unique to the smart client application model. The requirement list is not intended to be exhaustive. The intention is to provide the architect with a summary view when gathering requirements. Furthermore, as we surveyed these requirements, we saw additional benefit in discussing potential provisions or candidate services (as we call them) that satisfy, in whole or part, a given requirement.

In summary, this article explores a proposed set of core smart client requirements that exist today and will continue to evolve on the smart devices of tomorrow.


The final point we wish to make by way of introduction is that we deliberately limit the scope of this initial discussion only to the client-side of the smart client model. Our assumption is that the smart client has vital connections to one or more server-side components or services, whatever their purpose, but we refrain from addressing this aspect of the model (for now) so we can better focus on requirements specific to the client. As such, we treat the client-side as an independent application domain wholly separate from the server. Readers who are designing both sides of a smart client application will find they have additional requirements and provisions not listed here since only the client side is considered.

Essential Requirements

The essential requirements of the smart client are grouped into several broad categories for discussion purposes:

  • Operational
  • User Interface
  • Business Logic
  • Data
  • Deployment

As critically important as security is to any application, and even more for smart clients with their dynamic network connections, security is not listed as its own requirements category. There are two reasons for this. First, we recommend to the reader the services of the operating system, such as Windows Authentication and Active Directory directory services, for providing basic application security support. Second, security is not unique to smart clients but is a critical need shared by all types of applications.

Table 1. Definitions

Term Definition
Smart Client Easily deployed and managed client applications that provide an adaptive, responsive and rich interactive experience by leveraging local resources and intelligently connecting to distributed data sources.
Essential Requirement A requirement that is unique and specific to a broad range of smart client applications. A smart client application undoubtedly has many functional requirements, but only those that are specific to this model are shown here.
Candidate Service A service that satisfies an essential requirement, in whole or part. The term service broadly applies to any solution, be it software, a pattern, a concept, a best practice, or a general strategy. Note that our use of the term does not imply a "service" as defined by the four tenets of service orientation, most notably that our services are not necessarily loosely-coupled. Depending on the specific requirement, employing only part of a service may be appropriate, or combining aspects of two or more services may be advisable. Also, in a few cases, a candidate service may have applicability to more than one essential requirement.
Requirement Category The classification of the essential requirements is based upon broad groupings of related requirements. Where a requirement has a singular theme, such as pertaining to the user interface or to data services, then placing the requirement in a single category is easy, but some requirements have strong implications for several categories.

Table 2 places related essential requirements together. For each requirement there is a list of one or more candidate services that address the needs of the requirement in some fashion, perhaps only partially. In fact, depending on your specific application, it may be necessary to combine certain elements from multiple candidate services to fully satisfy a given requirement. A candidate service is a provision or strategy that satisfies a given requirement. For some requirements the list of candidate services are only conceptual and meant to stimulate further ideas, whereas others draw on existing implementations that may directly benefit the smart client developer. By thinking of smart clients in terms of their essential requirements and candidate services, we begin to develop a common vocabulary and contextual framework for extending the model in new and interesting ways.

Table 2. Requirements categories

CategoryEssential RequirementCandidate Service
OperationalConnection DetectionConnection Manager
Bandwidth ManagementBandwidth Manager
Events and NotificationsActivity Manager
User InterfaceDynamic Environment ConfigurationEnvironment Manager
Business LogicReuse and PortabilityRules Engine
DataLocal Data ManagementSmart Data Manager
DeploymentInstallationDeployment Strategies

Each essential requirement is presented using a repeating layout structure: the name of the requirement, the essence of the requirement followed by a general description, business and technical drivers, related complications, a Scenario for context, and one or more candidate services that meet the requirement, in whole or part. Similarly, a candidate service is framed by its description, drivers, and complications. Where known, the reader is directed to additional resources or information about the candidate service. Listing the drivers and complications from the both the demand (the essential requirement) and supply sides (the candidate service) provides a quick assessment of the issues and tradeoffs involved. Note that the term application is used in the following section to generically mean any smart client application.

Operational Category

The operational category is a catch-all for essential requirements that do not fit well into other categories or whose requirements span multiple categories. To date, the operational category is mostly about network management and intra-application messaging.

Connection Detection Requirement

Smart clients function differently depending upon their connection state, and must manage transitions from "connected," through "partially connected," to "disconnected" states throughout the application session.

In many cases, smart client behavior must be implemented differently depending upon connectivity to external services. For robust smart client operations, the requirement for connection detection does not imply that detection is as simple as insuring the presence of a network connection since a connection to a network does not guarantee connectivity to a targeted external service. Rather, the application framework needs to detect the state of the smart client's connection to one or many external services. Connection detection assists in the transition between different states (or along a spectrum) of connectivity throughout the life of the application.


  • Adjust levels of application functionality depending upon connectivity to external services.
  • Detect connections on demand with minimal resource use as external services are needed.
  • Behave predictably, based on thresholds, as connections degrade. Examples of a degraded connection include intermittent or unacceptably slow connections.
  • Maintain connectivity states for multiple external services concurrently. This allows the state of connectivity to drive the behavior of the application based on the connectivity of individual services or a combination of related services.
  • Allow manual setting of connected and disconnected states.


  • The connection may technically exist but perform at an unacceptably poor level.
  • The connection may be intermittent, causing the system to rapidly change behaviors unless thresholds are set.
  • "Connected" may be defined as connectivity to multiple external services simultaneously.
  • Connectivity to different services may be defined differently, adding complexity to the connection detection service. For example, access to a Web service, queue, and data service may all be defined differently.


When a bank teller (or ATM) is executing a withdrawal transaction for a customer when connected, the account balance is available from an external data source. Therefore, the teller's application can complete the withdrawal (up to a limit). However, when disconnected (from the sever), the application may not allow withdrawals, but still allow the teller to provide services to the customer, such as making a deposit, which is queued for final processing when the network (or server) is available again.

Candidate Service: Connection Manager

Monitors the network resources to determine if connectivity is available and if any server-based resources are available. Based on network availability, including the actual service endpoints, provides operational context back to the application.


  • Determine if network-dependent operations, such as synchronizing local data stores with a server, should be attempted.


  • On expensive networks, excessive consumption of bandwidth should be minimized.
  • On slow networks (due to heavy loads or minimal bandwidth), local-side execution may be degraded.

Bandwidth Management Requirement

While connected over low-bandwidth or when using expensive connections, the application must optimize network resource use.

Once an application has determined that it has a viable network connection, it then must determine the optimal use of that connection based on several factors such as the throughput of the connection and the cost of use. As bandwidth use changes (or is intentionally downgraded by the application due to user-defined cost parameters), application functionality should automatically adjust as necessary. Network usage can be costly both in real dollars and in application performance.


  • Support occasionally-connected applications.
  • Leverage low-bandwidth networks, such as dial-up or wireless carriers.
  • Require a rich user experience regardless of connectivity (none, low-bandwidth, high-bandwidth).
  • Provide data segmentation categories that use various synchronization strategies: must synchronize, synchronize on demand, synchronize on high-bandwidth connection, and synchronize based on time.


  • Network detection and quality of service assessment are challenging and require their own set of network resources.
  • It is difficult to determine the cost of a network connection by speed alone (dial-up versus GPRS).
  • Need for real-time monitoring.
  • Low bandwidth connectivity can be a subjective judgment.
  • Segmenting data into categories to determine which data can be synchronized can be difficult.
  • Unreliable networks may cause partial (incomplete) data synchronization.


A sales representative markets multiple brands. Before traveling, the representative updates her local data store with the most recent catalogs, pricing, itineraries, and CRM information. Away from the office, connectivity may be limited to expensive wireless connections or the occasional high-bandwidth connection at a store, hotel, or remote office. During times of low bandwidth connectivity, the representative transmits only important or short information, such as orders. Longer or less important transmissions, such as for catalog or contact information updates can wait until a higher bandwidth connection is available.

Candidate Service: Bandwidth Manager

Monitors network connections to efficiently use network-dependent resources required by the application. The service generates events when certain network thresholds are reached to optimize application behavior. To optimize the experience, it is necessary for the service to report levels (or types) of bandwidth capability. By providing attributes about the network, the application can determine what operations may be performed for optimal functionality at minimal network cost. For important functions, such as the transmission of software updates, the user should be notified when time or cost thresholds may be exceeded. With increased network capability there is increased expense (for example, cell networks). It is difficult to determine from an application's perspective whether the network is slow and inexpensive (such as local dial-up), or slow and expensive (such as hotel dial-up or some GPRS plans). Similarly, an application serving the same user population over the exact same network may encounter different network usage contracts (for instance an unlimited GPRS plan versus a limited one).


  • Combine with the Connection Manager to provide a more robust solution (such as a Communications Manager).


  • Bandwidth capability is fairly subjective and may vary from application to application.
  • Two network connections may be low bandwidth but one may be expensive (GPRS) and one may be inexpensive (local dial-up), each of which may change the desired network usage patterns.


Events and Notifications Requirement

Smart clients must dynamically react and adjust to their environment, which includes the network. Therefore, a robust communication (messaging) infrastructure is needed for generating, recognizing, and managing events and notifications from a myriad of sources.

Events and notifications provide the communication infrastructure for messaging inside the client application, between the client application and the server, and between the application and the end user. Because of their distributed nature on a variable network, smart clients have hypersensitive messaging requirements. We distinguish events and notifications based on their intended target. An event typically targets the application with system level information in contrast to a notification which targets the end user carrying a payload of primarily informational text. Here are some examples:

  • Observer Events (for example, active context changes)
  • Environmental Events (for example, network connectivity changes, device added/removed, system settings changed)
  • Data Events (for example, element synchronized, element dirty/pending)
  • User Action (for example, interaction with application menus)
  • Notifications (for example, server-based alerts, network-enabled features)


  • Support for multiple user interfaces (for example, input screens) simultaneously and potentially interdependently.
  • Provide notification service targeting the user, and an event service targeting the application.
  • Encourage functional reuse.


  • Network-blocking events.
  • Prioritized requests.
  • Event delegation.
  • Excessive intra-application messaging (for example, between components, windows, services).


An application-centric "dispatch" service receives and publishes system events and user notifications to registered delegates. Notification examples include the next task in a requisite user workflow process, confirmation of a received and processed data transmission, or an alert (from the server) of a pending data synchronization error.

Candidate Service: Activity Manager

The concept of the Activity Manager is to provide an application-centric message registration and distribution hub for receiving and routing events and notifications throughout the application. At application startup, activity generators and handlers register with the hub. Ideally, the Activity Manager could be pre-configured to process both industry standard events (for example, the presentation mode of the computing device has changed from portrait to landscape), and application-specific ones (for example, the numeric value in field X in form Y has exceeded its threshold).


  • Expedites development of the Activity Manager facilities using the .NET Common Language Runtime (CLR).


  • Performance and scalability challenges for processing potentially significant numbers of events (for example, queue management for guaranteed message delivery).

User Interface Category

This requirement category pertains to the user's direct, optimal interaction with the smart client application. An historical side-note on this category is that in May, 2004, the Board was meeting in England where the Smart Client Working Group presented some of its early ideas on extending smart clients via common services and frameworks. At the time, we borrowed the notion of the ASP.NET WebParts and applied it to the domain of smart clients and called it (predictably) SmartParts. We are pleased to see this concept eventually become real as described in the Composite Application Block listed in the Resources section below.

Dynamic Environment Configuration Requirement

Smart clients must dynamically configure their features for optimal use based on the capabilities of its host device and the surrounding environment.

Personal application servers (for example, laptop, tablet, PDA, phone) are rapidly evolving and giving rise to new kinds of computing platforms (such as Origami). Increasingly, applications will need to interrogate or discover the capabilities and limits of the host computer. Approaches to dynamic environment discovery include:

  • Device metrics (for example, display resolution, size, and color; input methods; pointing devices, graphics engine) based on standardized host attributes properties.
  • Standardized UI application profiles for stating preferred and minimal requirements to the host (OS and device).
  • UI components that are dynamically configured and plug into the Activity Manager (see Candidate Service above) using standardized connectors for exchanging environmental information. (For example, a system event: "in operational proximity of an infrared printer"; a user notification: "Secure network detected: Connect?")


  • Provide standardized mechanisms for applications to query their operating environment.
  • Provide a mechanism for applications to define and declare operational requirements to the host environment.
  • Appropriately respond to connected events and state changes as background activities affect information content.


  • There is no standardized host support for common responses to discovery requests and operational demands. Similarly, there is no standardized application UI profile schema(s) for defining application preferences and requirements to the host.
  • In some settings, the user may need to negotiate directly with the host environment, using the application, to access "non-standard" levels of functionality, such as connecting over a non-secured network.


Smart client applications (made smarter by smart devices) that notify the user of available resources in the current environment (for example, printers, network services, peer-computers). In the case of network services, the application determines that the use-cost and throughput will allow a complete refresh of the local data store from a server-side source without exceeding policy-based thresholds.

Candidate Service: Environment Manager

On behalf of the application, the Environment Manager generates parameterized queries to discover the capabilities and features of the host and brokers the responses. An extension of the Environment Manager is its ability to negotiate minimal requirements with the host device and its networked environment. (For example, screen size, mouse device, printer, local data cache has not expired, and so forth.)


  • Automatically configure application menus and features, update local data cache, and establish network connections, and so on based on an application profile.
  • Coupled with the Activity Manager, the Environment Manager provides a comprehensive application nervous system.


  • Complexity of heterogeneous devices.


Business Logic Category

Business logic is the heart and soul of most applications, including smart client ones. This category looks at some of the needs related to defining once and publishing to the many codified business rules.

Reuse and Portability Requirement

The business logic (rules) for smart clients must execute on the client for all of the features that are designed to work when the application is disconnected. Therefore, the application's business rules must be defined and maintained centrally (in a single location) on behalf of all the smart clients and distributed to the clients as needed.


Figure 1. Logic Distribution

For performance and scaling reasons it may be advisable to distribute the business rules to the client for local-side execution. But for the disconnected case, it is mandatory. Given this requirement for reuse and portability, we want to ensure that the business rules are maintained in a central location using a format easily-deployed and consumed by the client.

Monolithic applications achieve reuse of their business logic by referencing a shared repository of rules, perhaps implemented as stored procedures in a server-side DBMS or encapsulated in business objects accessed using remote method invocation. But smart clients must be self-sufficient when disconnected, which requires that the rules exist and run on the client. The portability of the smart client rules further requires that any updated rules are synchronized and persisted on the client side, as pictured in the graphic.


  • Execute complex business rules when disconnected.
  • Write the business logic once.
  • Deploy and execute on each of the client machines.
  • Deploy updated business rules without having to update the entire application.


  • Not all of the business rules may be executable on the smart client.
  • Not all of the smart clients may be using the most recent version of the business rules.


An insurance claim adjuster is in the field assessing the property damage caused to the policyholders by a recent and widespread natural disaster. The representative is able to calculate, assess, and issue checks based on the company's guidelines, even though her smart client claim's application is frequently disconnected. Whenever a network connection can be established, the application requests any updated rules from the company's server-side rules service and applies them as necessary.

Candidate Service: Rules Engine


Figure 2. Rules engine service

A general purpose rules engine (or rules manager) that executes codified business logic described in a portable (i.e. platform independent) format. The client application invokes the co-located rules engine by sending it business entities (i.e. state). In response, the engine applies its rules to the entities which results in specific action steps for the application.


  • The definition and format of the rules are resilient to technology and platform changes.
  • The engine can create audit trails that trace the what, why, and when for any action.


  • For the disconnected case, some client-side rules may require additional validation when the affected data is eventually synchronized with the server.


Data Category

With its focus on client-side data storage and management, this requirement category is large in scope and filled with complexity. Fortunately, there already exist some excellent guidance and application blocks to help.

Local Data Management Requirement

Equip the application with local data storage and management services that provide both optimal performance and capability whether connected or disconnected, and support for server-side synchronization.

Good smart client design strives to provide reasonable (and consistent) functionality whether connected or disconnected. Obviously, the disconnected state poses many challenges. Some smart clients may have no operational requirement for disconnected support yet still require local side storage for performance and scaling benefits. Other smart clients may require support for disconnected operations and, therefore, need a local cache and related data management services. With local data comes the additional requirement that any modifications must propagate once a connected state is established. When disconnected (or for performance reasons even when connected), the client may use a local store for all of its data needs. Beneficial byproducts are that the server load is reduced and the end-user experience is optimal on both slow and no-network connections. For the implementation that always uses a local store (regardless of connection state), developer productivity is improved since only one code source must be written. Many applications may have more stringent requirements that do not allow this latitude.

A simple example of a network-dependent application that continually relies on its local data store, regardless of its connectivity state, is Microsoft Outlook. You might say that Outlook is the precursor to smart clients. No matter the user's personal computing device, a desktop PC or a Pocket PC, Outlook information is cached and always available to the user. Whenever the user re-connects to Exchange Server, any pending e-mails or scheduled appointments are processed.


  • The user's experience with the application is always productive, even when disconnected from the (data) services of the server.
  • The client application uses a unified data model that works the same whether connected or disconnected which helps to reduce complexity and development cost.
  • The client can assure specific service levels of performance and uptime (less dependent on external systems for normal operation, which also reduces server load).
  • The client has greater flexibility in using reference data from the server since it need not be constrained by the server's exposed data structure or schema.


  • Local data store must remain secure on the client.
  • A persistent local data store may complicate application installation.
  • Sequential "replay" of transactional data must be supported when synchronizing with the server.
  • Certain server-side synchronization errors may require the user's intervention to resolve.
  • Conflicts resulting from multiple sources updating the same data must be handled.


A medical application, running on a tablet PC, is used daily by practitioners to record patient information in the clinic and in the field. Connectivity is a given in the clinic but not in the field. All relevant patient information is cached locally so the practitioner can review patient history and previous notes while recording new information, regardless of the patient's location. When the application reconnects to the clinic's server, all updated information is uploaded, and any new patient information from the other practitioners is also downloaded.

Candidate Service: Smart Data Manager

The concept of the Smart Data Manager borrows from the functionality of the Offline Application Block (based on .NET Framework 1.1) for queuing data operations while disconnected and replaying them on the server upon connecting again, and the Caching Application Block that provides an in-memory or on-disk cache for storing reference data that improves performance and supports data lookups when disconnected. The Caching Application Block has been incorporated into the Enterprise Library for .NET Framework 2.0.


  • Keeping the data as close as possible to the client improves performance and makes the system resilient against network related problems.
  • Reducing network traffic and server-side processing improves scalability.
  • Provides a common framework for a secure local data cache (in-memory and on-disk) supporting queued, synchronized updates to a server-side data repository.
  • Built-in support for network connection detection.
  • The Offline Application Block takes a service-oriented approach (i.e. loose coupling) when communicating with the server-side.


  • The Offline Application Block is not updated for use with .NET Framework 2.0.
  • May need to add support for canceling queued operations while disconnected.
  • Cascading data changes may be difficult to support while disconnected. Must be able to resolve server-side errors when synchronizing.
  • The need for extensive reference data may greatly increase local storage requirements and cause excessive network traffic when synchronizing.


Deployment Category

This requirement category concerns itself with the distribution of smart client applications to the end user. Smart clients have a higher bar to clear when it comes to the installation of their wares since they must first be deployed to the user's personal computing device(s) before they can execute. There is no doubt that the installation and update requirements for Web applications are effectively removed for the network-only user since this activity is managed by an IT staff on the backend on behalf of the total user community. Fortunately for the developer, there are a number of solutions that exist today that greatly help with the deployment of smart client applications.

Installation Requirement

Provide for the deployment and subsequent updates of smart clients using highly efficient means that are cost-effective and minimally disruptive to the user.

The ultimate goal for this requirement is to make software distribution of smart clients, whether initially or subsequently, as imperceptible to the end user as possible. In effect, it is to provide a comparable experience to the network-only users who need never concern themselves with software updates. Therefore, the most expedient delivery mechanism for smart clients is to leverage automatic updates through the network that address all facets of the process: packaging, validation, delivery, installation, updating, and un-installation. Similar to the Web-application deployed to a server, the smart client distribution package must be staged to a server before it can be transmitted to the end-user.


  • Any smart client application that is being actively maintained will be periodically updated and distributed due to any number of reasons: corrections and improvements, changes in the business, new requirements, and so on.


  • Requisite infrastructure to support smart clients. (For example, .NET Framework, OS service packs, third-party updates).
  • Installation without requiring the user to exercise administrative rights (recommended).


Deployment usage falls into three broad environments loosely defined as managed, partially managed, and unmanaged. The managed environment is usually administered by a professional IT staff that may use policies, procedures, and deployment tools to keep their users' computing environment up-to-date. The partially managed environment is less capable but strives, effectively, for the same results, often using many manual steps. Then there is the individual user who is responsible for installation and updates. The deployment and updating of smart clients must work well in all of these environments.

Table 3 lists the major deployment options and several of their prominent characteristics.

Table 3. Deployment models and characteristics

Characteristics No Touch DeploymentNo Touch Application LauncherSmart Stub DeploymentSmart Application DeploymentClickOnce
Ability to target clients for download    x
Ability to negotiate or elevate privileges xxxx
Ability to support disconnected operation   xxx
COM deployment support   xx
Deployment API  xxx
Model similar to Web deployment model x   x
Enables a high-level of deployment extensibility    x 

Candidate Service: No-Touch Deployment

This deployment model starts with copying an application's assemblies to a Web server. Whenever the user runs the application using its URL, whether initially or subsequently, Internet Explorer recognizes that the requested executable is managed code and streams all newer assemblies down to the client where it is placed in the local Web cache, noting the assembly's last modified date and time. On subsequent invocations of the application (using its URL), the request for binaries on the server will include the last modified date time. If newer assemblies exist, they will be downloaded. If no newer assemblies are found, the download cache will be used. Deploying a newer application involves copying any new or updated assemblies to the Web server.


  • Provides a Web-like deployment model.


  • User must always have access to the application's URL, which is accessed directly upon every application invocation.
  • Code access security may prevent certain desired installation behaviors. (For example, installation of files residing outside of the application assemblies).

Candidate Service: No-Touch Deployment Application Launcher

This deployment model uses an MSI-based "application launcher" to install and execute the application in a similar fashion to the above No-Touch Deployment option. The key difference is the process is started with a client-side installation program (the launcher) that runs with full trust. This gives the installation program greater functionality due to its elevated permissions. As with the No-Touch Deployment option, updated application assemblies need only be copied to the Web server whereupon they will be streamed to the user the next time the application is invoked through the launcher.


  • Simplicity of a Web install with the greater functionality of a fully-trusted installation program.


  • Must seed user's machine with the launcher program.
  • Additional effort needed to implement the MSI program.
  • User must always have access to the application's URL, which is accessed through the launcher upon every application invocation.


Candidate Service: Smart Stub Deployment

The Smart Stub Deployment model combines a MSI-based "application launcher" with an Automated Update Framework. The key difference here is that the launcher relies on the Automated Update Framework embedded in the application, and not No-Touch Deployment, to install the application. Currently there are three frameworks available to provide this functionality:

  • Updater Application Block
  • Updater Component
  • The Enterprise Library Updater Application Block (version 2)

A deployment manifest is used to declare the constituent pieces of the application, which must be deployed to a server for downloading to the user's machine. Updates are accomplished by modifying the deployment manifest and copying the new assemblies to the deployment server. The next time the application stub is launched, the deployment manifest will be checked for updates. If updates exist they will be downloaded. The use of the automated update frameworks allow more flexibility in the way the application is delivered. For example, the CLR only delivers through HTTP, while the Updater Application Block Version 2.0 can use any transport mechanism.


  • Application can run even when disconnected.


  • The Automated Update Framework increases complexity and size of the application.


Candidate Service: Smart Application Deployment

This model provides full programmatic customization of the installation process, enabling the smart client application to fully control all aspects of the update process. This approach may be necessary for distribution of large updates and updates of smart clients that must support an administrative installation to the network, from which end-user machines may be automatically updated.


  • Full programmatic control for almost any application-specific deployment requirement. (For example, periodic updating of business rules).
  • Update feature is integrated into the application itself using Microsoft Windows Installer (MSI) technology.


  • Potentially more complex to implement.

Candidate Service: ClickOnce Deployment

ClickOnce Deployment succeeds No-Touch Deployment as the most efficient (low impact) means to distribute Windows® applications. Users may initially install from a URL/UNC to a Web or file server or from a CD/DVD.


  • Potentially less complex to implement.
  • Installation can request, if needed, elevated permission levels from the user.
  • The application can determine if updates are available at startup, on demand, or at periodic intervals.
  • Supports managed environments where security policies apply to the installation of software.


  • Requires .NET Framework 2.0 on the user's machine or it must be "bootstrapped" during the initial installation process.
  • May not support full range of distribution requirements (see Smart Application Deployment).


Acknowledgements and Contributors

We hope that we have given you some new ideas to ponder as you gather requirements for your next smart client application. We are convinced that as software becomes more adaptive and contextually aware of its environment, it becomes more useful and accessible, and that is just plain "smart." We also hope we have stimulated further exploration into the design and implementation of general-purpose smart management services that satisfy the essential requirements of today's smart clients and the new ones of tomorrow.

This paper is the work of the Smart Client Working Group, which was formed from among the Microsoft Architect Advisory Board. Although the Board is now retired and its members have moved on to new endeavors, we remain thankful to Microsoft for their foresight, leadership, and generosity in providing several excellent opportunities to collaborate in an open and unfettered environment on the future of software architecture. We are especially grateful to Microsoft's Earnie Glazener and Harry Pierson for their management and direction. We also thank David Hill (Microsoft) for his valuable contributions and consultations with the Group, and to Paul Cross (Microsoft) for his excellent assistance facilitating the group's initial work in England. We are also indebted to the many architects, developers, and thought-leaders that have contributed to the current ideas and capabilities of the smart client model and continue to promote its usefulness.

The members of the Smart Client Working Group are:

  • Shannon Braun (SysKnowlogySysknowlogy)
  • Scott Colestock (Trace Ventures)
  • Victor Dossey (Getronics)
  • Loren Goodman (InRule Technology)
  • Rodney Guzman (InterKnowology)
  • Matt Hessinger (Group co-chair) (Hessinger Consulting)
  • David Hill (Microsoft)
  • Joe Hughes (Accenture)
  • Rockford Lhotka (Magenta)
  • Greg Poirier (Group co-chair) (Thomson)
  • Craig Randall (EMC)
  • Joe Shirey (Interlink)
  • Jim Wilt (NuSoft Solutions)

The Group commends the Chicago 4 (Shannon Braun, Loren Goodman, Greg Poirier, and Jim Wilt) for their efforts and dedication in seeing this paper to completion.