Rich internet application что это

Rich Internet Application

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

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

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

В настоящее время тремя наиболее распространенными подобными платформами являются Adobe Flash, JavaFX и Microsoft Silverlight с уровнем проникновения 96 %, 70 % и 70% соответственно (по состоянию на июль 2012 года) [1] .

История

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

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

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

См. также

Примечания

1. ↑Rich Internet Application Market Share

Rich Internet Application и управление контентом

Ныне модно говорить о Web 2.0. В то время как идея коллективного разума, заложенная в это определение его же автором Тимом О’Рейли, по-прежнему остается темой досужих разговоров, нельзя не заметить, что всемирная паутина меняется. Веб-приложения по удобству использования становятся все ближе к настольным приложениям. Данная тенденция с нарастающей прогрессией охватывает Интернет и уже сегодня можно говорить о наступлении эры веб-приложений нового типа, «обогащенных» интернет-приложений или RIA. Впрочем, популярность таких терминов как Web 2.0 и RIA столь высока, что разработчики спешат повесить привлекательные ярлычки на свои продукты, порой толком не разбираясь в том, что подразумевается под этими терминами. Так, что же такое RIA на самом деле? Термин Rich Internet Applications (RIA) впервые был упомянут в рекламных материалах компании Macromedia в марте 2002 года. Менеджеры Macromedia тем самым подчеркнули, что хорошо известная технология Flash – это не только способ получения красочных визуальных эффектов на сайтах, но и инструмент создания полноценных бизнес-приложений на базе Web. Статические страницы сайтов старого типа предоставляют информацию пользователю и имеют весьма скудные возможности, в сравнении настольными приложениями, для организации взаимодействия пользователя с этой информацией. Когда вы запрашиваете дополнительную информацию (выполняете навигацию по сайту) или передаете данные на сервер, происходит перегрузка страниц сайта. Это неудобно, но так же и не безопасно, так как в момент перегрузки страниц можно потерять данные (скажем, из-за утери соединения с сервером). Однако именно так устроен Web 1.0. Сервер получает инструкции, когда вы набираете адрес страницы или сохраняете данные в вебформе. На их основе сервер формирует страницу, которую вы затем увидите. В обогащенных интернет-приложениях перегрузки страниц не требуется. Когда вы нажимаете кнопку для получения дополнительной информации или для отправки данных, сервер получает соответствующие инструкции и возвращает на страницу результаты своей работы. Программа на странице получает ответ севера и изменяется соответствующим образом. К примеру, если вы просматриваете каталог продукции в электронном магазине старого образца вы будете вынуждены ожидать перегрузку и формирование новой страницы при каждом нажатии кнопки «следующие 20 товаров». На сайте, построенном в традициях RIA вы сможете запросить выборку товаров с 50-80 позиции или же всех товаров отвечающих заданному диапазону цен. При этом страница сайта будет оставаться неизменной, но список с товарами будет меняться при каждом новом запросе.

Rich internet application что это

Растущий разрыв между потребностями пользователей www и скудными возможностями HTML, который, пусть даже расширенным JavaScript и CSS, не был способен на многое, породил целый класе веб-приложений, которые одно время всерьез претендовали на то, чтобы стать будущим веба. Впрочем, и сейчас претензии на это все еще остались. Я говорю о RIA — Rich Internet Applications, термин, который, наверное, лучше переводить как «насыщенные» интернет-приложения.

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

При всех различиях RIA имеют ряд общих черт. Перечислим их:

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

— работа с RIA требует единовременной установки дополнительного ПО в виде плагина к браузеру;

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

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

Давайте кратко осмотрим современные RIA, ставшие заметными в www.

Вам также могут быть интересны следующие статьи:

• RIA и HTML5
• Adobe Flex
• HTML5 для адаптивных веб-дизайнов
• JavaFX
• Microsoft Silverlight

Rich Internet Application и контент-менеджмент

Ныне модно говорить о Web 2.0. В то время как идея коллективного разума, заложенная в это определение его же автором Тимом О’Рейли, по-прежнему остается темой досужих разговоров, нельзя не заметить, что всемирная паутина меняется. Веб-приложения по удобству использования становятся все ближе к настольным приложениям. Данная тенденция с нарастающей прогрессией охватывает Интернет и уже сегодня можно говорить о наступлении эры веб-приложений нового типа, обогащенных веб-приложений или RIA. Впрочем, популярность таких терминов как Web 2.0 и RIA столь высока, что разработчики спешат повесить привлекательные ярлычки на свои продукты, порой толком не разбираясь в том, что подразумевается под этими терминами. Так, что же такое RIA на самом деле?

