16. Rich Internet application

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

Содержание

• 16.1. Введение в RIA

  • 16.1.1. Общие сведения

  • 16.1.2. Ключевые термины

• 16.2. Технологии RIA

  • 16.2.1. Технологии Adobe

    • 16.2.1.1. Adobe Flash

    • 16.2.1.2. Adobe Flex

    • 16.2.1.3. Adobe Air

  • 16.2.2. Ajax

  • 16.2.3. Технологии Microsoft

    • 16.2.3.1. ActiveX

    • 16.2.3.2. Технология WPF

    • 16.2.3.3. Технология Silverlight

  • 16.2.4. Технологии Oracle (Sun)

    • 16.2.4.1. Технология JavaFX

  • 16.2.5. Другие технологии

  • 16.2.7. Сравнение технологий

  • 16.2.8. Ключевые термины

• 16.3. Примеры RIA-приложений

  • 16.3.1. Технологии Adobe

  • 16.3.2. Технология Ajax

  • 16.3.3. Технологии Microsoft

• 16.4. Краткие итоги

16.1. Введение в ria

16.1.1. Общие сведения

RIA (Rich Internet application, "богатое Интернет-приложение" или Rich Interactive Applications, "богатое интерактивное приложение") – это приложение, доступное через Интернет, богатое функциональностью традиционных настольных приложений, не поддерживаемой браузерами непосредственно [1]. Как правило, приложение RIA:

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

2. запускается в браузере и не требует дополнительной установки ПО;

3. запускается локально в среде безопасности, называемой "песочница" (sandbox).

На рис. 16.1 с помощью диаграммы Венна демонстрируется место Rich Internet Applications среди других технологий программных систем [2].

Рис. 16.1.  Место Rich Internet Applications среди технологий создания программных систем

Традиционные веб-приложения большей частью работают на сервере – в клиентской программе-браузере (Internet Explorer, Firefox или Opera) отображается контент, размеченный языком разметки HTML [3]. В силу такого подхода традиционные веб-приложения:

• имеют достаточно ограниченный уровень интерактивности;

• постоянно взаимодействуют с сервером – отправляют на него данные, получают ответы и загружают новые страницы.

В RIA значительная часть функционала вынесена в клиентскую часть, т.е. исполняется на стороне клиента (по сути, в том же браузере, но с использованием плагинов и/или технологии Ajax), что позволяет получить приложение, которое:

• работает быстрее, за счет меньшего количества обращений к серверу и отсутствия перегрузок страниц;

• обеспечивает близкий к традиционным настольным приложениям уровень интерактивности и удобства интерфейса (например, такую возможность как drug&drop).

Термин "RIA" впервые был упомянут компанией Macromedia в официальном сообщении от марта 2002 года. Эта концепция существовала несколькими годами ранее со следующими названиями:

• Remote Scripting, Microsoft, около 1998 года;

• X Internet, Forrester Research в октябре 2000 года;

• Rich (web) client;

• Rich web application.

Работа традиционных веб-приложений сконцентрирована вокруг клиент-серверной архитектуры с тонким клиентом. Такой клиент переносит все задачи по обработке информации на сервер, а сам используется лишь для отображения статического контента (например, HTML-кода). Основной недостаток этого подхода в том, что все взаимодействие с приложением должно обрабатываться сервером, что требует постоянной отправки данных на него, ожидания ответа сервера и загрузки страницы обратно в браузер. При использовании технологии запуска приложений на стороне клиента, RIA могут обойти этот медленный цикл синхронизации за счет большего взаимодействия с пользователем. Эта разница примерно аналогична разнице между архитектурой с "тонким клиентом" (Thin client) и архитектурой с "толстым клиентом" (Fat client), а также между терминалом и мейнфреймом.

На рис. 16.2 представлено историческое развитие приложений [4].

Рис. 16.2.  Историческое развитие приложений

Рассмотрим архитектурные особенности построения RIA-приложений.

Сравнение принципов работы веб-приложения и RIA-приложения представлен на рис. 16.3 [5].

Рис. 16.3.  Сравнение принципов работы традиционного веб-приложения и RIA-приложения

В табл. 16.1 приведены сравнительные данные профилирования традиционного веб-приложения (на примере сайта mail.ru) и RIA-приложния (на примере сайта gmail.com) [5].

Таблица 16.1. Сравнение данных профилирования традиционного веб-приложения и RIA-приложения
Действие	mail.ru	gmail.com
Начальная страница	24 запроса 116Kb	33 запроса 379 Kb
Открыть письмо	17 запросов 71 Kb	3 запроса 2 Kb

Также можно сравнить архитектуры толстого клиента и RIA-приложения.

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

Обычно архитектура представлена следующими компонентами (рис. 16.4) [6]:

