Размещено на http://www.allbest.ru/

ВВЕДЕНИЕ

Невероятный успех Интернета разжег аппетиты пользователей выше всяких ожиданий. Многолетняя потребность пользователей в еще более мощных приложениях с веб-поддержкой заставляла архитекторов и разработчиков внедрять все больше функций на серверной платформе и в клиентских браузерах. В результате традиционная схема веб-приложения с каждым днем становится все менее актуальной. Стало очевидно, что откладывать на будущее радикальные изменения в архитектуре и модели программирования далее невозможно.

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

Сокращение AJAX происходит от слов «Asynchronous JavaScript and XML» («асинхронный код JavaScript и ХМL»). Этим общим термином обозначаются высокоинтерактивные приложения, быстро реагирующие на действия пользователя, выполняющие большую часть работы на стороне клиента и взаимодействующие с сервером посредством внеполосных обращений. Внеполосным (out-of-band) обращением называется запрос к серверу, который приводит к оперативному обновлению страницы (вместо ее замены). В результате веб-приложения на базе AJAX обычно в большей степени напоминают классические приложения Microsoft Windows, поддерживают перетаскивание и асинхронные операции, быстро реагируют на действия пользователя, не мигают при перерисовке и не раздражают пользователя.

Если взглянуть на ситуацию с точки зрения разработчика, термином AJAX обозначается совокупность компонентов разработки, инструментов и методов создания высокоинтерактивных веб-приложении. В соответствии с парадигмой AJAX, веб-приложения в процессе работы обмениваются с веб-сервером данными (а не страницами). Актуальность проблемы заключается в следующем: для конечного пользователя, использование AJAX-приложений, это более быстрое получение обновленных данных и, что более важно, - существенное ускорение загрузки н обновления страниц. Веб-приложения приближаются к классическим приложениям Microsoft Windows, поддерживают перетаскивание и асинхронные операции, быстро реагируют на действия пользователя, не мигают при перерисовке и не раздражают пользователя.

Целью данной дипломной работы является рассмотрение технологии создания веб-приложений, ознакомление с инструментарием и методами создания ajax-приложений, использование полученных в ходе дипломной работы навыков и знаний для создания информационного портала по языкам программирования.

1 ПОСТАНОВКА ЗАДАЧИ

1.1 Формулировка задачи

Разработать и создать информационный портал по языкам программирования с использованием технологии задач. Портал должен иметь средство для управления информационной частью и предоставлять доступ пользователя к информации. Информация предоставляемая пользователю: книги (данные в формате Acrobat Reader), статьи (формат HTML), исходные коды (файлы сжатые в архив), видеоматериалы (формат AVI , WMV, MPEG).

Задачи, поставленные в ходе выполнения дипломной работы:

- ознакомиться с устройством метода AJAX, а также с историей его возникновения и развития;

- изучить вопросы безопасности AJAX-приложений и способы их решений;

- исследовать и выбрать инструментарий разработки веб-приложений с использованием AJAX;

- разработать дизайн оформления клиентской и администраторской частей портала;

- разработать и реализовать базу данных для хранения пользовательской и служебной информации;

- разработать и создать инструментарий управления порталом (администраторская часть);

- разработать и создать пользовательский интерфейса для доступа к информационной части портала (клиентская часть);

- собрать информационное содержание портала.

1.2 Структура и история развития технологии AJAX

AJAX -- это коллекция технологий, существующих с момента появления Web. А вот и возможности, предоставляемые AJAX (как это представил Джис Джеймс Гаррет (Jesse James Garrett), он первым ввел термин «AJAX» для асинхронного JavaScript + XML):

- стандартно-базированная презентация с использованием XHTML и CSS;

- динамическое отображение и взаимодействие с использованием объектной модели документа;

- взаимообмен данными и манипуляция с задействованием XML и XSLT;

- асинхронное извлечение данных с использованием XMLHttpRequest;

- JavaScript, связывающий все вместе.

Вкратце AJAX позволяет писать быстрореагирующие веб-приложения, в которых не нужно постоянно обновлять страницы. AJAX -- простая технология, поддерживаемая всеми основными браузерами. Как можно вкратце отметить, единственным предварительным условием для внедрения AJAX является знание JavaScript.

AJAX -- это подход к построению интерактивных пользовательских интерфейсов веб-приложений, заключающийся в «фоновом» обмене данными браузера с веб-сервером. В результате при обновлении данных веб-страница не перезагружается полностью, и веб-приложения становятся более быстрыми и удобными.

AJAX -- это не самостоятельная технология, а концепция использования нескольких смежных технологий. AJAX базируется на двух основных принципах:

а) использование технологии динамического обращения к серверу «на лету», без перезагрузки всей страницы полностью, например:

1) с использованием XMLHttpRequest (основной объект);

2) через динамическое создание дочерних фреймов;

б) через динамическое создание тега <script>;

в) использование DHTML для динамического изменения содержания страницы.

В качестве формата передачи данных обычно используются JSON или XML.

Впервые термин AJAX был публично использован 18 февраля 2005 года в статье Джесси Джеймса Гарретта «Новый подход к веб-приложениям». Гарретт придумал термин, когда ему пришлось как-то назвать новый набор технологий, предлагаемый им клиенту.

Однако в той или иной форме многие технологии были доступны и использовались гораздо раньше, например в подходе «Remote Scripting», предложенным компанией Microsoft в 1998 году, или с использованием HTML элемента IFRAME, появившегося в Internet Explorer 3 в 1996 году.

AJAX стал особенно популярен после использования его компанией Google в сервисах Gmail, Google Maps и Google Suggest.

