Московский государственный университет им. М.В. Ломоносова

Факультет Вычислительной Математики и Кибернетики

ДИПЛОМНАЯ РАБОТА

АНАЛИЗ И РАЗРАБОТКА СИСТЕМЫ PUSH-УВЕДОМЛЕНИЙ

С ИСПОЛЬЗОВАНИЕМ ТЕХНОЛОГИЙ GOOGLE Inc.

Работу выполнил студент ВВО:

Павлов Владимир Владимирович Научный руководитель:

c.н.с., к.ф.-м.н.

Намиот Дмитрий Евгеньевич Лаборатория ОИТ факультета ВМК МГУ им. М.В. Ломоносова Москва, 2013г.

Содержание Введение

ГЛАВА I. Обзор и анализ существующих технологий pushуведомлений для мобильных устройств 1.1. Описание push-технологии для мобильных устройств.............. 1.2. Push-технология Google Inc

1.3. Push-технология компании Apple

1.4. Push-технология компании Blackberry

1.5. Анализ интеграционных возможностей push-технологий...... 1.6. Обзор аналогов действующих push-систем

ГЛАВА II. Разработка системы push-уведомлений 2.1. Описание предлагаемой архитектуры системы push-уведомлений

2.2. Описание клиентской части

2.3. Описание серверной части

ГЛАВА III. Анализ применимости системы 3.1. Модель применения системы push-уведомлений

3.2. Направления дальнейшего развития системы

Заключение

Список литературы

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

Такие возможности для разработки новых направлений сегодня представлены большинством производителей операционных систем для мобильных устройств. При этом основные игроки на рынке (Google, Apple, BlackBerry) пытаются максимально безопасно открыть доступ к телефону извне для связи с абонентом.

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

ГЛАВА I. Обзор и анализ существующих технологий pushуведомлений для мобильных устройств 1.1. Описание push-технологии мобильных устройств Push-технология клиентов, который предполагает наличие мобильного устройства с установленным приложением для осуществления подписки к службам непосредственно на приложение по совершению определенного события. В данном случае событие является триггером для сервера приложений, который срабатывает на определенные условия, например, в соответствии с установленным расписанием или завершением определенной работы, и осуществляет рассылку требуемой информации клиенту. Реализация данной технологии подразумевает использование клиент-серверной архитектуры.

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

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

ограниченный емкостной ресурс системы питания;

относительно высокий уровень оплаты услуг за контент провайдерам (SMS, MMS);

операционных систем и как следствие, развитие дополнительных бесплатных сервисов;

телекоммуникационной инфраструктурой.

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

Система облачных сообщений Google (Google Cloud Messaging, далее GCM) - служба, построенная с использованием ресурсов Интернета, которая позволяет организовать рассылку данных со стороннего сервера пользователям устройств с операционной системой Android. Сообщения представляют собой легковесные данные объемом 4 kB, отправляемые сервером при наступлении определенного типа событий. Данная служба управляет возникающими очередями сообщений и доставкой их до целевого приложения.

мобильных устройств представлена на рис. 1.

Можно выделить следующие основные особенности GCM-службы [1]:

возможность использовать сторонний сервер приложений для отправки данных;

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

установленная операционная система Android версии 2.2 и выше;

наличие Google-аккаунта для устройств с операционной системой версии ниже Android 4.0.4.

Таким образом, для использования мобильного приложения на стороне клиента не предъявляются высокие требования, что, безусловно, позволяет популяризировать технологию.

Для организации полноценной работы система должна включать в себя следующий минимальный набор компонент:

сторонний сервер приложений для отправки данных через службу GCM;

службу GCM – служба доставки сообщений до приложения клиента.

При работе в системе используются следующие параметры доступа [1]:

идентификатор отправителя (Sender ID) – номер проекта, регистрируемый разработчиком в сервисах Google. Используется в момент регистрации Android-приложения для идентификации устройства при отправке сообщения;

идентификатор приложения (Application ID) – наименование приложения, которому адресовано сообщение;

