Использование Windows Phone совместно с Windows Azure

При создании службы для приложения Windows Phone, размещаемой в Windows Azure, можно указать, требуется ли от клиентов аутентификация. Аутентификация помогает уменьшить вероятность злоумышленных атак на ваши службы, заставляя клиентов подтверждать свою личность. Кроме того, аутентификация позволяет санкционировать доступ к подмножествам сохраняемых данных, относящимся к тем или иным клиентам. Такое приложение называется мультитенантным приложением. Дополнительные рекомендации по созданию мультитенантных приложений в Windows Azure см. в статье Разработка многопользовательских приложений в Windows Azure.

Поддерживаются два метода аутентификации приложения Windows Phone с помощью служб, размещенных в Windows Azure:

Службы управления доступом к Windows Azure

Службы управления доступом (ACS) — это облачные службы, которые предоставляют простой способ аутентификации клиентов Windows Phone в веб-приложениях и службах. Вместо необходимости поддержания собственных списков доступа клиентов можно переложить эту работу на доверенного поставщика удостоверений, например Windows Live ID, Google, Yahoo! или Facebook. Дополнительные сведения см. в разделе ACS Overview. Пример доступа к веб-каналу OData из приложения Windows Phone с помощью службы ACS см. в статье Соединение со службой OData, защищенной OAuth 2.0.

Аутентификация на основе форм ASP.NET

В ASP.NET есть собственный поставщик членства, который также поддерживается для веб-ролей ASP.NET в Windows Azure. Этот поставщик членства используется в ходе аутентификации запрашивающих клиентов на основе формы ASP.NET. При использовании аутентификации на основе форм ASP.NET от вас требуется поддерживать собственные списки доступа клиентов. Дополнительные сведения см. в статье Реальный мир: модели аутентификации на основе форм ASP.NET для Windows Azure.

Набор средств Windows Azure Toolkit для Windows Phone поддерживает обе эти схемы аутентификации.

При обмене учетными данными со службами, размещенными в Windows Azure, необходимо всегда использовать шифрованное соединение. Также настоятельно рекомендуется использовать шифрованное соединение всякий раз при отправке или получении приложением данных, которые ваши пользователи считают конфиденциальными. В Windows Azure такая защита обеспечивается использованием соединения по протоколу SSL или TLS. Дополнительные сведения см. в разделе Web Service Security for Windows Phone.

Мы настоятельно рекомендуем, чтобы ваше приложение запрашивало имена и пароли пользователей каждый раз, когда они требуются. Если попытаться сохранить учетные данные в телефоне, возникает риск утечки этих учетных данных во вредоносное приложение в случае потери или кражи Windows Phone. Используйте класс ProtectedData и связанные с ним криптографические классы для шифрования и хранения конфиденциальных данных в приложении. Дополнительные сведения см. в разделе How to: Encrypt Data in a Windows Phone Application.

По возможности храните все данные, необходимые вашему приложению Windows Phone, в локальном устройстве, даже когда они получены из облака. Это особенно важно для ссылочных данных, например таблиц подстановки, а также для данных, необходимых при первом запуске приложения или улучшающих работу с ним пользователей. Дополнительные сведения см. в разделе Синхронизация данных между Windows Azure и мобильными клиентами.

Реализация

Рекомендуется хранить в локальном устройстве все данные из облака, необходимые вашему приложению для корректного или более эффективного запуска. Эти данные можно хранить как в локальной базе данных, так и в изолированном хранилище. Дополнительные сведения см. в разделе Local Data Storage for Windows Phone.

Пример хранения данных из веб-каналов OData в локальной базе данных см. в серии Синхронизация OData с локальным хранилищем в Windows Phone.

Поскольку Windows Phone не накладывает на объем хранилища устройства никаких ограничений, ответственность за объем используемой памяти возлагается на ваше приложение. Проверяйте доступное место на устройстве с помощью свойства AvailableFreeSpace и будьте готовы остановить сохранение данных, когда приложение превысит разумный, самостоятельно установленный предел. Рекомендуется предоставлять клиентам способ вручную удалить сохраненные данные.

Компромиссы

Одно из преимуществ облачного хранилища состоит в том, что ваши данные доступны в любом месте и на любом устройстве. В то время как локальное хранение данных приложения может улучшить его производительность, хранящиеся локально данные недоступны за пределами приложения Windows Phone. Это значит, что в случае потери или повреждения устройства клиент не сможет восстановить данные. Также одни и те же данные может понадобиться сделать доступными вашим клиентам с любого устройства или компьютера. Для поддержания критически важных клиентских данных как на устройстве, так и в облаке рекомендуется использовать службу Synchronization Services на основе протокола OData. Дополнительные сведения см. в публикации Синхронизация данных Windows Phone со службами Windows Azure с помощью набора средств Sync Framework.