Исходная инфраструктура - простая, универсальная и эффективная - стала определяющим фактором стремительного успеха модели веб-приложений. Следующее поколение веб-приложений по-прежнему будет базироваться на HTTP и страницах, однако содержимое страниц и возможности оборудования, работающего на стороне сервера, существенно изменятся. В результате впечатление от работы с веб-приложениями заметно изменится -- последние приблизятся к классическим Windows-приложениям для настольных систем.

Работа сегодняшних веб-приложений основана на отправке форм, заполненных пользователем, на веб-сервер и последующем отображении разметки, возвращенной сервером. При обмене данными между браузером и сервером используется классический протокол HTTP. Как известно, HTTP относится к числу протоколов без состояния; иначе говоря, каждый запрос никак не связан с предыдущим, а автоматическое сохранение информации состояния отсутствует (объекты состояния, известные всем нам, например, по ASP.NET, представляют собой абстракцию, реализуемую средой серверного программирования).

Обмен данными между браузером и веб-сервером происходит при помощи форм. С точки зрения пользователя пересылка осуществляется постранично. Каждое действие пользователя, в результате которого серверу отправляется новый запрос, приводит к пересылке и отображению совершенно новой страницы (или измененной версии текущей страницы).

Небольшой анализ этой модели поможет выявить ее недостатки и те причины, по которым сегодня стала необходима новая модель.

На основании URL, введенного в строке адреса, браузер отображает страницу. Страница, в конечном счете, состоит из разметки HTML и содержит одну или несколько форм HTML. Пользователь вводит данные, а затем приказывает браузеру отправить форму по URL, заданному для этой цели (URL действия).

Браузер преобразует заданный URL в IP-адрес и открывает сокет. Пакет HTTP, содержащий форму вместе со всеми полями, пересылается по каналу связи заданному получателю. Веб-сервер принимает запрос и обычно передает его внутреннему модулю для дальнейшей обработки. В конце процесса создается пакет ответа HTTP, а возвращаемое браузером значение вставляется в тело пакета.

Получив запрос, например, на ресурс .aspx, веб-сервер передает его подсистеме ASP.NET для обработки и получает разметку HTML. Сгенерированная разметка включает все теги классической страницы HTML (<html>, <body>, <form> и т. д.). Исходный код страницы встраивается в ответ HTTP и помечается соответствующим типом MIME, чтобы браузер знал, как его следует обработать. В зависимости от типа MIME браузер выбирает дальнейшие действия.

Если ответ содержит страницу HTML, браузер полностью заменяет текущее содержимое новой разметкой. Во время обработки запроса сервером на экране отображается «старая» страница. Как только «новая» страница будет полностью загружена, браузер стирает изображение и выводит ее.

Описанная модель хорошо работала в начале эпохи Web, когда содержимое веб-страниц ограничивалось форматированным текстом, гиперссылками и небольшим количеством графики. Из-за успеха Web пользователи становились все более требовательными, а это заставляло разработчиков и дизайнеров создавать все более сложный сервис и графику. В качестве примера возьмем рекламу. Сегодня на большинстве страниц (причем даже очень простых, как страницы блогов) присутствуют рекламные ротаторы, пересылающие клиенту немалый объем данных.

В результате страницы становятся тяжелыми и громоздкими - даже если упорно говорить о «расширенной функциональности», от этого ничего не изменится.

При действующей архитектуре веб-приложений каждое действие пользователя требует полной перерисовки страницы. Как следствие, более тяжелые («широкофункциональные») страницы медленнее воспроизводятся на экране, а их прорисовка сопровождается мерцанием. При большом наборе страниц крупного приложения (например, портала) такой механизм лишь вызовет раздражение у конечного пользователя.

Хотя для построения страницы на сервере разработчик может воспользоваться целым рядом гибких архитектур (ASP.NET -- всего лишь один из возможных примеров), с точки зрения клиента веб-страницы изначально проектировались в расчете на статичность и отсутствие изменений. В конце 1990-х годов этот основополагающий факт изменился: сначала появился стандарт Dynamic HTML, затем модель объекта документа W3C (World Wide Web Consortium). В наши дни страница, отображаемая браузером, может модифицироваться с учетом изменений, вносимых исключительно на стороне клиента, в зависимости от действий пользователя.

Стандарт Dynamic HTML стал серьезным шагом вперед, но одного его было недостаточно для качественного изменения Web.

Перерисовку страниц было необходимо свести к минимуму. Для этой цели около 1997 года появились первые примитивные формы сценарного удаленного вызова процедур (RPC, Remote Procedure Call). В частности, компания Microsoft со своей технологией RS (Remote Scripting) стала одним из новаторов в этой области.

В RS, для получения данных с удаленного URL, были задействованы апплеты Java. URL предоставлял формализованный программный интерфейс и сериализацию данных, пересылаемых в обе стороны в строковом формате. На стороне клиента компактная инфраструктура JavaScript принимала данные и активизировала функцию обратного вызова, определяемую пользователем, для обновления пользовательского интерфейса средствами Dynamic HTML или аналогичными методами. Технология RS работала в Microsoft Internet Explorer 4.0, Netscape Navigator 4.0 и последующих версиях.

Позднее компания Microsoft заменила апплет Java объектом СОМ с именем XmlHttpRequest и сняла большинство ограничений программного интерфейса, предоставляемого удаленным URL.

В то же время стараниями сообщества появился ряд аналогичных прикладных сред, которые должны были поднять технологию RS на новый уровень и расширить область ее практического применения. Апплет Java исчез и был заменен объектом XmlHttpRequest.

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

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

Рисунок 1 - Браузер отправляет форму HTML и получает новую страницу, отображаемую на экране

