Smart Client Offline Application Block

Microsoft Corporation

February 2004

Summary: Chapter 1 introduces the offline application block and reviews concepts that are important to the understanding of the block.

Contents

Who Should Read This Guide

Prerequisites

Chapter Overviews

Smart Clients and Offline Capability

Enabling Offline Functionality

When Is Offline Operation Appropriate?

The Offline Application Block

Customer Scenario

Summary

More Information

Smart clients are applications that are native to a user's PC and are also network-aware. By this, we mean that they are connected to a network (typically, the Internet) and that they can automatically download or upload updates to software, data, and work items.

This guide describes the design and features of the Offline Application Block that you can incorporate into your smart client applications. By incorporating the Offline Application Block into your code, you can extend your smart client application capabilities to download data and still function when disconnected from the network. For example, when connected, the application will be able to consume the data exposed by a Web service and then allow users to work on that data when no longer connected to that service.

Here is an overview of the guide's prerequisites and an outline of its contents.

Who Should Read This Guide

This guide is intended for software architects and developers who are developing smart client applications for the PC. (Personal Data Assistants [PDAs] and other alternative devices are not within the scope of this guide.)

Prerequisites

To benefit fully from this guide, you should have an understanding of the following technologies:

• Microsoft® Visual C#® development tool
• Microsoft Visual Basic® development tool
• .NET Framework
• Extensible Markup Language (XML)
• Microsoft SQL Server™ Desktop Engine (MSDE) development tool
• Message Queuing (MSMQ)
• Multi-threading

Chapter Overviews

The remainder of Chapter 1 gives a high-level description of the Offline Application Block architecture and includes a customer scenario, which is further developed in Chapter 2. Here is a summary of the rest of the chapters in this guide:

• Chapter 2 is examines the Offline Application Block features, architecture, and design, as well as its relationship to other components that support it, such as the Caching Application Block.
• Chapter 3 covers the QuickStarts that ship with application block code. Once you understand the features of the Offline Application Block, you can use the block in your development efforts. A QuickStart walks you through a feature, code concept, or complex task and also includes example code. The QuickStarts provided are:
  • Connection Management QuickStart
  • Download QuickStart
  • Upload QuickStart
  • Insurance Claims QuickStart
• Chapter 4 explains how to configure, deploy, and secure your applications.
• The Reference section documents the classes used in the Offline Application Block.
• Appendix A documents the test cases used to test the Offline Application Block.

Smart Clients and Offline Capability

Before the advent of smart clients, applications were considered to be either thick or thin clients. A thick client stores all applications on the client computer and has a user interface that is capable of displaying complex graphics and animation. On the other hand, a thin client has all its applications stored on the server. Basically, it only retrieves and displays data. A major concern for thin clients is that data is transferred over many round trips to the server, slowing performance. A major concern of thick clients is that distribution is challenging and causes porting issues. The smart client is a solution that combines the best features of both approaches.

A smart client provides the same rich interface as a thick client and also has the ability to manage content changes efficiently. Moreover, a smart client can provide these features while minimizing the resources—such as disk space and memory—that it uses.

A smart client also takes advantage of such .NET features as the ability to automatically deploy and update applications, and it can be designed to function while offline. For more information about these and other features, refer to the Overview of Smart Client Applications in the Microsoft Office System.

Enabling Offline Functionality

Users often require that smart client applications continue to function while disconnected from the network. There are two approaches to enabling offline functionality in a smart client application: a data-centric approach and a service-oriented approach. With the data-centric approach, the client employs a local database and a replication mechanism to manage changes to the data in offline mode. With the service-oriented approach, the client interacts with a number of services through service requests. While the application is in offline mode, it can defer service requests until it reconnects to the Web service.

Each method has its advantages and disadvantages and is suited to different styles of applications. Our emphasis is on the service-oriented approach but we cover both for completeness. Figure 1.1 illustrates both the service-oriented and the data-centric approaches.

Figure 1.1 . Service-oriented and data-centric approaches

Data-Centric Approach

Applications that are coupled to the data on the server employ the data-centric approach. A local database manages changes to the locally held data and then uses merge-replication to propagate these changes back to the server.

