Разработка коллажей

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

Web-коллажи создаются путем объединения контента, описаний или функциональности приложений, получаемых из разнородных источников в WWW [1]. Коллажи позволяют объединить все эти источники для создания новых приложений или сервисов. Контент и элементы внешнего представления, как правило, предоставляются в виде потоков RSS или Atom, в различных XML-форматах, в виде HTML, Shock-Wave Flash (SWF) и др. Открытые интерфейсы прикладного программирования (на JavaScript, например) обычно формируют функциональность приложений. Контент, функциональность и внешнее представление связываются вместе в браузере с помощью серверных языков скриптов, таких как Hypertext Preprocessor (PHP) или Ruby, либо средствами традиционных языков, таких как Java или C#.

«Коллаж» (mashup) становится одним из самых популярных терминов в области Web-приложений. Многие организации спешат предложить свои средства их поддержки — или называют уже существующие интеграционные решения инструментами для создания коллажей. При такой путанице трудно различать коллажи и традиционные интеграционные решения, поэтому попытаемся внести определенную ясность в отношении того:

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

Рассмотрим ряд популярных инструментальных средств создания коллажей и покажем, как они поддерживают разработку «функционально богатых Internet-приложений» (Rich Internet Application). Наша цель состоит не в том, чтобы установить, какие виды поддержки существуют для разработки коллажей, а в том, чтобы выявить новые характеристики и параметры, по которым можно сравнивать и анализировать появляющиеся инструменты и подходы.

Подходы к разработке коллажей

Разработка коллажей отличается от создания традиционных компонентных приложений главным образом тем, что коллажи, как правило, служат для конкретной «ситуационной» (краткосрочной) цели и формируются при помощи новейших, простых в использовании Web-технологий — таких как Web-сервисы на базе Representational State Transfer или потоки RSS/Atom. В силу этого Web представляет собой естественную среду для коллажей.

Приложение HousingMaps (www.housingmaps.com) на рисунке — пример удачного коллажа, увязывающего каталог жилых помещений из Craigslist с картой из Google Maps и предназначенного для тех, кто переезжает из одного города в другой и ищет жилье. Как правило, когда люди просматривают список жилых помещений, адрес дома им ни о чем не говорит, если они не знакомы с новой местностью. HousingMaps предоставляет пользователям список домов и указывает их местонахождение, а также дает описание жилья и показывает его на карте при выборе соответствующего объекта из списка. Мы могли бы вручную создать такое приложение-коллаж с помощью традиционных технологий Web-программирования, однако специализированные средства для создания коллажей существенно упрощают задачу, позволяя составлять свои собственные коллажи даже конечным пользователям.

Создание коллажей вручную

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

Предположим, никаких специальных средств разработки нет. Что в этом случае нужно сделать, чтобы вручную создать приложение, подобное HousingMaps? Прежде всего, ознакомиться с двумя приложениями-источниками (Craigslist и Google Maps) и определить, как извлекать данные с обоих сайтов. Если Google Maps предоставляет общедоступные JavaScript API, то Craigslist передает свои списки через RSS, и для извлечения данных о жилых помещениях и адресах необходимо проанализировать и интерпретировать поток RSS, получаемый из Craigslist. Чтобы сконфигурировать маркеры, появляющиеся по щелчку мыши, над которыми во всплывающем окне выводится информация о жилом помещении, необходимо использовать Google Maps JavaScript API. Для того чтобы такие всплывающие окна появлялись автоматически, требуется специальная функция JavaScript, которая фиксирует выбор жилого помещения и реагирует на это вызовом Google Maps API для выбора соответствующего маркера. Несмотря на то что карты Google Maps имеют свой собственный пользовательский интерфейс, пользователи смогут выбирать свойства, оформленные в Craigslist, только в том случае, если заполнить и должным образом отформатировать соответствующую таблицу. Наконец, необходимо расположить два компонента должным образом, чтобы сформировать пользовательский интерфейс композитного приложения. Столь сложные и отнимающие массу времени задачи не позволяют рядовым пользователям программировать собственные коллажи.

Разработка коллажей с помощью инструментов

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

Мы выбрали наиболее характерные подходы к реализации инструментальных средств создания коллажей, ориентированных на конечных пользователей. Несколько альтернативных и дополняющих подходов приводятся во врезке «Работа с повторно используемыми компонентами».

