Introduction to Intelligent Client Offline Application Block

xiaoxiao2021-03-06  63

Introduction

Release Date: 8/6/2004

| Update Date: 8/6/2004

Introduction

Microsoft Corporation

Summary: Chapter 1 introduces the OFFLINE Application Block and explores the concept of understanding application blocks.

This page

You should read this guide Prerequisites Chapter Overview Intelligent Client and Offline Features When is offline? When you apply offline operations? OFFLINE Application Block Customer Plan Summary More Information

The smart client is an application located on the user's local PC and has a network aware function. Here, we think they have been connected to the network (usually referred to as the Internet), and can automatically download or upload updates to software, data, and work items.

This guide describes the design and functionality of the OFFLINE Application Block that can be merged into the smart client application. By incorporating the Offline Application Block into your code, you can extend the functions of the smart client application, making it available, and can still work normally without disconnecting the network connection. For example, when connected, the application will be able to store data disclosed by the web service, and then user can process the data when the user is no longer connected to the service.

Here are an overview of the prerequisites of this guide and its contents.

Should read this guide

This guide is written for the development of software architects and developers for smart client applications for PC. (Personal Data Assistant [PDA] and other alternative devices are not within the discussion of this guide.)

Back to top

Precondition

To benefit from this guide, you should learn about the following techniques:

• Microsoft Visual C # (R) Development Tool • Microsoft Visual Basic (R) Development Tool • .NET Framework • Scalable Markup Language (XML) • Microsoft SQL ServerTM Desktop Engine (MSDE) Development Tool • Message Queue (MSMQ) • More Thread

Back to top

Chapter Overview

The rest of Chapter 1 provides advanced description of the OFFLINE Application Block architecture and includes a customer plan that will be further developed in Chapter 2. Below is a summary of this guide:

• Chapter 2 analyzes the function, architecture, design, and relationships of other components (such as Caching Application Block) that supports it. • Chapter 3 describes QuickStart, which is included with the application block code. After you understand the functionality of Offline Application Block, you can use the application block to your development process. Each QuickStart introduces you to a function, a code concept or a complex task, and also contains sample code. The QuickStart provided includes:

• Connection Management QuickStart • Download QuickStart • Upload QuickStart • Insurance claim QuickStart • Chapter 4 explains how to configure, deploy and protect your application. • The "Reference" section describes the classes used in the Offline Application Block. • Appendix A describes test cases for testing OFFLINE Application Block.

Back to top

Intelligent client and offline function

Before the smart client appears, the application is divided into fat client and thin client. The fat client stores all applications on the client computer and has a user interface that can display complex graphics and animations. On the other hand, the thin client stores all applications on the server. Basically, it is only responsible for retrieving and displaying data. The main problem with the thin client is that the data needs to be round-trip to transfer to the server, thereby reducing performance. The main problem with the fat client is that allocation is more complicated and will lead to port issues. The smart client is a solution that combines the best features of these two methods. The smart client provides the same adequate interface with the fat client, and can also manage content changes. In addition, the smart client can minimize the resources it used while providing these features (for example, disk space and memory).

Smart clients can also take advantage of certain .NET functions (for example, automatic deployment and updating applications), and can be designed to operate normally when offline. For more information on these features and other features, see Overview of Smart Client Applications In The Microsoft Office System.

Back to top

Enable offline function

Users often require smart client applications to continue running after disconnecting the network. In the smart client application, there are two ways to enable offline function: data-centric approach and way-oriented approach. With data-centric methods, the client can use the local database and replication mechanism to manage changes to data in offline mode. With service-oriented methods, the client can interact with many services through service requests. If the application is offline mode, it can post off service request until you are reconnecting to the web service.

Each method has its advantages and disadvantages, and is applicable to different types of applications. Our focus is on service-oriented methods, but in order to maintain integrity, we will introduce these two methods. Figure 1.1 shows a service-oriented method and a data-centric approach.

Figure 1.1. Service-oriented method and data-centric approach

Data-centric approach

The application combined with the data on the server uses data-centered methods. Local Database Management changes made by the locally saved data, then use merge replication to return these changes back to the server.

First, the client creates a subscription to the required data so that the client can copy the data into the local data store before the offline. Once the client offlines, it will change the local data by calling the local data storage area. Then, when the client is renewed, the merge replication mechanism of the data storage area will return the client data to the server. Changes made to server data may also pass to the client. Any conflicts encountered during the merge phase will process the conflict resolution rules specified on the server or client, or to process depending on the custom rules defined by the data storage area administrator.

