Содержание


Гибридные приложения: новое поколение web-приложений

Введение в гибридные приложения

Comments

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

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

Итак, на что похоже гибридное приложение? Web-сайт ChicagoCrime.org представляет собой хороший наглядный пример так называемого картографического гибридного приложения. Являясь одним из первых гибридных приложений, завоевавших популярность в прессе, этот Web-сайт объединяет данные о преступности, полученные из баз данных реального времени полицейского департамента города Чикаго, с картографическими функциями сервиса Google Maps. Пользователи могут работать с гибридными сайтами в диалоговом режиме, указывая исходные требования к выводу запроса; можно, например, вывести на экран графическое изображение карты, на которой размещены виртуальные канцелярские кнопки; если нажать мышью на такой кнопке, появится выноска с самыми свежими данными о преступности в Южном Чикаго и ссылками на подробное описание для каждого инцидента. Идея и реализация просты, а визуальная композиция из данных о преступности и картографических данных эффективна.

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

Классы гибридных приложений

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

Картографические гибридные приложения

В наш век информационных технологий человечество осуществляет сбор очень больших объемов данных о субъектах и действиях; и те, и другие снабжаются примечанием о месте действия или размещения. Все эти совершенно разные наборы данных содержат и данные о размещении, которые просто требуют графического отображения с использованием карт местности. Одним из самых главных катализаторов появления гибридных приложений было появление на сайте Google программного интерфейса приложения (API) Google Maps. Этот сервис стал тем шлюзом, который дал возможность web-разработчикам (а также любителям, начинающим и всем остальным) привязывать любые типы данных (буквально все что угодно - от ядерных инцидентов до коров, участвующих в выставке крупного рогатого скота в Бостоне) к картам местности. Нельзя не отметить появившиеся вскоре после этого API от Microsoft (Virtual Earth), Yahoo (Yahoo Maps) и AOL (MapQuest).

Видео и фото гибридные приложения

Появление сайтов, предоставляющих место для размещения фотографий, и социальных сетей, например, Flickr, с API, которые используют фотографии, предоставленные для общего использования, привело к созданию множества интересных гибридных приложений. Поскольку метаданные этих контент-провайдеров связаны с изображениями, размещенными на их серверах (кто сделал фотоснимок, кто на нем изображен, место и время съемки, и так далее), разработчики гибридных приложений могут привязывать фотографии к другой информации, которую можно ассоциировать с этими метаданными. Гибридное приложение может, например, проанализировать текст песни или стихотворения и создать мозаику или коллаж из подходящих по сюжету фотографий или отобразить схему социальной сети, основываясь на метаданных фотографий (субъект, временная метка и другие метаданные). Еще один пример: приложение может в качестве входных данных использовать какой-либо web-сайт (например, новостной сайт типа CNN) и проиллюстрировать текст фотографиями, сопоставляя размеченные фотографии с текстом новостей.

Поисковые и торговые гибридные приложения

Поисковые и торговые гибридные приложения существовали задолго до того, как был создан термин гибридное приложение. До наступления эпохи Web-API основанные на сравнительном методе инструменты - BizRate, PriceGrabber, MySimon и Google's Froogle - использовали сочетание технологий бизнес-бизнес (b2b) или захвата дампа экрана для того, чтобы собирать сравнительную информацию о ценах. Чтобы содействовать распространению гибридных и других интересных web-приложений, клиенты торговых площадок в интернете, таких как eBay и Amazon, создали API для программного доступа к своему контенту.

Новостные гибридные приложения

Источники новостей (например, New York Times, BBC или Reuters) с 2002 года используют технологии синикации RSS и Atom (о которых говорится в следующем разделе) для распространения новостных каналов, сгруппированных по различным темам. Mashup-каналы для синдикации новостей могут собирать каналы новостей, выбранные пользователями, и представлять их через интернет, создавая персональную газету, которая учитывает интересы конкретного читателя. Примером может послужить сайт Diggdot.us, который собирает каналы технических новостей с сайтов Digg.com, Slashdot.org и Del.icio.us.

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

Архитектура

