Насыщенное интернет-приложение: различия между версиями

Интерактивная навигация по истории

(Показать все непатрулированные изменения)

[отпатрулированная версия]

[непроверенная версия]

← Предыдущая правка

Содержимое удалено Содержимое добавлено

ВизуальныйВики-текст

Линейный

Текущая версия от 03:20, 6 октября 2023

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

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

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

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

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

По данным^[3] на июль 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».

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

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

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

См. также

Примечания

↑ Ларри Зельцер. Насыщенные интернет-приложения привлекательны для злоумышленников Архивная копия от 22 декабря 2015 на Wayback Machine // PCWeek, 15.09.2010.
↑ Пауэрс Ш., Пауэрс Ш. Добавляем Ajax. — БХВ-Петербург, 2009. — С. 3–4. — ISBN 978-5-9775-0226-9.
↑ Rich Internet Application Market Share (неопр.). Дата обращения: 9 декабря 2010. Архивировано из оригинала 6 октября 2011 года.

Литература

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

[1] Ларри Зельцер. Насыщенные интернет-приложения привлекательны для злоумышленников Архивная копия от 22 декабря 2015 на Wayback Machine // PCWeek, 15.09.2010.

[2] Пауэрс Ш., Пауэрс Ш. Добавляем Ajax. — БХВ-Петербург, 2009. — С. 3–4. — ISBN 978-5-9775-0226-9.

[3] Rich Internet Application Market Share (неопр.). Дата обращения: 9 декабря 2010. Архивировано из оригинала 6 октября 2011 года.

[1]

[2]

[3]

