Data Synchronization between Windows Azure and Mobile Clients
Author: Brad Severtson
Reviewers: Ralph Squillace and Glenn Gailey
This topic provides guidance on design choices that effect the synchronizing of data on mobile devices with data stored on Azure technologies. Data synchronization is the process of establishing the consistency over extended periods of time of the data in a Windows Azure application and the data stored on one or more mobile devices.
The approach here starts by providing a brief discussion of some of the constraints involving the resources that developers face when creating applications for mobile devices. It then provides some general recommendations regarding application patterns such as representational state transfer (REST), and, in particular, those REST patterns specifically exposing Open Data protocol (OData) endpoints from Windows Azure. This guidance specifies two axes of criteria to consider when selecting the appropriate approach to use for data synchronization:
The data exchange formats (JSON, XML) and communication protocols (HTTP, TCP) that are available to use;
The type of mobile device (Windows Phone 7, iOS, Android, Web browsers) on which the applications will run.
The topic concludes by outlining some guidelines about what data is best stored on the mobile device, what data should be stored on the service, and when is should be synchronized, given the performance and backup requirements and the costs incurred from moving data back and forth.
Mobile devices such as phones typically have less storage and processing capacity than a desktop or notebook computer. They are intermittently connected and so experience latencies with data synchronizations that on premise clients (clients directly connected to a network, either with an efficient wireless signal or a network cable) with do not encounter. Even more critically, network bandwidth for mobile devices is more restricted in many parts of the world than it used to be, and users are charged more for consuming more of it. To keep the cost of running a mobile application down, storage needs to be used responsibly, Wi-Fi connections need to be leveraged when possible, and either a compact data format like JSON should be used or some form of compression library deployed with less compact formats like XML. More specific guidelines that address working with these constraints can be provided for specific devices and applications. For guidelines applicable to the Windows phone, for example, see Using Windows Phone with Windows Azure.
For most scenarios on a wide variety of mobile devices, the general recommendation is to build a REST Web service over HTTP that expects and returns data as JSON, in addition to any XML format that your clients may require, or that uses a binary form such as Binary JSON or some other format that has undergone compression using a program such as GNU gzip.
WCF Data Services and other OData services such as Windows Azure Tables service, SQL Database, and SharePoint support Atom, JSON, and XML data formats. But note that WCF Data Services clients do not yet support sending and receiving JSON; they only support sending and receiving tom XML currently.
The most straightforward approach for exposing most kinds of data to mobile devices that use Windows Azure is to use WCF Data Services to expose an Open Data Protocol (OData) endpoint to your devices. OData is a REST-based open Web protocol for querying and updating data. The protocol enables a consumer to query a data source over the HTTP protocol and get the result back in Atom, JSON or XML formats. Many Microsoft products such as Windows Azure DataMarket and Sharepoint expose OData natively, as does the Access Control Service management API.
Several other possibilities exist that may be mentioned here for completeness regarding the main alternatives.
- Windows Sync Framework Toolkit
- The Sync Framework Toolkit extends the Sync Framework capabilities for building offline applications, making it easier to expose data for synchronization to applications running on any client platform, including Windows Phone 7, iOS, and Android. This solution performs true synchronization over OData to local isolated storage, and should be evaluated in light of the requirements for the upload and download scenarios.
- Tabular Data Streams (TDS)
- Some devices and platforms have the ability to consume TDS streams directly from a source such as SQL Database or SQL Server. In this situation, it may fit your solution if such a direct connection is needed. However, because there are important limitations inherent in a design that connects directly to a data source, it is likely that only a few specialized analyses or development tools are genuine candidates for this approach.
|There are many third-party libraries that you can use to implement one or more of these recommendations. It is important when using them that you test them in advance.|
Azure Data Exchange Formats and Protocols
Note that the Representational State Transfer (REST) approach over HTTP exposes both functionality and data to the largest possible number and types of clients.
When writing applications for Windows Azure data, the choices made regarding the serialization and encoding of data can impact the performance and cost of running an application more than it might with typical on-premise applications. Azure applications get charged for database use, general storage, data transfers and caching. Data going in to Azure is free, but it is charged for when going out. For more information on Azure pricing, see, Windows Azure Pricing Overview. In general, the smaller the payloads your mobile application requires, the less it will cost to run and the fewer latencies it will encounter. So storing more of the less volatile data on the device can be a win for both cost and performance. Text encoders may be required by interoperability constraints. The best serializer and encoder to use will depend upon your specific application and its interoperability needs. For additional information and guidance on serialization options with Azure applications, see Data Synchronization between Windows Azure and Mobile Clients.
Mobile devices that run applications do so principally on the more popular Web browsers and phones, both the Microsoft and non-Microsoft platforms. In all of these cases, the recommendation is to build REST Web services over HTTP that expect and return data as JSON or (ideally, compressed) XML.
Phones: For the Windows Phone, iOS, and Android, the recommendation is to define your own Azure-hosted service that accesses the platform services, and not to access those platform services directly from the phone clients. Windows Azure Toolkits for Devices supports the building of mobile applications for Windows Phone, iOS, and Android that use Windows Azure cloud services. Guidance for leveraging the Windows Azure platform to build great experiences on Windows Phone devices is available at Using Windows Phone with Windows Azure. The general guidance provided there for optimizing the on Windows phone is also applicable to iOS and Android phones: use local storage responsibly, check for connectivity regularly, use JSON for exchanging data, and use compression. More specifically, there are OData servers and client libraries for all major device platforms itemized at the Open Data Protocol site. Also, non-Microsoft phone platforms such as iOS and Android do permit unmanaged libraries to access TDS stream data directly to some degree when appropriate.
Build yourself a REST/JSON data service on top of your Azure data source for Windows Phone that selects serialization options to minimize payloads, especially for payloads going out for which users of an application are charged.
Do the same for other devices like iOS and Android.
Do the same for applications that run in Web browsers.
The Microsoft Sync Framework Toolkit performs synchronization over OData to local isolated storage and works for mobile devices.
Only consider using TDS if you have rich data from SQL Database and a large budget.