Yahoo Pipes. Yahoo Pipes (pipes.yahoo.com) позволяет объединять потоки данных для создания коллажей данных с помощью визуального редактора. «Каналом» называют конвейер обработки данных, поступающих из одного или нескольких источников (например, потоки RSS/Atom или источники XML), с использованием наборов взаимосвязанных операторов, выполняющих определенную задачу обработки. Сюда относятся операторы для манипулирования потоками данных (например, сортировка и фильтрация) и операторы для реализации циклов, регулярных выражений или счетчиков. Канал также поддерживает более совершенные возможности, такие как извлечение данных о местонахождении (например, географических координат, выявленных и преобразованных из информации о местонахождении, найденной в текстовых фрагментах) или выделение терминов (например, ключевых слов). Yahoo Pipes служит для того, чтобы предоставить пользователям возможности создавать конвейеры обработки данных, которые фильтруют, преобразуют, дополняют и объединяют потоки данных и снова представляют их в виде потоков RSS.

Посмотрим, как Yahoo Pipes может помочь в разработке примера HousingMaps. Поскольку Pipes не предоставляет пользовательских интерфейсов, а выдает поток RSS, мы не можем явно реализовать пользовательский интерфейс из рис. 1. Вместо этого мы используем Pipes для обработки потока Craigslist и определения информации о местонахождении («геокодов») при помощи соответствующего экстрактора Pipes. Тогда мы сможем воспользоваться информацией, описывающей местонахождение, чтобы дополнить поток Craigslist ссылкой, которая позволит отображать адрес жилого помещения на карте, путем передачи геокодов в Google Maps.

Google Mashup Editor. GME (editor.googlemashups.com) предоставляет среду для разработки коллажей на базе шаблонов, предлагая набор стандартных модулей, с помощью которых пользователи могут инкапсулировать и компоновать внешние данные. Так, модуль list представляет поток RSS/Atom в виде списка, а модуль item представляет отдельный элемент в потоке. Модули могут инициировать предопределенные события, которые другие модули способны перехватывать и затем выполнять соответствующие действия. Создание коллажей предусматривает разработку шаблонов пользовательского интерфейса, содержащих управляющие XML-теги и элементы компоновки HTML/CSS вместе со встроенным кодом JavaScript. Во время исполнения GME заполняет шаблоны пользовательского интерфейса и представляет их в виде Web-страниц.

При реализации приложения HousingMaps мы могли бы интегрировать поток Craigslist с помощью модуля list и использовать модуль item для того, чтобы показать детали описания конкретного жилого помещения. Модуль map из GME изначально поддерживает Google Maps, и когда пользователь указывает на жилое помещение и щелкает клавишей мыши в модуле Craigslist, этот модуль инициирует событие «выбрать», которое модуль map может перехватывать и после этого выводить всплывающее окно над маркером, отображая в нем информацию о выбранном жилом помещении. Нам следует интегрировать модуль Craigslist и Google Maps в шаблон пользовательского интерфейса, который определяет компоновку приложения коллажа.

Microsoft Popfly. Popfly (www.popfly.ms) предлагает визуальную среду на базе компонентов для разработки коллажей. В Popfly повторно используемые компоненты или блоки могут действовать как посредники между внешними сервисами (например, Web-сервисами [2]) или реализовывать полезную функцию на JavaScript (скажем, вычислять площадь круга данного радиуса). Блоки имеют операции с входными и выходными параметрами, которые указываются в специальном XML-дескрипторе. Блок также может действовать как поверхность для вывода изображения, а именно, как часть пользовательского интерфейса, которая извлекает данные из других блоков и отображает их, давая пользователю возможность взаимодействовать с ними и позволяя разработчику компоновать приложение коллажа. Чтобы создать приложение HousingMaps, нам необходимы три блока: блок потока RSS для потока Craigslist, блок map и блок table.

Если мы используем Microsoft Virtual Earth (microsoft.com/virtualearth) вместо Google Maps, то все эти три блока уже имеются, и нужно поместить их на поверхность проектирования коллажа, а затем связать выходной параметр операции getItems из блока RSS с двумя блоками вывода изображения для RSS и Virtual Earth. Возможно, что для того, чтобы корректным образом сконфигурировать первоначальный набор маркеров, блок RSS придется дополнить подходящей операцией JavaScript.