регистрационный идентификатор (Registration ID) – номер, формируемый GCM сервером для Android-приложения, которое используется сторонним сервером приложений для рассылки аккаунт пользователя в системе Google (Google User Account);

маркер авторизованного отправителя (Sender Auth Token) – ключ, используемый сервером приложений для доступа к службам Основные этапы процесса работы данной системы pushуведомления можно выделить в две основные группы: регистрация, отправка и получение сообщения.

Рассмотрим эти группы этапов более подробно [1].

1) Регистрация в GCM.

1.1) В момент регистрации активируется регистрационный (com.google.android.c2dm.intent.REGISTER), содержит идентификаторы отправителя и приложения (1).

1.2) В случае успешной регистрации GCM сервер сообщает приложению регистрационный идентификатор (2).

1.3) Для завершения регистрации Android-приложение приложений (3).

2) Отправка и получение сообщения.

2.1) Сервер приложения отправляет сообщение GCM-серверу (4).

2.2) Google ставит в очередь и сохраняет сообщение, если устройство выключено или недоступно.

2.3) Когда устройство доступно, GCM служба перенаправляет сообщение мобильному приложению (5).

2.4) Специальная служба операционной системы Android (notification service) приложению.

Рис.1. Общая схема архитектуры push-уведомления Google Момент доставки уведомления на мобильное устройство может не совпадать с моментом отправки сообщения GCM службе и получения сервером приложения присвоенного идентификационного номера уведомления, что связано с использование системы Throttling.

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

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

предоставляется в специальной библиотеке jar.

Push-технология Apple (далее APN) – служба, разработанная компанией Apple, и использующая постоянно открытое зашифрованное IP соединение для пересылки уведомлений со стороннего сервера Appleустройствам. Уведомления могут содержать значки, звуки или текст.

Сервис был запущен в июне 2009г. При этом каждое уведомление ограничено размером в 256B. Для проверки подлинности push-запросов из iOS-приложения Apple использует цифровые сертификаты с открытым ключом. Если уведомление поступает на устройство с остановленным приложением, появляется сигнал о поступлении новых данных.

Общая схема архитектуры приведена на рис.2.

Рис.2. Общая схема архитектуры push-уведомления Apple В целом схема работы push-технологии Apple совпадает с ранее рассмотренной службой Google и включает в себя следующие этапы [2]:

В момент активации приложения через диалоговое окно в iOS-приложении система запрашивает разрешение пользователя на получение уведомлений.

Если разрешение получено, iOS-приложение подключается к службе Apple Push Notification (APNs) за строкой уникального идентификатора для этого установленного на устройстве приложения (его можно представить как аналог телефонного номера получателя в традиционном сценарии обмена сообщениями).

приложений.

осуществить отправку push-сообщения, APN проверяет подлинность push-сервера и использует идентификатор для указания получателя сообщения.

Если устройство получателя находится в режиме онлайн, оно принимает и обрабатывает сообщение. Если устройство недоступно, сообщение ставится в очередь и доставляется, как только устройство выйдет на связь.

При этом система первоначальной аутентификации устройств и сторонних серверов устроена сложнее и происходит с использованием протокола TLS. В данном случае APN служба после установления соединения с ней направляет на мобильное устройство сертификат, который проходит проверку, после чего сертификат самого устройства перенаправляется для проверки в APN. В случае успешной верификации устанавливается TSL соединение (см. рис. 3) [2].

Каждое уведомление, которое отправляется в службу APN, должно сопровождаться идентификатором устройства, полученного с клиентского приложения. Данный идентификатор расшифровывается для оценки валидности уведомления и получения ID устройства назначения (см. рис 4.) [2].

Архитектура системы push-технологии BlackBerry включает в себя инициатора push-уведомлений и устройство BlackBerry с установленным приложением, которое способно принимать такие сообщения. В данной технологии предполагается, что инициатор не дожидается запроса на отправку контента от получателя. Максимальный размер данных не должен превышать 8KB. Компания BlackBerry утверждает, что сообщения мгновенно поступают на приложения пользователя [3].