Основным фактором, заложенным в основу удаленного исполнения сценариев, является возможность выдачи внеполосных запросов HTTP. В данном контексте под внеполосным вызовом понимается запрос HTTP, который выдается за пределами встроенного модуля, обеспечивающего отправку форм HTTP (то есть вне традиционного механизма, показанного на рисунке 1). Внеполосный вызов инициируется событием страницы HTML и обслуживается компонентом-посредником (proxy component). В новейших AJAX-решениях таким посредником является объект XmlHttpRequest; в самых первых реализациях RS им был апплет Java.

Компонент-посредник (например, объект XmlHttpRequest) отправляет обычный запрос HTTP и дожидается (синхронно или асинхронно) завершения его обработки. Получив готовые данные ответа, посредник вызывает функцию обратного вызова JavaScript; эта функция должна обновить все части страницы, нуждающиеся в обновлении. На рисунке 2 показано графическое представление этой модели.

Рисунок 2 - Внеполосные вызовы обслуживаются компонентом-посредником, а функция обратного вызова JavaScript обновляет все части страницы, зависящие от полученных данных

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

Спецификация DOM (Document Object Model) определяет общий интерфейс обновления содержимого, структуры и стиля документов HTML и XML, не зависящий от языка и платформы. Стандарт DOM получил признание и был ратифицирован комитетом W3C, поэтому сейчас он поддерживается все большим количеством браузеров. DOM определяет стандартный набор объектов для представления элементов, образующих документы HTML и XML. Совокупность этих объектов образует стандартный интерфейс для работы с элементами страниц HTML, или на более общем уровне - документов XML.

Следует заметить, что хотя первые работоспособные прикладные среды удаленного исполнения сценариев появились около десяти лет назад, ограниченная поддержка динамического изменения отображаемого документа в браузере тормозила массовое принятие таких технологий в масштабах отрасли. До сегодняшнего дня.

Как видно из рисунка 2, модель AJAX предъявляет два ключевых требования к браузеру: наличие компонента-посредника и поддержка обновляемой модели DOM. В течение долгого времени оба требования выполнялись только передовыми, элитными браузерами (также часто встречается термин «широкофункциональный браузер»). За прошедшие годы только компании, способные жестко контролировать возможности клиентских браузеров, могли выбрать модель AJAX для своих сайтов. Слишком долго термин «широкофункциональный» подразумевал «редко встречающийся», и для большинства коммерческих отраслей такие браузеры определенно не подходили. Впервые сложилась ситуация, когда широкофункциональный браузер перестал быть синонимом браузера с ограниченным кругом пользователей. Проектирование высокоинтерактивных веб-приложений, реализующих методы удаленного исполнения сценария, перестало быть недостижимой мечтой и стало совершенно реальным делом.

Каждая платформа и каждая фирма-разработчик предлагает собственную прикладную среду и инструментарий, но это не изменяет основополагающего факта - реализация стиля AJAX стала возможной в 90% существующих браузеров. Это настоящий прорыв, благодаря которому сегодня можно создавать и распространять приложения, невозможные вчера.

Что же именно требуется от браузера для поддержки функциональности AJAX? Как упоминалось ранее, браузер должен удовлетворять двум ключевым требованиям: поддержке посредников, чтобы клиентский код мог выдавать внеполосные вызовы HTTP, и поддержке обновляемой модели DOM.

В настоящее время стандарт обновляемой модели DOM был ратифицирован комитетом W3C. Стандарт W3C для компонента-посредника пока находится в стадии разработки. Он воплощен в форме объекта XmlHttpRequest и представляет собой интерфейс, предоставляемый браузером и позволяющий сценарному коду выполнять клиентские функции HTTP - такие, как отправка данных формы или загрузка данных с удаленного веб-сайта.

Также браузер должен поддерживать JavaScript и желательно CSS (каскадные таблицы стилей, Cascading Style Sheets). Выходит, что стиль AJAX доступен практически для любого разработчика и для 90% аудитории Web, независимо от платформы. Инструменты, необходимые для работы AJAX, получили такое же повсеместное распространение, как парсеры HTML/XML и обработчики JavaScript. Перефразируя лозунг популярной рекламной кампании, можно сказать: «AJAX здесь и сейчас!» А в том, что касается Windows и платформы ASP.NET, AJAX воплощается в форме Microsoft Atlas.

Объект XmlHttpRequest впервые появился в Internet Explorer 5.0. Этот внутренний объект публикуется браузером для работы с его подсистемой исполнения сценариев. Сценарный код, входящий в клиентскую страницу (как правило, код JavaScript), обращается к объекту и использует его функциональность.

Что касается функциональности (несмотря на префикс XML), объект XmlHttpRequest представляет собой компактную объектную модель для отправки сценарием обращений HTTP в обход браузера. Когда пользователь щелкает на кнопке отправки формы или выполняет любое действие, приводящее к вызову метода submit объекта form модели DOM, браузер вмешивается в происходящее и берет последующую отправку запроса HTTP под свой полный контроль. С точки зрения пользователя, отправка запроса работает по принципу «черного ящика» с единственным видимым результатом: на экране появляется новая страница. Клиентский код сценария не может управлять процессом размещения и результатом отправки запроса.

Объект XmlHttpRequest дает возможность сценарному коду отправлять запросы HTTP и обрабатывать полученные ответы.

Объект XmlHttpRequest, созданный компанией Microsoft и вскоре принятый в Mozilla, в наши дни поддерживается большинством веб-браузеров. Его реализация в значительной мере зависит от браузера, хотя интерфейс верхнего уровня остается практически неизменным. По этой причине комитет W3C в настоящее время работает над точным описанием минимального набора общих возможностей, основанного на существующих реализациях.