The client first creates a subscription to the data it needs so that it can copy that data to the local data store before the client goes offline. Once the client is offline, it makes changes to the local data through calls into the local data store. Then, when the client goes back online, the data store's merge-replication mechanism propagates the changes made to the data on the client back to the server. Changes made to the data on the server may also be propagated back to the client. Any conflicts encountered during the merge phase are handled according to the conflict resolution rules specified on the server or the client, or according to custom rules defined by the data store administrator.

Characteristics of the data-centric approach include:

• The approach provides robust data conflict detection at the column and row level of the database. Additionally, it provides data validation and constraints.
• The client is coupled to the data store, which means that changes to the data store schema have a direct impact on the client. The client can provide offline support for the data stores to which it subscribes.
• Merge-replication is a two-tier architecture and therefore has constraints in terms of manageability and maintainability.
• The approach requires a local data store such as SQL Server for Windows® CE (SQLCE) or MSDE to be installed on the client that can replicate with the server. This may not be suitable for applications running on small devices or on devices that require a light-touch deployment mechanism.
• All change tracking code is contained inside the relational database management system (RDBMS). There is no need to write additional change tracking or conflict detection and resolution code.

For more details on the data-centric approach, see Merge Replication.

Service-Oriented Approach

A smart client that forms part of a service-oriented solution interacts with services on the network through service requests. These services may be implemented as Web services or by some other mechanism, but the essential feature of this approach is that the client is not tightly coupled to the services it uses, and both the client and services are independent of each other.

In this approach, the client is free to interact with whatever services are required. Also, the client is focused on the service requests themselves rather than on making direct changes to locally held data. The service requests may lead to state changes on the client or the server, but such changes are by-products of the service requests.

Characteristics of the service-oriented approach include:

• Offline logic is encapsulated on the client.
• Client data schemas can be different than on the server.
• Customized business logic determines conflict detection and resolution.
• More design and coding are required to implement a service-oriented approach.

To support smart clients when working offline, an infrastructure is required that allows the details of the service requests to be stored so that they can be executed when the client reconnects to the network. Such an infrastructure consists of the following four main elements.

• Service Agent–The service agent provides the primary access point to the service. It manages all client interaction with the service and encapsulates all of the necessary logic to allow the client to create service requests.
• Service Request–All details of the service request are encapsulated in a service request object. The service requests are then persisted in the service request queue until the executor component is ready to process them. The service request object is responsible for making the actual service request.
• Service Request Queue–The queue provides persistent storage for the service request objects.
• Executor–The executor is responsible for taking service requests from the queue and executing them when the client reconnects to the network. Once the service request has been completed, the executor informs the service agent so that it can inform the client.

Figure 1.2 illustrates these four elements and shows how they relate to each other. This drawing can be considered as a representation of the capabilities that must be included in a component that uses a service-oriented approach. Another way to view it is as a representation of the classes such a component will have.

Figure 1.2. Four components of a service-oriented approach

In addition to the four elements described above, there are a number of other issues that have to be considered before offline support can be built into a smart client application. For example, it is necessary to have some form of notification mechanism so that the executor can begin or suspend service requests from the queue. The Offline Application Block provides a Connection State Management component for this purpose.

When Is Offline Operation Appropriate?

When deciding how to design your application for offline use, you need to consider which tasks you want users to be able to perform offline. Some tasks will not make sense when the application is disconnected and others will only be able to be partially completed when offline.

Note   Tasks are discrete and independent units of work that the user expects to be able to complete when interacting with the application.

Tasks that require a single service request are well suited to offline scenarios. Such tasks follow a "compose and forward" model, where the user specifies all of the required data for the service request, which is then forwarded to the actual service when the client reconnects. Examples of this type of task are: composing an e-mail, composing a meeting request, and entering order information. All of these tasks are discrete items that the user can complete offline and that result in a single service request.

In contrast, tasks that require multiple service requests to be completed are difficult to manage offline because the results from the intermediate service requests will not be available until the application is reconnected to the network. To the user, the task will appear to be suspended until reconnection occurs, making for a poor user experience.