Intel Mash Maker. Mash Maker (mashmaker.intel.com) предоставляет среду для интеграции данных из аннотированных Web-страниц, базирующуюся на специальном подключаемом модуле для браузера. Вместо того чтобы использовать в качестве входных данных информацию из структурированных источников данных, таких как RSS или Atom, Mash Maker дает пользователям возможность аннотировать структуру Web-страниц при просмотре и использовать такие аннотации для вырезки данных из аннотированных страниц. Опытные пользователи могут с помощью интегрированного редактора структур вводить выражения XPath посредством DOM Inspector (дополнительный модуль для браузера Firefox) в FireBug. Составление коллажей с помощью Mash Maker выполняется путем копирования и вставки в двух режимах слияния контента: слияние целых страниц, при котором пользователь вставляет контент одной страницы как заголовок в другую; поэлементное слияние, при котором пользователь объединяет контент из двух страниц на уровне строк с учетом дополнительных аннотаций пользователя. Для слияния более чем двух страниц можно использовать оба метода.

В случае с HousingMaps мы сначала аннотируем структуру соответствующей страницы Craigslist, поскольку Mash Maker работает с обычным контентом HTML, а не с RSS. Затем объединяем страницу Craigslist со страницей Google Maps, используя механизм копирования и вставки. Точнее, мы применяем поэлементное слияние, поскольку выводим каждый элемент со страницы Craigslist как отдельный маркер на карте.

Quick and Easily Done Wiki. QedWiki (services.alphaworks.ibm.com/qedwiki)— средство от IBM для «автора коллажей» на базе вики, выполняемое в браузере клиента и обеспечивающее доступ к IBM Mashup Hub (services.alphaworks.ibm.com/mashuphub). Mashup Hub поддерживает создание потоков данных и виджетов пользовательского интерфейса и включает в себя средство Data Mashup Fabric for Intranet Applications (DaMIA) для сбора данных и работы с ними [3]. Cистема позволяет редактировать и просматривать коллажи, а также обмениваться ими. Коллажи составляются из виджетов на базе JavaScript или PHP, структура которых определяет поведение коллажа. Виджеты представляют собой компоненты приложения и могут иметь или не иметь свой собственный пользовательский интерфейс. Для того чтобы собрать коллаж, пользователь выбирает компоновку страницы (шаблон HTML), а затем буксирует виджеты на сетку страницы и конфигурирует их в интерактивном режиме.

Чтобы создать приложение HousingMaps с помощью QedWiki, сначала мы создаем новую страницу wiki и выбираем «компоновочную сетку» (grid layout). В нашем случае мы выбираем компоновку, которая позволяет разместить Google Maps и предложения жилых помещений рядом друг с другом (в двух колонках). Затем ищем виджет GoogleMap в палитре виджетов, буксируем его на компоновочную сетку и помещаем в левую колонку. Мы используем виджет LoadFeed для доступа к RSS-потоку Craigslist и заполняем виджет ShowData предложениями жилых помещений, сообщая ShowData, что он должен брать данные из виджета LoadFeed. Для того чтобы расположить жилые помещения на карте, мы можем теперь во время исполнения просто брать адреса из виджета ShowData и помещать их на виджет GoogleMap.

Особенности подходов к созданию коллажей

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

Компонентная модель

Компонентная модель определяет природу компонентов и влияет на то, как эти компоненты можно объединять. Четко определенный компонентный интерфейс, например, поддерживает повторное использование, в то время как гибкий компонентный интерфейс гарантирует расширяемость. Мы описываем компонентную модель с помощью трех характеристик.

Первая из них — тип. Компонент может иметь тип данных (DA), тип логики приложения (AL) или тип пользовательского интерфейса (UI), в зависимости от того, действует ли он исключительно как источник данных, как компонент, предоставляющий доступ к логике приложения, или как компонент, который обеспечивает графический пользовательский интерфейс (GUI). Во-вторых, мы оцениваем интерфейс модели. Компонент может предоставлять интерфейс «создания-чтения-обновления-удаления» (CRUD), прикладные программные интерфейсы на определенных языках программирования или IDL/WSDL, разметки XML/HTML, либо он может предоставлять конечным пользователям только элементы GUI. Компонент может также предлагать комбинацию этих элементов. Наконец, расширяемость показывает, может ли пользователь создавать новые компоненты или расширять компонентную модель для того, чтобы реализовать определенные требования приложения, например, новые операции.