В то время, когда появился объект XmlHttpRequest, в мире господствовала модель COM (Component Object Model), разработанная компанией Microsoft. Модель расширяемости программных продуктов и приложений базировалась на технологии СОМ и реализовывалась с использованием компонентов СОМ. В конце 1990-х годов было совершенно правильно и естественно реализовать новый компонент в виде объекта автоматизации СОМ, которому было присвоено имя Microsoft.XmlHttp.

За последующие годы были выпущены разные версии того же компонента (даже со слегка различающимися именами), но во всех случаях исходная модель компонента оставалась неизменной - СОМ. Например, в Internet Explorer 6.0 объект XmlHttpRequest поставляется в форме объекта СОМ.

Объекты СОМ представляют собой внешние компоненты, для выполнения которых в веб-браузере необходимо специальное разрешение. В частности, для инициализации объекта XmlHttpRequest и последующего использования любой функциональности AJAX, построенной на его базе, клиентский компьютер должен принимать компоненты ActiveX, помеченные как безопасные для использования в сценариях, как следует из рисунка 3.

Рисунок 3 - Окно свойств для изменения настроек безопасности в Internet Explorer

Несомненно, компонент XmlHttpRequest безопасен. Но чтобы использовать его, пользователь должен понизить общий уровень безопасности и принять все остальные компоненты, объявленные «безопасными» для использования в сценариях, во всех посещаемых веб-сайтах.

Объект XmlHttpRequest предназначен для выполнения одной ключевой операции: отправки запросов HTTP. Запросы могут отправляться как синхронно, так и асинхронно.

Операции с компонентом выполняются в два этапа. Сначала открывается канал к URL, выбирается метод (GET, POST и т. д.) и указывается, должен ли запрос быть отправлен асинхронно. На втором этапе задаются все необходимые заголовки, а запрос отправляется серверу. Если для запроса используется метод POST, методу send передается тело запроса.

При выполнении асинхронных операций метод send немедленно возвращает управление. Написанная функция onreadystatechange должна проверить состояние текущей операции и определить момент ее завершения.

Ответ доступен в двух форматах - физического текста и документа XML.

Для веб-страницы, выдающей внеполосные вызовы, определяется одно или несколько триггерных событий, которые в результате обработки кодом JavaScript выдают запросы через объект XmHttpRequest. Триггерными событиями могут быть только события HTML, отслеживаемые реализацией DOM текущего браузера.

Что должна делать страница при отправке внеполосного вызова? Как она определяет ответ? Большинство существующих AJAX-сред по-разному отвечают на эти вопросы, поэтому можно сказать, что единого ответа на эти вопросы не существует. В общем случае программист определяет открытый программный интерфейс, активизируемый при внеполосном вызове.

Остается сделать еще один шаг - что происходит на стороне клиента при получении ответа на внеполосный запрос?

Правильное отображение результатов в большинстве браузеров - задача не из простых. Так, модель DOM в Internet Explorer поддерживает ряд нестандартных сокращений, не работающих в других браузерах. Самая распространенная проблема - получение ссылок на элементы HTML с использованием метода document.getElementByld вместо прямого обращения по имени элемента.

Следовательно, для обновления страницы, отображаемой в данный момент на стороне клиента, потребуется кросс-браузерный код JavaScript. В то же время для обеспечения работоспособной и эффективной среды сервер должен сделать ряд допущений относительно клиента. По этой причине единственным разумным способом реализации функциональности AJAX остаются прикладные среды. Впрочем, разные среды могут предоставлять разные программные интерфейсы на основе механизма, состоящего из единого набора составных частей.

Итак, подведем итоги. AJAX - набор технологий, который служит для создания более гибких и интерактивных веб-приложений. Он позволяет выполнять асинхронные обращения к серверу, не прерывая работы пользователя и незаметно для него. AJAX - это инструмент, который может применяться разработчиками для создания веб-приложений, более интеллектуально взаимодействующих с человеком.

Технологии, из которых состоит AJAX, уже реализованы во всех современных веб-браузерах, таких как Mozilla Firefox, Internet Explorer или Opera. Таким образом, клиент не требует установки каких-либо дополнительных модулей, чтобы иметь возможность взаимодействия с веб-сайтами, построенными на основе AJAX. В состав AJAX входят следующие компоненты:

- JavaScript - основной ингредиент AJAX, позволяющий реализовать функциональность на стороне клиента. В ваших функциях JavaScript для манипулирования отдельными частями страницы HTML часто задействуется объектная модель документа (Document Object Model - DOM);

- объект XMLHttpRequest позволяет из JavaScript организовать асинхронный доступ к серверу, благодаря чему пользователь имеет возможность продолжать работу со страницей, в то время как она выполняет некоторые действия. Под доступом к серверу подразумеваются простые запросы HTTP на получение файлов или сценариев, размещенных на сервере. Запросы HTTP просты в исполнении и не вызывают каких-либо трудностей в случае применения брандмауэров;

- серверные технологии, которые необходимы для обслуживания запросов, поступающих от JavaScript, со стороны клиента.

Для организации взаимодействия клиент-сервер необходимо иметь возможность передавать данные и понимать, что за данные были переданы. Передача данных - это самое простое. Сценарий на стороне клиента, обладающий доступом к серверу (посредством объекта XMLHttpRequest), может передавать серверу пары имя-значение с помощью методов GET или POST. Эти данные легко могут быть прочитаны с помощью любого сценария на стороне сервера.

Сценарий на стороне сервера просто отправляет свой ответ по протоколу HTTP, но, в отличие от обычного веб-сервера, ответ должен иметь такой формат, который легко может быть разобран кодом JavaScript на стороне клиента. Большинство специалистов рекомендуют формат XML, который имеет свои преимущества, заключающиеся в том, что, во-первых, он получил широкое распространение и, во-вторых, существует большое количество библиотек, облегчающих работу с XML документами. Но при желании можно выбрать любой другой формат (данные могут передаваться даже в виде простого текста). Одна из известных альтернатив XML - JavaScript Object Notation (JSON - представление объектов в JavaScript).