На диаграмме видно, что архитектура представляет собой клиентсерверное решение (см. рис. 5). Библиотеки серверной и клиентской частей взаимодействуют с различными компонентами системы для обеспечения доставки контента.

Рис.5. Общая схема архитектуры push-уведомления BlackBerry Основные компоненты push-технологии BlackBerry Initiator) части (Server-side library) взаимодействия с PPG в формате XML со Push прокси-шлюз (Push Процессы PPG проталкивают сообщения, Proxy Gateway - PPG) части (Client-side library) взаимодействия с PPG (The BlackBerry® Java® application) рассмотренных ранее push-технологий (рис.6.) и состоит из следующих этапов [3]:

1. поставщик контента (инициатор) отправляет push-запрос;

2. инфраструктура BlackBerry (PPG) возвращает ответ;

4. мобильное устройство возвращает ответ PPG;

5. ответ-подтверждение направляется инициатору сообщения;

уведомления возвращается на сервер PPG.

Рис.6. Алгоритм работы службы уведомления BlackBerry 1.5. Анализ интеграционных возможностей push-технологий Все рассмотренные технологии предоставляют возможность разработчикам использовать библиотеки, написанные на языке Java, для построения различных архитектур стороннего сервера приложений для одновременной работы с инфраструктурой Google, Apple и BlackBerry.

Взаимодействие со службой APN может быть организовано с помощью зарекомендовавшей себя библиотекой JavaPNS с открытым исходным кодом. Основные методы интерфейса данной библиотеки представляют собой статические методы класса Push для сообщений каждого типа и выполняют преобразование сообщения в формат JavaScript Object Notation (JSON), принимаемый серверами APNs [2].

Компания BlackBerry разработала собственный комплект средств разработки для реализации взаимодействия с собственной инфраструктурой - Push Service SDK, которая предоставляет Java APIs, используемое Push-инициатором для взаимодействия с PPG [3].

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

1.6 Обзор аналогов действующих push-систем Идеи развития систем push-уведомлений с расширенными функциональными возможностями для пользователей существуют давно. Первые и наиболее интересные реализации присутствуют на рынке уже не первый год, но в качестве языков программирования в большинстве коммерческих проектов используются HTML, CSS, JavaScript.

Наиболее ярким примером в этой области является программный продукт AppCloud компании Brightcove – для создания мобильных приложений с использованием технологии HTML5. Данная система позволяет дополнительно создавать, устанавливать расписание и определять целевую аудиторию по географическому признаку для рассылки уведомлений служб GCM и APN.

собственной системой аналитики и позволяет получить маркетинговые оценки проводимых кампаний и определить поведение клиентов по активности самого приложения. Более подробная информация представлена на сайте разработчика [6]. Тем не менее, компания объявила о закрытии своего проекта в 2013г.

Другим коммерческим проектом, активно использующим технологии push-систем Google и Apple, является Push Messaging компании Urban Airship [8]. В данном программном продукте реализована та же функциональность, что и в AppCloud за исключением того, что создание мобильного приложения и интеграцию его с системой рассылки пользователю необходимо решать самостоятельно.

В целом на рынке сейчас активно развиваются и другие проекты (например, PushIO, AirBop), которые позволяют через веб-интерфейс либо через веб-службы получить доступ к API серверной части системы push-уведомлений и начать организованную рассылку контента на мобильные приложения.

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

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

1)

егментировать пользователей по месторасположению и по 2)

существлять рассылку в определенные периоды времени;

3)

инимизировать затраты на рекламу на каждого клиента;

4)

обирать аналитику для изучения поведения клиентов.

