Интернет магазин китайских планшетных компьютеров

Компьютеры - Rich Internet Application - Сложности разработки приложений

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

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

• Большая технологическая сложность делает разработку труднее. Возможность передавать код приложения непосредственно клиентам даёт большую творческую свободу разработчикам и дизайнерам. Но это, в свою очередь, усложняет разработку приложения, увеличивает вероятность ошибок при внедрении и затрудняет тестирование программного обеспечения. Эти осложнения удлиняют процесс разработки вне зависимости от специфики методологии и процесса разработки. Некоторые из этих проблем могут быть сокращены за счёт использования каркаса программной системы под веб для стандартизации разработки RIA. Тем не менее, растущая сложность в программных решениях может усложнить и удлинить процесс тестирования при увеличении числа тестируемых вариантов использования. Неполное тестирование снижает качество и надежность приложения в ходе его использования. Можно спорить о том, относится ли замечание выше только к RIA-технологии или к сложности разработки в целом. Например, точно такой же аргумент приводился, когда Apple и Microsoft независимо друг от друга объявили о GUI в 1980-х, и, возможно, даже тогда, когда компания Ford представила свою Model T. Тем не менее, человечество продемонстрировало замечательную способность впитывать все технологические новшества в течение десятилетий, если не столетий.
• Архитектура RIA ломает парадигму веб-страницы. Традиционные веб-приложения представляют из себя набор веб-страниц, каждая из которых требует отдельного скачивания, инициированного запросом HTTP GET. Эта модель была описана как парадигма веб-страницы. RIA ломает эту парадигму, внося дополнительный сервер асинхронной коммуникации для поддержки более интерактивного интерфейса. Должны быть разработаны новые технологии измерения для RIA, предоставляющие информацию о количестве потраченного времени. При отсутствии подобных стандартных средств разработчики RIA должны добавить в свои приложения средства измерения данных, необходимые для SLM.
• Асинхронная коммуникация осложняет выявление проблем производительности. Парадоксально, но меры, принимаемые для снижения времени отклика приложения затрудняют само его определение, измерение и управление. Некоторые RIA не делают никаких дальнейших HTTP GET-запросов из браузера после получения первой страницы, используя асинхронные запросы с помощью движка клиента для последующих загрузок. Клиент RIA может быть запрограммирован таким образом, чтобы постоянно загружать новый контент и обновлять дисплей, или движок на стороне сервера может постоянно передавать новый контент браузеру через постоянно открытое соединение. В этом случае концепция «загрузки страницы» более не применима. Все это привносит определённые трудности в измерение и разделение времени отклика приложения, которые являются фундаментальными требованиями для изоляции проблем и SLM. Инструменты, созданные для измерения традиционных веб-приложений, в зависимости от специфики и инструментария приложения могут рассматривать каждую веб-страницу, запрошенную по HTTP, в отдельности или как набор не связанных между собой показателей. Однако, ни один из этих подходов не показывает, что в действительности происходит на уровне приложения.
• Движок клиента усложняет измерение времени отклика приложения. Для традиционных веб-приложений измерительное программное обеспечение может располагаться на клиентской машине и на машине, близкой к серверу, таким образом, оно может наблюдать за потоком сетевого трафика на TCP и HTTP уровнях. Поскольку это синхронизированные и предсказуемые протоколы, пакет со снифером может читать и интерпретировать данные пакетного уровня и выводить заключение о времени отклика с помощью средств отслеживания сообщений HTTP и времени подтверждения пакетов TCP на нижнем уровне. Но архитектура RIA уменьшает возможности подхода с использованием пакетного снифинга, поскольку движок пользователя разбивает взаимодействие между клиентом и сервером на два отдельных цикла, работающих асинхронно — цикл переднего плана и цикл заднего плана. Оба этих цикла имеют важное значение, поскольку их общая взаимосвязь определяет поведение приложения. Но это отношение зависит только от построения самого приложения, которое в большинстве случаев не может быть спрогнозировано измерительными инструментами, в особенности первым, который может наблюдать только один из двух циклов. Поэтому наиболее полное измерение RIA может быть получено только с использованием инструментов, которые находятся на стороне клиента и наблюдателя в обоих циклах.