Применение AJAX для создания новых веб-приложений дает следующие преимущества:

- он позволяет создавать более динамичные и более качественные веб-сайты и веб-приложения;

- высокая популярность способствует появлению шаблонных решений, которые помогут разработчикам не изобретать велосипед при решении наиболее распространенных задач;

- он задействует уже существующие технологии;

- позволяет разработчикам применять наработанные навыки;

- функциональные возможности AJAX прекрасно интегрируются функциональностью, предоставляемой веб-браузерами (например, навигацией по странице, приведением размеров страницы к определенным значениям и т. д.).

Наиболее общие случаи применения AJAX:

- проверка правильности заполнения формы с привлечением возможностей сервера, что очень удобно, когда невозможно заранее передать клиенту все данные, которые могут потребоваться в процессе проверки;

- разработка простых чатов, которые не требуют наличия внешних библиотек, таких как виртуальная Java-машина или Flash;

- добавление функциональности, аналогичной подсказкам Google;

- более эффективное использование других технологий;

- создание динамических таблиц данных, которые на лету обновляют базы данных на сервере;

- разработка приложений, которые требуют обновления информации в режиме реального времени, считывая ее из различных внешних источников.

С AJAX связаны следующие потенциальные трудности:

- поскольку адрес страницы в процессе ее работы не изменяется, добавить в закладки ссылку на страницу AJAX будет не так-то просто. В случае приложений AJAX установка закладки имеет иное значение, зависящее от конкретного приложения, т.е. обычно требуется сохранить текущее состояние;

- поисковые системы могут оказаться не в состоянии проиндексировать все части сайта, созданного на основе AJAX;

- нажатие на кнопку «Назад» в браузерах не приводит к тому же результату, как в классических веб-приложениях, поскольку все действия пользователь выполняет в одной и той же странице;

- на стороне клиента JavaScript может быть отключен, что сделает приложения AJAX нефункциональными, поэтому нужно предусмотреть сайте альтернативные варианты страниц, чтобы не потерять потенциальных клиентов.

1.3 Безопасность AJAX-приложений

Наличие средств защиты - важное свойство Интернет-служб. Система Web изначально не защищена, поэтому качество Ajax-приложения во многом зависит от наличия в нем средств обеспечения безопасности. Независимо от того, покупает ли пользователь товары в интерактивном магазине или приобретает право воспользоваться сетевыми услугами, он платит деньги, и этот факт еще больше повышает важность средств защиты.

Безопасность - обширная тема, которой посвящены многие книги. К средствам защиты Ajax во многом предъявляются те же требования, что и к системе защиты классического Web-приложения.

В первую очередь следует упомянуть о передаче исполняемого кода по сети и мерах, которые производители браузеров принимают для того, чтобы сделать эту процедуру безопасной.

Рассмотрим вопросы передачи клиентского кода по сети. При загрузке Ajax-приложения Web-сервер посылает браузеру набор JavaScript-команд, предназначенных для выполнения на удаленной машине, о которой сервер не имеет практически никаких сведений. Позволяя командам выполняться в среде браузера, пользователь тем самым высказывает доверие приложению и его авторам. Это доверие не всегда оправдано, поэтому производители браузеров предусматривают ряд мер, направленных на защиту системы и информации. Наибольший интерес у разработчиков Ajax-приложений вызывает возможность непосредственно обращаться к Web-службам независимых производителей.

Прежде всего, определим понятие мобильного кода. Любой фрагмент содержимого жесткого диска компьютера представляет собой двоичные данные. Несмотря на это, существует возможность отличить собственно данные от машинных инструкций, которые могут быть выполнены на компьютере. Обычные данные не выполняют никаких действий, по крайней мере, до тех пор, пока они не будут обработаны некоторым процессом. В первых приложениях клиент/сервер клиентский код устанавливался на компьютере пользователя наравне с другими приложениями, и весь трафик, передаваемый по сети, представлял собой обычные данные. Однако в Ajax-приложениях JavaScript-код может быть выполнен. Помимо того что он предоставляет ряд интересных возможностей, которые не могут обеспечить обычные данные, он также может стать источником опасности для системы. Назовем код мобильным, если он хранится на одной машине и может быть передан по сети для выполнения на другом компьютере. Компьютер, принимающий мобильный код, должен решить, доверяет ли он источнику кода. Это решение становится еще более ответственным, если исполняемый код получен из общедоступной сети. Необходим аргументированный ответ на вопрос, к каким из системных ресурсов можно предоставить доступ мобильному коду.

Как было сказано ранее, в среде Web-браузера выполняется код, написанный неким «третьим лицом», зачастую неизвестным пользователю. Выполнение мобильного кода, копируемого по сети, представляет потенциальную опасность для локальной системы. Для того чтобы уменьшить эту опасность, производители браузеров организуют запуск JavaScript-программ в специально сформированной среде, которая носит название «песочница» (sandbox). При этом программа имеет ограниченный доступ к ресурсам локальной системы либо не имеет его вовсе.

Так, Ajax-приложение не может читать информацию из локальной файловой системы или записывать ее. Код Ajax-клиента также не может устанавливать сетевое соединение ни с одним сервером, за исключением того, с которого он был скопирован. Элемент IFrame, сгенерированный в результате выполнения программы, позволяет получать документы с любого узла и даже запускать их, но сценарии из различных фреймов не могут взаимодействовать друг с другом. Такой подход носит название политики «сервера-источника».

Рассмотрим очень простой пример. Определим в сценарии некоторую переменную: x=3;.

Во втором файле сценария попытаемся использовать ее: alert (top.x+4);.

