Тех. документы
Технические документы

{chronoforms}white_papers_form{/chronoforms}

РОЛЬ СЕРВЕРНОГО ПРИЛОЖЕНИЯ (BACK-END)

Полина Черкасова

Помните, как выпуск мобильного клиента приложения считался новым, необычным и приятным дополнением? Как быстро мы достигли точки, когда спрос на мобильные клиенты стал важнее, чем на классические веб-клиенты? Возможности мобильного клиента или приложения очевидны, поскольку мы держим приложение в своих руках; однако, часто остается без внимания вопрос о влиянии мобильных приложений на разработку серверных приложений и текущую работу серверов. Вот о чем важно помнить: каждый щелчок по экрану планшета или смартфона вызывает ряд действий на сервере, включая обработку трансакций, извлечение, доставку или сохранение данных, а также сообщение между многими устройствами, приложениями и серверами.

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

  • Вследствие преобладания большего количества коротких пакетов и синхронизаций изменились модели сетевого трафика.
  • Стандартной практикой стала интеграция многих приложений в реальном времени.
  • Побочным продуктом мобильности становится уменьшение безопасности в клиентской среде.
  • Слабеет предсказуемость Интернет-соединений.

В этом техническом документе , мы коротко рассмотрим три ключевые темы разработки серверных приложений для обслуживания мобильных устройств, которые играют важнейшую роль в создании успешных, масштабируемых приложений. Они включают:

  • Признание различий между мобильным и веб-трафиком.
  • Выбор правильных протоколов и архитектурных подходов для клиент-серверного взаимодействия.
  • Понимание функции и поведения серверных платформ для мобильных приложений (MBaaS).

1 МОБИЛЬНЫЙ ТРАФИК ПРОТИВ ВЭБ-ТРАФИКА

Мобильные устройства изменяют модели трафика несколькими важными путями.

  • Поскольку маленькие устройства вмещают на экране меньше информации, пользователи быстрее пробегают по экрану, отправляя меньшие, но более частые запросы на сервер.
  • Из-за меньшего размера экрана на планшетах и смартфонах, публичные приложения содержат меньше рекламы, чем веб-сайты. Вместе с тем, рекламные объявления обычно более эффективны и имеют более высокую кликабельность. Таким образом, их необходимо доставлять быстро и привлекательным образом, невзирая на то, что типы и разнообразие мобильных устройств в руках пользователей создают огромные вызовы для тестирования и доставки.
  • Плохие Интернет-соединения влияют на оптимизацию страницы. Большая часть расчетов и вычислений происходит на сервере, а значит, плохие соединения приводят к уменьшению пропускной способности со стороны сервера.
  • Мобильными приложениями пользуются круглосуточно без выходных, причем в основном после обычного рабочего времени.
  • Поскольку пользователи мобильной связи выходят в интернет «на ходу», сессии значительно укорачиваются, но поскольку устройства всегда включены и автоматически связываются с сервером, количество обращений многократно возрастает.
  • Цифровые изображения, аудио и видеофайлы сегодня стали значительной составляющей мобильного трафика даже для бизнес-ориентированных приложений.

2 ПРОТОКОЛЫ КЛИЕНТ-СЕРВЕР

В мобильной среде количество и разнообразие обращений к серверу возрастает, поскольку больше пользователей подключаются и пользуются приложением. Серверная сторона должна быть не только быстрой и гибкой, но еще и элегантной. Значительную роль играют протоколы, известные как REST и oData.

REST

Протокол REST де-факто стал стандартом взаимодействия клиент-сервер, заменив традиционный протокол веб-сервиса (SOAP). Протокол REST предлагает два важных преимущества:

  • Он упрощает API-вызовы.
  • Он позволяет вам давать ссылку на любой объект или операцию, используя URL, построенную с помощью простых, хорошо известных правил, а не устанавливать отдельные процедуры для доступа к каждому набору данных.

Вот пример сравнения одинаковых вызовов с использованием SOAP и REST:

Вызов SOAPВызов REST
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
 <soap:body pb="http://acme.com/phonebook">
  <pb:GetUserDetails>
   <pb:UserID>12345</pb:UserID>
  </pb:GetUserDetails>
 </soap:Body>
</soap:Envelope>

http://acme.com/phonebook/UserDetails/12345

 

