RSS    

   Дипломная работа: Технічне створення Web-додатків

Технологія Java є відкритою — її вихідні коди та специфікації доступні під вільною ліцензією GNU General Public License.

Аплет може працювати майже на будь-якій версії віртуальної машини Java, хоча в деяких випадках він вимагає останню версію.

Аплет кешується, тому при повторному використанні він завантажується швидко.

Аплет працює на порядок швидше, ніж JavaScript і має майже таку саму швидкість, як і мови програмування, що компілюються — наприклад С/C++.

Аплет може перенести більшу частину бізнес-логіки на сторону клієнта. Таким чином зменшується навантаження на сервер і це дає змогу створювати сервіси з великою кількістю користувачів при відносно невеликих серверних потужностях.

Аплети мають недоліки:

Аплет потребує віртуальної машини Java, яка по замовчуванню не присутня в деяких популярних ОС (наприклад Microsoft Windows XP).

Швидкість початку роботи Аплету залежить від швидкості запуску віртуальної машини Java.

Політика деяких компаній забороняє інсталяцію та використання віртуальної машини Java на службових комп’ютерах працівників.

Детальний аналіз цих недоліків та способи їх подолання наведені нижче.

1. Будь-яка розширена Web-технологія (крім базових HTML, CSS і т.п.) потребує підтримки в браузері. Для JavaScript необхідно мати відповідний двигунець, для Adobe Flash — Adobe Flash Player, для Microsoft Silverlight — платформу .NET, для Java Апплетів — віртуальну машину Java.

Порівняємо статистику [5] підтримки у користувачів вище названих технологій.

JavaScript — ~95%

Adobe Flash — ~90%

Microsoft Silverlight — ~10%

Java — ~80%

Як бачимо, Java підтримується у переважної більшості користувачів, а при сучасних швидкостях Інтернет завантажити і встановити віртуальну машину Java можна без особливих витрат часу.

Також віртуальна машина Java входить в комплект з програмами деяких розробників — OpenOffice.org, Oracle та інших.

2. Сучасні комп’ютери достатньо потужні, щоб користувач не помічав затримок із запуском віртуальної машини Java.

Комп’ютери 3-5 річної давнини все ще мають цю проблему, але їх кількість постійно зменшується.

Інші технології також створюють значне навантаження на комп’ютер, а JavaScript ще й має відносно низьку швидкодію.

3. З тією ж проблемою користувачі стикаються і при використанні інших Web-технологій. В залежності від політики компаній, забороненими можуть бути також Flash, Silverlight і навіть JavaScript. Тому ця проблема є недоліком не лише Java а й інших популярних web-технологій.

Розділ 3. Розробка альтернативного механізму доступу для Web 2.0


3.4 Класичний механізм взаємодії у Web

Браузер

Сервер

запит

відповідь

HTTP — протокол передачі даних, що використовується в комп'ютерних мережах, належить до протоколів моделі OSI 7-го програмного рівня.

Основним призначенням протоколу HTTP є передача веб-сторінок (текстових файлів з розміткою HTML), хоча за допомогою його можна передавати й інші файли, як пов'язані з веб-сторінками (зображення і додатки), так і не пов’язані з ними (у цьому HTTP конкурує з складнішим FTP).

HTTP припускає, що клієнтська програма — веб-браузер — здатна відображати гіпертекстові веб-сторінки і файли інших типів в зручній для користувача формі. Для правильного відображення HTTP дозволяє клієнтові дізнатися мову і кодування веб-сторінки і/або запитати версію сторінки в потрібних мові/кодуванні, використовуючи позначення із стандарту MIME.

Класичний механізм взаємодії у Web відбувається так: браузер генерує HTTP запит і відправляє його на сервер. Сервер оброблює запит і відправляє відповідь клієнту у вигляді готової HTML сторінки, яку браузер показує користувачу. Для кожного обміну даними між сервером та клієнтом потрібен окремий запит (перезавантаження сторінки).

Є два основні види запитів до сервера — GET та POST.

