Глава 3 Устройство мэшапа
Архитектура мэшапов всегда состоит из трёх частей.
Сборщик содержимого — это источник данных. Данные доступны через API и различные веб-протоколы, такие как RSS, REST, веб-сервисы
Бизнес-логика — это веб-приложение, реализующее новый сервис, использующий не принадлежащие ему источники данных
Отображение — собственно пользовательский интерфейс мэшапа. В некоторых веб-приложениях вся логика может быть реализована клиентским браузером с использованием клиентского языка программирования, например, JavaScript
Сборщик содержимого
Сборщик (англ. Harvester) является одной из наиболее важных частей системы, ведь именно он определяет, как и каким образом будут получаться данные из сторонних сервисов. Считается, что мэшапы должны использовать только те сервисы, которые предоставляют для этого специальные API.
На данные, получаемые от веб-сервиса, не накладывается никаких ограничений. Чаще всего это географические координаты объектов, фотографии, видеоролики, текстовая или гипертекстовая информация.
По сути, любой сборщик является примером паттерна «Фасад»[23] (Англ. Facade). Это шаблон проектирования, который предлагает упрощённый интерфейс для большого количества кода (в случае мэшапов — код для агрегации разных источников данных с различными API).
Кроме непосредственного получения данных, на сборщик накладывается задача по переводу этих данных во внутренний формат мэшапа. Сборщик предоставляет объектную модель данных, к которой могут обращаться остальные части системы, уже не заботясь о проблемах получения данных (отсутствует связь с сервисом, данные получаются слишком долго) и правильности полученных данных. Некоторые веб-сервисы, помимо основной функциональности, могут предоставлять своё описание, например, посредством WSDL. Этот формат описывает типы данных, используемые веб-сервисом, способы подключения, поддерживаемые протоколы передачи данных, наборы методов и способы из вызова. Для многих языков программирования существуют утилиты, позволяющие преобразовать wsdl-файл в код, тем самым решив проблему транспортного уровня и создав модель данных, схожую с той, что используется на стороне сервиса.
Стоит заметить, что любое обращение к подобной модели является запросом. Соответственно, удобно представлять сборщик в качестве базы данных и использовать SQL подобный язык для извлечения данных. В частности, для языка C# удобно будет использовать Linq запросы для операций с наборами данных.
В случае если используемый сервис таков, что данные, полученные от него, не изменяются, то на сборщик также ложится задача по кэшированию данных в целях уменьшения количества запросов к серверу, экономии времени выполнения и трафика. Хорошим примером сервисов такого типа могут служить новостные источники данных, которые со временем лишь добавляют информацию, практически никогда её не удаляя и не меняя. Правильным поведением для мэшапа, использующего новостные источники данных, будет получать только изменения, которые произошли после предыдущего запроса и использовать ранее полученные данные, сохранённые локально.
На рисунке 1, представлена общая схема сборщика данных.
Service
Harvester
Cache
Xml, Json,
Harvester API
Рисунок 1
Архитектура картографических мэшапов
В картографических мэшапах сторонние сервисы можно разделить на две логические части. Первая — это картографический сервис, который отвечает, прежде всего, за отображение информации и источники данных, из которых эта информация непосредственно получается. Вторая – это сервисы данных, от которых получается информация, которая впоследствии будет отображена на карте. Общая схема взаимодействия выглядит так, как показано на рисунке 2.
Data Harvester
Data Harvester
Harvester
Service
Logic
Map View
Рисунок 2
Service
Рассмотрим конкретный пример: есть веб-страница, отображаемая в браузере, на ней необходимо поместить область с картой; кроме того имеется сервис, данные которого нужно отображать на карте. В этом случае логично будет использовать видоизменённый паттерн Model-View-Controller[15].
Сборщик содержимого порождает объектную базу данных и модель данных, используемую логикой мэшапа. Именно объектная база данных соответствует части Model. Кроме того, на базу ложится задача по предоставлению возможности изменения данных и хранению изменённых данных.
Чаще всего, интерфейсы картографических сервисов, будь то Яндекс Карты или Google Maps, предоставляют возможности для выполнения пользователями типовых операций на карте, будь то перемещение карты, изменение масштаба, выбор конкретного места на карте и обеспечивает возможность обработки реакций пользователя посредством механизма событий. Именно при помощи событий будет осуществляться обратная связь с контроллером, а при помощи функций ввода информации, модель сможет отображаться непосредственно на карте.
Вся бизнес-логика данного мэшапа целиком уходит в контроллер, задачей которого является реакция на события представления. Кроме того, на контроллер ляжет задача по передаче данных из модели в представление, что является существенным отличием от классического паттерна MVC. В целях упрощения восприятия возможно введение в архитектуру дополнительной сущности — передатчика (Mapper), который будет отвечать непосредственно за отображение модели на карте. В то же время, для небольших проектов, использование передатчика усложнит написание кода.
Рассматриваемый пример можно изобразить на рисунке 3:
Service
Harvester
Mapper
View
Controller
Business logic
Controller
Business logic
Рисунок 3
Рассматриваемый пример хорошо отражает принцип работы с картографической системой в целом. Для большинства задач можно произвести декомпозицию, после чего каждая из частей будет представлять описанный выше сервис. Таким образом, можно работать с таким мэшапом как с элементом большей системы. В частности, этот мэшап можно представить в виде сервиса, который общается непосредственно с конкретным картографическим сервисом.
View
Рисунок 4
Service
Оформлять работу с каждым из сервисов данных в виде отдельного сервиса, который может быть непосредственно отображён на карте, выгодно с точки зрения SOA архитектуры. Во-первых, такой подход позволит сократить время, затрачиваемое на рефакторинг кода, в случае если один из сервисов данных поменяется. Во-вторых, при добавлении сущности передатчика из модели в представление, в случае если изменится сам интерфейс карт, изменениям будет подвержена лишь небольшая часть проекта, поскольку с большой долей вероятности можно будет ограничиться лишь изменениями в самом передатчике. В-третьих, подобный подход позволит в дальнейшем переиспользовать новый сервис для других задач, а следовательно увеличит расширяемость системы. Кроме того, код, используемый внутри передатчика, с большой вероятностью может быть переиспользован, из-за чего расходы на соответствие SOA архитектуре не станут слишком велики.
Следует заметить, что сервисов данных, которые предоставляют непосредственно географические координаты объекта, на данный момент достаточно мало. Чаще всего это информация задана при помощи естественного языка, то есть в виде адреса или указания на определённое место. Картографические сервисы предоставляют возможность поиска географических координат по запросам, заданным на естественном языке, но внесение задачи по преобразованию данных из модели в географические координаты в передатчик чрезмерно его усложнит. Поэтому удобно будет расположить это преобразование в отдельном сервисе, использовать который будет легче, чем запросы к картографическому сервису. Например, в эту часть системы можно будет включить фильтрацию результатов выдачи, чтобы все географические координаты располагались в пределах одной области, например в одном городе.
Архитектуру мэшапа картографического типа удобно представить в виде дерева сервисов, часть из которых может непосредственно отображать какую-либо информацию на карту.
Service
View
Service
Service
Service
Рисунок 5
В рамках практической части данной работы построено мэшап-приложение в соответсвии с данной архитектурой. Единственное его отличие будет заключатся в том, что верхним слоем будет сервис, отвечающий за передачу контента на телефон и осуществление обратной связли.
|