Благодаря своей простоте, протокол REST:

  • Гораздо быстрее кодирует/декодирует/разбирает/передает.
  • Его намного дешевле и проще разрабатывать, поддерживать и тестировать.
  • Намного меньше зависит от проприетарных инструментов.

Вот несколько хороших ресурсов по REST:

  • http://rest.elkstein.org/
  • http://net.tutsplus.com/tutorials/other/a-beginners-introduction-t-http-and-rest/

API С ВОЗМОЖНОСТЬЮ ЗАПРОСА: ODATA

Для многих приложений необходимы разные представления одних и тех же данных. Некоторые типичные примеры включают:

  • Определить 30 наиболее популярных товаров по категориям в алфавитном порядке.
  • Найти названия и изображения самых ходовых 10 товаров.
  • Указать названия и цены 10 самых популярных уцененных товаров в настоящий момент.

Обычно разработчики пишут длинные протоколы, чтобы избежать поддержки метода API для каждого вида; однако, не имеет смысла предоставлять лишь один метод API в случаях, когда клиентские приложения «требуют все и сразу», а затем использовать лишь информацию, необходимую в данном запросе. Нагрузка на сервер и сеть будет слишком значительной.

Чтобы решить эту проблему, Microsoft ввел протокол oData, построенный на лямбда-выражениях .NET и протоколе REST. С протоколом oData, ваш веб-API публикует схему базы данных. На основе этой схемы клиентские приложения могут строить запросы по схеме и отправлять их на сервер.

Пример того, как выглядит URL-запрос в oData на основе протокола REST:

http://mystore,com/Products?$orderby=Name desc&$filter=Category eq 'Toys'&$top=10&$select=Name,Picture

 

А вот как выглядит запрос .NET Linq, который производит приведенный выше URL:

var q = (from p in data.Products 
         where p.Category.CategoryName  == "Toys"
         orderby p.Name 
         select new {Name = p.Name, Picture = p.Picture}).Take(10);

 

Используя протокол oData, разработчики могут создавать более быстрые и гибкие способы доставки информации в мобильные устройства, сохранив при этом пропускную способность и внутреннего сервера, и сети. Вот некоторые хорошие ресурсы по oData:

СЕРВЕРНАЯ АРХИТЕКТУРА

Возможность создания Linq-запроса на мобильном устройстве и его передачи на сервер создает приятную иллюзию прямого соединения с базой банных. Существуют платформы, которые могут автоматически генерировать и API сервера oData, и клиентский прокси на основе схемы отношений базы данных. В результате иллюзия прямого соединения не требует кодирования.

На диаграмме справа приведена такая архитектура. В целом, разработчики избегают предоставления всех деталей физической базы данных в API приложения.

В качестве альтернативы, вы можете использовать для генерации API логическую схему, которая включает:

  • Логическую схему.
  • Физическую схему.
  • Триггерную бизнес-логику между ними.

Больше информации о ее реализации можно найти здесь.

Если вы хотите использовать этот подход, необходимо помнить о нескольких важных моментах:

  • Бизнес-логика таких приложений является не процедурно-ориентированной, а событийно-ориентированной. Если вы не следуете четким стандартам кодирования, неясность операций может вызвать серьезные проблемы сопровождаемости.
  • Если ваше хранилище данных не является реляционным или вы рассматриваете возможность перехода на технологию noSQL в будущем, вам придется инвестировать в запрашиваемость данных – что может быть очень дорого.
  • Способность выполнить практически любой запрос по вашей базе данных сделает ваш сервер подверженным проблемам производительности. Если у вас имеются компоненты отчетности, объединяйте их не с операционной базой данных, критически важной для бизнеса, а с ее репликой.

Мы рекомендуем предоставлять гибридный API, который является и запрашиваемым, и процедурным.

Если вы можете гарантировать одно из двух следующих условий, вам нужно предоставить API с возможностью запроса:

  • Гибкость не может повлиять на наличие и производительность критически важных для бизнеса функциональных возможностей.
  • Существуют надежные механизмы контроля набора запросов, которые с которыми клиентское приложение обращается к API.

Для реализации событийно-ориентированной бизнес-логики, вам необходимы четкие письменные правила, описывающие, как должен быть структурирован код. Ваша группа разработки должна понимать и бескомпромиссно поддерживать эту структуру.

3 СЕРВЕРНЫЕ ПЛАТФОРМЫ ДЛЯ МОБИЛЬНЫХ ПРИЛОЖЕНИЙ КАК СЕРВИС (MBAAS)