Yahoo Pipes поддерживает компоненты DA и AL за счет операторов, которые предоставляют доступ к потокам RSS/Atom и внешним Web-сервисам. Компоненты DA поддерживают только операции чтения, а внешние Web-сервисы имеют интерфейс RESTful на основе JavaScript Object Notation (JSON) или RSS. Компонентные модели Yahoo Pipes фиксированы.

GME поддерживает компоненты DA, AL и UI. Компоненты DA, как правило, поддерживают интерфейс с помощью разметки, компоненты AL — через JavaScript, а компоненты UI — посредством разметки и JavaScript. Компонентные модели GME являются гибкими.

Popfly также поддерживает компоненты DA, AL и UI. В Popfly все компоненты взаимодействуют с помощью JavaScript, а компонентные модели являются расширяемыми.

Intel Mash Maker поддерживает компоненты DA, выделенные из аннотированных Web-страниц (например, таблица или карта). Их интерфейс может быть интерпретирован как разметка XML, а компонентные модели фиксированы.

QedWiki главным образом ориентирован на компоненты UI, а Mashup Hub поддерживает компоненты DA и AL. Компоненты имеют интерфейс JavaScript и их можно расширять.

При традиционной интеграции расширяемые компоненты приложений со специфическими для приложений API описывают Web-сервисы. При интеграции данных [4] ключевую роль играют ориентированные на данные компоненты, которые часто фиксированы или имеют ограниченную расширяемость. Например, ETL-приложения (Extract-Transform-Load — «выделение-преобразование-загрузка») имеют множество встроенных модулей, которые выполняют операции объединения или поиска в реляционной базе данных или в документах XML. Специфическое поведение, как правило, реализуется через SQL-компонент общего назначения.

Композиционная модель

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

Во-первых, мы различаем тип вывода модели. Как и в случае с компонентами, предоставляющими входные данные, результат композиции может иметь тип DA, AL или UI, в зависимости от того, что именно предоставляет композиция: данные, программируемые API или приложения с пользовательским интерфейсом. Вторая характеристика — это организационный стиль. Он определяет, как будут определяться и синхронизироваться выполнение компонентов. Существует три основных подхода.

• Стиль на основе потоков определяет организацию как последовательные или частично упорядоченные задачи или компоненты и выражается с помощью формализма, подобного потоковым диаграммам.
• Стили на основе событий используют модель публикации — подписки. Они особенно хорошо подходят для поддержки синхронизованного поведения компонентов.
• При использовании стиля на основе компоновки компоненты (имеющие или не имеющие пользовательские интерфейсы) организуются в общую структуру композитного приложения. Поведение каждого компонента определяется индивидуально с учетом реакции других компонентов на действия пользователя.
• В-третьих, мы оцениваем стиль передачи данных. Мы определяем два подхода к передаче данных:
• подход потоков данных, при котором данные передаются от компонента к компоненту;
• подход «классной доски», при котором данные записываются в переменные, служащие источником и результатом вызова операции над компонентами, во многом так же, как в языках программирования.

Кроме того, композиция может быть дискретной (на основе экземпляров) и непрерывной. Модель на основе экземпляров — это традиционная модель композиции сервисов, при которой появление определенного рода сообщений активирует новый экземпляр композиции, а система запускает этот экземпляр в одном и том же главном потоке и в том же контексте (во многом так же, как работает программа).

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

Еще одна характеристика связана с исключениями и транзакциями. Композитная модель может поддерживать или не поддерживать обработку исключений и транзакций. Обработка исключений, если она поддерживается, может выполняться в соответствии с подходом «пропускать-и-перехватывать» (в стиле Java) или может строиться на правилах (используя правила «событие-условие-действие», связанные с композицией). Транзакции, если они поддерживаются, всегда обрабатываются в соответствии с каким-либо вариантом модели Saga [5].

Yahoo Pipes, скорее всего, можно считать лучшим образом интеграции входных данных DA (каналы — это потоки RSS). Его язык графического моделирования опирается на потоки, и, соответственно, данные также передаются через потоки. Pipes использует экземпляры и не предоставляет обработку исключений или поддержку транзакций.

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

Popfly порождает выходные данные UI и использует стиль организации, опирающийся на события, а для передачи информации — подход потоков данных. Компоненты непрерывны. Как и GME, пакет Popfly не поддерживает исключения и транзакции.