Первый сценарий включен в документ верхнего уровня. По его инициативе был создан элемент IFrame и загружена страница, содержащая второй сценарий, как показано на рисунке 4.

Рисунок 4 - Модель безопасности JavaScript запрещает сценариям, полученным с разных источников, взаимодействовать друг с другом

Если оба сценария получены из одной области или из одного домена, функция alert() выполняется успешно. В противном случае при выполнении второго сценария возникает ошибка.

При взаимодействии, ориентированном на сценарии, JavaScript-код копируется с сервера и непосредственно выполняется на стороне клиента. В большинстве случаев клиент получает код с того же сервера, с которого он был скопирован сам, однако возможны случаи получения программного кода из другого домена. При этом возникает так называемый кросс-сценарий. Предоставляя право получать сценарии с произвольно выбранных узлов, мы тем самым формируем условия для возможной подмены документов или их искажения путем манипуляции DOM-информацией. Ограничения, предусмотренные в модели безопасности JavaScript, обычно обеспечивают реальную защиту от подобных явлений. Эта модель также предотвращает копирование клиентского кода Ajax на узлы, контролируемые злоумышленниками, и подмену сервера. При взаимодействии, ориентированном на данные, риск значительно ниже, так как вместо исполняемого кода сервер предоставляет лишь данные. Тем не менее, информация на серверах злоумышленников может быть подобрана так, чтобы нанести вред системе, используя известные недостатки в программах разбора. Таким образом, например, можно переопределить или удалить важную информацию или создать условия для неоправданно интенсивного потребления ресурсов.

Рассмотрим некоторые системы безопасности браузеров.

Система обеспечения безопасности Internet Explorer оперирует с набором «зон безопасности» с ограниченными правами. По умолчанию исполняемые файлы из локальной файловой системы имеют право взаимодействовать с узлами из всемирной сети, не оповещая об этом пользователя (такое поведение предусмотрено в Internet Explorer 6). Таким образом, локальная файловая система считается безопасной зоной.

В браузере Mozilla понятие зон не используется. Приложение, загруженное из локальной системы, испытывает на себе те же ограничения, что и приложение, загруженное с Web-сервера. В Internet Explorer коды, полученные из различных зон безопасности, будут вести себя по-разному. Модель защиты браузера Mozilla основана на понятии привилегий. Считается, что каждое действие, независимо от того, является ли оно обращением к стороннему Web-серверу или чтением файлов из локальной файловой системы, может представлять опасность для системы. Чтобы выполнить действие, код приложения должен запросить соответствующие привилегии.

Средства защиты в составе браузера, конечно же, необходимы, но бывают ситуации, когда они лишь мешают нормальной работе. Чтобы система, обеспечивающая безопасность, работала эффективно, она обязана подвергать сомнению правомочность каждого действия. Тем не менее, в ряде случаев приложению бывает необходимо обратиться к стороннему серверу. Теперь, рассмотрим два возможных решения задачи ослабления налагаемых ограничений. Одно из них предполагает наличие дополнительного кода на стороне сервера, а второе затрагивает только клиентскую программу.

В соответствии с политикой «сервера-источника» Ajax-приложение может копировать данные лишь из своего собственного домена. Если нужно получать информацию с другого сервера, можно организовать обращение к нему не с клиентской машины, а с «сервера-источника», а ответ перенаправить клиенту. Рисунок 5 иллюстрирует это решение.

Рисунок 5 - Если Ajax-приложению необходимо получить доступ к ресурсам из другого домена, "сервер-источник" выступает в роли посредника, или прокси-сервера

В этом случае с точки зрения браузера данные поступают с того сервера, с которого загружена клиентская программа, что не противоречит политике «сервера-источника». Кроме того, перед перенаправлением информации клиенту на сервере может быть выполнена проверка на наличие недопустимых данных.

Недостатком такого подхода является увеличение нагрузки на сервер.

В настоящее время многие организации предоставляют Web-службы, которые могут быть использованы различными программами, включая JavaScript-клиентов. При работе клиента Ajax желательно иметь возможность непосредственно обращаться к Web-службе. Помехой этому является политика «сервера-источника». Решить данную проблему можно, запрашивая из программы привилегии, необходимые для выполнения требуемых действий в сети. Запрос на получение привилегий отображается на экране, чтобы пользователь подтвердил его правомочность. Браузер может запомнить решение пользователя и, в дальнейшем, оно будет приниматься автоматически.

В итоге обеспечение безопасности выполнения AJAX-приложений зависит от администратора инфрасети. Существует другой способ обеспечения безопасности, но он предполагает специальное оформление приложения. Web-приложение может быть подписано с помощью сертификата.

Однако остается еще одна опасность, связанная с обменом информацией, особенно конфиденциальной.

Компьютер пользователя, на котором работает браузер, как правило, не имеет непосредственного соединения с сервером. Данные, передаваемые на сервер, проходят через промежуточные узлы (маршрутизаторы и прокси-серверы). Обычные HTTP-данные представляют собой незашифрованный текст, который можно прочитать в любой точке по пути следования пакета. Таким образом, информация может стать доступна любому, кто имеет контроль над промежуточными узлами.

Например, рассмотрим приложение Ajax, которое передает по Интернету финансовую информацию. Если маршрутизатор работает корректно, он передает пакеты в неизменном виде и не читает их содержимое. Он лишь извлекает из заголовков данные, необходимые для выбора маршрута. Если же маршрутизатор контролируется злоумышленниками, как показано на рисунке 6, он может собирать содержащиеся в пакетах сведения, выявляя, например, номера платежных карточек или почтовые адреса для рассылки спама.

Рисунок 6 - При обычном HTTP-взаимодействии, данные передаются по сети в незашифрованном виде, что позволяет злоумышленникам, контролирующим промежуточные узлы, прочитать информацию и даже изменить ее

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

