Enterprises frequently have to deal with part of their infrastructure that doesn't have the privilege of uninterrupted connectivity. Such system environments designed using Service Oriented Architecture (SOA) need a way to manage uncertain connectivity. SOA as an architectural paradigm depends on a set of services providing business functionality. These services may be distributed over different domains or geographical boundaries. SOA, characterized by independent and self-sufficient services primarily needs to handle the issue of data inconsistency that may result from a disconnect in such environments.

Some SOA business applications mandate systems or devices be in sync with the central business database even when connectivity is uncertain. "Disconnected SOA" or "Occasionally Connected SOA" are designed to deal with such SOA implementations so that they can work in offline mode and can connect to the central server whenever connectivity is available, i.e., they can work seamlessly while taking care of data discrepancies and inconsistencies. This kind of independent and self-sufficient nature of services with business integrity requirements needs intelligence to realize an offline SOA.

Unlike a connected architecture, an offline SOA (disconnected architecture or occasionally connected architecture) demands sophisticated distributed business logic wrapped over the architectural components to interchange data seamlessly while maintaining business data integrity. Such an architecture lets users use such services offline independent of any network latency or dependency or network outage thus increasing overall productivity. Enterprises can benefit from the location transparency that such an architecture provides. For example, the sales people can work when they are in transit or at a location where there is no connectivity.

Offline architectures have interesting implications for enterprise systems in creating services with non-persistent connectivity. The approach discussed in this article for dealing with common problems in these kinds of architectures is based on distributed data objects that not only carry data but also piggyback the metadata and change history details. This helps in designing distributed disconnected services and, in turn, helps maintain the integrity of the business information in an offline SOA. Invariably we're concerned with offline SOA scenarios involving enterprise services with some kind of enterprise data access. Hence the terms of service and data will be used interchangeably because the primary problem we're tackling in an offline SOA is that of data.

Scenarios for Disconnected Environments

Field Sales Force
One scenario for a disconnected SOA is a field sales force, where agents go from place to place invoking enterprise back-end services to while collecting information and passing the information to a central repository.

A typical example is the retail business, where a sales team approaches vendors to take orders. They go to geographically distant places with uncertain connectivity carrying handheld devices. A typical salesperson, at periodic intervals, will update the central repository with the data in his PDA. This opearion needs to be in sync with data collected by other members and consistent data sans redundancy.(Figure 1)

Multi-vendor Systems
Another scenario could be an enterprise that has multiple vendors who maintain independent databases, i.e., each vendor maintains its own local data store. These vendors update the data in the enterprise's central repository every fortnight. For example, consider a drug manufacturer that takes orders are at the end of the day from all the sales outlets that use its products.

Challenges Faced
Now the offline (disconnected or occasionally connected) invocation of enterprise services brings with it a few challenges likelost updates due to concurrency. In a disconnected SOA, when a client has read the data, closed the connection, and is working on it, there's only an optimistic lock on the database feeding the service. This means that the client is making an assumption that the data won't be changed by other clients working on the same source, as opposed to a locked version of events; where other clients would be denied access to the resource.

Data Validations
Having called it a disconnected environment, we also have to consider the gap between two sessions; one for when the data is being worked on by the end user and second when the updated data is being stored in the central database. Any inconsistent or insufficient information gathered during this period will be acknowledged only at the point of update. To elucidate, a field agent may collect data from all the prospective users in a certain format. Let's say he sends all his aggregated data once a week. Any data validation against the database or the central repository is known later and would be considered insufficient for the system as a whole.

Strategies/Solution Approach
The ideal solution to these challenges would be to have a technique in place to push the changes automatically or semi-automatically from the server side to the client application. Correspondingly it's also necessary to have a technique at the user end or client end to manage the unforeseen discrepancies that may arise when the updates or inserts or deletes are being carried out at the data source or a business rule kicks in. A general flow or handshake between the server and client will need to take the following steps:

1. Data transfer from the source to end-user systems (this could mean the necessary data or metadata to operate in a disconnected environment).
2. Business data is pushed to the server end in a consistent format when connected to the network.
3. A process needs to be in place to update the data and remove all concurrency inconsistencies.
4. A process needs to be in place to deal with child record conflicts or any trigger-based application conflicts.
5. Business data goes back to the end user or client with minor updates/acknowledgement.

While it might be difficult to articulate an all-encompassing solution to these issues, any disconnected SOA implementation must address the minimum pre-requisites of the architecture like maintaining a local copy of the data and checking data integrity when updating the source to prevent lost updates. We'll discuss in detail a couple of current technologies that will facilitate business integrity in disconnected services.

Below we'll show that ADO.NET and SDO not only help in providing a mechanism for transferring data but inherently manage the key issues of concurrency and version.

ADO.NET
ADO.NET is the data access component of the .NET Framework that helps in connecting to databases and manipulating data. The ADO.NET architecture has been uniquely designed to decouple the business logic layer from the data layer by introducing a new data access layer. The core component is the DataSet object: an in-memory cache of data representing a disconnected standalone entity that holds the data. Dataset combines the data tables and data relation object. Together they serve as a miniature disconnected implementation of a data source. ADO.NET objects can play a major role in .NET-based services in solving the concurrency issues across services in a SOA. Some of the features of ADO.NET that might help in disconnected architectures are mentioned below. (Figure 2)

Snapshots
When the data is accessed by an application, a snapshot of the database is stored. The data is then retrieved and stored in the dataset. When the application connects to the database to update the data a snapshot of the database is taken again and compared to the earlier one. If both are the same, the updates are committed.