Гибридное приложение структурно составлено из трех различных участников, которые логически или физически обособлены (они могут быть разделены границами сетей и организаций): провайдеров API/контента, mashup-сайта и клиентского web-браузера.

  • Провайдеры API/контента. Это провайдеры (иногда невольные) контента, который используют гибридные приложения. В примере с ChicagoCrime.org провайдерами являются Google и полицейский департамент Чикаго. Чтобы содействовать извлечению данных, провайдеры часто распространяют контент через web-протоколы, например, REST, web-сервисы и технологии RSS/Atom (которые описаны ниже). Однако многие потенциально интересные данные не предоставляют (пока) удобного API. Гибридные приложения, извлекающие контент с таких сайтов, как Wikipedia, TV Guide и практически всех web-сайтов в правительственных и публичных доменных зонах, осуществляют это при помощи технологии захвата дампа экрана. В данном контексте захват дампа экрана обозначает процесс, при котором специальный инструмент пытается извлечь информацию из ресурсов контент-провайдера путем проведения синтаксического анализа web-страниц, которые первоначально предназначались для использования человеком;
  • Гибридные сайты. Это сайты, на которых размещены гибридные приложения. Довольно интересно, что только по тому, что на каком-либо web-сайте логически размещено гибридное приложение, нельзя точно сказать, где оно выполняется. С одной стороны, гибридные приложения могут быть реализованы так же, как традиционные web-приложения, которые используют технологии динамической генерации контента на стороне сервера, как, например, Java-сервлеты, CGI, PHP или ASP.

    С другой стороны, смешанный контент может генерироваться непосредственно в клиентском браузере посредством выполнения сценариев на стороне клиента (то есть, JavaScript) или апплетов. Логическая схема клиентской стороны часто представляет собой комбинацию программного кода, встроенного непосредственно в web-страницу гибридного приложения, и библиотек API для создания сценариев или апплетов (предоставляемых контент-провайдерами), на которые ссылается данная web-страница. Гибридные приложения, использующие такой принцип, можно назвать полнофункциональными интернет-приложениями (rich internet applications, RIA); это означает, что они в значительной степени ориентированы на интерактивное взаимодействие с пользователем. (Полнофункциональные интернет-приложения (RIA) - это одно из названий следующего поколения web-сервисов во Всемирной паутине, которые сейчас обозначаются как сервисы "Web 2.0"). Преимущества выполнения гибридных операций на стороне клиента включают меньшую нагрузку на сервер гибридного приложения (данные могут быть получены непосредственно от контент-провайдера) и более бесперебойную работу для пользователя (страницы могут запрашивать обновления своего контента по частям, без обновления страницы полностью). API Google Maps предназначен для доступа через размещенные на стороне браузера сценарии JavaScript и является примером технологии на стороне клиента.

    Часто гибридные приложения для осуществления сбора данных используют сочетание логических схем серверной и клиентской сторон. Многие гибридные приложения используют данные, которые поставляются напрямую этим приложениям посредством собственной базы данных пользователей, что делает источник данных (по меньшей мере один) локальным. Кроме того, выполнение сложных запросов к нескольким источникам данных (например, "покажите среднюю цену недвижимости, которая была приобретена актерами, снимавшимися в фильмах вместе с Кевином Бэконом") требуют выполнения расчетов, которые невозможно выполнить в рамках клиентского web-браузера;

  • Клиентский web-браузер Это среда, в которой приложение интерпретируется в графическом виде и происходит взаимодействие с пользователем. Как говорилось выше, гибридные приложения используют логическую схему клиентской стороны для сбора и компоновки гибридного содержимого.

Ajax

В компьютерном сообществе идут споры по поводу того, является ли Ajax сокращением (некоторые считают, что Ajax означает "Asynchronous JavaScript + XML"). Независимо от этого, Ajax, скорее, представляет собой модель web-приложения, чем конкретную технологию. Он включает в себя несколько технологий, которые объединяет асинхронность загрузки и способ представления контента:

  • XHTML и CSS для представления стиля;
  • API модели DOM (Document Object Model), предоставляемый браузером для динамического отображения и взаимодействия;
  • Асинхронный обмен данными, обычно XML;
  • Использование сценариев на стороне браузера, главным образом, JavaScript.