Невозможность корректного запуска при отсутствии соединения с Интернетом может стать причиной отказа в сертификации вашего приложения для Windows Phone. Не забудьте проверять наличие соединения с Интернетом перед запросом облачной службы. Кроме того, поскольку большинство пользователей платит за мобильный сетевой трафик свыше установленного лимита, фоновые задачи синхронизации данных следует выполнять с помощью соединения Wi-Fi, а не мобильной сети. Также можно позволить пользователям отключить любые фоновые задачи синхронизации или разрешить им доступ только к Wi-Fi.

Реализация

Проверить наличие соединения с Интернетом можно, вызвав метод GetIsNetworkAvailable. Можно также вызвать метод GetCurrentNetworkInterface для проверки типа соединения, будь то сотовая связь или Wi-Fi. Дополнительные сведения см. в разделе How to: Get Connection Information about a Socket for Windows Phone.

Компромиссы

Отключение пользователями доступа к определенным сетевым подключениям или фоновым задачам может повлиять на производительность или функциональные возможности вашего приложения.

Некоторые форматы обмена данными существенно компактнее и эффективнее других. Если вашим основным соображением является трафик, следует создавать и использовать только такие службы Windows Azure, которые поддерживают протокол JSON. Причина в том, что формат данных JSON по своей сути эффективнее форматов на основе XML.

Реализация

Старайтесь использовать службы, поддерживающие JSON. Службы OData поддерживают формат JSON в дополнение к применяемому по умолчанию формату Atom XML. Чтобы получить ответ JSON от службы OData, предоставьте значение application/json в качестве заголовка запроса Accept. Можно также указать параметр запроса $format=json в URI запроса службы данных, но службы WCF Data Services не поддерживают по умолчанию параметр запроса $format. Дополнительные сведения см. в статье Рекомендации по использованию преимуществ служб OData. WCF REST также поддерживает формат JSON.

Не существует поддержки клиентской библиотеки для JSON, эквивалентной поддержке Atom XML при использовании OData client for Windows Phone. Однако можно использовать класс DataContractJsonSerializer на устройстве для сериализации ответа JSON в объекты на клиенте, основанные на контракте данных. Дополнительные сведения см. в публикации Вывод схем для JSON.

Компромиссы

OData client for Windows Phone облегчает взаимодействие со службами OData. Однако эта клиентская библиотека в настоящее время поддерживает только формат Atom XML. Если вам нужно воспользоваться удобством клиентской библиотеки OData, рекомендуется использовать сжатие, которое более эффективно для форматов на основе XML, чем для JSON.

Можно сократить требования к пропускной способности сети, используя схему сжатия, например gzip. Применение сжатия еще важнее для формата на основе XML, например Atom. Рекомендуется применять сжатие для уменьшения сетевых требований при использовании OData client for Windows Phone, который поддерживает только формат Atom XML.

Реализация

Включите сжатие на сервере и убедитесь, что он настроен для соответствующего типа MIME ответа вашей службы (например, application/json или application/atom+xml). Дополнительные сведения см. в публикации Сжатие IIS в Windows Azure. Чтобы запросить от веб-сервера сжатый ответ, установите в заголовке запроса Accept-Encoding поддерживаемую схему сжатия, например gzip. У Windows Phone в настоящее время нет собственной библиотеки сжатия, поэтому необходимо использовать библиотеку сторонней разработки, например SharpCompress. Библиотека OData для Windows Phone позволяет установить запрос сжатия в заголовках. Она предоставляет интерфейс API для доступа к сжатому потоку ответов и возврата распакованного ответа для материализации библиотекой в объекты. Пример использования сжатия с OData client for Windows Phone см. в статье Сжатие OData с Windows Phone 7.5 (Mango).

Компромиссы

Сжатие экономит сетевой трафик, но за счет производительности — как службы, так и устройства. К счастью, Windows Azure позволяет масштабировать размещенную службу для соответствия требованиям к емкости. Это можно сделать, увеличив или уменьшив число экземпляров ролей, запускаемых как часть вашей размещенной службы. Однако с увеличением числа экземпляров выполняемой роли увеличивается оплачиваемое число часов вычислений. Дополнительные сведения см. в разделе How to Scale Applications by Increasing or Decreasing the Number of Role Instances.

Выполнение сжатия и распаковки также потребляет ресурсы процессора устройства Windows Phone. Такая дополнительная обработка может отрицательно сказаться на времени работы устройства от аккумулятора.