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.

Time Stamping
This is similar to snapshot isolation but here we compare timestamps instead of snapshots. When the application connects to the database, it makes note of the timestamp. The database maintains a record of when different applications/services had access to, retrieved, or updated the data. Before updating the records in the database, the last timestamp on the data and the timestamp on the service are compared. If they're the same, the database is updated successfully.

Metadata and Data Integrity
The dataset contains rows, columns, and Constraints and Relations (DataRelation) that combine to form the objects of the dataset. DataRelation allows the service to retrieve the metadata with the data. When changes are made to the data in the dataset, the constraints and relationships are maintained and the data isn't flattened. When the database is updated, the metadata gets updated too maintaining data integrity.

ADO.NET and XML
ADO.NET leverages XML to transfer datasets over the wire. The advantage to transmitting datasets as XML is that any endpoint that is XML-aware can receive and process the dataset, a big advantage in a SOA world. It means that the receiving endpoint doesn't necessarily have to be an ADO.NET component. These days most databases have XML-in and XML-out capabilities that lets ADO.NET to talk to them. Another advantage of XML is that it's not proprietary like the binary protocols for data interchange.

Service Data Objects (SDO)
The concept of service data objects (SDO), a recent standard offered by a few SOA vendors, facilitates the abstraction of accessing data and its manipulation in an SOA world. While ADO.NET as discussed above is meant specifically for databases as data sources, SDO isn't restricted to any particular data source type. SDO is essentially a disconnected architecture in that clients aren't connected to the data source as they perform manipulations. SDOs are already used as a standard for transmitting data in some of the specifications used to realize a SOA-like Service Component Architecture (SCA). They don't repeatedly hit the data sources every time the data is changed. Instead they maintain a Data Graph that holds the data in the form of a graph of interrelated Data Objects. To help represent the data in the form of a graph the SDOs are given the ability to make references to or contain other data objects as their attributes. SDOs have a facility called Change Summary to maintain a record of the changes that were made and so the original state of the data is preserved. (Figure 3)

CHANGE SUMMARY
The provision of a change summary in the SDO lets the client record the changes that were made to the data and retain the original face of the data (as it was, when it was read) and to restore a graph of the data objects to the state they were in when logging began.

Logging is a feature that can be disabled and the change summary no longer recorded. The change summary indicates the exact changes so, to reduce the amount of data being sent back and forth, only the change summary is sent.

This feature can help avoid the lost updates. Just before writing the data back to the database, the change summary, with its initial data state store, can be used to check to see if the data in the database has been changed while the client was disconnected. If the data hasn't changed the data in the database can be updated without any lost updates.

METADATA
SDO implementations enable services to exchange metadata on the source and enforce a certain level of integrity . SDO also maintains relational integrity through the validations and the rules captured in the metadata. The metadata can be captured from the XML Schema or the relational database or any structured representation. So if employees and departments are related, then an employee referring to a particular department must be updated when the department is deleted otherwise any action will be disallowed.

SDO AND XML
When an SDO DataGraph is serialized, it is in XML format. When two services interact via SDO they communicate in XML. This means that any service may be sent an SDO and it should be able to read it and make corresponding objects out of it. This is a major advantage compared to normal Java or C# data, which would be incomprehensible to other platforms.

OBJECT COMPARISON SUPPORT
SDO can also compare two data objects for equality. As discussed a disconnected architecture needs to check the new state of the data with the old state of the data to ensure that it hasn't changed somewhere between the read and the write. This requirement can be addressed by the support for object comparison that SDO provides. SDO provides an Equality Helper Interface that can make shallow or deep comparisons on the data objects. Which means that not only can we tell if there's a difference, but which part of the data changed . There is a Copy Helper Interface that creates shallow or deep copies of the data objects that can save data states at different stages in the change. This is valuable since the change summary can only provide the first and last states of the data.

Limitations and Disadvantages
SDO and ADO.NET can be significant in addressing the data concerns of an offline SOA. However, a few disadvantages and limitations should be underscored.

BULKY FORMAT
The data payloads in SDO and ADO.NET are bulkier than normal data since their format is XML. They also carry more information than just the data. In SDO this is in XML. Such bulky formats can affect network bandwidth and hence SOA performance.

SECURITY
In an offline SOA, distributed data objects have to be transferred over the wire. So the security of data is a concern. SDO and ADO.NET have no inherent features for securing the data over a network.

Conclusion
While most of the challenges faced in an offline SOA can be handled only at the application architecture level, SDOs and ADO.NET provide basic features for handling some data concerns. SDOs are already being used as a standard for transmitting data to realize a SOA-like Service Component Architecture (SCA). Features like change summary, timestamp, and metadata can be key facilitators in addressing data concerns in a disconnected/occasionally connected SOA.

References
1.  Occasionally Connected Computing Architectures - http://findarticles.com/p/articles/mi_m0BRZ/is_9_23/ai_109082341
2.  Occasionally Connected System Architectures - http://udidahan.weblogs.us/2007/04/04/occasionally-connected-systems-architecture/
3.  Occasionally Connected Computing Profile - http://xml.coverpages.org/SOA-BlueprintsOccConnPv01.pdf
4.  Service Data Objects - http://ftpna2.bea.com/pub/downloads/commonj/Commonj-SDO-Specification-v1.0.pdf
5.  ADO.NET - http://msdn2.microsoft.com/en-us/library/3y0bb1zd(VS.80).aspx
6.  .NET and Java: A Study in Interoperability - www.theserverside.net/tt/articles/content/Interoperability/Neward_Interoperability.pdf
7.  Web Services and DataSets. MSDN Magazine. April 2003. - http://msdn.microsoft.com/msdnmag/issues/03/04/XMLFiles/default.aspx