В Ajax-приложениях протокол HTTP используется как для копирования клиентского кода, так и для передачи запросов клиента серверу. Любое Web-приложение, в том числе и инфраструктура Ajax, имеет ряд уязвимых мест, которыми могут воспользоваться злоумышленники.

Атака путем перехвата передаваемых данных на промежуточном узле носит название «человек посередине». Рассмотрим меры, которые можно принять для противодействия подобным атакам.

Если необходимо защитить трафик между клиентской программой Ajax и сервером, самая очевидная мера, которую можно предпринять, - кодировать данные, используя защищенное соединение. Hypertext Transfer Protocol на базе Secure Socket Layer (HTTPS) реализует оболочку для обычного HTTP. Кодирование данных, передаваемых в обоих направлениях, осуществляется посредством пары ключей (открытого и закрытого). «Человеку посередине» по-прежнему доступно содержимое пакетов, но оно закодировано, и извлечь выгоду из данной информации невозможно, как показано на рисунке 7.

Рисунок 7 - При использовании защищенного HTTP соединения данные, передаваемые в обоих направлениях, кодируются. На промежуточных узлах можно прочитать закодированную информацию, но ключ, необходимый для ее расшифровки, закрыт

Для того чтобы протокол HTTPS можно было применить на стороне браузера и на стороне сервера, необходима поддержка платформенноориентированного кода. Современные браузеры содержат встроенные средства для работы с HTTPS, и многие компании, предоставляющие на своих серверах пространство для Web-узлов, также предлагают защищенные соединения. При поддержке протокола HTTPS выполняются интенсивные вычисления, поэтому решение формировать передаваемые двоичные данные в программе на JavaScript вряд ли можно считать удачным.

Против использования HTTPS можно выдвинуть ряд аргументов. Во-первых, для кодирования и декодирования требуется большой объем вычислительных ресурсов. Это не создает проблему на стороне клиента, так как клиентская программа должна обрабатывать один поток данных. На сервере же дополнительная нагрузка крайне нежелательна. В особенности это важно на больших узлах. В классических Web-приложениях принято передавать посредством HTTPS только критичные данные, а обычное содержимое, например изображения или дескрипторы, формирующее общую структуру документа, пересылается посредством протокола HTTP. В Ajax-приложении необходимо учитывать влияние модели безопасности JavaScript, согласно которой http:// и https:// считаются различными протоколами. Во-вторых, HTTPS защищает только сам процесс передачи данных, но не обеспечивает безопасность приложения в целом. Если передавать по защищенному каналу номер платежной карточки, а затем поместить его в базу данных, в системе защиты которой имеются недостатки, ценная информация вполне может быть похищена. Тем не менее, HTTPS можно рекомендовать для передачи важных данных по сети. Стоимость такой передачи высока, и ее не всегда можно реализовать на небольших узлах. Если требования к защите не столь критичны, можно использовать обычный протокол HTTP для передачи шифрованных данных.

Предположим, что необходимо поддержать небольшой Web-узел и при его работе не возникает потребности передавать секретные данные по защищенному каналу. Однако пользователи регистрируются на этом узле, и необходимо принять меры, чтобы пароль не попал в руки постороннему. В этой ситуации можно воспользоваться помощью JavaScript. Рассмотрим основные принципы, на которых базируется возможное решение.

Если нужно организовать передачу пароля, возможно пересылать его в зашифрованном виде. Алгоритм шифрования преобразует входную строку в последовательность, с виду напоминающую случайный набор знаков. В качестве алгоритма кодирования можно выбрать MD5. Ряд возможностей, обеспечиваемых данным алгоритмом, позволяет применять его для обеспечения безопасности. Во-первых, в результате преобразования одного и того же фрагмента данных каждый раз будут получены одинаковые результаты. Во-вторых, вероятность того, что при преобразовании двух различных фрагментов будут получены одинаковые выходные данные, исчезающе мала. Благодаря этим особенностям данные, полученные в результате применения алгоритма, или MD5-дайджест, могут служить достаточно надежным идентификатором ресурсов. Есть и третья особенность. Она состоит в том, что алгоритма обратного преобразования не существует. Поэтому MD5-дайджест может пересылаться по сети в открытом виде. Если злоумышленник и перехватит его, он не сможет восстановить исходное сообщение.

Выходные данные будут неизменными при каждом преобразовании. Можно закодировать строку на стороне клиента и передавать ее в таком виде серверу. Сервер извлечет пароль из базы, закодирует его, используя тот же алгоритм, и сравнит две строки. Если они совпадут, регистрация будет считаться успешной. Нужно заметить, что пароль в исходном виде по сети не передается.

При регистрации на сервере MD5-дайджест нельзя непосредственно передавать по Интернету. Злоумышленник не может выяснить, на основе какой исходной строки был сгенерирован дайджест, но может использовать сам дайджест в процессе регистрации. Здесь на помощь приходит механизм открытого и закрытого ключа. Вместо того чтобы кодировать один пароль, можно зашифровать его вместе с псевдослучайной последовательностью символов, предоставленной сервером. Сервер при каждой регистрации генерирует новую псевдослучайную последовательность и передает ее по сети клиенту. На уровне клиента пользователь вводит пароль, а к нему присоединяется строка, предоставленная сервером, и шифруется результат конкатенации. Переданная клиенту последовательность символов хранится на сервере. Получив от клиента идентификатор пользователя, сервер читает из базы пароль, присоединяет к нему запомненную последовательность символов, шифрует их и сравнивает результаты. При совпадении закодированных последовательностей регистрация считается успешной. В противном случае (например, если пользователь неправильно ввел пароль) процедура регистрации повторяется, но при этом уже используется другая последовательность символов.