Некоторые провайдеры создали сервисы, которые делают работу приложений в «облаке» эффективной, рентабельной и продуктивной. Эти сервисы делятся на три категории:

  • Инфраструктура как сервис (IaaS)
  • Платформа как сервис (PaaS)
  • Программное обеспечение как сервис (SaaS)

Сегодня к этому списку можно добавить еще серверные платформы для мобильных приложений как сервис (MBaaS). MBaaS, подмножество SaaS, обеспечивает основные функциональные возможности серверной платформы мобильных приложений, позволяя разработчикам сосредоточиться на клиентских функциональных возможностях. Предлагаемые сегодня MBaaS обеспечивают ключевые услуги, которые значительно уменьшают время и стоимость разработки, а также потенциально увеличивают надежность. Эти услуги делятся на восемь категорий:

  • Управление авторизацией и пользователями
  • Удаленные уведомления
  • Хранение
    • Структурированное
    • Неструктурированное
    • Полуструктурированное
  • Автоматически генерируемые клиентские прокси, которые создают иллюзию прямого подключения к данным
  • Механизмы кэширования клиентских данных и отсроченной синхронизации
  • Аналитика (исследование особенностей использования)
  • Интеграция с другими сервисами
    • Социальные сети
    • Локальные услуги
    • Реклама
  • Расчеты

Наиболее популярными участниками нынешнего рынка MBaaS являются:

MS Azure Mobile, Amazon Mobile, StackMob, Parse, Kinvey, Apigee, Appcelerator, Sencha.iи FeedHenry.

При выборе MBaaS необходимо задать пять важных вопросов:

  • Насколько развитым является провайдер в областях, необходимых для вашего приложения?
  • Насколько дружественной является ценовая модель с учетом ваших прогнозов потребления? Помните, что окончательная сумма счета будет зависеть не только от трафика и размера хранилища, но и от использования других услуг, количества пользователей, количества удаленных уведомлений, количества аналитических отчетов и так далее.
  • Насколько приемлемыми для вашего бизнеса являются показатели Соглашения об уровне услуг (SLA)? Ограничения хранилища данных? Показатели доступности услуг? Гарантии продолжительности хранения данных?
  • Насколько гибкими и автоматизированными являются процессы масштабирования в обоих направлениях?
  • Существует ли механизм получить ваши данные у провайдера в массе и в стандартной форме?

К сожалению, природа ниши MBaaS не оставляет места для открытого программного обеспечения, поскольку ПО тесно связано с хост-узлом.

4 В ЗАКЛЮЧЕНИЕ

Нет никаких сомнений: разработка мобильных приложений – это следующий рубеж, который должны покорить ИТ-организации. Бесспорно, пользователям должны нравиться приложения, которые они держат в своих руках. Они должны ощущать производительность и получать удовольствие от работы. Мы считаем, что хорошее впечатление от приложения связано также с тем, чего пользователи не видят. Создавая свои мобильные приложения, помните о таких моментах:

    • Учитывайте различия между веб- и мобильным трафиком. Неспособность учесть специфику частых маленьких пакетов данных и синхронизаций может обречь на провал даже самые симпатичные мобильные приложения.
    • Используйте самые современные подходы к архитектуре мобильных приложений. Такие подходы к управлению обменом данными, как REST, могут позволить вашим приложениям работать гораздо более гладко и создадут гораздо меньшую нагрузку на внутренние системы и источники данных, которые поддерживают ваши мобильные приложения.
    • Старайтесь найти сервисы, которые упрощают разработку ваших мобильных приложений. Провайдеры MBaaS могут предложить возможности, которые обеспечат стабильность серверных приложений, и у ваших пользователей сложатся только самые лучшие впечатления.

О КОМПНИИ VIACODE CONSULTING:

Компания VIAcode, штаб-квартира которой расположена в Западном Хартфорде (Коннектикут, США), разрабатывает и поставляет коммерческие или «внутренние» программные продукты, которые коренным образом изменяют эффективность работы наших клиентов. Мы значительно расширяем технические возможности наших клиентов, привлекая специалистов мирового уровня в течение всего жизненного цикла разработки программного обеспечения, и создаем в результате высококачественное программное обеспечение в установленный срок и в рамках бюджета.

Связаться с нами можно по телефону: 1.860.882.1150 или электронной почтой: This email address is being protected from spambots. You need JavaScript enabled to view it..