When implementing an occasionally connected architecture for a solution, there are three fundamental requirements:

  1. Part of the overall solution, some smart client is deployed and installed on the desktop and a web only approach is not possible. The main rational being that a smart client can work in a disconnected mode which of course with a web application is not possible.
  2. Underlying infrastructure needs to be in place to support this. Infrastructure is not specifically networks and servers, but also both the operational environment and the user’s environment and machine. The operational environments need to allow things such as: data caching, local storage of user data, user profile details, etc.
  3. More robust exception management process – this is not only about handling errors but also understanding the fact that the application is in a disconnected state and needs to do things differently.

When designing an occasionally connected application, there are two design approaches that one can take - data centric or service oriented.

  1. Data Centric – Applications had a RDBMS of some sort installed locally and use the built-in capabilities of that RDBMS to propagate and sync data including resolving any conflicts.
    1. Server publishes data, which a client subscribes to and is copied locally. The conflict resolution (as changes can be both on the server or client) needs to be agreed upfront.
    2. Generally the database’s built-in conflict resolution is used – this makes it simpler for the application as one does not need to build this in the application.
    3. As there is only one data repository, the data convergence is guaranteed between the client and the server.
    4. Both the client and the server are tightly coupled.
    5. As a database needs to run locally, machines with small footprints or devices such as mobile phones will not be able to run this.
    6. If deployment is an issue then there is more work required here.
  2. Service-Oriented – Applications use the SOA paradigm and store information in messages which are queued (when disconnected) and send to the server when connected for processing.
    1. The client can interact with any service required and focuses on the service requests instead of the local data i.e. are loosely coupled.
    2. No local RDBMS required; of course some state information would still need to be saved.
    3. Better when needs to interact outside of the firewall (e.g. Internet or Intranet)
    4. Deployment is still required, but is simpler.

For Data centric application, from a design perspective the following aspects should be factored in:

  1. Application needs to be aware of the merge-replication schemes that are implemented as the application needs to optimise for data updates and conflicts.
  2. As a result, ACID properties are not used for transactions; instead a pub-sub model is implemented.

On the other hand, for Service-oriented apps, the application design should address the following:

  • Application has to implement asynchronous communication.
  • Overall solution needs to keep all the network interactions simple and cannot be complex.
  • Application needs to add data caching capabilities
  • Application needs to implement robust connection management (e.g. Manual vs. Automatic)
  • Implement a store-and-forward mechanism such as using MSMQ.
  • Application needs to implement a robust data and business rule conflict manager.
  • Interacting with CRUD like Web services.
  • The application and the work can be logically broken into “chunks” to allow one using a task-based approach.
  • The application should be able to handle both forward and reverse dependencies which in turn could be complex business logic.

As a high level guide, a data centric approach should be used when:

  • One can deploy a database instance on the client.
  • The application can function in a two-tier environment.
  • One can tightly couple the client to the server through data schema definitions and communication protocol.
  • There is a need for built-in change tracking and synchronization.
  • One wants to rely on the database to handle data reconciliation conflicts and minimize the amount of custom reconciliation code that needs to be written.
  • There is no need to interact with multiple disparate services.
  • Users are able to connect to a database directly through a LAN/VPN/IPsec.

And, a service oriented approach should be taken when:

  • One wants to decouple the client and server to allow independent versioning and deployment.
  • There is a need for more control and flexibility over data reconciliation issues.
  • The delivery team has expertise to write more advanced application infrastructure code.
  • There is a need for a lightweight client footprint.
  • The applications can be structured into a service-oriented architecture.
  • There is a need for specific business functionality (for example, custom business rules and processing, flexible reconciliation, and so on).
    • Note: One might also need to look at a few good rules engine if this is the case.
  • One needs control over the schema of data stored on the client and flexibility that might be different from the server.
  • The application needs to interact with multiple services using different communication technologies (Web services, Message Queuing, RPC, etc.).
  • There is a need for a custom security scheme.
  • The application needs to operate outside of the firewall.