The data-centric approach includes the following features:

• This method provides reliable data conflict detection with column levels and rows of databases. In addition, it provides data verification and constraints. • The client combines with the data store, which means that the changes made to the data storage area architecture will directly affect the client. The client can provide offline support for its subscribed data storage area. • Merging Copy is a two-layer architecture that is constrained in manageability and maintainability. • This method requires mounting local data stores (eg, SQL Server for Windows CE (SQLCE) or MSDE) on the client to replicate with the server. This may not apply to applications on devices running in small devices or require simple deployment mechanisms. • All change tracking code is included in the interior of the relevant database management system (RDBMS). You don't need to write other changes to track code or conflict detection and solving code.

For more information on data-centric methods, see Merge Replication.

Service-oriented method

The smart client is an integral part of the service solution that interacts with services on the network through service requests. These services may be implemented as a web service, or through some other mechanism, the basic feature of this method is that the client does not closely combine with the services it use, the client and services are independent of each other. In this method, the client can freely interact with any of the services you need. In addition, the client will focus on the service request itself instead of being directly changed on the local saved data. Service requests may cause state changes on the client or server, but these changes are just the side effects of service requests.

Service-oriented methods include the following features:

• Offline logic is encapsulated on the client. • The client data architecture can be different from the architecture on the server. • Customized business logic determines conflict detection and resolution. • Realize the service-oriented approach requires more design and encoding.

To support the intelligent client while working offline, you need to use an infrastructure that allows the storage service request details, so when the client reconnects to the network, you can perform these service requests. Such an infrastructure consists of the following four main elements.

• Service Agent - The main access point of the service agent provides services. It manages all the interactions of the client and the service and package all necessary logic to allow the client to create a service request. • All details of the service request - service request are packaged in a service request object. The service request is then retained in the service request queue until the execution program component can be processed. The service request object is responsible for issuing an actual service request. • Service Request Queue - The queue provides a persistent storage area as a service request object. • Executers - When the client reconnects to the network, the executor is responsible for extracting a service request from the queue and executes them. After the service request is completed, the execution will notify the service agent so that it can notify the client.

Figure 1.2 shows these four elements and showing the relationship between them. This figure can be viewed as a representation of the function necessary to include the service method. It is also possible to see it as a representation of the class of such components.

Figure 1.2. Four components of the service-oriented method

In addition to the above four elements, many other problems are needed, and then the offline support can be constructed into the smart client application. For example, you must have some form of notification mechanism so that the program can start or hang a service request in the queue. To this end, Offline Application Block provides a "Connection Status Management" component.

Back to top

When is it easy to do offline?

When you decide how to design an application for use, you need to consider the tasks that users can perform in offline. Some tasks are meaningless when the application is disconnected, and some tasks can only be partially completed in the offline state.

Note When interacting with an application, the task is the scattered and independent work unit expects to be able to complete.

The task requiring a single service request is ideal for offline schemes. Such tasks follow the "Pre-write forwarding" model, in which the user specifies all the data required by the service request, then forward it to the actual service when the client is reconnected. Examples of such tasks include: writing email, writing a meeting invitation, and entering order information. All these tasks are independent projects, and users can complete them offline, and they only generate a single service request.

In contrast, the task requested to complete multiple service requests is difficult to manage in the offline state, because the results of the intermediate service request are not available before the application is reconnected to the network. For the user, the task will be displayed as hang before reconnecting, which will cause a bad user experience.

When considering how the task interacts with the backend service, you also need to consider which data needs to be cached on the client to support these tasks. These data must be retrieved before the client application is offline. This means that task reference data, its effectiveness and other constraints need to be carefully considered.

One basic consideration of all user applications is to make them intuitive as possible. Users should be able to easily divide which tasks are hang synchronization, when synchronization occurs, which tasks have been successfully completed and which tasks have not been completed. The task that is not available offline should be displayed as disabled on their corresponding menu items or toolbar buttons. Back to top

Offline Application Block

Some specific functions must be built into the application to support offline work. They include:

• Detects whether the network connection exists so that the application can execute the necessary data according to its online or offline, so that even when the network connection is not available, the application can continue to run • When the network connection is available, The status of the client application and / or the data and server synchronization

