Для установки нажмите кнопочку Установить расширение. И это всё.

Исходный код расширения WIKI 2 регулярно проверяется специалистами Mozilla Foundation, Google и Apple. Вы также можете это сделать в любой момент.

4,5
Келли Слэйтон
Мои поздравления с отличным проектом... что за великолепная идея!
Александр Григорьевский
Я использую WIKI 2 каждый день
и почти забыл как выглядит оригинальная Википедия.
Статистика
На русском, статей
Улучшено за 24 ч.
Добавлено за 24 ч.
Что мы делаем. Каждая страница проходит через несколько сотен совершенствующих техник. Совершенно та же Википедия. Только лучше.
.
Лео
Ньютон
Яркие
Мягкие

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

Из Википедии — свободной энциклопедии

Насыщенное интернет(веб)-приложение[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 как синхронно (как традиционные веб-приложения), так и асинхронно). Возможности «движка клиента» могут быть ограничены возможностями устройства и ОС пользователя.

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

Преимущества веб-приложений:

  • веб-приложение не требует установки (пользователи загружают приложение с сервера по необходимости; этим обеспечивается автоматическое распространение приложения);
  • веб-приложение обновляется автоматически (на сервере размещается последняя версия приложения);
  • веб-приложение может работать на любом устройстве, имеющем соединение с интернетом, и под управлением любой ОС (разнообразие ОС не создаёт проблемы благодаря единому для всех ОС 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 может быть получено только с использованием инструментов, которые находятся на стороне клиента и наблюдателя в обоих циклах.

См. также

Примечания

  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 года.

Литература

  • Константин Ковалев. RIA — значит свобода // Мир ПК. — 2008. — № 3. — С. 62-65. — ISSN 0235-3520
Эта страница в последний раз была отредактирована 6 октября 2023 в 03:20.
Как только страница обновилась в Википедии она обновляется в Вики 2.
Обычно почти сразу, изредка в течении часа.
Основа этой страницы находится в Википедии. Текст доступен по лицензии CC BY-SA 3.0 Unported License. Нетекстовые медиаданные доступны под собственными лицензиями. Wikipedia® — зарегистрированный товарный знак организации Wikimedia Foundation, Inc. WIKI 2 является независимой компанией и не аффилирована с Фондом Викимедиа (Wikimedia Foundation).