Цель совместного использования этих технологий - это обеспечение целостной, бесперебойной работы пользователя через интернет путем обмена небольшими количествами данных с серверами, на которых размещен контент, вместо того, чтобы перезагружать и заново интерпретировать всю страницу после нескольких действий пользователя. При помощи различных наборов инструментов Ajax и библиотек (например, Sajax или Zimbra), обычно реализованных в виде сценариев JavaScript, можно спроектировать движки Ajax. API Google Maps API имеет собственный движок Ajax, и действие, которое он оказывает на работу пользователя, очень впечатляет: он ведет себя так, как реальное web-приложение, в котором нет полос прокрутки для манипуляций или стрелок перехода, перезагружающих страницу.

Web-протоколы: SOAP и REST

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

SOAP - это основополагающая технология парадигмы web-сервисов. Первоначально это сокращение означало Simple Object Access Protocol (простой протокол доступа к объектам), но впоследствии получило новую расшифровку: Services-Oriented Access Protocol (протокол сервис-ориентированного доступа, или просто протокол SOAP), потому что основная область использования протокола переместилась с систем на базе объектов на возможность взаимодействия через обмен сообщениями. В спецификации SOAP два главных компонента. Первый - это использование формата XML-сообщений для платформенно-агностического кодирования, второй компонент - структура сообщения, состоящая из заголовка и тела. Заголовок используется для обмена контекстной информацией, которая не является специфичной для приложения полезной нагрузкой (телом сообщения), например, информация, используемая при аутентификации. Тело сообщения SOAP инкапсулирует специфичную для приложения полезную нагрузку. API SOAP для web-сервисов описывается документами WSDL, в которых указано, какие операции предлагает сервис, формат сообщений, которые он принимает (используя XML-схему), и как их адресовать. Как правило, сообщения SOAP передаются через транспортный протокол HTTP, хотя равным образом возможна передача этих сообщений через другие виды протоколов транспортного уровня (например, JMS или электронная почта).

REST - это сокращение от Representational State Transfer (протокол передачи состояния для интерпретации в представлении), способ осуществления коммуникаций через интернет посредством только HTTP и XML. Простота этого протокола и остутствие строгих профилей отдалила его от SOAP и повысила его привлекательность для сообщества разработчиков. В отличие от типичного словесного интерфейса, который характерен для современных языков программирования (которые состоят из различных методов, например, getEmployee(), addEmployee(), listEmployees() и так далее), REST, в принципе, поддерживает всего несколько операций (это методы POST, GET, PUT, DELETE), которые применимы к любым фрагментам информации. Ключевым понятием в REST является понятие ресурсов, которое описывает собственно фрагменты информации. Например, запись ресурса для какого-либо сотрудника идентифицируется по URL, извлекается посредством действия GET, обновляется посредством действия PUT и так далее. Таким образом, REST напоминает документально-буквенный стиль сервисов SOAP.

Захват дампа экрана

Как было отмечено ранее, отсутствие API у провайдеров контента часто вынуждает разработчиков гибридных приложений прибегать к захвату дампа экрана, чтобы получить информацию, которая им нужна. Захват - это процесс использования программных инструментов для разбора и анализа контента, созданного для использования человеком, чтобы извлечь образец семантической структуры данных этой информации, который может быть использован и обработан программным путем. Небольшое количество гибридных приложений использует технологию захвата дампа экрана для получения данных, особенно если данные извлекаются из публичных секторов. Например, гибридное приложение, отображающее объекты недвижимости на карте, может сопоставлять список объектов, выставленных на продажу или сдаваемых в аренду, с картами провайдера картографического сервиса и с полученными методом захвата "дополнительными" данными из архива исторических документов. Еще один проект, использующий технологию захвата дампа экрана, это XMLTV, коллекция инструментов, собирающая программы телевидения по всему миру.

Технологию захвата дампа экрана часто считают не особенно красивым решением, и для этого есть достаточно оснований. Ей присущи два недостатка. Первый заключается в том, что, в отличие от API, которые имеют интерфейс, захват не предполагает программного контракта между провайдером контента и потребителем контента. Разработчики, использующие эту технологию, должны проектировать свои инструменты в соответствием с моделью контента источника и надеяться на то, что провайдер последовательно будет придерживаться этой модели представления данных. Для web-сайтов характерно стремление периодически переделывать дизайн, чтобы оставаться свежими и стильными, что создает серьезные трудности для разработчиков, использующих технологию захвата дампа экрана, потому что их инструменты, скорее всего, не будут работать с новым дизайном.

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

