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

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

Как правило, приложение RIA:

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

В настоящее время тремя наиболее распространенными подобными платформами являются Adobe Flash, Java и Microsoft Silverlight с уровнем проникновения 99 %, 80 % и 54 % соответственно (по состоянию на июль 2010 года) .

История

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

• Remote Scripting, Microsoft, около 1998 года
• X Internet, Forrester Research в октябре 2000 года
• Rich (web) client
• Rich web application

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

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

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

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

Несмотря на то, что разработка веб-приложений для браузера имеет ограничения, более сложна по сравнению с разработкой стандартных приложений, усилия обычно оправдываются, потому что:

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

Поскольку RIA используют движок клиента для взаимодействия с пользователем, они:

• Богаче. RIA предлагают пользовательский интерфейс, не ограниченный лишь использованием языка HTML, применяемого в стандартных веб-приложениях. Расширенная функциональность позволяет использовать такие возможности пользовательского интерфейса, как drag-and-drop, использование ползунка для изменения данных, а также возможность производить вычисления, которые не отправляются обратно на сервер, а выполняются прямо на машине пользователя (например, ипотечный калькулятор).
• Более интерактивные. Интерфейсы RIA более интерактивны, чем стандартные интерфейсы веб-браузеров, которые требуют постоянного взаимодействия с удалённым сервером.
• Наиболее сложные приложения RIA предлагают внешний вид и функциональность, близкие к настольным приложениям. Использование движка клиента позволяет добиться и других преимуществ в производительности:
• Сбалансированность клиент-сервера. Использование вычислительных ресурсов клиента и сервера лучше сбалансировано. Поэтому сервер не должен быть «рабочей лошадкой», как в традиционных веб-приложениях. Это освобождает вычислительные ресурсы сервера, позволяя обрабатывать большее количество сессий одновременно за счёт одного и того же аппаратного обеспечения.
• Асинхронная коммуникация. Движок клиента может взаимодействовать с сервером, не дожидаясь, пока пользователь совершит действие в приложении, нажав на кнопку или ссылку. Это позволяет пользователю просматривать страницу и взаимодействовать с ней асинхронно с помощью коммуникации между движком и сервером. Эта возможность позволяет разработчикам RIA передавать данные между клиентом и сервером без ожидания пользователя. В Google Maps эта техника используется для того, чтобы подгружать прилегающие сегменты карты, прежде чем пользователь пролистает, чтобы их посмотреть.

Недостатки

Основными недостатками и ограничениями RIA являются:

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

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

Появление технологии 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) движок на стороне сервера может постоянно передавать новый контент браузеру через постоянно открытое соединение. В этом случае концепция «загрузки страницы» более не применима. Все это привносит определённые трудности в измерение и разделение времени отклика приложения, которые являются фундаментальными требованиями для изоляции проблем и SLM. Инструменты, созданные для измерения традиционных веб-приложений, в зависимости от специфики и инструментария приложения могут рассматривать каждую веб-страницу, запрошенную по HTTP, в отдельности или как набор не связанных между собой показателей. Однако, ни один из этих подходов не показывает, что в действительности происходит на уровне приложения.
• Движок клиента усложняет измерение времени отклика приложения. Для традиционных веб-приложений измерительное программное обеспечение может располагаться на клиентской машине и на машине, близкой к серверу, таким образом, оно может наблюдать за потоком сетевого трафика на TCP и HTTP уровнях. Поскольку это синхронизированные и предсказуемые протоколы, пакет со снифером может читать и интерпретировать данные пакетного уровня и выводить заключение о времени отклика с помощью средств отслеживания сообщений HTTP и времени подтверждения пакетов TCP на нижнем уровне. Но архитектура RIA уменьшает возможности подхода с использованием пакетного снифинга, поскольку движок пользователя разбивает взаимодействие между клиентом и сервером на два отдельных цикла, работающих асинхронно — цикл переднего плана (пользователь-движок) и цикл заднего плана (движок-сервер). Оба этих цикла имеют важное значение, поскольку их общая взаимосвязь определяет поведение приложения. Но это отношение зависит только от построения самого приложения, которое в большинстве случаев не может быть спрогнозировано измерительными инструментами, в особенности первым, который может наблюдать только один из двух циклов. Поэтому наиболее полное измерение RIA может быть получено только с использованием инструментов, которые находятся на стороне клиента и наблюдателя в обоих циклах.