As well as considering how tasks interact with the back-end services, you also need to consider what data needs to be cached on the client to support those tasks. Such data will have to be retrieved before the client application goes offline. This means that task reference data, its validity, and other constraints need to be carefully considered.

An essential consideration of all user applications is to make them as intuitive as possible. Users should be able to easily tell what tasks are pending synchronization, when synchronization occurs, and which tasks have succeeded and which have not. Tasks that are not available when offline should be shown as disabled on their corresponding menu item or toolbar button.

The Offline Application Block

There are certain capabilities that must be built into the application to support the ability to work while offline. They include:

• Detecting the presence or absence of network connectivity, thus enabling the application to behave according to its online or offline state
• Caching the required data so that the application can continue to function even when the network connection is not available
• Synchronizing the client application state and/or data with the server when the network connection becomes available

The Offline Application Block provides reusable code and recommendations that you can use to build these offline mode capabilities into your application. It also takes advantage of other block components. For example, it uses the Caching Application Block to make use of the cache and as the foundation for its Reference Data Cache.

For more information on the caching block, refer to Caching Application Block for .NET.

Important   Smart client applications must be designed to support offline capabilities. You cannot simply plug the Offline Application Block into an existing application and expect it to work. For example, if you download the block and incorporate it into an existing application, you will not be able to force the application offline—you must design that feature into the smart client. The block does provide samples to help you understand the processes, but the block is not production ready and the samples are meant only as a recommendation.

Because the Offline Application Block uses a service-oriented approach, the capabilities (or classes) that it includes correspond to those shown in Figure 1.2. The following figure, Figure 1.3, shows the Offline Application Block's corresponding subsystems, which are loosely coupled components.

Figure 1.3. High-level view of the Offline Application Block architecture

Table 1.1 describes each of the subsystems shown in Figure 1.3.

Table 1.1 Definitions of Block Elements

Security

The Offline Application Block does not provide a security schema. It does, however, support encryption and signing of all data stored in the cache and in queues. Use of encryption and signing is not mandatory but it is highly recommended. By using these security measures, applications can protect their data while it is stored temporarily on the hard disk. For more information about security and encryption, refer to Chapter 4.

Customer Scenario

This section provides an example of a business application that requires offline capabilities. We use this scenario throughout the guide to illustrate the functions of each subsystem within the Offline Application Block.

David Campbell is an insurance claims adjustor for Humongous Insurance. He is responsible for the western region of Washington and frequently travels to his client's home or workplace to complete claims. Humongous Insurance analyzed the process flow of claims from their initial stage to their final stage, and determined that it was important for claims adjustors to enter detailed information while away from the office. The challenge and solution for the development team was to create an offline environment for insurance adjustors to complete claims electronically.

Humongous Insurance requires that the application detect its connection state (whether it is online or offline). Depending on the design of the offline component, the insurance adjustor's user experience may or may not change depending on the connection state. It is possible to design the offline component so that the online/offline changes are transparent.

In preparation for working offline, the application must download work items and the associated reference information pertaining to each work item. Additionally, the application will execute business logic while offline.

When a claims adjustor enters data offline, the data is saved in a message. Messages are stored locally until a connection can be made with the corporate network. Once connected to the corporate network, the offline environment automatically synchronizes the message with the Web service.

These capabilities provide David with a seamless application environment whether online or offline.

Summary

This chapter explained the smart client premise and provided an overview of concepts important to the Offline Application Block. These concepts include the following:

• Smart clients use a service-oriented approach to enable offline functionality.
• Offline functionality is best suited to tasks that use a single service request.
• Offline functionality allows users to download data from the network and then work on that data while disconnected from the network.
• The Offline Application Block is made up of the following subsystems:
  • Service Agent Management that interacts with the other subsystems and server
  • Connection State Management that detects whether an application is online or offline
  • Reference Data Management that downloads reference data, which is then stored on the local machine
  • Message Data Management that handles data requests while offline.

More Information

The following links provide more information about Patterns and Practices, smart client, and other blocks you can use to find more information.

Patterns and Practices

Patterns and Practices Library

Overview of Smart Client Applications in the Microsoft Office System

Application Architecture for .NET: Designing Applications and Services

Start | Previous | Next