Browse DevX
Sign up for e-mail newsletters from DevX


Managing Offline Clients with the Smart Client Offline Application Block : Page 2

The offline functionality provided by smart clients offers a lot of opportunity for developers, but there are numerous implementation approaches. The Smart Client Offline Application Block from Microsoft will disperse the confusion and let you leverage this technology in your own smart clients right away.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

Emissary and Fiefdom: The SOA Architecture
Figure 1. SOA Structure: This image shows the Service Consumer and the Service Provider platform on which the emissary and the fiefdoms are built.
To understand how to manipulate a smart client, it's a good idea to first map out its role as part of a service-oriented architecture (SOA) structure (see Figure 1).

As Figure 1 shows, there are two platforms: the service consumer platform (emissary), which includes the smart client, and the service provider platform (fiefdom), which includes Web services.

The fiefdom follows the principle "Never trust an outsider." Typically, fiefdoms are an organization's enterprise applications. Why? Because fiefdoms allow data access and data manipulation only through a set of well defined interfaces. For example, a SQL Server 2005 instance that exposes stored procedures via Web services for data access and data manipulation is a fiefdom. In that scenario the only way for outside persons and software components to manipulate data is via the set of well-defined interfaces exposed by those stored procedures. In short, a fiefdom offers services rather than direct data access to its consumers.

An emissary is the client. It uses services to communicate through well-defined interfaces with the fiefdom. The fiefdom and the emissary have no direct references to each other—a very big advantage in the evolution of software components.

Figure 2. Two Approaches: This image compares the service oriented and the data oriented approach to building distributed applications.
When you implement the emissary as a smart client, you gain the ability to add offline support. Offline support means that the emissary can work with the fiefdom without any physical connection being present during execution. How can this be achieved?

The answer lies in the way that the client receives and accesses data. Data that the client needs to make a service request to the fiefdom is called reference data. Often this is static data such as product catalogs and customer lists. The emissary can download static data from the fiefdom, storing and caching it locally. But there is another kind of data, user data, which is generated by the emissary and includes items such as orders and bank statements. The emissary transmits these through service requests to the fiefdom where the data can be processed further.

The Components of the Application Block
So now that you know that smart clients can deliver the application without an underlying connection to the fiefdom, how do you make it work? There are two approaches: data-oriented and service-oriented. The data-oriented approach uses a local database (such as MSDE) where the client stores changes while offline. This local database can then be synchronized with the backend database when the smart client is back online. In the service-oriented approach the smart client uses service requests, which are cached locally and then executed when the connection is restored. Figure 2 shows both approaches.

Figure 3. Workflow: This figure shows the workflow of the components used in the Smart Client Offline Application Block.
The Smart Client Offline Application Block from Microsoft is a toolkit that helps you implement the service-oriented approach. It provides an infrastructure to cache service requests locally until the network connection is back. This infrastructure is built on top of these four components:
  • Service Agent: The Service Agent is a central component where all the other services of the building block can be accessed.
  • Service Request: All details for a service request are stored in a service request object, which is stored in a queue awaiting execution.
  • Service Request Queue: Stores the service requests until the underlying network connection is restored.
  • Executor: Takes the cached requests from the queue and executes them.
Figure 3 shows the workflow among these components.

The Smart Client Offline Application Blocks provide these services:
  • Determine if a physical network connection is available, and switch between offline and online modes.
  • Cache the reference data.
  • Execute locally stored service requests when a connection is made.
  • Provide extension points for the customization of the Smart Client Offline Application Block.
Figure 4 shows a logic flow diagram of subsystems within the Smart Client Offline Application Block. All of these subsystems are loosely coupled so it's very easy to change or extend them. The Smart Client Offline Application Blocks offers interfaces for implementing your own components.

Table 1 describes a few of these subsystems.



Connection State Management

Makes it possible to check if a connection to the network is available. This process is performed automatically or started manually.

Service Agent Management

Coordinates the work with all other subsystems of the Building Block and creates an event when a service request completes successfully.

Reference Data Management

Makes it possible to store reference data locally so that it can be used in offline mode.

Message Data Management

Manages the caching, queuing, and execution of service requests.

Figure 4. Logic Flow Diagram: This graphic shows the several subsystems into which the Smart Client Offline Application Block is divided.
Figure 5. Internal Design: This figure shows the internal components used by the Smart Client Offline Application Block.

Figure 5 shows the internal design of the Smart Client Offline Application Block and the components behind the subsystems that carry out specific tasks.

Table 2 gives detail on these components.



Connection Detection Strategy

Determines if a connection to the underlying network is present.


Manages the connection detection providers. Through the implementation of the interface IConnectionDetectionStrategy you can plug in your own written connection detection providers.


When the smart client is in online mode, the executor takes the cached service requests from the local queue and executes them against the proper online proxy.

Queue Storage

Provides a cache where service requests can be stored when the smart client is in offline mode.


Provides an interface to the physical queue storage.


Provides features for storing reference data locally.


Provides an interface to the available cache providers. The features of the Caching Application Block are used here.

Cache Block

The complete collection of caching storage providers.

Application Service Agent

Stores service requests locally during offline mode and accesses the online proxy.

Online Proxy

Communicates with the Web service and stores reference data in the local cache when necessary.


A base class from which to derive your own service agents. It is responsible for registering service agents in the Service Agent Registry.


The Service Agent Manager returns the result of a service request back to the correct service agent.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date