При использовании HTML-технологии существует проблема - невозможности отслеживания последовательных запросов пользователей. Cookie является решением одной из наследственных проблем HTTP протокола. Эта проблема заключается в непостоянстве соединения между клиентом и сервером, После того, как браузер послал запрос и получил ответ, HTTP соединение закрывается, и информация о пользователе теряется. Транзакция завершается после того, как браузер сделал запрос, а сервер выдал соответствующий ответ. Сразу после этого сервер "забывает" о пользователе и каждый следующий запрос того же пользователя считает новым пользователем.
Cookie - это информация, которая хранится в браузере и каждый раз передается от клиента серверу вместе с запросом и другими заголовками (HTTP Request Headers). Таким образом, при последующих запросах сервер может получить значения переменных, установленные на посещенных ранее страницах.
Используя cookie, можно эмулировать сессию по HTTP протоколу. Принцип эмуляции сессии следующий: на первом запросе выдается соотвествующее значение cookie, а при каждом последующем запросе это значение читается из переменной окружения HTTP_COOKIE и соответствующим образом обрабатывается.
Пример: есть форма, где пользователю предлагается указать свое имя, из нее вызывается скрипт, прописывающий значение cookie в браузер пользователя. При каждом последующем заходе на основе анализа значения cookie из браузера пользователя на странице появляется либо именное приветствие (если есть установленное значение cookie), либо первоначальная форма с запросом имени пользователя (если значение cookie не установлено).
Сервер может считывать содержащуюся в cookies информацию и на основании ее анализа совершать те или иные действия. Например, в случае авторизованного доступа к чему либо через WWW в cookies сохраняется login и password в течение сессии, что позволяет пользователю не вводить их снова при запросах каждого документа, защищенного паролем.
На использовании cookies также часто строят функции оформления заказов в онлайновых магазинах. При их помощи реализуют виртуальную корзину покупателя, в которую сервер записывает информацию обо всех заказанных товарах. Пользователь просто помечает интересующие его товары, а затем оформляет покупку сразу всех отмеченных товаров.
Еще одна распространенная область использования cookies - при настройке индивидуального профиля каждого зарегистрированного пользователя.
Другая область - использование механизма cookie в рекламном бизнесе. Cookie используются для определения целевой аудитории, например, по географическому положению пользователей, отслеживания интересов пользователей, учета количества показов и проходов сквозь баннеры.
Полное описание поля Set-Cookie HTTP заголовка:
Set-Cookie: NAME=VALUE; expires=DATE; path=PATH; domain=DOMAIN NAME; secure Минимальное описание поля Set-Cookie HTTP заголовка:
Set-Cookie: NAME=VALUE;
Set-Cookie-заголовок включает выбранный Set-Cookie:, за которым следует перечень одной или более записей. Каждая запись начинается с пары NAME=VALUE, за которыми следуют ноль или больше пар "атрибут-значение", разделенных точками с запятой. Синтаксис для пар атрибут-значение приведен выше. Пара NAME=VALUE должна быть самой первой в объявлении записи. Все другие могут следовать в любом порядке. Стандарт не предусматривает поведение при неоднократном использовании одной и той же пары атрибут-значение.
expires=DATE - время хранения cookie, т.е. вместо DATE должна стоять дата в формате Wdy, DD-Mon-YYYY HH:MM:SS GMT, после которой истекает время хранения cookie. Если этот атрибут не указан, то cookie хранится в течение одного сеанса, до закрытия браузера. Использование expires не гарантирует сохранность cookie в течение заданного периода времени, поскольку браузер может удалить запись вследствие нехватки выделенного места или каких-либо других лимитов.
domain=DOMAIN_NAME - домен, для которого значение cookie действительно.
path=PATH - этот атрибут устанавливает подмножество документов, для которых действительно значание cookie. Например, указание path=/win приведет к тому, что значение cookie будет действительно для множества документов в директории /win/, в директории /wings/ и файлов в текущей директории с именами типа wind.html и windows.shtml. Если этот атрибут не указан, то значение cookie распространяется только на документы в той же директории, что и документ, в котором было установлено cookie.
secure - если стоит такой маркер, то информация cookie пересылается только через HTTPS (HTTP с использованием SSL). Если этот маркер не указан, то информация пересылается обычным способом.
Значение записи устанавливается тремя способами:
1. веб-сервером (при включении соответствующих настроек);
2. через заголовки ответа CGI-приложения (например Perl, PHP, C, Sh);
3. серез клиентский скрипт (javascript ,vbscript).
Когда запрашивается документ с HTTP сервера, браузер проверяет свои cookie на предмет соответствия домену сервера и прочей информации. В случае если найдены удовлетворяющие всем условиям значения cookie браузер посылает их серверу в виде пары имя/значение:
Cookie: NAME1=OPAQUE_STRING1; NAME2=OPAQUE_STRING2 …
В случае если cookie принимает новое значение при имеющемся уже в браузере cookie с совпадающими NAME, domain и path, старое значение заменяется новым. В остальных случаях новые cookies добавляются.
Дается понятие Интернет-приложения. Рассказывается, какие существуют типы Интернет-приложений, их архитектурные шаблоны, а также виды Web-серверов.
•Архитектурные шаблоны Интернет-приложений
Web-приложение это web-система, позволяющая пользователям реализовать доступ к бизнес-логике через браузер. Web-система это система гипермедиа, поскольку ее ресурсы связаны между собой. Термин "web" означает, что система рассматривается как набор узлов с перекрестными ссылками.
Существует четыре типа Интернет-приложений:
• Web-приложения, которые работают на сервере, передавая через Интернет данные на клиентские машины. Для их применения требуются Web-браузеры, такие, как Microsoft Internet Explorer и Netscape Navigator;
• Web-сервисы, которые позволяют приложениям обрабатывать их данные на сервере. При этом передача подлежащих обработке данных на сервер и возврат результатов осуществляется через Интернет;
• приложения с поддержкой Интернета автономные программы со встроенными механизмами, позволяющими их пользователям регистрироваться, получать обновления, а также предоставляющими доступ к справочной системе и другим вспомогательным службам через Интернет;
• одноранговые приложения автономные программы, использующие Интернет для взаимодействия с другими программными продуктами этого же типа.
Под архитектурой системы понимается высокоуровневое представление архитектурнозначимых компонентов системы. В этом смысле компонент представляет собой отдельную сущность с открытым интерфейсом. Архитектурно-значимые компоненты это те, которые входят в представление системы на самом высоком уровне. Обычно эти компоненты или их набор нельзя сгруппировать или объединить в пакет с другими аналогичными компонентами. Свойства отдельных компонентов будут зависеть от особенностей представления системы.
Существует широкий спектр продуктов и технологий, которые могут быть частью архитектуры web-приложений. Архитектурный шаблон отражает фундаментальную структурно-организационную схему программных систем. Он представляет набор предопределенных подсистем, описывает спектр их обязанностей, а также определяет правила и рекомендации для организации взаимодействия между ними.
Можно выделить следующие архитектурные шаблоны web-приложений:
1. Шаблон Thin Web Client (на основе "тонкого" Web-клиента) используется в большинстве приложений Internet и предоставляет ограниченные возможности по управлению конфигурацией клиента. В распоряжении клиента должен быть только стандартный браузер, поддерживающий формы. Все операции, связанные с бизнес-логикой, выполняются на сервере. Этот шаблон больше всего подходит для Web-приложений, в которых клиент обладает минимальными вычислительными возможностями или не может управлять своей конфигурацией.
2. Шаблон Thick Web Client (на основе "толстого" Web-клиента) предполагает, что значительная часть бизнес-логики выполняется на клиентской машине. Обычно для выполнения бизнес-логики клиентом используется DHTML, аплеты Java или управляющие элементы ActiveX. Взаимодействие с сервером также происходит через протокол HTTP.
Шаблон Web Delivery (на основе механизма Web-доставки). При взаимодействии клиента и сервера, кроме протокола HTTP, используются и другие протоколы, такие как IOOP (Internet Inter-Orb Protocol) и DCOM, которые могут применяться для поддержки системы распределенных объектов. В данном случае браузер функционирует как контейнерный модуль системы распределенных объектов.
Различают статические и активные серверы Web. Если страницы сервера содержат только статическую текстовую и мультимедийную информацию, а также гипертекстовые ссылки на другие страницы, то сервер называется статическим. Если страницы web-сервера изменяют своё содержимое в зависимости от действий пользователя, то такие серверы называют активными. Статический сервер Web не может служить основой для создания интерактивных приложений с доступом через Интернет, так как он не предусматривает никаких средств ввода и обработки запросов.
Лекция посвящена способам реализации клиентской активности. Рассказывается о клиентских сценариях JavaScript и VBScript, а также о технологии, классах и платформе Java, инструментах создания Java-приложений. Дается понятие элементов управления ActivX, технология их создания и применения, а также встраивания в страницу.
•Клиентские сценарии JavaScript
oНазначение клиентских сценариев JavaScript
oСпособы включения сценариев JavaScript в HTML-страницу
oТехнология JavaoКлассы JavaoПлатформа Java
oИнструменты создания Java-приложений
oИспользование аплетов Java для создания динамических HTML-документовoБезопасность аплетов
oВстраивание элементов управления ActiveX в страницуoОбеспечение безопасности загрузки элементов управления ActiveX
•Выбор способа реализации клиентской активности
При разработке динамических web-сайтов в большинстве случаев целесообразно разделять бизнес-логику между клиентом и сервером, чтобы добиться оптимальной производительности в условиях низкоскоростных каналов Интернета и лимитированных ресурсов Web-серверов.
Например, предварительную обработку введенных данных, отправляемых серверу, имеет смысл выполнять на стороне клиента. Это позволит исключить повторные передачи неправильно заполненных форм. Графическое представление результатов запроса также стоит выполнять на стороне клиента, что существенно сократит объем данных, передаваемых по сети.
Для реализации клиентской активности возможно применение сценариев JavaScript, VB Script, аплетов Java и элементов управления ActiveX.
⇐Class | Введение в технологии создания Интернет-узлов | Javascript⇒