Насичений інтернет-застосунок

Термін «RIA» вперше використала компанія Macromedia в офіційному повідомленні в березні 2002 року. Проте ця концепція існувала кількома роками раніше з такими назвами:

• Remote Scripting, Microsoft, близько 1998
• X Internet, Forrester Research, жовтень 2000
• Rich (web) client
• Rich web application

Робота традиційних веб-застосунків зосереджена довкола клієнт-серверної архітектури з тонким клієнтом. Такий клієнт переносить усі задачі з обробки інформації на сервер, а сам використовується лише відображати статичний контент (тут — HTML). Основним недоліком цього підходу є те, що вся взаємодія із застосунком має оброблятися сервером, що потребує постійного відсилання даних на сервер, очікування відповіді сервера та завантаження сторінки назад до браузера. За використання технології запуску застосунків на боці клієнта, RIA може обійти цей повільний цикл синхронізації за рахунок більшої взаємодії із користувачем. Ця відмінність приблизно аналогічна такій між архітектурою з «тонким клієнтом» (англ. Thin client) та архітектурою з «товстим клієнтом» (англ. Fat client), чи між терміналом і мейнфреймом.

Поступовий розвиток стандартів мережі Інтернет призвів до можливості реалізувати подібні технології на практиця, хоча й складно провести чітку межу між тим, які саме технології включають у собі RIA, а які ні. Проте всі RIA мають одну схожу особливість: вони включають у собі певну проміжну частину коду застосунку, що знаходиться між користувачем і сервером, яку як правило називають «рушієм клієнта». Цей рушій завантажується із самого початку та далі може довантажуватися в ході роботи застосунку. Рушій клієнта відіграє роль надбудови браузера та як правило відповідає за рендеринг користувацького інтерфейсу та взаємодію із сервером.

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

Не зважаючи на те, що розробка web-застосунків для браузера має обмеження та складніша порівняно до розробки стандартних застосунків, зусилля звичайно виправдані, оскільки:

• Не потрібно встановлювати застосунок; поширення застосунку — швидкий і автоматизований процес
• Оновлення версій відбувається автоматично
• Користувачі можуть використовувати застосунок на будь-якому комп'ютері, який має з'єднання з Інтернет
• Під час роботи web-застосунку комп'ютер користувача набагато менше ризикує піддатися вірусним небезпекам, ніж під час запуску виконуваних бінарних файлів.

Оскільки RIA використовують рушій клієнта, щоб взаємодіяти із користувачем, вони:

• Функціональніші. RIA пропонують користувацький інтерфейс, не обмежений лише використанням мови HTML, застосовної в стандартних web-застосунках. Розширена функціональність дозволяє використовувати такі можливості користувацького інтерфейсу, як drag-and-drop або повзунець для змінювання даних, а також обчислення, які не відсилаються назад на сервер, а виконуються безпосередньо на машині користувача (наприклад, іпотечний калькулятор).
• Інтерактивніші. Інтерфейси RIA інтерактивніші, ніж стандартні інтерфейси веб-браузерів, які вимагають постійної взаємодії з віддаленим сервером.

Найскладніші RIA пропонують зовнішній вигляд і функціональність, близькі до настільних застосунків. Використання рушія клієнта дозволяє досягти й інших переваг продуктивності:

• Збалансованість клієнт-сервера. Використання обчислювальних ресурсів клієнта і сервера краще збалансовано. Тому сервер не мусить бути «робочою конячкою», як у традиційних web-застосунках. Це вивільняє обчислювальні ресурси сервера, дозволяє обробляти більшу кількість сесій одночасно коштом того ж самого апаратного забезпечення.
• Асинхронна комунікація. Рушій клієнта може взаємодіяти із сервером, не очікуючи, поки користувач виконає дію в застосунку, натиснувши кнопку чи посилання. Це дозволяє користувачу переглядати сторінку та взаємодіяти з нею асинхронно за допомогою комунікації між рушієм і сервером. Ця моливість дозволяє розробникам RIA передавати дані між клієнтом і сервером не очікуючи на користувача. В Google Maps ця техніка використовується для того, щоби підвантажувати прилеглі сегменти мапи, перш ніж користувач пересуне її, щоби їх переглянути.

Основними недоліками й обмеженнями RIA є:

• «Пісочниця». Оскільки RIA завантажуються в локальному середовищі безпеки — «пісочниці» — вони мають обмежений доступ до системних ресурсів. Якщо права на доступ до ресурсів порушено, RIA можуть працювати некоректно.
• Підключення скриптів. Як правило, для роботи RIA потрібна JavaScript або інша скриптова мова. Якщо користувач відключив активні сценарії у своєму браузері, RIA може не функціонувати належним чином або взагалі не працювати.
• Швидкість обробки клієнтом. Щоби забезпечити платформну незалежність, деякі RIA використовують скриптову мову на боці клієнта, на кшталт JavaScript, із частковою втратою продуктивності (серйозна проблема для мобільних пристроїв). Проте ця проблема не виникає за використання вбудованої мови, скомпільованої на стороні клієнта, такого как Java, де продуктивність порівнянна з використанням традиційних вбудованих мов, або з Flash або з Silverlight, в яких програмний код запускається безпосередньо в плагіні Flash Player або Silverlight відповідно.
• Час завантаження скрипту. Навіть якщо немає потреби в установленні скрипту, рушій клієнта RIA повинен бути переданий клієнту сервером. Оскільки більшість скриптів зберігаються в кеші, він повинен бути переданий хоча б один раз. Залежно від розміру й типу передачі, завантаження скрипту може зайняти досить багато часу. Розробники RIA можуть зменшити наслідки цієї затримки шляхом стиснення скриптів, а також за рахунок разбивання передачі застосунка на декілька строрінок.

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

