Насыщенное интернет-приложение

Насыщенное интернет(веб)-приложение (англ. 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 существовала несколькими годами ранее со следующими названиями:

• «Remote Scripting» (фирма 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 позволяет хранить данные на стороне клиента; HTML5 File API позволяет получать доступ к ФС устройства пользователя.

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

Появление технологии 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