Что касается open source решений, то готовых систем, написанных на языке Java, на рынке не представлено. Тем не менее, среди прочих аналогичных проектов можно выделить Uniqush (С++), NuGet(C#), Easy позволяют отправлять сообщения c учетом функциональности, которая заложена в соответствующие службы APN, GCM и PPG.

ГЛАВА II. Разработка системы push-уведомлений В качестве объекта для разработки архитектуры системы, реализующей функции push – уведомлений, была выбрана за основу базовая технология компании Google Inc. Основными критериями, повлиявшими на решение, в большей степени явились факторы ориентированности компании на развитие софтверных продуктов с открытым исходным кодом и ожидания существенного расширения API и более качественной поддержки разработчиков.

Архитектура предлагаемого решения приведена на рис. 7 и включает в себя:

- сервер приложения с расширенной функциональностью;

- база данных для хранения и обработки информации;

- клиентское мобильное приложение для Android.

Рис.7. Архитектура проектируемой системы push-уведомлений На первоначальном этапе разработки системы уведомлений были определены следующие основные требования:

использованием web-интерфейса;

2) на мобильном устройстве по каждому сообщению можно идентифицировать отправителя;

3) отправленный текст должен представлять собой html-страницу, определенным графиком;

хранится в реляционной базе данных;

5) легкая масштабируемость системы для новых проектов и появлением нового функционала существенно расширился и помимо раннее рассмотренных этапов включает в себя следующие новые позиции:

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

- клиент (заказчик системы рассылки) через предлагаемый вебинтерфейс осуществляет управление рассылкой (4). Непосредственно через веб-браузер происходит выбор тем, устанавливается график рассылки для каждого сообщения, вводится текст сообщения с использованием html-тегов;

- вся информация о совершенных действиях клиента и пользователя поступает на хранение в реляционную базу данных(5, 6).

Клиентская часть приложения для пользователей мобильных устройств написана под операционную систему Android версии 2.3.3. (и выше) с использованием среды разработки Eclipse.

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

Реализация процесса регистрации осуществляется в классе RegisterActivity.class Данная идентификационная информация сохраняется в базе данных «PushNotification» SQLite на мобильном устройстве, а также дублируется в централизованной базе данных Postgresql, используемой сервером приложения для осуществления процесса отправки уведомлений.

Структура БД «PushNotification» приведена на рис.9. В таблицах «person» хранится регистрационная информация о пользователе, отправитель, тема подписки, наименование сообщения и дата получения сообщения), «company» - связь между компанией и ее логотипом.

При работе с приложением пользователю предоставляется просматривать сообщения, осуществлять отказ от регистрации в системе.

возможности осуществления удаления всех ранее полученных сообщений, отказа от подписки в системе рассылки сообщений.

Приложение также позволяет осуществлять сбор анонимной статистики по возрасту, полу, времени открытия сообщения.

В качестве базовых технологий для разработки архитектуры серверной части системы push-уведомлений используется платформа JavaEE 6 (java enterprise edition). В текущей реализации планируется использовать стабильный и достаточно эффективный сервер приложений с открытым исходным кодом GlassFish 3.1.2, позволяющий реализовать все возможности данной платформы. Для общения с GCMслужбой используется стандартный HTTPS протокол.

Ядро серверной части системы реализовано в качестве Java приложения с back-end базой данных Postgresql, в которой хранятся списки пользователей, клиентов, темы подписки и отправленные сообщения.

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

Для отправки сообщения приложение формирует POST запрос по адресу https://android.googleapis.com/gcm/send. В HTTP заголовке в обязательном порядке указывается поле авторизации, содержащее маркер отправителя, и тип контента (Content-Type: application/json).

Поля тела сообщения приведены в таблице №2 [1].

Идентификационные номера Список (от 1 до 1000) регистрационных зарегистрированных мобильных номеров приложений приложений (registration_ids) Задержка (delay_while_idle) Сообщение отправляется только при Время жизни (time_to_live) Период, в течение которого сообщение По результатам отправки сообщений сервер приложений получает код ответа от GCM службы, позволяющий проанализировать сбои и ошибки в системе. Так, в случае успешной обработки сообщений в GCM, код ответа принимает значение 200, а в теле содержатся дополнительные информационные поля (см. таблицу №3) [1].