З початку GET був єдиним способом передачі даних від клієнта до сервера. Дані від клієнта до сервера передаються у вигляді параметрів адреси (наприклад — http://www.example.ua/file?p1=v1&p2=v2). Згідно стандарту HTTP запити типу GET вважаються «безпечними» — багаторазове повторення одного і того ж запиту призводить до одного і того ж результату (при умові, що сам ресурс не змінився за час між запитами). Це дозволяє кешувати відповіді на HTTP запити з типом GET.

За допомогою GET не можна передавати великі об’єми даних та файли (в браузерах, проксі-серверах та web-серверах є ліміти на довжину адреси, наприклад в браузерів Microsoft Internet Explorer це 1Кб).

Використання GET є небезпечним для відправлення поролів та іншої конфіденційної інформації — вона буде присутня в адресі у відкритому вигляд.

В 1996 з’явилася специфікація HTTP 1.0, що містила новий механізм запиту до сервера — POST. Дані від клієнта до сервера передаються в тілі запиту і, при необхідності, можуть бути зашифрованими. На відміну від запиту з типом GET, запити з типом POST вважаються «небезпечними» — багатократне повторення одних і тих же запитів з типом POST може давати різні результати.

Також за допомогою POST запиту можлива передача файлів від клієнта до сервера.

Існують також інші методи доступів, але вони мають специфічне застосування:

OPTIONS — повертає методи HTTP, які підтримуються сервером. Використовується для визначення можливостей Web-сервера.

HEAD — аналогічний методу GET, єдина різниця — у відповіді сервера відсутнє тіло. Використовується для отримання мета-даних, що задаються в заголовку відповіді, без відправлення всього вмісту.

PUT — завантажує вказаний ресурс на сервер.

DELETE — видаляє вказаний ресурс.

TRACE — повертає отриману відповідь так, що клієнт може побачити, що проміжні сервери додали чи модифікували в запиті.

CONNECT — використовується разом з proxy-сервером, які можуть динамічно переключатися в тунельний режим SSL.

Переваги класичного механізму доступу до Web — підтримка будь-яким HTTP клієнтом (браузером, роботом пошукової системи і т.п.).

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

3.5 Взаємодія у Web за допомогою Ajax

В цьому механізмі доступу з’єднуючою ланкою між сервером та сторінкою є JavaScript-об’єкт XMLHttpRequest. В різних двигунцях та їх версіях він реалізований по різному тому потрібно використовувати спеціальну функцію, яка враховує всі можливі варіанти.

HTML

сторінка

Об’єкт

XMLHttpRequest

PHP

скрипт

При певних діях користувача (наприклад при активізації кнопки в складі користувацького інтерфейсу) браузер генерує запит і за допомогою JavaScript-об’єкта XMLHttpRequest відправляє його на сервер. При цьому метод доступу може бути GET або POST. Користувацький інтерфейс під час відправлення запиту і отримання відповіді не блокується і користувач може продовжувати виконувати певні дії, результатом яких можуть бути нові запити до сервера — Ajax підтримує декілька одночасних взаємодій сторінки з сервером. Користувацький інтерфейс виглядає і реагує на дії користувача як звичайна програма, що полегшує роботу з ним.

Сервер оброблює запит і відправляє браузеру відповідь у форматі XML, JSON або подібних. При цьому не відбувається генерації усієї сторінки (як у класичному механізмі доступу), тому час обробки запиту скорочується. Це дозволяє зменшити навантаження на сервер або збільшити кількість клієнтів, що можуть працювати одночасно.

Браузер, за допомогою JavaScript, обробляє отриману відповідь і модифікує сторінку без перезавантаження за допомогою DHTML.

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

Недоліки методу:

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

зміст сторінок, згенерованих за допомогою Ajax, не індексується пошуковими системами і сторінку не можна зберегти за допомогою браузера збережеться лише початкова сторінка та сценарії JavaScript.

на сторінку, згенеровану за допомогою Ajax, не можна поставити пряме посилання — при модифікації сторінка не змінює адреси.

Для подолання вказаних недоліків потрібно:

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

Створювати окремі статичні сторінки, що матимуть той самий вміст, що і динамічні сторінки, але їх зможуть прочитати та обробити пошукові системи а також переглянути ті користувачі, що використовують застарілі браузери або браузери із відключеними або заблокованими додатковими можливостями (JavaScript, Java, Flash і т.п.). Також ці статичні сторінки користувач може зберегти на свій комп’ютер для перегляду оффлайн або редагування за допомогою HTML-редакторів.

Створити спеціальний елемент користувацького інтерфейсу — «посилання на цю сторінку», що міститиме спеціально сформоване посилання, перейшовши за яким відкривається сторінка з таким самим вмістом, як і згенерована динамічно. Це потребує модифікації серверної частини (в більшості випадків ця модифікація є незначною), але подолання цього недоліку є дуже важливим для комфортної роботи з Web-сторіками, що побудовані динамічно.

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10


Новости


Быстрый поиск

Группа вКонтакте: новости

Пока нет

Новости в Twitter и Facebook

                   

Новости

© 2010.