@@ Строка 1: / Строка 1: @@
+{{обновить}}
-'''Rich Internet application''' ('''RIA''', «''Насыщенное („богатое“) [[Интернет-приложение]]''»<!-- По поводу перевода см. обсуждения, а не переводим, не обосновывая сути. -->) — это [[приложение]], доступное через [[Интернет]], насыщенное функциональностью традиционных [[Компьютерная программа|настольных приложений]], которое предоставляется либо уникальной спецификой [[браузер]]а, либо через [[плагин]], либо путём «[[Песочница (программное обеспечение)|песочницы]]» (виртуальной машины).
+'''Насыщенное интернет(веб)-приложение'''<ref>Ларри Зельцер. [http://www.pcweek.ru/security/article/detail.php?ID=125325 Насыщенные интернет-приложения привлекательны для злоумышленников] {{Wayback|url=http://www.pcweek.ru/security/article/detail.php?ID=125325 |date=20151222095248 }} // PCWeek, 15.09.2010.</ref><ref>{{книга| автор = Пауэрс Ш., Пауэрс Ш. | заглавие = Добавляем Ajax | издательство = БХВ-Петербург | год = 2009 | страницы = 3–4 | isbn = 978-5-9775-0226-9}}</ref> ({{lang-en|rich internet application}}, {{lang-en2|RIA}}) — это [[веб-приложение]], загружаемое пользователем через [[интернет]], предназначенное для выполнения функций традиционных [[Компьютерная программа|настольных приложений]] и работающее на устройстве пользователя (не на сервере).
+Технологии, используемые для реализации RIA:
-Как правило, приложение RIA:
+* [[язык разметки]] [[HTML5]] и [[язык программирования]] [[JavaScript]];
-* передаёт веб-клиенту необходимую часть пользовательского интерфейса, оставляя большую часть данных (ресурсы программы, данные и пр.) на сервере;
+* (Google) [[Native Client]];
-* запускается в браузере и не требует дополнительной установки ПО;
+* [[Adobe Flash]];
-* запускается локально в среде безопасности, называемой «[[Песочница (безопасность)|песочница]]» (sandbox).
+* ([[Oracle]]) [[JavaFX]];
+* [[Microsoft Silverlight]].
+Основные черты:
-В настоящее время тремя наиболее распространенными подобными платформами являются [[Adobe Flash]], [[Java]] и [[Microsoft Silverlight]] с уровнем проникновения<!-- куда? и может «внедрения»?--> 99 %, 80 % и 54 % соответственно (по состоянию на июль 2010 года)<ref>[http://www.statowl.com/custom_ria_market_penetration.php Rich Internet Application Market Share]</ref> .
+* RIA состоит из двух частей: клиентской и серверной;
+* серверная часть RIA выполняется на сервере, может хранить информацию, необходимую для работы приложения, может заниматься обслуживанием запросов, поступающих от клиентской части RIA;
+* клиентская часть RIA выполняется на компьютере пользователя, занимается рисованием [[Интерфейс пользователя|интерфейса пользователя]], выполняет запросы пользователя, при необходимости может отправлять запросы серверной части RIA;
+* клиентская часть RIA выполняется в безопасной среде, называемой «[[Песочница (безопасность)|песочницей]]» ({{lang-en|sandbox}}), и не требует установки дополнительного [[Программное обеспечение|ПО]].
+По данным<ref>{{Cite web |url=http://www.statowl.com/custom_ria_market_penetration.php |title=Rich Internet Application Market Share |access-date=2010-12-09 |archive-date=2011-10-06 |archive-url=https://web.archive.org/web/20111006175307/http://www.statowl.com/custom_ria_market_penetration.php |deadlink=yes }}</ref> на июль 2012 года самыми популярными платформами, используемыми для создания RIA, были [[Adobe Flash]], [[JavaFX]], [[Microsoft Silverlight]]<!-- с уровнем проникновения{{куда}} 96 %, 70 % и 70 % соответственно -->.
 == История ==
-Термин «RIA» впервые был упомянут компанией Macromedia в официальном сообщении от марта 2002 года. Эта концепция существовала несколькими годами ранее со следующими названиями:
-* [[Remote Scripting]], [[Microsoft]], около [[1998 год]]а
-* X Internet, Forrester Research в октябре 2000 года
-* Rich (web) client
-* Rich web application
+Термин «RIA» впервые упомянут компанией [[Macromedia]] в официальном сообщении, опубликованном в марте 2002 года. Идея RIA существовала несколькими годами ранее со следующими названиями:
-Работа традиционных [[Веб-приложение|веб-приложений]] сконцентрирована вокруг [[Клиент-серверная архитектура|клиент-серверной архитектуры]] с [[Тонкий клиент|тонким клиентом]]. Такой клиент переносит все задачи по обработке информации на сервер, а сам используется лишь для отображения статического контента (в нашем случае [[HTML]]). Основной недостаток этого подхода в том, что все взаимодействие с приложением должно обрабатываться сервером, что требует постоянной отправки данных на сервер, ожидания ответа сервера, и загрузки страницы обратно в браузер. При использовании технологии запуска приложений на стороне клиента, RIA могут обойти этот медленный цикл синхронизации за счёт большего взаимодействия с пользователем. Эта разница примерно аналогична разнице между архитектурой с «тонким клиентом» (Thin client) и архитектурой с «толстым клиентом» (Thick client), а также между терминалом и мейнфреймом.
+* «[[Remote Scripting]]» (фирма [[Microsoft]]; около [[1998 год]]а);
+* «X Internet» (фирма Forrester Research; октябрь 2000 года);
+* «Rich (web) client»;
+* «Rich web application».
+Традиционные [[Веб-приложение|веб-приложения]] работают следующим образом.
-Постепенное развитие стандартов сети Интернет привело к возможности реализовать подобные технологии на практике, однако сложно провести четкую границу между тем, какие именно технологии включают в себя приложения RIA, и какие нет. Но все RIA имеют одну схожую особенность: они включают в себя некую промежуточную часть кода приложения, находящуюся между пользователем и сервером, которую обычно называют «движком клиента». Этот движок загружается в самом начале и в дальнейшем может догружаться по ходу работы приложения. Движок клиента выступает в роли надстройки браузера и обычно отвечает за рендеринг пользовательского интерфейса и взаимодействие с сервером.
+# Клиент отправляет запрос на сервер и ожидает получения ответа.
+# Сервер получает запрос от клиента, формирует и отправляет ответ клиенту.
+# Клиент получает и отображает ответ.
+Эти действия постоянно повторяются (цикл). В такой архитектуре клиент занимается лишь отображением информации (статического контента, например, [[HTML]]), а все задачи по обработке данных передаёт на сервер. Основной недостаток такой архитектуры в том, что вся работа выполняется сервером. Увеличить скорость работы приложения можно, если часть работы переложить на клиента.
+В архитектуре RIA часть работы или вся работа может выполняться клиентом.
-То, что может быть выполнено RIA, может быть ограничено возможностями пользовательской системы. Но в целом, интерфейс пользователя создавался для выполнения функций, которые по надеждам разработчиков должны были улучшить пользовательский интерфейс и ускорить обработку пользовательских запросов, по сравнению с возможностями стандартного веб-браузера. Также, простое добавление движка клиента не запрещает приложению уходить с нормальной синхронной модели взаимодействия браузера и сервера, большинство движков RIA позволяют выполнить дополнительные асинхронные запросы серверу.
+Постепенное развитие стандартов сети Интернет привело к возможности реализовать RIA. Однако сложно провести чёткую границу между тем, какие именно технологии включают в себя RIA, а какие — нет. Но все RIA имеют одну особенность: на устройстве пользователя перед началом работы RIA загружается так называемый «движок клиента»; в дальнейшем движок может догружаться по ходу работы приложения.
+«Движок клиента» реализует возможности, недоступные традиционным веб-приложениям, может загружаться в контексте веб-браузера (HTML, JavaScript) или в контексте [[плагин|плагина (надстройки)]] веб-браузера (Adobe Flash, JavaFX, Microsoft Silverlight, Native Client). «Движок клиента», обычно, отвечает за [[рендеринг]] (рисование) пользовательского интерфейса (UI) (например, реализация UI для RIA может оказаться проще и может работать быстрее, чем для традиционного веб-приложения) и взаимодействие с сервером (например, клиентская часть RIA может отправлять запросы серверной части RIA как синхронно (как традиционные веб-приложения), так и [[Асинхронный ввод-вывод|асинхронно]]). Возможности «движка клиента» могут быть ограничены возможностями устройства и [[Операционная система|ОС]] пользователя.
 == Преимущества ==
-Несмотря на то, что разработка веб-приложений для браузера имеет ограничения, более сложна по сравнению с разработкой стандартных приложений, усилия обычно оправдываются, потому что:
+Преимущества веб-приложений:
-* Не требуется установка приложения; обновление и распространение приложения — быстрый и автоматизированный процесс
+* веб-приложение не требует установки (пользователи загружают приложение с сервера по необходимости; этим обеспечивается автоматическое распространение приложения);
-* Обновление версий автоматическое
+* веб-приложение обновляется автоматически (на сервере размещается последняя версия приложения);
-* Пользователи могут использовать приложение на любом компьютере, имеющем соединение с Интернетом, причем неважно, какая операционная система на нём установлена
+* веб-приложение может работать на любом устройстве, имеющем соединение с интернетом, и под управлением любой ОС (разнообразие ОС не создаёт проблемы благодаря единому для всех ОС [[API]]);
-* При работе веб-приложения компьютер пользователя гораздо меньше подвержен вирусному заражению, чем при запуске исполняемых бинарных файлов.
+* при работе веб-приложения устройство пользователя меньше подвержено вирусному заражению, чем при запуске [[Исполнимый модуль|исполняемых]] [[Двоичный файл|бинарных файлов]] (веб-приложение исполняется в «песочнице»).
-Поскольку RIA используют движок клиента для взаимодействия с пользователем, они:
-* ''Богаче''. RIA предлагают пользовательский интерфейс, не ограниченный лишь использованием языка HTML, применяемого в стандартных веб-приложениях. Расширенная функциональность позволяет использовать такие возможности пользовательского интерфейса, как [[drag-and-drop]], использование ползунка для изменения данных, а также возможность производить вычисления, которые не отправляются обратно на сервер, а выполняются прямо на машине пользователя (например, ипотечный калькулятор).
+Преимущества RIA по сравнению с традиционными веб-приложениями, достигаемые благодаря использованию возможностей «движка клиента»:
-* ''Более интерактивные''. Интерфейсы RIA более интерактивны, чем стандартные интерфейсы веб-браузеров, которые требуют постоянного взаимодействия с удалённым сервером.
+* возможность использования в UI стандартных для ОС элементов управления (например, использование ползунка для изменения данных);
-* Наиболее сложные приложения RIA предлагают внешний вид и функциональность, близкие к настольным приложениям. Использование движка клиента позволяет добиться и других преимуществ в производительности:
+* возможность использования типовых действий для взаимодействия с другими программами (например, [[drag-and-drop]], копирование данных в [[буфер обмена]]);
-* ''Сбалансированность клиент-сервера''. Использование вычислительных ресурсов клиента и сервера лучше сбалансировано. Поэтому сервер не должен быть «рабочей лошадкой», как в традиционных веб-приложениях. Это освобождает вычислительные ресурсы сервера, позволяя обрабатывать большее количество сессий одновременно за счёт одного и того же аппаратного обеспечения.
+* возможность выполнения вычислений на устройстве пользователя (без отправки личных данных пользователя на сервер (например, ипотечный [[калькулятор]]));
-* ''Асинхронная коммуникация''. Движок клиента может взаимодействовать с сервером, не дожидаясь, пока пользователь совершит действие в приложении, нажав на кнопку или ссылку. Это позволяет пользователю просматривать страницу и взаимодействовать с ней асинхронно с помощью коммуникации между движком и сервером. Эта возможность позволяет разработчикам RIA передавать данные между клиентом и сервером без ожидания пользователя. В [[Google Maps]] эта техника используется для того, чтобы подгружать прилегающие сегменты карты, прежде чем пользователь пролистает, чтобы их посмотреть.
+* гибкие возможности по построению UI (например, [[валидация]] введённых пользователем данных в процессе ввода без отправки запросов серверу ([[интерактивность]]));
+* возможность продолжения работы приложения после отправки запроса серверу (асинхронность);
+* возможность загрузки данных с сервера до того, как пользователь запросит данные (например, в [[Google Maps]] фрагменты карты, расположенные рядом с фрагментом, на который смотрит пользователь, загружаются заранее);
+* возможность снижения нагрузки на сервер (в случае выполнения вычислений на клиенте), и, следовательно, возможность повышения количества сессий, обрабатываемых сервером одновременно (без замены «железа»).
 == Недостатки ==
-Основными недостатками и ограничениями RIA являются:
+Недостатки RIA:
-* ''«[[Песочница (безопасность)|Песочница]]»''. Поскольку RIA загружаются в локальной среде безопасности — «песочнице» — они имеют ограниченный доступ к системным ресурсам. Если права на доступ к ресурсам некорректны, RIA могут работать неправильно.
+* отсутствие доступа к ресурсам ОС (так как веб-приложение выполняется в «[[Песочница (безопасность)|песочнице]]»). Если права на доступ к ресурсам некорректны, RIA могут работать неправильно;
-* ''Подключение скриптов''. Как правило, для работы RIA требуется JavaScript или другие скриптовые языки. Если пользователь отключил активные сценарии в своем браузере, RIA может не функционировать должным образом или вообще не работать.
+* для запуска веб-приложения может потребоваться выполнение кода, написанного на [[Сценарный язык|скриптовом языке]] (например, на JavaScript); если пользователь отключит возможность выполнения кода, RIA может работать неправильно или может вообще не работать;
-* ''Скорость обработки клиентом''. Чтобы обеспечить платформенную независимость, некоторые RIA используют скриптовый язык на стороне клиента, например, такой как JavaScript, с частичной потерей производительности (серьёзная проблема для мобильных устройств). Однако такая проблема не возникает при использовании встроенного языка, скомпилированного на стороне клиента, такого как Java, где производительность сопоставима с использованием традиционных встроенных языков, либо с [[Adobe Flash|Flash]] или с [[Silverlight]], в которых программный код запускается непосредственно в плагине Flash Player или Silverlight соответственно.
+* низкая скорость работы многоплатформенных веб-приложений. Для обеспечения независимости RIA от платформы в клиентской части RIA может использоваться код, написанный на скриптовом языке (например, на JavaScript); при выполнении такого кода наблюдается падение производительности — серьёзная проблема для мобильных устройств. Такая проблема не возникает при использовании встроенного языка, компилируемого на стороне клиента (например, Java), где производительность сопоставима с использованием традиционных встроенных языков, либо с [[Adobe Flash]] или с [[Microsoft Silverlight]], в которых [[Исходный код|программный код]] запускается непосредственно в плагине Flash Player или Silverlight соответственно;
-* ''Время загрузки скрипта''. Даже если нет необходимости в установке скрипта, движок клиента RIA должен быть передан клиенту сервером. Поскольку большинство скриптов сохраняются в кэше, он должен быть передан хотя бы один раз. В зависимости от размера и типа передачи, загрузка скрипта может занять довольно много времени. Разработчики RIA могут уменьшить последствия этой задержки посредством сжатия скриптов, а также за счёт разбиения передачи приложения на несколько страниц.
+* необходимость установки «движка клиента»;
-* ''Утрата целостности''. Если приложение основано на X/HTML, возможны конфликты между целями приложения (которое, естественно, хочет иметь контроль над его представлением и действиями) и целями X/HTML (которое хочет отдать контроль). Интерфейс DOM для X/HTML делает возможным создание RIA, но это не даёт никаких гарантий, что оно будет работать корректно. Из-за того, что клиент RIA может изменять основную структуру приложения и переопределять его действия и представление, это может привести к ошибке приложения на стороне клиента. В конце концов, эта проблема может быть решена за счёт нового механизма клиент-сервер, предоставляющего клиенту RIA ограниченный доступ к изменению тех ресурсов, которые не входят в сферу его полномочий. Работа родного стандартного ПО не вызывает подобных проблем, поскольку они по определению автоматически обладают всеми необходимыми правами на локальные ресурсы.
+* продолжительное время загрузки веб-приложения. Клиент каждый раз загружает с сервера [[Клиент (информатика)|клиентскую часть]] RIA. Поскольку большинство загружаемых данных сохраняется в кэше, для ускорения запуска клиентскую часть RIA необходимо загрузить хотя бы один раз. Время загрузки зависит от размера загружаемых данных; для уменьшения размера клиентской части RIA разработчики могут сжать её или поделить на части, загружаемые по необходимости;
-* ''Утрата видимости для поисковых систем''. Поисковые системы могут оказаться не в состоянии проиндексировать содержимое приложения RIA.
+* утрата целостности. Если приложение основано на X/HTML, возможны конфликты между целями приложения (которое, естественно, хочет иметь контроль над его представлением и действиями) и целями X/HTML (которое хочет отдать контроль). Интерфейс DOM для X/HTML делает возможным создание RIA, но это не даёт никаких гарантий, что оно будет работать корректно. Из-за того, что клиент RIA может изменять основную структуру приложения и переопределять его действия и представление, это может привести к ошибке приложения на стороне клиента. В конце концов, эта проблема может быть решена за счёт нового механизма [[Клиент — сервер|клиент-сервер]], предоставляющего клиенту RIA ограниченный доступ к изменению тех ресурсов, которые не входят в сферу его полномочий. Работа родного стандартного ПО не вызывает подобных проблем, поскольку они по определению автоматически обладают всеми необходимыми правами на локальные ресурсы;
-* ''Зависимость от подключения к Интернету''. Идеальная замена для настольных приложений должна позволять пользователям подключаться к сети «эпизодически», покидая [[хот-спот]]ы, уходя и приходя в офис. Однако к 2007 году типичные приложения RIA требовали постоянного подключения.
+* невозможность индексирования веб-приложения [[Поисковая система|поисковыми системами]]. Поисковые системы могут оказаться не в состоянии проиндексировать содержимое RIA. Однако, часто, индексирование и не требуется;
-* ''Доступность''. Известно множество проблем веб-совместимости с RIA. Одна из распространённых заключается в том, что пользователю, читающему текст с экрана, сложно выявлять динамические изменения (вызванные JavaScript) в контенте HTML.
+* зависимость от подключения к интернету. RIA, созданные для замены настольных приложений, должны позволять пользователям подключаться к сети по необходимости, например, не должны терять работоспособность при перемещении пользователя между [[Хот-спот (Wi-Fi)|зонами покрытия беспроводных сетей]]. К 2007 году типичные приложения RIA требовали постоянного подключения к сети. С появлением HTML5 данная проблема становится менее актуальной; API [[Web Storage|HTML5 local storage]] позволяет хранить данные на стороне клиента; [[HTML5 File API]] позволяет получать доступ к [[Файловая система|ФС]] устройства пользователя.
-* ''Сложность расширяемости''. RIA сложно расширять [[плагин]]ами и [[мод]]ами, как это делается в традиционных приложениях. Возможно использование пользовательских JavaScript, внедряемым iFrame контентом, и т д.
 == Сложности разработки приложений ==
 Появление технологии RIA сопровождалось значительными сложностями в [[Процесс разработки программного обеспечения|разработке веб-приложений]]. Традиционные веб-приложения, созданные на основе стандартного HTML, имеющего сравнительно простую архитектуру и довольно ограниченный набор функций, были относительно просты в разработке и управлении. Лица и организации, внедряющие веб-приложения на основе технологии RIA, часто сталкиваются с дополнительными сложностями в разработке, тестировании, измерениях и поддержке.
-Применение технологии RIA ставит новые задачи по управлению услугами SLM (''service level management''), не все из которых решены на сегодняшний день. Вопросы касательно SLM не всегда учитываются разработчиками приложений и почти не воспринимаются пользователями. Однако они жизненно важны для успешного внедрения приложения в сети Интернет. Основными аспектами, осложняющими процесс разработки RIA, являются:
+Применение технологии RIA ставит новые задачи по управлению услугами SLM ({{lang-en|service level management}}), не все из которых решены на сегодняшний день. Вопросы касательно SLM не всегда учитываются разработчиками приложений и почти не воспринимаются пользователями. Однако они жизненно важны для успешного внедрения приложения в сети интернет. Основными аспектами, осложняющими процесс разработки RIA, являются следующие:
-* ''Большая технологическая сложность делает разработку труднее''. Возможность передавать код приложения непосредственно клиентам даёт большую творческую свободу разработчикам и дизайнерам. Но это, в свою очередь, усложняет разработку приложения, увеличивает вероятность ошибок при внедрении и затрудняет тестирование программного обеспечения. Эти осложнения удлиняют процесс разработки вне зависимости от специфики методологии и процесса разработки. Некоторые из этих проблем могут быть сокращены за счёт использования каркаса программной системы под веб (''web application framework'') для стандартизации разработки RIA. Тем не менее, растущая сложность в программных решениях может усложнить и удлинить процесс тестирования при увеличении числа тестируемых вариантов использования (use cases). Неполное тестирование снижает качество и надежность приложения в ходе его использования. Можно спорить о том, относится ли замечание выше только к RIA-технологии или к сложности разработки в целом. Например, точно такой же аргумент приводился, когда Apple и Microsoft независимо друг от друга объявили о GUI в 1980-х, и, возможно, даже тогда, когда компания Ford представила свою Model T. Тем не менее, человечество продемонстрировало замечательную способность впитывать все технологические новшества в течение десятилетий, если не столетий.
+* ''технологическая сложность''. Возможность передавать код приложения непосредственно клиентам даёт большую творческую свободу разработчикам и дизайнерам. Но это, в свою очередь, усложняет разработку приложения, увеличивает вероятность ошибок при внедрении{{прояснить}} и затрудняет [[Тестирование программного обеспечения|тестирование ПО]]. Эти осложнения удлиняют процесс разработки вне зависимости от специфики методологии и процесса разработки. Некоторые из этих проблем могут быть сокращены за счёт использования [[Каркас веб-приложений|каркаса программной системы под веб]] ({{lang-en|web application framework}}) для стандартизации разработки RIA. Тем не менее, растущая сложность в программных решениях может усложнить и удлинить процесс тестирования при увеличении числа тестируемых вариантов использования (use cases). Неполное тестирование снижает качество и надёжность приложения в ходе его использования. Можно спорить о том, относится ли это только к RIA-технологии или к сложности разработки в целом. Например, точно такой же аргумент приводился, когда Apple и Microsoft независимо друг от друга объявили о GUI в 1980-х, и, возможно, даже тогда, когда компания [[Ford]] представила свою [[Ford Model T|Model T]]. Тем не менее, человечество продемонстрировало замечательную способность впитывать все технологические новшества в течение десятилетий, если не столетий;
-* ''Архитектура RIA ломает парадигму веб-страницы''. Традиционные веб-приложения представляют из себя набор веб-страниц, каждая из которых требует отдельного скачивания, инициированного запросом HTTP GET. Эта модель была описана как парадигма веб-страницы. RIA ломает эту парадигму, внося дополнительный сервер асинхронной коммуникации для поддержки более интерактивного интерфейса. Должны быть разработаны новые технологии измерения для RIA, предоставляющие информацию о количестве потраченного времени. При отсутствии подобных стандартных средств разработчики RIA должны добавить в свои приложения средства измерения данных, необходимые для SLM.
+* ''архитектура RIA ломает парадигму веб-страницы''. Традиционные веб-приложения представляют собой набор [[Веб-страница|веб-страниц]]; для скачивания каждой веб-страницы клиент посылает запрос [[HTTP GET]]; такая модель называется парадигмой веб-страницы. RIA «ломает» эту парадигму; теперь сервер должен обслуживать асинхронные запросы для поддержки более интерактивного интерфейса. Для получения информации о количестве времени, потраченного при работе RIA, должны быть разработаны новые стандартные технологии. При отсутствии подобных технологий (стандартных средств) разработчики RIA должны добавить в свои приложения средства измерения данных, необходимых для SLM;
-* ''Асинхронная коммуникация осложняет выявление проблем производительности''. Парадоксально, но меры, принимаемые для снижения времени отклика приложения затрудняют само его определение, измерение и управление. Некоторые RIA не делают никаких дальнейших HTTP GET-запросов из браузера после получения первой страницы, используя асинхронные запросы с помощью движка клиента для последующих загрузок. Клиент RIA может быть запрограммирован таким образом, чтобы постоянно загружать новый контент и обновлять дисплей, или (в приложениях, использующих подход Comet) движок на стороне сервера может постоянно передавать новый контент браузеру через постоянно открытое соединение. В этом случае концепция «загрузки страницы» более не применима. Все это привносит определённые трудности в измерение и разделение времени отклика приложения, которые являются фундаментальными требованиями для изоляции проблем и SLM. Инструменты, созданные для измерения традиционных веб-приложений, в зависимости от специфики и инструментария приложения могут рассматривать каждую веб-страницу, запрошенную по HTTP, в отдельности или как набор не связанных между собой показателей. Однако, ни один из этих подходов не показывает, что в действительности происходит на уровне приложения.
+* ''асинхронность осложняет выявление проблем с производительностью''. Парадоксально, но меры, принимаемые для снижения [[Время отклика|времени отклика]] приложения, затрудняют определение времени отклика, измерение времени и управление приложением. Некоторые RIA запускаются в веб-браузере после скачивания браузером одной веб-страницы, используют «движок клиента» для асинхронной загрузки необходимых данных; браузер больше не отправляет никаких запросов [[HTTP GET]]. Клиентская часть RIA может быть запрограммирована таким образом, чтобы постоянно загружать новые данные (контент) и обновлять содержимое экрана, или (в приложениях, использующих подход [[Comet (программирование)|Comet]]) серверная часть RIA может постоянно передавать клиентской части новые данные (контент) через постоянно открытое соединение. В этом случае понятие «загрузка страницы» более неприменимо. Всё это привносит определённые трудности в измерение времени и разделение времени отклика приложения, которые являются фундаментальными требованиями для выявления проблем с производительностью и SLM. Инструменты, созданные для измерения времени работы традиционных веб-приложений, в зависимости от специфики и инструментария приложения могут рассматривать каждую веб-страницу, запрошенную по HTTP, в отдельности или как набор не связанных между собой показателей. Однако, ни один из этих подходов не показывает, что в действительности происходит на уровне приложения;
-* ''Движок клиента усложняет измерение времени отклика приложения''. Для традиционных веб-приложений измерительное программное обеспечение может располагаться на клиентской машине и на машине, близкой к серверу, таким образом, оно может наблюдать за потоком сетевого трафика на TCP и HTTP уровнях. Поскольку это синхронизированные и предсказуемые протоколы, пакет со снифером может читать и интерпретировать данные пакетного уровня и выводить заключение о времени отклика с помощью средств отслеживания сообщений HTTP и времени подтверждения пакетов TCP на нижнем уровне. Но архитектура RIA уменьшает возможности подхода с использованием пакетного снифинга, поскольку движок пользователя разбивает взаимодействие между клиентом и сервером на два отдельных цикла, работающих асинхронно — цикл переднего плана (пользователь-движок) и цикл заднего плана (движок-сервер). Оба этих цикла имеют важное значение, поскольку их общая взаимосвязь определяет поведение приложения. Но это отношение зависит только от построения самого приложения, которое в большинстве случаев не может быть спрогнозировано измерительными инструментами, в особенности первым, который может наблюдать только один из двух циклов. Поэтому наиболее полное измерение RIA может быть получено только с использованием инструментов, которые находятся на стороне клиента и наблюдателя в обоих циклах.
+* ''«движок клиента» усложняет измерение времени отклика приложения''. Для традиционных веб-приложений ПО, предназначенное для измерения времени, может располагаться на клиентской машине и на машине, расположенной близко к серверу, может наблюдать за потоком [[Сетевой трафик|сетевого трафика]] на [[Сетевая модель OSI|уровнях]] TCP и HTTP. Поскольку TCP и HTTP — синхронизированные и предсказуемые протоколы, [[Анализатор трафика|сниффер]] может читать данные из пакетов TCP и HTTP, интерпретировать прочитанные данные и делать выводы о времени отклика с помощью средств отслеживания сообщений HTTP и времени подтверждения пакетов TCP на нижнем уровне. Использование сниффера для измерения времени приложений, использующих архитектуру RIA, затруднено, поскольку движок пользователя разбивает взаимодействие между клиентом и сервером на два отдельных цикла, работающих асинхронно — цикл переднего плана (пользователь-движок) и цикл заднего плана (движок-сервер). Оба этих цикла имеют важное значение, поскольку их общая взаимосвязь определяет поведение приложения. Но это отношение зависит только от архитектуры самого приложения, которая в большинстве случаев не может быть спрогнозирована измерительными инструментами, в особенности первым (сниффером), который может наблюдать только один из двух циклов. Поэтому наиболее полное измерение времени RIA может быть получено только с использованием инструментов, которые находятся на стороне клиента и наблюдателя в обоих циклах.
 == См. также ==
+* [[Рич-медиа]]
-* [[Сравнение платформ для создания RIA]]
+* [[WAI-ARIA]]
 == Примечания ==
 {{примечания}}
+== Литература ==
-{{rq|img|sources|refless|cleanup|renew|topic=IT}}
+* Константин Ковалев. RIA — значит свобода // Мир ПК. — 2008. — № 3. — С. 62-65. — ISSN 0235-3520
+{{rq|img|sources|cleanup|renew|topic=IT|isbn}}
 {{Rich Internet Applications}}
@@ Строка 67: / Строка 93: @@
 [[Категория:RIA]]
 [[Категория:Архитектура программного обеспечения]]
-[[ar:تطبيق إنترنت غني]]
-[[ca:Rich Internet Application]]
-[[cs:Rich Internet application]]
-[[de:Rich Internet Application]]
-[[en:Rich Internet application]]
-[[es:Rich Internet Applications]]
-[[eu:RIA]]
-[[fa:برنامه‌های غنی اینترنتی]]
-[[fi:Rikkaat Internet-sovellukset]]
-[[fr:Rich Internet Application]]
-[[hu:Rich Internet Application]]
-[[it:Rich Internet application]]
-[[ja:リッチインターネットアプリケーション]]
-[[ko:리치 인터넷 애플리케이션]]
-[[mn:Rich Internet Application]]
-[[nl:Rich internet application]]
-[[pl:Rich Internet Application]]
-[[pt:Internet rica]]
-[[sv:Rich Internet Applications]]
-[[th:Rich Internet Application]]
-[[uk:Насичений інтернет-застосунок]]
-[[uz:Boy Internet dasturi]]
-[[zh:丰富互联网应用程序]]

Насыщенные интернет-приложения
Основные фреймворки	Adobe Flex Apache Pivot Cappuccino Curl Google Web Toolkit JavaFX JVx Lively Kernel Moonlight Silverlight Qt Quick SproutCore XULRunner
Специальные браузеры	Adobe AIR Curl Fluid Google Chrome (Gears) Mozilla Prism