Термин Rich Internet Applications (RIA) впервые был упомянут в рекламных материалах компании Macromedia в марте 2002 года. Суть данной технологии можно определить как распределение задач по обслуживанию пользовательского интерфейса между серверным и клиентским программным обеспечением (ПО). В классических веб-приложениях старого типа, серверное ПО формирует и возвращает уже готовый интерфейс пользователю. Для выполнения любой новой бизнес-операции требуется запросить от сервера новое состояние интерфейса, фактически перезагрузить страницу и получить новый интерфейс. В RIA приложениях запрашивается не новый интерфейс, а лишь инструкции по модификации единожды сформированного интерфейса. Данные возможности могут быть достигнуты посредством AJAX, Adobe Flex, Windows Presentation Foundation, Flash, Java-апплетов, Java и некоторых декларативных языков, таких как XUL, MXML. Из всех перечисленных инструментов широчайшую популярность приобрели лишь AJAX и Flash, в первую очередь благодаря их доступности. Причем, если создание приложений целиком во Flash весьма ресурсоемкий и дорогостоящий процесс, разработка с применением AJAX едва ли занимает больше времени, нежели разработка классических веб-приложений старого типа. В большинстве современных проектов Flash используется лишь по мере необходимости. Как, например, на сайте журнала Elle (www.elle.ru).

Уже в самом названии AJAX (асинхронный JavaScript и XML) отражена суть технологии. Она позволяет клиентской и серверной сторонам веб-приложения взаимодействовать асинхронно. В случае события на клиентской стороне совершается запрос к серверу, сервер возвращает результаты запроса, интерфейс меняет состояние. Как это бывает на практике?

Одно из наиболее популярных применений AJAX — реализация в Web технологии drag & drop («перетянул и оставил»). Вы наверняка уже видели сервисы виртуального рабочего стола, такие как www.netvibes.com, www.pageflakes.com, www.yourminis.com или, по крайней мере, www.pusk.ru. Они позволяют нам располагать виджеты на экране, настраивать их размеры тем же образом, каким мы привыкли делать это с окнами Microsoft Windows. Данные возможности постепенно мигрируют и в бизнес-приложения. Так, к примеру, на портале www.atlas.cz пользователи могут настраивать стартовую страницу с той же легкостью, как и в случае виртуального рабочего стола.

Благодаря возможности конструировать внешний вид страниц из заранее заготовленных дизайн-шаблонов, пользователи CMS (систем управления контентом) теперь менее зависят от разработчиков их сайтов. Еще большие преимущества пользователям дает Drag&Drop при управлении содержанием сайта. В современной CMS для того, чтобы задать новое положение для документа в структуре или же для записи в списке, достаточно лишь «зацепить» эту позицию мышью и «перетащить» на новое место. Точно также как это делается с файлами в Проводнике Microsoft Windows.

Возможность обслуживания событий по запросу также позволяет первоначально загружать для интерфейса лишь минимум необходимых данных, но «догружать» востребованные данные, когда они понадобились пользователю. Например, при переходе в интерфейс управления структурой сайта в CMS загружается лишь первый уровень дерева структуры. Однако если пользователь пожелает раскрыть какую-либо ветвь дерева, ее данные будут «догружены» в тот же момент. Данная возможность еще более востребована при управлении списками записей. Приложение возвращает в интерфейс лишь тот диапазон записей, который пользователь запросил. Более того, даже формы ввода данных обретают новые черты. В современных веб-приложениях все чаще встречается форма ввода строки данных, известная благодаря популярному сервису Google Suggest. Когда вы только начинаете набирать что-либо в этой форме, под ней появляется выпадающий список со значениями, содержащими набранную подстроку. Тем, кому приходилось вносить данные посредством «бесконечного» списка в SELECT, удалось оценить эффективность новой формы.

Само по себе отсутствие необходимости перегрузки всего интерфейса при любом действии пользователя меняет представление о веб-интерфейсах. Вы можете вносить данные в нескольких формах интерфейса, размещенных, скажем, на различных табах. Затем все введенные данные можно одновременно отправить на сохранение. И обратите внимание, если отправленные данные по какой-либо причине (обрыв соединения с сервером, внутренняя ошибка и т.д.) не будут сохранены, интерфейс сообщит вам об этом и позволит повторить попытку. А ведь ненадежность передачи данных была одним из краеугольных камней веб-интерфейсов старого образца.

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

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