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

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

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

История

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

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

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

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

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

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

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

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

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

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

Недостатки

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

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

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

Появление технологии 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 может быть получено только с использованием инструментов, которые находятся на стороне клиента и наблюдателя в обоих циклах.