• уровень представления – отвечает за взаимодействие приложения с пользователем, он формирует, отрисовывает и проверяет введенные пользователям данные;

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

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

Рис. 16.4.  Архитектура толстого клиента

Богатые Интернет приложения (RIA) выполняются в "песочнице" браузера.

Архитектура Веб-сервера представлена следующими компонентами (рис. 16.5) [6]:

• уровень сервисов предоставляет интерфейсы клиентской части для взаимодействия с уровнем логики;

• уровень бизнес логики идентичен уровню логики толстого клиента;

• уровень данных идентичен уровню данных толстого клиента.

Рис. 16.5.  Архитектура RIA-приложения

В табл. 16.2 представлено сравнение толстого клиента и RIA-приложения.

Таблица 16.2. Сравнение "толстого" клиента и RIA-приложения
Архитектура	Преимущества	Проблемы
Толстый клиент	Может расходовать клиентские ресурсы Интерактивность, богатый пользовательский функционал Высокая способность к реагированию Поддержка работы без сети	Требует установки (Click Once, Windows Installer, Copy) Контроль версий Зависимость от платформы
RIA	Тот же богатый пользовательский интерфейс, как и у толстого клиента Поддержка 3D и медиа высокого качества Простой способ распространения Простой механизм контроля версий Кросс-платформенность и кросс-браузерность	Небольшой размер приложений Ограничения по использованию клиентских ресурсов Требует установленного плагина для браузера

Если обобщить все вышесказанное, то RIA-приложения включили в себя [2]:

• От толстого клиента:

  • предоставление пользователю интерактивного интерфейса;

  • быстрое время отклика интерфейса без обновления страницы;

  • привычные средства пользовательского интерфейса, такие как: drag-and-drop и возможность работы как в режиме онлайн и оффлайн;

• От интернет-приложения:

  • быстрое развертывание;

  • кросс-платформенность;

  • использование прогрессивной загрузки для получения информации и данных;

  • использование большинства Интернет-стандартов;

• От средств передачи данных:

  • интерактивные аудио- и видео- технологии.

Основными достоинствами и преимуществами RIA-приложений являются [1, 5]:

• RIA предлагают пользовательский интерфейс, не ограниченный лишь использованием языка HTML, применяемого в стандартных веб-приложениях (drag-and-drop, использование ползунка для изменения данных, возможность производить вычисления, которые не отправляются обратно на сервер);

• интерфейсы RIA более интерактивны, чем стандартные интерфейсы веб-браузеров, которые требуют постоянного взаимодействия с удаленным сервером;

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

• движок клиента может взаимодействовать с сервером, не дожидаясь, пока пользователь совершит действие в приложении, нажав на кнопку или ссылку, что позволяет пользователю просматривать страницу и взаимодействовать с ней асинхронно с помощью коммуникации между движком и сервером;

• приложения, доступные через браузер, не требуют установки;

• кросс-платформеность и кросс-браузерность;

• автоматическое обновление версий (версия программы обновляется на сервере);

• меньше опасность заражения вирусами для пользователей за счет использования "песочницы";

• частичная возможность работы в режиме offline.

Основными недостатками и ограничениями RIA являются [1, 3, 4, 5]:

• поскольку RIA загружаются в локальной среде безопасности "песочница", они имеют ограниченный доступ к системным ресурсам;

• как правило, для работы RIA требуется JavaScript или другие скриптовые языки, а, соответственно, если пользователь отключил активные сценарии в своем браузере, RIA может не функционировать должным образом или вообще не работать;

• чтобы обеспечить платформенную независимость, некоторые RIA используют скриптовый язык на стороне клиента, например, такой как JavaScript, с частичной потерей производительности;

• даже если нет необходимости в установке скрипта, движок клиента RIA должен быть передан клиенту сервером (поскольку большинство скриптов сохраняются в кэше, он должен быть передан хотя бы один раз);

• если приложение основано на XHTML, возможны конфликты между целями приложения (которое хочет иметь контроль над его представлением и действиями) и целями X/HTML (которое хочет отдать контроль);

• поисковые системы могут оказаться не в состоянии проиндексировать содержимое приложения RIA;

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

• известно множество проблем веб-совместимости с RIA (одна из распространенных заключается в том, что пользователю, читающему текст с экрана, сложно выявлять динамические изменения (вызванные JavaScript) в контенте HTML);

• RIA нельзя расширять плагинами и модами, как это возможно в традиционных приложениях;

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

• Accessability issues (проблемы доступности), в силу преобладания мультимедийного контента, который, например, не прочитают программы – "читалки" для слепых;

• дорогая разработка.

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

Основными аспектами, осложняющими процесс разработки RIA, являются:

• Большая технологическая сложность делает разработку труднее;

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

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

• Движок клиента усложняет измерение времени отклика приложения.