Насыщенное интернет(веб)-приложение ( англ. rich internet application , RIA ) — это веб-приложение , загружаемое пользователем через интернет , предназначенное для выполнения функций традиционных настольных приложений и работающее на устройстве пользователя (не на сервере).

Технологии, используемые для реализации RIA:

• язык разметки HTML5 и язык программирования JavaScript ;
• (Google) Native Client ;
• Adobe Flash ;
• ( Oracle ) JavaFX ;
• Microsoft Silverlight .

Основные черты:

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

По данным на июль 2012 года самыми популярными платформами, используемыми для создания RIA, были Adobe Flash , JavaFX , Microsoft Silverlight .

История

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

• « » (фирма Microsoft ; около 1998 года );
• «X Internet» (фирма Forrester Research; октябрь 2000 года);
• «Rich (web) client»;
• «Rich web application».

Традиционные веб-приложения работают следующим образом.

1. Клиент отправляет запрос на сервер и ожидает получения ответа.
2. Сервер получает запрос от клиента, формирует и отправляет ответ клиенту.
3. Клиент получает и отображает ответ.

Эти действия постоянно повторяются (цикл). В такой архитектуре клиент занимается лишь отображением информации (статического контента, например, HTML ), а все задачи по обработке данных передаёт на сервер. Основной недостаток такой архитектуры в том, что вся работа выполняется сервером. Увеличить скорость работы приложения можно, если часть работы переложить на клиента.

В архитектуре RIA часть работы или вся работа может выполняться клиентом.

Постепенное развитие стандартов сети Интернет привело к возможности реализовать RIA. Однако сложно провести чёткую границу между тем, какие именно технологии включают в себя RIA, а какие — нет. Но все RIA имеют одну особенность: на устройстве пользователя перед началом работы RIA загружается так называемый «движок клиента»; в дальнейшем движок может догружаться по ходу работы приложения.

«Движок клиента» реализует возможности, недоступные традиционным веб-приложениям, может загружаться в контексте веб-браузера (HTML, JavaScript) или в контексте плагина (надстройки) веб-браузера (Adobe Flash, JavaFX, Microsoft Silverlight, Native Client). «Движок клиента», обычно, отвечает за рендеринг (рисование) пользовательского интерфейса (UI) (например, реализация UI для RIA может оказаться проще и может работать быстрее, чем для традиционного веб-приложения) и взаимодействие с сервером (например, клиентская часть RIA может отправлять запросы серверной части RIA как синхронно (как традиционные веб-приложения), так и асинхронно ). Возможности «движка клиента» могут быть ограничены возможностями устройства и ОС пользователя.

Преимущества

Преимущества веб-приложений:

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

Преимущества RIA по сравнению с традиционными веб-приложениями, достигаемые благодаря использованию возможностей «движка клиента»:

• возможность использования в UI стандартных для ОС элементов управления (например, использование ползунка для изменения данных);
• возможность использования типовых действий для взаимодействия с другими программами (например, drag-and-drop , копирование данных в буфер обмена );
• возможность выполнения вычислений на устройстве пользователя (без отправки личных данных пользователя на сервер (например, ипотечный калькулятор ));
• гибкие возможности по построению UI (например, валидация введённых пользователем данных в процессе ввода без отправки запросов серверу ( интерактивность ));
• возможность продолжения работы приложения после отправки запроса серверу (асинхронность);
• возможность загрузки данных с сервера до того, как пользователь запросит данные (например, в Google Maps фрагменты карты, расположенные рядом с фрагментом, на который смотрит пользователь, загружаются заранее);
• возможность снижения нагрузки на сервер (в случае выполнения вычислений на клиенте), и, следовательно, возможность повышения количества сессий, обрабатываемых сервером одновременно (без замены «железа»).

Недостатки

Недостатки RIA:

• отсутствие доступа к ресурсам ОС (так как веб-приложение выполняется в « песочнице »). Если права на доступ к ресурсам некорректны, RIA могут работать неправильно;
• для запуска веб-приложения может потребоваться выполнение кода, написанного на скриптовом языке (например, на JavaScript); если пользователь отключит возможность выполнения кода, RIA может работать неправильно или может вообще не работать;
• низкая скорость работы многоплатформенных веб-приложений. Для обеспечения независимости RIA от платформы в клиентской части RIA может использоваться код, написанный на скриптовом языке (например, на JavaScript); при выполнении такого кода наблюдается падение производительности — серьёзная проблема для мобильных устройств. Такая проблема не возникает при использовании встроенного языка, компилируемого на стороне клиента (например, Java), где производительность сопоставима с использованием традиционных встроенных языков, либо с Adobe Flash или с Microsoft Silverlight , в которых программный код запускается непосредственно в плагине Flash Player или Silverlight соответственно;
• необходимость установки «движка клиента»;
• продолжительное время загрузки веб-приложения. Клиент каждый раз загружает с сервера клиентскую часть RIA. Поскольку большинство загружаемых данных сохраняется в кэше, для ускорения запуска клиентскую часть RIA необходимо загрузить хотя бы один раз. Время загрузки зависит от размера загружаемых данных; для уменьшения размера клиентской части RIA разработчики могут сжать её или поделить на части, загружаемые по необходимости;
• утрата целостности. Если приложение основано на X/HTML, возможны конфликты между целями приложения (которое, естественно, хочет иметь контроль над его представлением и действиями) и целями X/HTML (которое хочет отдать контроль). Интерфейс DOM для X/HTML делает возможным создание RIA, но это не даёт никаких гарантий, что оно будет работать корректно. Из-за того, что клиент RIA может изменять основную структуру приложения и переопределять его действия и представление, это может привести к ошибке приложения на стороне клиента. В конце концов, эта проблема может быть решена за счёт нового механизма клиент-сервер , предоставляющего клиенту RIA ограниченный доступ к изменению тех ресурсов, которые не входят в сферу его полномочий. Работа родного стандартного ПО не вызывает подобных проблем, поскольку они по определению автоматически обладают всеми необходимыми правами на локальные ресурсы;
• невозможность индексирования веб-приложения поисковыми системами . Поисковые системы могут оказаться не в состоянии проиндексировать содержимое RIA. Однако, часто, индексирование и не требуется;
• зависимость от подключения к интернету. RIA, созданные для замены настольных приложений, должны позволять пользователям подключаться к сети по необходимости, например, не должны терять работоспособность при перемещении пользователя между зонами покрытия беспроводных сетей . К 2007 году типичные приложения RIA требовали постоянного подключения к сети. С появлением HTML5 данная проблема становится менее актуальной; API HTML5 local storage позволяет хранить данные на стороне клиента; позволяет получать доступ к ФС устройства пользователя.

Сложности разработки приложений

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

Применение технологии RIA ставит новые задачи по управлению услугами SLM ( англ. service level management ), не все из которых решены на сегодняшний день. Вопросы касательно SLM не всегда учитываются разработчиками приложений и почти не воспринимаются пользователями. Однако они жизненно важны для успешного внедрения приложения в сети интернет. Основными аспектами, осложняющими процесс разработки RIA, являются следующие:

• технологическая сложность . Возможность передавать код приложения непосредственно клиентам даёт большую творческую свободу разработчикам и дизайнерам. Но это, в свою очередь, усложняет разработку приложения, увеличивает вероятность ошибок при внедрении ^{[ прояснить ]} и затрудняет тестирование ПО . Эти осложнения удлиняют процесс разработки вне зависимости от специфики методологии и процесса разработки. Некоторые из этих проблем могут быть сокращены за счёт использования каркаса программной системы под веб ( англ. web application framework ) для стандартизации разработки RIA. Тем не менее, растущая сложность в программных решениях может усложнить и удлинить процесс тестирования при увеличении числа тестируемых вариантов использования (use cases). Неполное тестирование снижает качество и надёжность приложения в ходе его использования. Можно спорить о том, относится ли это только к RIA-технологии или к сложности разработки в целом. Например, точно такой же аргумент приводился, когда Apple и Microsoft независимо друг от друга объявили о GUI в 1980-х, и, возможно, даже тогда, когда компания Ford представила свою Model T . Тем не менее, человечество продемонстрировало замечательную способность впитывать все технологические новшества в течение десятилетий, если не столетий;
• архитектура RIA ломает парадигму веб-страницы . Традиционные веб-приложения представляют собой набор веб-страниц ; для скачивания каждой веб-страницы клиент посылает запрос HTTP GET ; такая модель называется парадигмой веб-страницы. RIA «ломает» эту парадигму; теперь сервер должен обслуживать асинхронные запросы для поддержки более интерактивного интерфейса. Для получения информации о количестве времени, потраченного при работе RIA, должны быть разработаны новые стандартные технологии. При отсутствии подобных технологий (стандартных средств) разработчики RIA должны добавить в свои приложения средства измерения данных, необходимых для SLM;
• асинхронность осложняет выявление проблем с производительностью . Парадоксально, но меры, принимаемые для снижения времени отклика приложения, затрудняют определение времени отклика, измерение времени и управление приложением. Некоторые RIA запускаются в веб-браузере после скачивания браузером одной веб-страницы, используют «движок клиента» для асинхронной загрузки необходимых данных; браузер больше не отправляет никаких запросов HTTP GET . Клиентская часть RIA может быть запрограммирована таким образом, чтобы постоянно загружать новые данные (контент) и обновлять содержимое экрана, или (в приложениях, использующих подход Comet ) серверная часть RIA может постоянно передавать клиентской части новые данные (контент) через постоянно открытое соединение. В этом случае понятие «загрузка страницы» более неприменимо. Всё это привносит определённые трудности в измерение времени и разделение времени отклика приложения, которые являются фундаментальными требованиями для выявления проблем с производительностью и SLM. Инструменты, созданные для измерения времени работы традиционных веб-приложений, в зависимости от специфики и инструментария приложения могут рассматривать каждую веб-страницу, запрошенную по HTTP, в отдельности или как набор не связанных между собой показателей. Однако, ни один из этих подходов не показывает, что в действительности происходит на уровне приложения;
• «движок клиента» усложняет измерение времени отклика приложения . Для традиционных веб-приложений ПО, предназначенное для измерения времени, может располагаться на клиентской машине и на машине, расположенной близко к серверу, может наблюдать за потоком сетевого трафика на уровнях TCP и HTTP. Поскольку TCP и HTTP — синхронизированные и предсказуемые протоколы, сниффер может читать данные из пакетов TCP и HTTP, интерпретировать прочитанные данные и делать выводы о времени отклика с помощью средств отслеживания сообщений HTTP и времени подтверждения пакетов TCP на нижнем уровне. Использование сниффера для измерения времени приложений, использующих архитектуру RIA, затруднено, поскольку движок пользователя разбивает взаимодействие между клиентом и сервером на два отдельных цикла, работающих асинхронно — цикл переднего плана (пользователь-движок) и цикл заднего плана (движок-сервер). Оба этих цикла имеют важное значение, поскольку их общая взаимосвязь определяет поведение приложения. Но это отношение зависит только от архитектуры самого приложения, которая в большинстве случаев не может быть спрогнозирована измерительными инструментами, в особенности первым (сниффером), который может наблюдать только один из двух циклов. Поэтому наиболее полное измерение времени RIA может быть получено только с использованием инструментов, которые находятся на стороне клиента и наблюдателя в обоих циклах.

См. также

• Рич-медиа
• WAI-ARIA

Примечания

Литература

• Константин Ковалев. RIA — значит свобода // Мир ПК. — 2008. — № 3. — С. 62-65. — ISSN 0235-3520

Для улучшения этой статьи по информационным технологиям желательно : Добавить иллюстрации . Найти и оформить в виде сносок ссылки на независимые авторитетные источники , подтверждающие написанное . Переработать оформление в соответствии с правилами написания статей . Обновить статью, актуализировать данные. Оформить список литературы. После исправления проблемы исключите её из списка. Удалите шаблон, если устранены все недостатки.