Intel Mash Maker ориентирован на вывод UI. В Mash Maker контенты связываются вместе в стиле компоновки (слияние страниц целиком) или потоков (поэлементное слияние). Он использует извлечение данных из аннотированных Web-страниц в стиле «классной доски». Модель Mash Maker больше всего напоминает модель на основе экземпляров, а обработка исключения и транзакции не поддерживается.

Как и GME, Popfly и Mash Maker, пакет QedWiki порождает выходные данные UI, предлагая организацию в стиле компоновки, а компоненты передают данные в стиле «классной доски». Виджеты непрерывны. QedWiki не поддерживает исключения и транзакции.

Традиционная интеграция, как правило, строится на потоках (вспомните Business Process Execution Language и большинство процессов ETL), а модель данных на базе XML следует подходу «классной доски» для сервис-ориентированных архитектур (Service-Oriented Arcitecture, SOA) и реляционной модели с потоками данных для ETL. В обоих случаях используется модель на базе экземпляров. Однако в SOA экземпляр создается с появлением определенного сообщения (такого, как заказ на покупку), в то время как в ETL экземпляр создается периодически (для каждого извлечения данных). Традиционная интеграция порождает выходные данные DA или AL, в то время как коллажи, как правило, включают в себя некую форму интеграции на уровне UI. Что же касается исключений и транзакций, то традиционная интеграция предлагает обработку исключений, подобную Java, и обработку транзакций в стиле Saga с предопределенными, но расширяемыми типами исключений (например, ошибки SOAP в BPEL или ошибки DB в ETL).

Среда разработки

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

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

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

Yahoo Pipes предоставляет визуальный редактор AJAX с возможностями буксировки, предназначенный для пользователей, имеющих базовые навыки программирования. Этот редактор работает в стандартном Web-браузере с поддержкой JavaScript-объекта XMLHttpRequest.

Предлагаемый в GME текстовый редактор AJAX на основе браузера, поддерживающий синтаксическое выделение и автоматическое добавление тегов по первым символам, рассчитан на программистов. Для его работы достаточно стандартного Web-браузера.

Microsoft Popfly предлагает графический и текстовый редактор с поддержкой буксировки, который рассчитан на пользователей Web. Пакет Popfly опирается на технологию Microsoft Silverligh, это обязательный дополнительный модуль для браузера.

Точно так же Intel Mash Maker поддерживает пользовательский интерфейс «указал-и-выбрал», который дает возможность опытным пользователям и программистам аннотировать страницы, а неопытным — извлекать и объединять данные с помощью копирования и вставки. Mash Maker требует специального подключаемого модуля, который дополняет браузер функциями работы с коллажами.

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

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

Среда исполнения

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

Первая характеристика — это стиль развертывания. Как и в случае с традиционными Web-приложениями, вы можете установить коллаж в виде автономного решения на Web-сервере, управляемом разработчиком коллажей, или работать с ним через сторонний Web-сервер (как правило, принадлежащий поставщику среды разработки коллажей). Еще одна характеристика — местонахождение во время исполнения. Вы можете собирать коллажи на сервере (например, с помощью PHP или Ruby), на клиенте (например, внутри браузера с помощью JavaScript), или там и там. Если интеграция выполняется на сервере, то браузер просто отображает полученное в результате композитное приложение. Серверные подходы могут использовать стиль реализации на базе ядра или Web-приложений. Подход на базе ядра требует, чтобы механизм, аналогичный ядру процессов, запускал коллаж (например, собирал и обрабатывал потоки). При использовании второго подхода коллаж реализуется как Web-приложение, поэтому его могут запускать как Web-серверы, так и серверы приложений. Третья характеристика среды исполнения — системные требования. Как и в случае со средами разработки, работа коллажа может зависеть от наличия дополнительных подключаемых модулей или расширений для браузера. Наконец, мы также оцениваем масштабируемость среды. Ее можно определять по трем показателям: число источников данных, число композиций и число пользователей. В целом, при клиентском подходе проблем с маштабируемостью не возникает. Коллаж выполняется на клиенте, поэтому нет никаких узких мест (за исключением перегрузки в самих источниках данных, но сам коллаж на это никак не влияет). Проблемы масштабируемости связаны с числом экземпляров и, как следствие, с числом пользователей и сложностью коллажа (которая зависит от числа источников и соответствующей обработки данных). Во всех случаях клиентские подходы используют те же средства поддержки масштабируемости, что и традиционная интеграция или Web-приложения, опирающиеся на методики масштабирования потоков заданий и приложений.

