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

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску
Интерактивная навигация по истории
(Показать все непатрулированные изменения)
[отпатрулированная версия][непроверенная версия]
← Предыдущая правкаСледующая правка →
Содержимое удалено Содержимое добавлено
ВизуальныйВики-текст
отмена правки 76851477 участника 94.180.92.57 (обс) пустые строки после названий разделов не ставятся
Нет описания правки
Строка 1: Строка 1:
'''Насыщенное интернет-приложение'''<ref>Ларри Зельцер. [http://www.pcweek.ru/security/article/detail.php?ID=125325 Насыщенные интернет-приложения привлекательны для злоумышленников], PCWeek, 15.09.2010]</ref><ref>{{книга| автор = Пауэрс Ш., Пауэрс Ш. | заглавие = Добавляем Ajax | издательство = БХВ-Петербург | год = 2009 | страницы = 3–4 | isbn = 978-5-9775-0226-9}}</ref> ({{lang-en|Rich Internet application, RIA}}) — это [[веб-приложение]], доступное через [[Интернет]], насыщенное функциональностью традиционных [[Компьютерная программа|настольных приложений]], которое предоставляется либо уникальной спецификой [[браузер]]а, либо через [[плагин]], либо путём «[[Песочница (программное обеспечение)|песочницы]]» (виртуальной машины).
'''Насыщенное интернет-приложение'''<ref>Ларри Зельцер. [http://www.pcweek.ru/security/article/detail.php?ID=125325 Насыщенные интернет-приложения привлекательны для злоумышленников], 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:
Как правило, насыщенное интернет-приложение:
* [[язык разметки]] [[HTML5]] и [[язый программирования]] [[JavaScript]];
* передаёт веб-клиенту необходимую часть пользовательского интерфейса, оставляя большую часть данных (ресурсы программы, данные и пр.) на сервере;
* (Google) [[Native Client]];
* запускается в браузере и не требует дополнительной установки ПО;
* [[Adobe Flash]];
* запускается локально в среде безопасности, называемой «[[Песочница (безопасность)|песочница]]» (sandbox).
* (Oracle) [[JavaFX]];
* [[Microsoft Silverlight]].


Основные черты:
В настоящее время{{когда}} тремя наиболее распространенными подобными платформами являются [[Adobe Flash]], [[JavaFX]] и [[Microsoft Silverlight]] с уровнем проникновения{{куда}} 96 %, 70 % и 70% соответственно (по состоянию на июль 2012 года)<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>[http://www.statowl.com/custom_ria_market_penetration.php Rich Internet Application Market Share]</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 как синхронно (как трациционные веб-приложения), так и [[Асинхронный ввод-вывод|асинхронно]]). Возможности «движка клиента» могут быть ограничены возможностями устройства и [[Операционая система|ОС]] пользователя.


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

Несмотря на то, что разработка веб-приложений для браузера имеет ограничения, более сложна по сравнению с разработкой стандартных приложений, усилия обычно оправдываются, потому что:
Преимущества 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 ограниченный доступ к изменению тех ресурсов, которые не входят в сферу его полномочий. Работа родного стандартного ПО не вызывает подобных проблем, поскольку они по определению автоматически обладают всеми необходимыми правами на локальные ресурсы;
* ''Зависимость от подключения к Интернету''. Идеальная замена для настольных приложений должна позволять пользователям подключаться к сети «эпизодически», покидая [[Хот-спот (Wi-Fi)|хот-споты]], уходя и приходя в офис. Однако к 2007 году типичные приложения RIA требовали постоянного подключения. Теперь же данная проблема становится менее актуальной, благодаря решениям хранения больших объёмов данных на стороне клиента ([[Web Storage|HTML5 Local Storage]]) и взаимодействия с локальными ресурсами (например, [[HTML5 File API]]).
⚫
* невозможность индексирования веб-приложения [[Поисковая система|поисковыми системами]]. Поисковые системы могут оказаться не в состоянии проиндексировать содержимое RIA. Однако, часто, индексирование и не требуется;
⚫
* ''Доступность''. Известно множество проблем веб-совместимости с RIA. Одна из распространённых заключается в том, что пользователю, читающему текст с экрана, сложно выявлять динамические изменения (вызванные JavaScript) в контенте HTML.
* зависимость от подключения к интернету. RIA, созданные для замены настольных приложений, должны позволять пользователям подключаться к сети по необходимости, например, не должны терять работоспособность при перемещении пользователя между [[Хот-спот (Wi-Fi)|зонами покрытия беспроводных сетей]]. К 2007 году типичные приложения RIA требовали постоянного подключения к сети. С появлением HTML5 данная проблема становится менее актуальной; API [[Web Storage|HTML5 local storage]] позволяет хранить данные на стороне клиента; [[HTML5 File API]] позволяет получать доступ к [[Файловая система|ФС]] устройства пользователя;
⚫
* ''Сложность расширяемости''. RIA сложно расширять [[плагин]]ами и [[мод]]ами, как это делается в традиционных приложениях. Возможно использование пользовательских JavaScript, внедряемым iFrame контентом, и т д.
⚫
* доступность. Известно множество проблем веб-совместимости с RIA. Одна из распространённых заключается в том, что пользователю, читающему текст с экрана, сложно выявлять динамические изменения (вызванные JavaScript) в контенте HTML;
⚫
* сложность расширяемости. RIA сложно расширять, например, с помощью [[плагин]]ов или [[мод]]ов, как это делается в традиционных приложениях. Возможно использование пользовательских JavaScript, внедряемым iFrame контентом, и т. д.


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

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


== См. также ==
== См. также ==

* [[Рич-медиа]]
* [[Рич-медиа]]
* [[WAI-ARIA]]
* [[WAI-ARIA]]
Строка 64: Строка 87:


== Литература ==
== Литература ==

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


{{rq|img|sources|cleanup|renew|topic=IT|isbn}}
{{rq|img|sources|cleanup|renew|topic=IT|isbn}}

Версия от 20:46, 2 марта 2016

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

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

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

  • 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».

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

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

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

В архитектуре RIA часть работы или вся работа может выполняться клиентом.

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

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

См. также

Примечания

  1. ↑ Ларри Зельцер. Насыщенные интернет-приложения привлекательны для злоумышленников, PCWeek, 15.09.2010]
  2. ↑ Пауэрс Ш., Пауэрс Ш. Добавляем Ajax. — БХВ-Петербург, 2009. — С. 3–4. — ISBN 978-5-9775-0226-9.
  3. ↑ Rich Internet Application Market Share

Литература

  • Константин Ковалев. RIA — значит свобода // Мир ПК. — 2008. — № 3. — С. 62-65. — ISSN 0235-3520
Источник — https://ru.wikipedia.org/ruwiki/w/index.php?title=Насыщенное_интернет-приложение&oldid=76861245