Архитектура поисковых мэшапов
Данный вид мэшапов, имеет наиболее простую архитектуру. Основной частью системы являются сборщики результатов выдачи из нескольких поисковых сервисов. Модель данных выдачи имеет простую структуру и может быть преобразована к внутренней модели мэшапа, не делая различий между тем, из какого источника были получены данные.
Таким образом, вместо множества сборщиков информации удобно использовать один сборщик, в котором каждый из сервисов порождает структуру:
Модуля отвечающего за коммуникацию и транспортные проблемы
Конвертера, который преобразует информацию из внутреннего представления каждого из сервисов во внутреннее представление данных мэшапа
Данные после преобразования конвертера будут помещаться в единую «базу данных».
Схематично процесс получения данных можно изобразить так:
Service
Converter
Service
Converter
Service
Converter
Converter
Data Harvester
Рисунок 6
Вся остальная работа осуществляется непосредственно с данными, которые предоставляет сборщик информации. Таким образом, типичный поисковый мэшап можно представить в виде уже рассмотренной модели, состоящей из одного сервиса, логики и преобразователя. Разница будет заключаться лишь в том, что преобразователь будет вместо того, чтобы отображать информацию на карте, преобразовывать её в гипертекстовый документ или просто в текстовую информацию.
Архитектура новостных мэшапов
Новостные мэшапы во многом схожи с поисковыми. Единственным существенным отличаем, является то, что вместо того, чтобы собирать данные по запросу, это можно делать упреждающе. Данные, получаемые из новостных сервисов, имеют следующие особенности:
Новости представляют собой инкрементальную структуру. То есть, практически не существует операций, в которых необходимо будет исправить ту или иную новость. Во многих случаях, даже если произошли какие-то изменения, их можно проигнорировать
Сама структура данных будет чрезвычайно проста. С большой вероятностью это будет гипертекстовый документ, либо документ, созданный на основе Wiki-разметки
Сервисы предоставляют новые данные с течением времени, а не в зависимости от запросов
Будет уместно применять механизмы кэширования. Соответственно, в качестве основы сборщика данных подойдёт обыкновенная реляционная база данных вроде MySQL или MS SQL.
Так как данные добавляются постепенно, то будет уместным совершать опрос сервисов с определённым интервалом времени и пополнять базу данных новостного мэшапа. Если делать это с достаточной периодичностью, то задачи наполнения базы данных и вся остальная работа с ней, включая поиск, фильтрацию и отображение, будут абсолютно независимы. Вся часть, кроме сборщика информации, представляет собой типичное веб-приложение, работающее с базой данных, пополняемой при помощи сборщика. Схемы построения приложений, осуществляющих вывод информации из базы данных хорошо изучены, проработаны, и их рассмотрение выходит за рамки данной работы.
Глава 4 Программные интерфейсы
В качестве практической части данной работы было решено сделать интерфейс для создания картографических мэшапов на базе сервиса Google Maps.
Сервис Google Maps[11] предполагает два вида использования:
Google Maps Static API - API статических карт Google позволяет встраивать изображения Карт Google в приложения, не требуя использования браузера. Служба статических карт Google создает, основываясь на параметрах URL, отправленных через стандартный HTTP-запрос, и возвращает карту в виде изображения
Google Maps API — API Карт Google позволяет встраивать Карты Google на веб-страницы при помощи JavaScript. API предоставляет ряд служебных программ для управления картами и добавления содержания на карту
Стоит отметить, что при использовании API, предназначенного для браузера, уже решены многие проблемы взаимодействия с пользователем, будь то перемещение карты, увеличение-уменьшение масштаба или переключение между режимами (карты и спутник). В частности, из-за этих возможностей было решено использовать Google Maps API как основной инструмент, с которым дальше будут работать разработчики картографических мэшапов для системы Ubiq Mobile.
Использование Google Maps API
Поскольку Карты Google предназначены для использования в браузере, то было решено разделить приложение на две части. Первая (браузерная) часть – это непосредственно сам браузер, который будет хранить в себе модель данных и по запросу осуществлять рендер готовых частей карты, и веб страница, на которой будет размещаться карта, в которую можно внедрить свой JavaScript код. Такой подход позволит разработчикам, у которых уже есть картографические мэшап-приложения, встраиваемые в браузер, адаптировать их под использование на мобильной платформе без внесения серьёзных изменений или даже переписывания кода с нуля.
Вторая часть (коннектор) – это код, который отвечает за работу непосредственно с мэшап платформой. Данная часть может быть реализована на любом .Net совместимо языке. Автор в качестве .Net языка использовал C#, и, не умаляя общности, в дальнейшем будем полагать, что используется именно этот язык. Именно это часть кода будет отвечать за взаимодействие с платформой, пересылку и приём данных с телефона. Кроме того, предполагается, что именно в этой части будет располагаться логика приложения, за исключением тех случаев, когда будут переиспользоваться приложения, логика которых располагается в JavaScript коде. Общая схема подобного взаимодействия находится на рисунке 7.
Browser
Service
Ubiq Mobile
New Service
Connector
Рисунок 7
Основные задачи по взаимодействию — это реакция на запросы устройства на передвижение карты, изменение масштаба или выбор маркера, располагающегося на карте. Запросы по умолчанию привязаны к нажатию определённых кнопок на мобильном устройстве. Когда происходит подобный запрос, коннектор расшифровывает его, строит на основе этого набора последовательность команд браузеру, отправляет эти команды на исполнение, после чего получает результат, который после этого передаётся мобильному устройству.
Теоретически, первая часть приложения может быть переделана в сервис, который по требованию клиента будет загружать веб-страницы и совершать на них определённые действия. Это позволит, например, создать альтернативу браузеру Opera Mini или сделать утилиту для автоматического тестирования веб приложений. Пример работы с таким сервисом при помощи команд:
Загрузить веб-страницу по адресу http://example.com
Выполнить на странице действия
Найти элемент типа кнопка с текстом «Ок»
Произвести действия с данным элементом управления (нажать)
Получить результат совершённых действий в виде картинки
Такой подход позволит проводить тестирование JavaScript кода или проводить регрессионное тестирование всего проекта. Схожей функциональностью обладает продукт Selenium[24]. Сравнение методик тестирования и создание фреймворка для тестирования веб-приложений выходит за рамки данной дипломной работы.
В целях улучшения производительности было решено реализовать первую часть в виде библиотеки.
Сервис Геокодер
Одной из наиболее важных задач при создании картографических мэшапов является получение географических координат объектов, которые будут отображаться на карте. В большинстве случаев достаточно функциональности нахождения географических координат по физическому адресу объекта. Например, преобразовать строку «Эрмитаж, Россия, Санкт-Петербург» в пару координат «59.94022 30.31415».
Компания Яндекс предоставляет веб-сервис со схожими возможностями под названием «Геокодер» [25]. Он позволяет определять координаты и получать сведения о географическом объекте по его названию или адресу и наоборот, определять адрес объекта на карте по его координатам (обратное геокодирование). Чтобы упростить разработку картографических мэшапов, было решено реализовать фасад для этого сервиса на языке C#, что позволит разработчикам не задумываться о формате получаемых и передаваемых данных, о возможных ошибках.
Метаданные этого класса находятся в приложении.
Внедрение в платформу Ubiq Mobile
В каждой из реализованных автором библиотек существуют функции, выполнение которых может занимать достаточно долгое время (например, выполнение описанной на веб-странице JavaScript функции, обращение к веб-сервису через интернет), за это время от клиента может прийти команда, которую необходимо обработать. Это может быть команда отмены текущего действия, команда отключения или сохранения пользовательской сессии.
Для того чтобы разрешить подобные проблемы, в платформе Ubiq Mobile взаимодействие с программными интерфейсами происходит при помощи системы сообщений. И в то время, когда приложение ожидает сообщение от одного из программных интерфейсов, могут быть обработаны другие сообщения.
Архитектура Ubiq Mobile имеет следующий механизм для использования сервисов. Приложение в момент запуска объявляет о том, что оно будет пользоваться программным интерфейсом при помощи вызова функции Use%InterfaceName%API, где %InterfaceName% — это имя программного интерфейса. В этот момент производятся необходимая подготовка для использования этого интерфейса, заводится очередь сообщений.
Для каждой из библиотек были разработаны классы сообщений, при помощи которых осуществляется коммуникация между приложением и сервисами. Сообщения аккумулируют в себе информацию о том, какая функция программного интерфейса должна быть вызвана, параметры и результат этой функции. Такой подход позволяет делать синхронные вызовы функций, притом, что в момент ожидания результата может быть произведена обработка других сообщений.
Сравнение подходов при работе с несколькими клиентами
В случае, когда несколько клиентов одновременно обращаются к приложению на платформе Ubiq Mobile, запросы клиентов могут быть обработаны при помощи нескольких стратегий. Были рассмотрены следующие варианты обработки запросов:
Для каждого клиента создавать отдельный поток, в котором будет происходить взаимодействие с картографическим интерфейсом
Дать возможность нескольким клиентам использовать поток, в котором происходит взаимодействие с картографическим интерфейсом
Первый вариант предполагает выигрыш в скорости, поскольку не осуществляется переключение контекста выполняемой задачи, но в то же время является более расточительным с точки зрения расхода памяти.
Второй вариант позволяет существенно снизить расход оперативной памяти, но в тоже время, в случае если несколько клиентов одновременно будут использовать сервис, может давать существенные задержки, связанные с переключением контекста. Измерение скорости переключения показало, что задержка составляет порядка 300-500 мс.
Для хранения информации, достаточной для переключения контекста, может быть использовано 2 способа:
Хранить обработанный браузером HtmlDocument, что позволит полностью сохранить внутреннее состояние браузера
Хранить только данные, которые отображаются на карте и свойства карты (например, позицию центра, вид карты, масштаб). Этот способ позволит уменьшить расход памяти, но в то же время будет препятствовать расширению системы и будет ограничивать свободу разработчика в выборе использованных данных и способах их хранения
Поскольку, в дальнейшем, планируется расширение и доработка предложенного автором решения, то было решено отказаться от сценария хранения данных описывающих состояние карты.
Было произведен анализ расходов памяти для сценариев хранения компоненты браузера и только загруженного документа. На каждый экземпляр компоненты браузера расходуется около 12 мегабайт оперативной памяти. На каждый документ около 5 мегабайт оперативной памяти.
Количество экземпляров
|
Расход памяти в мегабайтах
|
Компоненты браузера
|
HtmlDocument
|
10
|
140
|
58
|
20
|
250
|
103
|
30
|
370
|
148
|
По результатам сравнения было решено использовать вариант, в котором на каждого клиента создаётся по отдельному потоку. Это решение было принято по следующим причинам:
Обеспечивает большую стабильность, поскольку в нём отсутствуют потенциальные ошибки, связанные с переключением контекста, гонками[26]
Обеспечивают максимальное быстродействие
Наиболее простое с архитектурной точки зрения, что в дальнейшем позволит уменьшить расходы, связанные с рефакторингом
Базовый класс
Было решено реализовать базовый класс приложения, который будет реализовывать функциональность, специфичную для картографических мэшапов. На этот класс ляжет задача по синхронизации части отвечающий за связь с телефоном и части отвечающей за работу браузера и отрисовку карты.
Метаданные базового класса представлены в приложении, кроме того к каждой функции даются комментарии, как и для чего она может быть использована. В простейшем случае, для получения работающего приложения, требуется лишь задать позицию центра карты и несколько точек вместе со связанной с ними информацией. Эта функциональность покрывает большинство потребностей картографических мэшап-приложений.
В случае если базовых возможностей недостаточно, то разработчик может создать свою веб-страницу и реализовать в ней недостающий функционал, например, динамическое изменение изображение маркера.
В случае если базовый класс использовать неудобно, то разработчики могут использовать реализованный программный интерфейс.
|