Композиции Yahoo Pipes размещаются на сервере Yahoo. Система вычисляет и собирает каналы на сервере (очевидное использование ядра) таким образом, чтобы для работы канала не требовались особые системные возможности. Однако серверному ядру, которое запускает каналы, может не хватать производительности для обработки множества каналов, множества пользователей, обращающихся к одному каналу, или поддержки канала, содержащего сотни источников.

Коллажи GME размещаются и выполняются на сервере Google и не имеют особых системных требований. Система компилирует коллажи в традиционные Web-приложения.

Коллажи Popfly размещаются на сервере Microsoft. Однако выполнение приложения Popfly осуществляется на клиенте и, как правило, требует наличия модуля Silverlight. Исполнение на клиенте способствует масштабируемости, поскольку интеграция множества источников выполняется главным образом на стороне клиента.

Коллажи Intel Mash Maker хранятся на клиентском ПК и выполняются в браузере Web с помощью подключаемого модуля Mash Maker. Хотя маловероятно, что в коллаже будет объединяться большое число источников, Mash Maker должен иметь возможность адекватно масштабироваться.

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

Подходы, основанные на SOA или ETL, как правило, имеют централизованный сервер ядер, который запускает определение процессов, вызывая сервисы или хранилища данных. Распределение рабочей нагрузки по нескольким ядрам гарантирует масштабируемость.

Перспективы

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

В целом, коллажи должны быть простыми, полезными и удобными в работе. Эта простота важнее функциональной полноты или хорошей расширяемости (как в SOA или BPEL). С улучшением инструментальной поддержки (например, с созданием более качественного пользовательского интерфейса) и появлением множества компонентов или модулей, конечные пользователи смогут составлять свои собственные коллажи. С учетом этого мы также считаем необходимыми разработку парадигм интеграции, ориентированных на конечных пользователей. С появлением таких парадигм изучение, организация, поиск и интеграция коллажей станут простыми и удобными. Это поможет превратить создание коллажей из процесса, выполняемого вручную и требующего длительного времени для написания скриптов, в работу с набором простых в поиске и расширяемых параметризованных шаблонов, которые описывают практически все многообразие сервисов коллажей. Скорее всего, поиск компонентов коллажей также со временем станет удобнее, причем не только благодаря системам поиска, подобным Google, но и благодаря зарождающейся тенденции к формированию Internet-сообществ, состоящих из разработчиков тегов для коллажей и блоггеров, и действующих в стиле социальных сетей.

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

Кроме того, необходимо специализированное программное обеспечение промежуточного слоя для интеграции пользовательского интерфейса. Сегодня эту роль играет Всемирная Паутина, по существу, не предлагающая никакой поддержки, рассчитанной специально на коллажи. Парадигмы программного обеспечения промежуточного слоя, такие как «публикация — подписка», которые оказались крайне успешными в области интеграции приложений предприятий (Enterprise Application Integration, EAI), так же хорошо подходят и для коллажей. Это объясняется природой коллажей, которые во многом опираются на события (по существу, они представляют собой реактивные приложения, отслеживающие появление события из таких источников, как контент потоков новостей или действия пользователя).

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

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

Литература

1. D. Merrill, Mashups: The New Breed of Web Application. IBM DeveloperWorks, 2006, www-128.ibm.com/developerworks/library/x-mashups.html?ca=dgr-lnxw16MashupChallenges.
2. G. Alonso et al., Web Services: Concepts, Architectures, and Applications. Springer, 2004.
3. M. Altinel et al., Damia: A Data Mashup Fabric for Intranet Applications. Proc. Very Large Databases Conf. (VLDB 07), VLDB Endowment, 2007.
4. M. Lenzerini, Data Integration: A Theoretical Perspective. Proc. Symp. Principles of Database Systems (PODS 02), ACM Press, 2002.
5. H. Garcia-Molina, K. Salem, Sagas. Proc. ACM Special Interest Group on Management of Data 1987 Ann. Conf. (SIGMOD 87), ACM Press, 1987.

Джин Ю (jyu@cse.unsw.edu.au)— аспирант университета Нового Южного Уэльса (Сидней). Буалем Бенаталлах (boualem@cse.unsw.edu.au)— профессор университета Нового Южного Уэльса. Фабио Касати (casati@dit.unitn.it)— профессор университета Тренто (Италия). Флориан Дэниэл (daniel@disi.unitn.it)— научный сотрудник университета Тренто.