Псевдослучайная строка выполняет роль открытого ключа и доступна для всех. Пароль можно считать закрытым ключом. Он хранится в течение длительного времени и не должен быть доступен посторонним.

1.4 Инструментарий разработки AJAX-приложений

По мере того как стиль программирования AJAX получает признание как следующий крупный шаг в области веб-разработки, вступают в действие два очевидных фактора. Во-первых, для разработчиков приложений очень важно иметь модель программирования, которая бы не слишком сильно отличалась от уже знакомых им моделей. Разработчики должны относительно быстро переходить на AJAX. Однако быстрый переход возможен только в том случае, если новая прикладная среда является расширением старой. Но, во-вторых, новая прикладная среда должна предоставлять в распоряжение разработчика широкофункциональные и эффективные готовые компоненты и службы, сводящие к минимуму влияние таких сложных и объективно существующих факторов, как написание кросс-браузерного сценарного кода, модели программирования на стороне сервера и сериализация данных. Вместо автономных библиотек - таких, как ASP.NET Script Callback и AJAX.NET (по крайней мере, в исходной версии проекта), - разработчики отдают предпочтение прикладным средам и пакетам компонентов ASP.NET, обеспечивающим расширенную поддержку AJAX.

Технология Microsoft Atlas, представленная на Конференции профессиональных разработчиков в 2005 году, представляет собой надстройку для платформы ASP.NET 2.0. Она стала одним из столпов следующей версии ASP.NET (Orcas). Atlas воплощается в форме нового семейства серверных элементов, для которых за счет использования новых runtime-функций становится возможной полная интеграция программирования на стороне клиента и сервера.

Microsoft Atlas - важное расширение платформы Microsoft ASP.NET, обеспечивающее эффективную поддержку AJAX-функциональности в приложениях. Технология Atlas проектировалась как составная часть ASP.NET, и как следствие, она полностью интегрируется с существующей платформой разработки и моделью приложений.

С архитектурной точки зрения, инфраструктура Atlas состоит из двух элементов: библиотеки клиентских сценариев и набора серверных расширений. Библиотека клиентских сценариев полностью написана на JavaScript и поэтому работает в любом современном браузере. Так как платформа Atlas является расширением ASP.NET, она полностью интегрируется с серверными службами и управляющими элементами ASP.NET. В результате разработчики могут создавать веб-страницы с расширенной функциональностью на базе Atlas, используя практически такую же методику, которая использовалась при разработке классических серверных страниц ASP .NET.

Большинство Atlas-разработчиков имеет опыт разработки ASP.NET, и как следствие, хорошо знакомы с серверной моделью разработки, основанной на элементах управления. Серверо-центрическая модель программирования Atlas является крупным шагом на пути эволюции программной модели ASP.NET. Серверные элементы Atlas чрезвычайно удобны - особенно если нет достаточной уверенности для того, чтобы создавать клиентские сценарии Atlas вручную.

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

Клиентская библиотека Atlas состоит из набора файлов JavaScript (*.js), подключаемых из клиентских страниц в случае надобности. Эти файлы *.js устанавливаются как файлы с исходным кодом при установке Atlas на компьютер разработчика. На рабочий компьютер они не копируются, потому что они также внедряются в сборку Atlas, а страницы ссылаются на все необходимые сценарные файлы как на ресурсы сборки.

Клиентская библиотека содержит объектно-ориентированные и кросс-браузерные расширения языка JavaScript, такие как классы, пространства имен, наследование и типы данных. В ней также определяется (по большей части закрытая) версия библиотеки базовых классов .NET, включающая поддержку построителей строк, регулярных выражений, таймеров и трассировки. Ключевой частью клиентской библиотеки Atlas является сетевой уровень, который берет на себя все сложности асинхронных вызовов с использованием XmlHttpRequest. Сетевой уровень позволяет клиентской странице взаимодействовать с веб-службами и вебстраницами посредством внеполосных вызовов.

Клиентская библиотека Atlas также содержит поддержку таких функций, как перетаскивание, всплывающие окна, задержка указателя мыши над объектом, а также группу элементов с поддержкой привязки данных полностью на стороне, клиента, навигации и автозаполнения. Такие элементы могут вставляться в исходный код страниц с использованием JavaScript (в дополнение к новому декларативному синтаксису XML Script).

Технология Atlas появилась как расширение ASP.NET, а ASP.NET является платформой разработки на стороне сервера. По этой причине в Atlas входит набор серверных компонентов, включая веб-службы и элементы управления. С одной стороны, вы можете программировать эти компоненты со стороны клиента и обновлять текущую страницу без полного обновления; с другой стороны, программная модель большей частью остается неизменной. В этом отношении (по крайней мере, в том, что касается базовой функциональности) срок освоения Atlas оказывается на удивление коротким.

Встроенные веб-службы Atlas предоставляют клиентским страницам набор стандартных функций ASP.NET, в числе которых профили пользователей, членство в группах, роли и глобализация. Серверные элементы Atlas выглядят как классические серверные элементы ASP.NET, но в отличие от последних они выдают дополнительный сценарный код. Код расширяет возможности элемента за счет (необязательного) использования функций, предоставленных клиентской библиотекой Atlas. Большинство элементов Atlas имеет близкие аналоги среди существующих элементов ASP.NET - таких, как кнопки, надписи, текстовые поля и элементы проверки данных. Другое важное подмножество серверных элементов Atlas выдает код JavaScript для связывания аспектов поведения клиентских сценариев с элементами разметки HTML. Код поведения находится в клиентской библиотеке. Некоторые серверные элементы позволяют управлять связыванием аспектов поведения с определенными видами разметки (например, связыванием автозалолнения с конкретным элементом TextBox).