Семантический интернет и RDF

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

Семейство спецификаций W3C, которое носит общее название Resource Description Framework, RDF (инфраструктура описания ресурсов), служит для решения задачи предоставления методик для принятия синтаксических структур, которые будут описывать данные. Одного XML недостаточно; он слишком деспотичен, чтобы можно было кодировать несколькими способами для описания одних и тех же фрагментов данных. RDF-Schema дополняет RDF возможностью кодировать понятия способом, доступным для считывания машиной. Поскольку объекты данных могут быть описаны при помощи модели данных, RDF предусматривает конструкцию связей между объектами данных через тройки "субъект-предикат-объект" ("субъект S имеет отношение R с объектом O"). Комбинирование модели данных и схемы отношений предусматривают создание онтологий, которые представляют собой иерархические структуры знаний, которые могут быть предметом поиска и формального осмысления. Например, можно описать модель, в которой "класс хищников" является подклассом "класса животных" с тем условием, что он "поедает" других представителей "класса животных", и создать два экземпляра этой модели: один экземпляр будет включать гепардов и белых медведей с их местами обитания, в другой попадут газели и пингвины, а также, соответственно, их места обитания. Механизм логических выводов может затем смешать эти отдельные экземпляры модели и вывести заключение, что гепарды могут охотиться только на газелей, но не на пингвинов.

RDF-данные быстро найдут применение во множестве областей, в том числе, в приложениях социальных сетей (например, FOAF - Friend of a Friend) и синдикациях (например, в каналах RSS, которые мы рассмотрим далее). Кроме того, технология и компоненты программного обеспечения RDF вступают в период зрелости, особенно в области языков запросов RDF (таких как RDQL и SPARQL), а также программных инфраструктур и механизмов логических выводов (Jena и Redland).

RSS и ATOM

RSS - это семейство форматов синдикации на основе XML. В этом контексте синдикация подразумевает, что web-сайт, который желает распространять контент, создает RSS-документ и регистрирует этот документ на сайте издателя RSS. RSS-клиент затем может проверять каналы издателя на наличие нового контента и соответствующим образом с ними взаимодействовать. Формат RSS был утвержден для синдикации широкого диапазона контента, от новостных статей и заголовков, журналов изменений для регистрации CVS или страниц Википедии, обновлений проекта до аудиовизуальных данных, например, радиопрограмм. Версия 1.0 использует RDF, а самая последняя версия, 2.0, нет.

Atom - это более новый, но очень похожий, протокол синдикации. Это рекомендуемый стандарт Комитета по инженерным вопросам интернета (Internet Engineering Task Force, IETF); он отличается стремлением к лучшей работе с метаданными по сравнению с RSS, предоставляет более скрупулезную документацию и включает понятие логических структур для представления данных общего характера.

Эти технологии синдикации прекрасно подходят для гибридных приложений, которые собирают контент на основе событий или обновлений, например, аггрегаторы новостей и web-логов.

Технические проблемы

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

Проблемы интеграции данных: семантическое значение и качество данных

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

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

Кроме потери данных или неполного отображения, проектировщики гибридных приложений могут обнаружить, что данные, которые они хотят интегрировать, не подходят для машинной автоматизации, что их необходимо очистить. Например, записи о применении меры пресечения "арест" могли вестись непоследовательно, с использованием распространенных сокращений имен (например, Рын. пл. в одной записи и "Рыночная площадь" в другой), что делает автоматическое осмысление тождественности этих выражений затруднительным даже при хорошей эвристике приложения. Технологии семантического моделирования, такие как RDF, могут помочь облегчить проблему автоматического осмысления в пределах различных наборов данных, при условии, что они встроены в хранилище данных. Очень вероятно, что традиционные источники данных потребуют больше человеческих усилий в смысле анализа и очистки данных перед тем, как они смогут быть полезными для технологий семантического моделирования.

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

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

Проблемы компонентов