Offline Application Block provides reusable code and suggestions that can be used to build these offline mode functions into applications. It can also take advantage of other block components. For example, it can use Caching Application Block to use cache and use the CACHING Application Block as its reference data cache.

For more information on cache application blocks, see Caching Application Block for .NET.

Point smart client applications must be designed to support offline functions. You cannot simply insert Offline Application Block into an existing application and expect it to work properly. For example, if you download the application block and incorporate it into an existing application, you will not be able to force the application to go offline - you must design this feature into the smart client. The application block does provide an example that helps you understand the process, but the application block is not ready-made product, and the example is only provided as a suggestion.

Because the Offline Application Block uses a service-oriented method, it contains the functions (or class) corresponding to the functions shown in Figure 1.2. Figure 1.3 below shows the corresponding subsystem of the Offline Application Block, which is loosely coupled components.

Table 1.1 describes each subsystem shown in Figure 1.3.

Table 1.1 The definition subsystem of the block element Description Connection Status Management "Connection Status Management" Detection application is on an online status or offline. There are two ways to determine the connection state: manually judgment or judge by automatic process. If automatic judgment is selected, the connection status is expressed as multi-layer connectivity including the network layer and the application connection (note that application connection detection is not implemented in the application block). The behavior of the application varies depending on the connection state. Service Agent Management "Service Agent Management" is interacting with these elements of Offline Application Block ("Message Data Management", "Reference Data Management"), and the server. It will coordinate to return the task to the application. Reference Data Management "Reference Data Management" with "Service Agent Management" and "Message Data Management" work, the reference data stored on the local computer is described below. In most cases, reference data is read-only data used to complete the workflow. "Reference Data Management" allows the reference data to be consistent with the data on the server. It stores messages in the "Queue" to download reference data. Then, "execute program" will use the message service request with the service connection, and the reference data will be downloaded. Message Data Management Message Data is data created during workflow. This data will be stored in a local queue when the application is in offline. When the application is online, "Execute Programs" will remove messages from "Queu", issue "Service Request" with server synchronization data, and then the data will synchronize with the server.

safety

Offline Application Block does not provide a security architecture. However, it supports encryption and signatures of all data stored in the cache and queue. The use of encryption and signatures is not mandatory, but it is highly recommended to use it. By using these security measures, the application can protect the data when it is temporarily stored on the hard disk. For more information on security and encryption, see Chapter 4. Back to top

Customer plan

This section provides an example of a business application that requires offline functions. We will use this scenario in the entire guide to explain the functions of each subsystem in the OFFLINE Application Block.

David Campbell is the insurance claims coordinator for Humongous INSURANCE. He is responsible for the business in Western Washington, and often runs between his customers' place of place or working locations. Humongous Insurance analyzes the process flow from the initial stage of claims to the final stage, and believes that the claims coordinator is important during the departure of the office. The challenges and solutions of the development team are to create an offline environment that enables the insurance coordinator to complete the claims in electronically.

Humongous Insurance requires an application to be able to detect its connection status (is an online status or offline state). Depending on the design of the offline assembly, the user experience of the insurance coordinator may (or not) change according to the connection state. The off -cher assembly can be designed to make the change in the online / offline.

During the preparation of offline work, the application must download work items and associated reference information related to each work item. In addition, the application will perform business logic at offline.

This data is saved in the message when the claim coordinator inputs data in a offline state. The message will be stored locally before establishing a connection to the enterprise network. After connecting to the enterprise network, the offline environment will automatically synchronize the message with the web service.

These features provide a seamless application environment for David (whether it is online or offline state).

Back to top

summary

This chapter describes the prerequisites of intelligent clients and provides an overview of the important concept of Offline Application Block. These concepts include:

• The smart client uses a service-oriented method to enable offline function. • Offline function is most suitable for tasks using a single service request. • Offline function Allows users to download data from the network, then process data in the case of disconnecting the network. • OFFLINE Application Block consists of the following subsystem:

• "Service Agent Management" with other subsystems and servers • Detect applications "Connection Status Management" • Download Reference Data (This data will be stored on the local machine) Management "•" Message Data Management "for processing data requests in offline state

Back to top

More information

The following links provide more information about the Patterns and Practices, smart clients, and other application blocks, you can use these links 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

Go to the original English page

Back to top