Застосування технології RIA ставить нові задачі з управління послугами SLM (service level management), не всі з яких вирішені на сьогоднішній день. Питання відносно SLM не завжди враховуються розроблювачами застосунків і майже не сприймаються користувачами. Однак вони життєво важливі для успішного впровадження застосунка в мережі Інтернет. Основними аспектами, що ускладнюють процес розробки RIA, є:

• Більша технологічна складність робить розробку важчою. Можливість передавати код застосунка безпосередньо клієнтам дає більшу творчу свободу розроблювачам і дизайнерам. Але це, у свою чергу, ускладнює розробку застосунка, збільшує ймовірність помилок при впровадженні й утрудняє тестування програмного забезпечення. Ці ускладнення сповільнюють процес розробки незалежно від специфіки методології й процесу розробки. Деякі із цих проблем можуть бути скорочені за рахунок використання каркаса програмної системи під веб (web application framework) для стандартизації розробки RIA. Проте, зростаюча складність програмних рішень може ускладнити й подовжити процес тестування при збільшенні числа тестованих варіантів використання (use cases). Неповне тестування знижує якість і надійність застосунка в ході його використання. Можна сперечатися про те, чи стосується зауваження вище тільки до RIA-технології, чи до складності розробки в цілому. Наприклад, точно такий же аргумент наводився, коли Apple і Microsoft незалежно один від одного оголосили про GUI в 1980-х, і, можливо, навіть тоді, коли компанія Ford представила свою Model T. Проте, людство продемонструвало чудову здатність усмоктувати всі технологічні нововведення протягом десятиліть, якщо не сторіч.
• Архітектура RIA ламає парадигму веб-сторінки. Традиційні веб-застосунки представляють із себе набір веб-сторінок, кожна з яких вимагає окремого звантажування, ініційованого запитом HTTP GET. Ця модель була описана як парадигма веб-сторінки. RIA ламає цю парадигму, вносячи додатковий сервер асинхронної комунікації для підтримки більше інтерактивного інтерфейсу. Повинні бути розроблені нові технології вимірювання для RIA, що надають інформацію про кількість витраченого часу. При відсутності подібних стандартних засобів розробники RIA повинні додати у свої застосунки засобу вимірювання даних, необхідні для SLM.
• Асинхронна комунікація ускладнює виявлення проблем продуктивності. Парадоксально, але заходи, прийняті для зниження часу відгуку застосунка утрудняють саме його визначення, вимірювання й керування. Деякі RIA не роблять ніяких подальших HTTP GET-запитів із браузера після одержання першої сторінки, використовуючи асинхронні запити за допомогою рушія клієнта для наступних завантажень. Клієнт RIA може бути запрограмований таким чином, щоб постійно завантажувати новий контент і обновляти дисплей, або (у застосунках, що використовують підхід Comet) рушій на стороні сервера може постійно передавати новий контент браузеру через постійно відкрите з'єднання. У цьому випадку концепція «завантаження сторінки» більше не застосовна. Усе це привносить певні труднощі у вимірювання й розділення часу відгуку застосунка, які є фундаментальними вимогами для ізоляції проблем і SLM. Інструменти, створені для вимірювання традиційних веб-застосунків, залежно від специфіки й інструментарію застосунка можуть розглядати кожну веб-сторінку, запитану по HTTP, окремо або як набір не пов'язаних між собою показників. Однак, жоден із цих підходів не показує, що в дійсності відбувається на рівні застосунка.
• Рушій клієнта ускладнює вимірювання часу відгуку застосунка. Для традиційних веб-застосунків вимірювальне програмне забезпечення може розташовуватися на клієнтській машині й на машині, близькій до сервера, таким чином, воно може спостерігати за потоком мережного трафіка на TCP і HTTP рівнях. Оскільки це синхронізовані й передбачувані протоколи, пакет зі сніфером може читати й інтерпретувати дані пакетного рівня й виводити висновок про час відгуку за допомогою засобів відстеження повідомлень HTTP і часу підтвердження пакетів TCP на нижньому рівні. Але архітектура RIA зменшує можливості підходу з використанням пакетного сніфінга, оскільки рушій користувача розбиває взаємодію між клієнтом і сервером на два окремих цикли, що працюють асинхронно — цикл переднього плану (користувач-рушій) і цикл заднього плану (рушій-сервер). Обидва цих цикли мають важливе значення, оскільки їхній загальний взаємозв'язок визначає поведінку застосунка. Але це відношення залежить тільки від побудови самого застосунка, що в більшості випадків не може бути спрогнозовано вимірювальними інструментами, особливо першим, котрий може спостерігати тільки один із двох циклів. Тому найповніше вимірювання RIA може бути отримано тільки з використанням інструментів, які є на боці клієнта й спостерігача в обох циклах.