Модель web-разработки Ajax может обеспечить более полнофункциональную и более бесперебойную работу пользователя, чем традиционное полное обновление страниц, но она также связана с некоторыми сложностями. В качестве основных средств Ajax использует средства работы со сценариями на стороне клиента вместе с моделью DOM и получает метод поставки контента, который не вполне предусматривался проектировщиками браузера (пожалуй, эта способность Ajax использовать средства браузера придает ему привлекательность). Однако, вследствие этого приложения на базе Ajax становятся уязвимыми для тех же проблем совместимости браузеров, которые досаждают web-дизайнерам с тех пор, как в Microsoft создали Internet Explorer. Например, движок Ajax использует объект XMLHttpRequst для асинхронного обмена данными с удаленными серверами. В Internet Explorer 6 этот объект реализован при помощи элемента управления ActiveX, а не встроенными средствами JavaScript, а это требует, чтобы в браузере были включены элементы управления ActiveX.

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

Использование JavaScript для асинхронного обновления контента на странице может также вызвать проблемы с интерфейсом пользователя. Поскольку контент теперь уже не привязан с определенностью к URL в адресной строке браузера, пользователи могут не получить тех функций, которые они обычно ожидают, пользуясь кнопкой Back (Назад) браузера или функцией BOOKMARK (Добавить в избранное). И хотя Ajax может уменьшить латентность, запрашивая инкрементные обновления контента, плохие разработки могут реально мешать работе пользователя, как в том случае, когда гранулярность обновлений достаточно мала, чтобы количество и служебные данные обновлений истощили доступные ресурсы. Следует также позаботиться о поддержке пользователя (например, при помощи наглядной обратной связи в виде индикатора выполнения) в процессе загрузки интерфейса или обновления контента.

Как и для любых приложений, использующих данные с нескольких доменов, разработчикам гибридных приложений и контент-провайдерам приходится решать проблемы, связанные с безопасностью. Понятие идентичности может оказаться сложным предметом, поскольку традиционный интернет изначально создавался для анонимного доступа. Общий вход в систему - желательная функция, но существует множество конкурирующих технологий (от Microsoft Passport до Liberty Alliance), тем самым создаются изолированные пространства имен идентичности, которые также следует интегрировать. Контент-провайдеры, вероятно, используют схемы аутентификации и авторизации (которые требуют представления защищенной идентичности или идентифицируемых по защищенной схеме атрибутов) в своих API, чтобы обеспечить реализацию бизнес-моделей, которые связаны с платной подпиской или уязвимыми данными. Уязвимые данные, вероятно, потребуют также конфиденциальности (то есть, шифрования), и вам придется проявить осторожность, смешивая их с другими источниками, чтобы не подвергнуть их риску. Идентичность может быть важна также для проведения аудита и обеспечения регулируемой совместимости. Кроме того, при интеграции данных, осуществляемой и на стороне клиента, и на стороне сервера, делегирование идентичности регистрационных данных от пользователя гибридному сервису может превратиться в требование.

Социальные проблемы

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

Одна из самых больших социальных проблем, с которой могут столкнуться разработчики гибридных приложений - это нахождение компромисса между защитой интеллектуальной собственности и конфиденциальности потребителя и законным использованием и свободным распространением информации. Невольные контент-провайдеры (которые становятся целью захвата дампа экрана), и даже те контент-провайдеры, которые используют API, чтобы содействовать извлечению данных, могут обнаружить, что их контент используется таким способом, который они не могут одобрить. Хороший обзор по web-аггрегации и нормативным документам можно найти в разделе Ресурсы.

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

Прежде, чем гибридные приложения смогут превратиться из престижных игрушек в сложные приложения, придется провести большую работу по созданию и утверждению надежных стандартов, протоколов, моделей и наборов инструментов. Чтобы это произошло, ведущие представители отрасли разработки программного обеспечения, контент-провайдеры и предприниматели должны будут признать ценность гибридных приложений, которые представляют собой жизнеспособные модели бизнеса. Провайдерам API придется определить, будут ли они брать плату за свой контент, и если будут, то каким образом (например, посредством подписки или по количеству использований). Пожалуй, они будут предоставлять различные уровни качества обслуживания. Некоторые провайдеры интерфейсов, такие как Amazon или eBay, могут обнаружить, что использование их API приводит к увеличению движения товара. Возможно, разработчики гибридных приложений будут искать модель дополнительного дохода или, может быть, создадут интересные гибридные приложения на продажу.

Заключение

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

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


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=XML
ArticleID=192678
ArticleTitle=Гибридные приложения: новое поколение web-приложений
publish-date=01292007