Следует заметить, что как и любая классификация, наша классификация архитектур информационных систем не является абсолютно жесткой. В архитектуре любой конкретной информационной системы часто можно найти влияния нескольких общих архитектурных решений. Тем не менее, при архитектурном проектировании системы кажется полезным иметь хотя бы частично ортогонализированный архитектурный базис. В следующих частях курса мы подробно рассмотрим особенности каждой архитектуры и остановимся на методологиях и инструментально-технологических средствах, поддерживающих проектирование и разработку информационных систем в соответствующей архитектуре.
2.1. Файл-серверные приложения
По всей видимости, организация информационных систем на основе использования выделенных файл-серверов все еще является наиболее распространенной в связи с наличием большого количества персональных компьютеров разного уровня развитости и сравнительной дешевизны связывания PC в локальные сети. Чем привлекает такая организация не очень опытных в области системного программирования разработчиков информационных систем? Скорее всего, тем, что при опоре на файл-серверные архитектуры сохраняется автономность прикладного (и большей части системного) программного обеспечения , работающего на каждой PC сети. Фактически, компоненты информационной системы, выполняемые на разных PC, взаимодействуют только за счет наличия общего хранилища файлов, которое хранится на файл-сервере. В классическом случае в каждой PC дублируются не только прикладные программы, но и средства управления базами данных . Файл-сервер представляет собой разделяемое всеми PC комплекса расширение дисковой памяти (рисунок 2.1).
Не останавливаясь подробно на имеющихся на сегодняшнем рынке перспективных инструментальных средствах разработки файл-серверных приложений и не приводя анализа тенденций развития соответствующих технологий (этому посвящается третья часть курса), мы кратко перечислим основные достоинства и недостатки файл-серверных архитектур.
Конечно, основным достоинством является простота организации. Проектировщики и разработчики информационной системы находятся в привычных и комфортных условиях IBM PC в среде MS-DOS, Windows или какого-либо облегченного варианта Windows NT. Имеются удобные и развитые средства разработки графического пользовательского интерфейса, простые в использовании средства разработки систем баз данных и/или СУБД. Но во многом эта простота является кажущейся. (Как гласит русская пословица, "Простота хуже воровства", а здесь мы, как правило, имеем простоту на основе воровства программных продуктов для PC.)
Рис. 2.1. Классическое представление информационной системы в архитектуре "файл-сервер"
Во-первых, информационной системе предстоит работать с базой данных. Следовательно, эта база данных должна быть спроектирована. Почему-то часто разработчики файл-серверных приложений считают, что по причине простоты средств управления базами данных проблемой проектирования базы данных можно пренебречь. Конечно, это неправильно. База данных есть база данных. Чем качественнее она спроектирована, тем больше шансов впоследствии эффективно использовать информационную систему. Естественно, сложность проектирования базы данных определяется объективной сложностью моделируемой предметной области. Но, собственно, из чего должно следовать, что файл-серверные приложения пригодны только в простых предметных областях?
Во-вторых, как мы неоднократно подчеркивали в первой части курса, необходимыми требованиями к базе данных информационной системы являются поддержание ее целостного состояния и гарантированная надежность хранения информации. Минимальными условиями, при соблюдении которых можно удовлетворить эти требования, являются:
- наличие транзакционного управления, хранение избыточных данных (например, с применением методов журнализации), возможность формулировать ограничения целостности и проверять их соблюдение.
В принципе, файл-серверная организация, как она показана на рисунке 2.1, не противоречит соблюдению отмеченных условий. В качестве примера системы, соблюдающей выполнение этих условий, но основанной на файл-серверной архитектуре, можно привести популярный в прошлом "сервер баз данных" Informix SE.
Длинноезамечание:
Для сохранения четкости дальнейшего изложения нам необходимо несколько уточнить терминологию. Мы недаром написали "сервер баз данных" в кавычках применительно к СУБД Informix SE. При использовании этой системы копия программного обеспечения СУБД поддерживалась для каждого инициированного пользователем сеанса работы с СУБД. Грубо говоря, для каждого пользовательского процесса, взаимодействующего с базой данных создавался служебный процесс СУБД, который выполнялся на том же процессоре, что и пользовательский процесс (т. е. на стороне клиента). Каждый из этих служебных процессов вел себя фактически так, как если бы был единственным представителем СУБД. Вся синхронизация возможной параллельной работы с базой данных производилась на уровне файлов внешней памяти, содержащих базу данных. Условимся впредь называть такие СУБД не серверами баз данных, а системами управления базами данных, основанными на файл-серверной архитектуре (СУБД-ФС).
Под истинным сервером баз данных мы будем понимать программное образование, привязанное к соответствующей базе (базам) данных, существующее, вообще говоря, независимо от существования пользовательских (клиентских) процессов и выполняемое, вообще говоря (хотя и не обязательно) на выделенной аппаратуре (мы намеренно используем не очень конкретные термины "программное образование" и "выделенная аппаратура", потому что их конкретное воплощение различается в разных серверах баз данных).
Истинные серверы баз данных существенно сложнее по организации, чем СУБД-ФС, на зато обеспечивают более тонкое и эффективное управление базами данных. Везде далее в этом курсе при употреблении термина "сервер баз данных" мы будем иметь в виду истинные серверы баз данных.
Но с другой стороны, в большинстве персональных СУБД эти условия не выполняются даже с помощью грубых приемов. В лучшем случае удается частично восполнить недостатки на уровне прикладных программ.
В третьих, интерфейс развитых серверов баз данных основан на использовании высокоуровневого языка баз данных SQL, что позволяет использовать сетевой трафик между клиентом и сервером баз данных только в полезных целях (от клиента к серверу в основном пересылаются операторы языка SQL, от сервера к клиенту - результаты выполнения операторов). В файл-серверной организации клиент работает с удаленными файлами, что вызывает существенную перегрузку трафика (поскольку СУБД-ФС работает на стороне клиента, то для выборки полезных данных в общем случае необходимо просмотреть на стороне клиента весь соответствующий файл целиком).
В целом, в файл-серверной архитектуре мы имеем "толстого" клиента и очень "тонкий" сервер в том смысле, что почти вся работа выполняется на стороне клиента, а от сервера требуется только достаточная емкость дисковой памяти (рисунок 2.2).
Рис. 2.2. "Толстый" клиент и "тонкий" сервер в файл-серверной архитектуре
Краткие выводы. Простое, работающее с небольшими объемами информации и рассчитанное на применение в однопользовательском режиме, файл-серверное приложение можно спроектировать, разработать и отладить очень быстро. Очень часто для небольшой компании для ведения, например, кадрового учета достаточно иметь изолированную систему, работающую на отдельно стоящем PC. Конечно, и в этом случае требуется большая аккуратность конечных пользователей (или администраторов, наличие которых в этом случае сомнительно) для надежного хранения и поддержания целостного состояния данных. Однако, в уже ненамного более сложных случаях (например, при организации информационной системы поддержки проекта, выполняемого группой) файл-серверные архитектуры становятся недостаточными.
Клиент-серверные приложения
Под клиент-серверным приложением мы будем понимать информационную систему, основанную на использовании серверов баз данных (см. длинное замечание в конце раздела 2.1). Общее представление информационной системы в архитектуре "клиент-сервер" показано на рисунке 2.3.
- На стороне клиента выполняется код приложения, в который обязательно входят компоненты, поддерживающие интерфейс с конечным пользователем, производящие отчеты, выполняющие другие специфичные для приложения функции (пока нас не будет занимать, как строится код приложения). Клиентская часть приложения взаимодействует с клиентской частью программного обеспечения управления базами данных, которая, фактически, является индивидуальным представителем СУБД для приложения.
(Здесь опять проявляются недостатки в терминологии. Обычно, когда компания объявляет о выпуске очередного сервера баз данных, то неявно понимается, что имеется и клиентская составляющая этого продукта. Сочетание "клиентская часть сервера баз данных" кажется несколько странным, но нам придется пользоваться именно этим термином.)
Рис. 2.3. Общее представление информационной системы в архитектуре "клиент-сервер"
Заметим, что интерфейс между клиентской частью приложения и клиентской частью сервера баз данных, как правило, основан на использовании языка SQL. Поэтому такие функции, как, например, предварительная обработка форм, предназначенных для запросов к базе данных, или формирование результирующих отчетов выполняются в коде приложения.
Наконец, клиентская часть сервера баз данных, используя средства сетевого доступа, обращается к серверу баз данных, передавая ему текст оператора языка SQL.
Здесь необходимо сделать еще два замечания.
Обычно компании, производящие развитые серверы баз данных, стремятся к тому, чтобы обеспечить возможность использования своих продуктов не только в стандартных на сегодняшний день TCP/IP-ориентированных сетях, но в сетях, основанных на других протоколах (например, SNA или IPX/SPX). Поэтому при организации сетевых взаимодействий между клиентской и серверной частями СУБД часто используются не стандартные средства высокого уровня (например, механизмы программных гнезд или вызовов удаленных процедур), а собственные функционально подобные средства, менее зависящие от особенностей сетевых транспортных протоколов. Когда мы говорим об интерфейсе на основе языка SQL, нужно отдавать себе отчет в том, что несмотря на титанические усилия по стандартизации этого языка, нет такой реализации, в которой стандартные средства языка не были бы расширены. Необдуманное использование расширений языка приводит к полной зависимости приложения от конкретного производителя сервера баз данных.
Посмотрим теперь, что же происходит на стороне сервера баз данных. В продуктах практически всех компаний сервер получает от клиента текст оператора на языке SQL.
- Сервер производит компиляцию полученного оператора. Не будем здесь останавливаться на том, какой целевой язык используется конкретным компилятором; в разных реализациях применяются различные подходы (примеры см. в части 4). Главное, что в любом случае на основе информации, содержащейся в таблицах-каталогах базы данных производится преобразование непроцедурного представления оператора в некоторую процедуру его выполнения. Далее (если компиляция завершилась успешно) происходит выполнение оператора. Мы снова не будем обсуждать технические детали, поскольку они различаются в реализациях. Рассмотрим возможные действия операторов SQL.
- Оператор может относиться к классу операторов определения (или создания) объектов базы данных (точнее и правильнее было бы говорить про элементы схемы базы данных или про объекты метабазы данных). В частности, могут определяться домены, таблицы, ограничения целостности, триггеры, привилегии пользователей, хранимые процедуры. В любом случае, при выполнении оператора создания элемента схемы базы данных соответствующая информация помещается в таблицы-каталоги базы данных (в таблицы метабазы данных). Ограничения целостности обычно сохраняются в метабазе данных прямо в текстовом представлении. Для действий, определенных в триггерах, и хранимых процедур вырабатывается и сохраняется в таблицах-каталогах процедурный выполняемый код. Заметим, что ограничения целостности, триггеры и хранимые процедуры являются, в некотором смысле, представителями приложения в поддерживаемой сервером базе данных; они составляют основу серверной части приложения (см. ниже). При выполнении операторов выборки данных на основе содержимого затрагиваемых запросом таблиц и, возможно, с использованием поддерживаемых в базе данных индексов формируется результирующий набор данных (мы намеренно не используем здесь термин "результирующая таблица", поскольку в зависимости от конкретного вида оператора результат может быть упорядоченным, а таблицы, т. е. отношения неупорядочены по определению). Серверная часть СУБД пересылает результат клиентской части, и окончательная обработка производится уже в клиентской части приложения. При выполнении операторов модификации содержимого базы данных (INSERT, UPDATE, DELETE) проверяется, что не будут нарушены определенные к этому моменту ограничения целостности (те, которые относятся к классу немедленно проверяемых), после чего выполняется соответствующее действие (сопровождаемое модификацией всех соответствующих индексов и журнализацией изменений). Далее сервер проверяет, не затрагивает ли данное изменение условие срабатывания какого-либо триггера, и если такой триггер обнаруживается, выполняет процедуру его действия. Эта процедура может включать дополнительные операторы модификации базы данных, которые могут вызвать срабатывание других триггеров и т. д. Можно считать, что те действия, которые выполняются на сервере баз данных при проверке удовлетворенности ограничений целостности и при срабатывании триггеров, представляют собой действия серверной части приложения. При выполнении операторов модификации схемы базы данных (добавления или удаления столбцов существующих таблиц, изменения типа данных существующего столбца существующей таблицы и т. д.) также могут срабатывать триггеры, т. е., другими словами, может выполняться серверная часть приложения. Аналогично, триггеры могут срабатывать при уничтожении объектов схемы базы данных (доменов, таблиц, ограничений целостности и т. д.). Особый класс операторов языка SQL составляют операторы вызова ранее определенных и сохраненных в базе данных хранимых процедур. Если хранимая процедура определяется с помощью достаточно развитого языка, включающего и непроцедурные операторы SQL, и чисто процедурные конструкции (например, языка PL/SQL компании Oracle), то в такую процедуру можно поместить серьезную часть приложения, которое при выполнении оператора вызова процедуры будет выполняться на стороне сервера, а не на стороне клиента. При выполнении оператора завершения транзакции сервер должен проверить соблюдение всех, так называемых, отложенных ограничений целостности (к таким ограничениям относятся ограничения, накладываемые на содержимое таблицы базы целиком или на несколько таблиц одновременно; например, суммарная зарплата сотрудников отдела 999 не должна превышать 150 млн. руб.). Снова к проверке отложенных ограничений целостности можно относиться как к выполнению серверной части приложения.
Как видно, в клиент-серверной организации клиенты могут являться достаточно "тонкими", а сервер должен быть "толстым" настолько, чтобы быть в состоянии удовлетворить потребности всех клиентов (рисунок 2.4).
Рис. 2.4. "Тонкий" клиент и "толстый" сервер в клиент-серверной архитектуре
С другой стороны, разработчики и пользователи информационных систем, основанных на архитектуре "клиент-сервер", часто бывают неудовлетворены постоянно существующими сетевыми накладными расходами , которые следуют из потребности обращаться от клиента к серверу с каждым очередным запросом. На практике распространена ситуация, когда для эффективной работы отдельной клиентской составляющей информационной системы в действительности требуется только небольшая часть общей базы данных. Это приводит к идее поддержки локального кэша общей базы данных на стороне каждого клиента.
Фактически, концепция локального кэширования базы данных является частным случаем концепции реплицированных (или, как иногда их называют в русскоязычной литературе, тиражированных) баз данных. Как и в общем случае, для поддержки локального кэша базы данных программное обеспечение рабочих станций должно содержать компонент управления базами данных - упрощенный вариант сервера баз данных, который, например, может не обеспечивать многопользовательский режим доступа. Отдельной проблемой является обеспечение согласованности (когерентности) кэшей и общей базы данных. Здесь возможны различные решения - от автоматической поддержки согласованности за счет средств базового программного обеспечения управления базами данных до полного перекладывания этой задачи на прикладной уровень. В любом случае, клиенты становятся более толстыми при том, что сервер тоньше не делается (рисунок 2.5).
Рис. 2.5. "Потолстевший" клиент и "толстый" сервер в клиент-серверной архитектуре с поддержкой локального кэша на стороне клиентов
Сформулируем некоторые предварительные выводы. Архитектура "клиент-сервер" на первый взгляд кажется гораздо более дорогой, чем архитектура "файл-сервер". Требуется более мощная аппаратура (по крайней мере, для сервера) и существенно более развитые средства управления базами данных. Однако, это верно лишь частично. Громадным преимуществом клиент-серверной архитектуры является ее масштабируемость и вообще способность к развитию.
При проектировании информационной системы, основанной на этой архитектуре, большее внимание следует обращать на грамотность общих решений. Технические средства пилотной версии могут быть минимальными (например, в качестве аппаратной основы сервера баз данных может использоваться одна из рабочих станций). После создания пилотной версии нужно провести дополнительную исследовательскую работу, чтобы выяснить узкие места системы. Только после этого необходимо принимать решение о выборе аппаратуры сервера, которая будет использоваться на практике.
Увеличение масштабов информационной системы не порождает принципиальных проблем. Обычным решением является замена аппаратуры сервера (и, может быть, аппаратуры рабочих станций, если требуется переход к локальному кэшированию баз данных). В любом случае практически не затрагивается прикладная часть информационной системы. В идеале, которого, конечно же не бывает, информационная система продолжает нормально функционировать после смены аппаратуры.
Цель лекции: показать, каким образом в веб-технологиях реализуются общие принципы клиент-серверных технологий. Рассмотреть ключевые элементы базового протокола HTTP.
Предметом данного курса являются технологии глобальной сети World Wide Web (сокращенно WWW или просто Web). На русском языке распространенным вариантом является название "Веб".
В частности, в рамках курса будут рассмотрены такие вопросы как: базовые стандарты и протоколы сети Веб, языки разметки и программирования веб-страниц, инструменты разработки и управления веб-контента и приложений для Веб, средства интеграции веб-контента и приложений в Веб.
Сеть Веб представляет собой глобальное информационное пространство, основанное на физической инфраструктуре Интернета и протоколе передачи данных HTTP. Зачастую, говоря об Интернете, подразумевают именно сеть Веб .
Клиент-серверные технологии Веб
Базовым протоколом сети гипертекстовых ресурсов Веб является протокол HTTP. В его основу положено взаимодействие "клиент-сервер ", то есть предполагается, что:
Потребитель-клиент инициировав соединение с поставщиком-сервером посылает ему запрос;
Поставщик-сервер , получив запрос, производит необходимые действия и возвращает обратно клиенту ответ с результатом.
При этом возможны два способа организации работы компьютера-клиента:
Тонкий клиент - это компьютер-клиент, который переносит все задачи по обработке информации на сервер. Примером тонкого клиента может служить компьютер с браузером, использующийся для работы с веб-приложениями.
Толстый клиент , напротив, производит обработку информации независимо от сервера, использует последний в основном лишь для хранения данных.
Прежде чем перейти к конкретным клиент-серверным веб-технологиям, рассмотрим основные принципы и структуру базового протокола HTTP.
Протокол http
HTTP (HyperText Transfer Protocol - RFC 1945, RFC 2616) - протокол прикладного уровня для передачи гипертекста.
Центральным объектом в HTTP является ресурс , на который указывает URI в запросе клиента. Обычно такими ресурсами являются хранящиеся на сервере файлы. Особенностью протокола HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и т. д. Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя изначально данный протокол предназначен для передачи символьной информации. На первый взгляд это может показаться излишней тратой ресурсов. Действительно, данные в символьном виде занимают больше памяти, сообщения создают дополнительную нагрузку на каналы связи, однако подобный формат имеет много преимуществ. Сообщения, передаваемые по сети, удобочитаемы, и, проанализировав полученные данные, системный администратор может легко найти ошибку и устранить ее. При необходимости роль одного из взаимодействующих приложений может выполнять человек, вручную вводя сообщения в требуемом формате.
В отличие от многих других протоколов, HTTP является протоколом без памяти. Это означает, что протокол не хранит информацию о предыдущих запросах клиентов и ответах сервера. Компоненты, использующие HTTP, могут самостоятельно осуществлять сохранение информации о состоянии, связанной с последними запросами и ответами. Например, клиентское веб-приложение, посылающее запросы, может отслеживать задержки ответов, а веб-сервер может хранить IP-адреса и заголовки запросов последних клиентов.
Всё программное обеспечение для работы с протоколом HTTP разделяется на три основные категории:
Серверы - поставщики услуг хранения и обработки информации (обработка запросов).
Клиенты - конечные потребители услуг сервера (отправка запросов).
Прокси-серверы для поддержки работы транспортных служб.
"Классическая" схема HTTP-сеанса выглядит так.
Установление TCP-соединения.
Запрос клиента.
Ответ сервера.
Разрыв TCP-соединения.
Таким образом, клиент посылает серверу запрос, получает от него ответ, после чего взаимодействие прекращается. Обычно запрос клиента представляет собой требование передать HTML-документ или какой-нибудь другой ресурс, а ответ сервера содержит код этого ресурса.
В состав HTTP-запроса, передаваемого клиентом серверу, входят следующие компоненты.
Строка состояния (иногда для ее обозначения используют также термины строка-статус, или строка запроса).
Поля заголовка.
Пустая строка.
Тело запроса.
Строку состояния вместе с полями заголовка иногда называют также заголовком запроса .
Рис. 1.1. Структура запроса клиента.
Строка состояния имеет следующий формат:
метод_запроса URL_pecypca версия_протокола_НТТР
Рассмотрим компоненты строки состояния, при этом особое внимание уделим методам запроса.
Метод , указанный в строке состояния, определяет способ воздействия на ресурс, URL которого задан в той же строке. Метод может принимать значения GET, POST, HEAD, PUT, DELETE и т.д. Несмотря на обилие методов, для веб-программиста по-настоящему важны лишь два из них: GET и POST.
GET. Согласно формальному определению, метод GET предназначается для получения ресурса с указанным URL. Получив запрос GET, сервер должен прочитать указанный ресурс и включить код ресурса в состав ответа клиенту. Ресурс, URL которого передается в составе запроса, не обязательно должен представлять собой HTML-страницу, файл с изображением или другие данные. URL ресурса может указывать на исполняемый код программы, который, при соблюдении определенных условий, должен быть запущен на сервере. В этом случае клиенту возвращается не код программы, а данные, сгенерированные в процессе ее выполнения. Несмотря на то что, по определению, метод GET предназначен для получения информации, он может применяться и в других целях. Метод GET вполне подходит для передачи небольших фрагментов данных на сервер.
POST. Согласно тому же формальному определению, основное назначение метода POST - передача данных на сервер. Однако, подобно методу GET, метод POST может применяться по-разному и нередко используется для получения информации с сервера. Как и в случае с методом GET, URL, заданный в строке состояния, указывает на конкретный ресурс. Метод POST также может использоваться для запуска процесса.
Методы HEAD и PUT являются модификациями методов GET и POST.
Версия протокола HTTP , как правило, задается в следующем формате:
HTTP/версия.модификация
Поля заголовка , следующие за строкой состояния, позволяют уточнять запрос, т.е. передавать серверу дополнительную информацию. Поле заголовка имеет следующий формат:
Имя_поля: Значение
Назначение поля определяется его именем, которое отделяется от значения двоеточием.
Имена некоторых наиболее часто встречающихся в запросе клиента полей заголовка и их назначение приведены в табл. 1.1 .
Таблица 1.1. Поля заголовка запроса HTTP. |
|
Поля заголовка HTTP-запроса |
Значение |
Доменное имя или IP-адрес узла, к которому обращается клиент |
|
URL документа, который ссылается на ресурс, указанный в строке состояния |
|
Адрес электронной почты пользователя, работающего с клиентом |
|
MIME-типы данных, обрабатываемых клиентом. Это поле может иметь несколько значений, отделяемых одно от другого запятыми. Часто поле заголовка Accept используется для того, чтобы сообщить серверу о том, какие типы графических файлов поддерживает клиент |
|
Набор двухсимвольных идентификаторов, разделенных запятыми, которые обозначают языки, поддерживаемые клиентом |
|
Перечень поддерживаемых наборов символов |
|
MIME-тип данных, содержащихся в теле запроса (если запрос не состоит из одного заголовка) |
|
Число символов, содержащихся в теле запроса (если запрос не состоит из одного заголовка) |
|
Присутствует в том случае, если клиент запрашивает не весь документ, а лишь его часть |
|
Используется для управления TCP-соединением. Если в поле содержится Close, это означает, что после обработки запроса сервер должен закрыть соединение. Значение Keep-Alive предлагает не закрывать TCP-соединение, чтобы оно могло быть использовано для последующих запросов |
|
Информация о клиенте |
Во многих случаях при работе в Веб тело запроса отсутствует. При запуске CGI-сценариев данные, передаваемые для них в запросе, могут размещаться в теле запроса.
Ниже представлен пример HTML-запроса, сгенерированного браузером
GET http://oak.oakland.edu/ HTTP/1.0
Connection: Keep-Alive
User-Agent: Mozilla/4.04 (Win95; I)
Host: oak.oakland.edu
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
Accept-Language: en
Accept-Charset: iso-8859-l,*,utf-8
Получив от клиента запрос, сервер должен ответить ему. Знание структуры ответа сервера необходимо разработчику веб-приложений, так как программы, которые выполняются на сервере, должны самостоятельно формировать ответ клиенту.
Подобно запросу клиента, ответ сервера также состоит из четырех перечисленных ниже компонентов.
Строка состояния.
Поля заголовка.
Пустая строка.
Тело ответа.
Ответ сервера клиенту начинается со строки состояния, которая имеет следующий формат:
Версия_протокола Код_ответа Пояснительное_сообщение
Версия_протокола задается в том же формате, что и в запросе клиента, и имеет тот же смысл.
Код_ответа - это трехзначное десятичное число, представляющее в закодированном виде результат обслуживания запроса сервером.
Пояснительное_сообщение дублирует код ответа в символьном виде. Это строка символов, которая не обрабатывается клиентом. Она предназначена для системного администратора или оператора, занимающегося обслуживанием системы, и является расшифровкой кода ответа.
Из трех цифр, составляющих код ответа, первая (старшая) определяет класс ответа, остальные две представляют собой номер ответа внутри класса. Так, например, если запрос был обработан успешно, клиент получает следующее сообщение:
HТТР/1.0 200 ОК
Как видно, за версией протокола HTTP 1.0 следует код 200. В этом коде символ 2 означает успешную обработку запроса клиента, а остальные две цифры (00) - номер данного сообщения.
В используемых в настоящее время реализациях протокола HTTP первая цифра не может быть больше 5 и определяет следующие классы ответов.
1 - специальный класс сообщений, называемых информационными. Код ответа, начинающийся с 1, означает, что сервер продолжает обработку запроса. При обмене данными между HTTP-клиентом и HTTP-сервером сообщения этого класса используются достаточно редко.
2 - успешная обработка запроса клиента.
3 - перенаправление запроса. Чтобы запрос был обслужен, необходимо предпринять дополнительные действия.
4 - ошибка клиента. Как правило, код ответа, начинающийся с цифры 4, возвращается в том случае, если в запросе клиента встретилась синтаксическая ошибка.
5 - ошибка сервера. По тем или иным причинам сервер не в состоянии выполнить запрос.
Примеры кодов ответов, которые клиент может получить от сервера, и поясняющие сообщения приведены в табл. 1.2.
Таблица 1.2. Классы кодов ответа сервера. |
||
Расшифровка |
Интерпретация |
|
Часть запроса принята, и сервер ожидает от клиента продолжения запроса |
||
Запрос успешно обработан, и в ответе клиента передаются данные, указанные в запросе |
||
В результате обработки запроса был создан новый ресурс |
||
Запрос принят сервером, но обработка его не окончена. Данный код ответа не гарантирует, что запрос будет обработан без ошибок. |
||
Partial Content |
Сервер возвращает часть ресурса в ответ на запрос, содержавший поле заголовка Range |
|
Multiple Choice |
Запрос указывает более чем на один ресурс. В теле ответа могут содержаться указания на то, как правильно идентифицировать запрашиваемый ресурс |
|
Moved Permanently |
Затребованный ресурс больше не располагается на сервере |
|
Moved Temporarily |
Затребованный ресурс временно изменил свой адрес |
|
В запросе клиента обнаружена синтаксическая ошибка |
||
Имеющийся на сервере ресурс недоступен для данного пользователя |
||
Ресурс, указанный клиентом, на сервере отсутствует |
||
Method Not Allowed |
Сервер не поддерживает метод, указанный в запросе |
|
Internal Server Error |
Один из компонентов сервера работает некорректно |
|
Not Implemented |
Функциональных возможностей сервера недостаточно, чтобы выполнить запрос клиента |
|
Service Unavailable |
Служба временно недоступна |
|
HTTP Version not Supported |
Версия HTTP, указанная в запросе, не поддерживается сервером |
В ответе используется такая же структура полей заголовка, как и в запросе клиента. Поля заголовка предназначены для того, чтобы уточнить ответ сервера клиенту. Описание некоторых из полей, которые можно встретить в заголовке ответа сервера, приведено в табл. 1.3.
Таблица 1.3. Поля заголовка ответа веб-сервера. |
|
Имя поля |
Описание содержимого |
Имя и номер версии сервера |
|
Время в секундах, прошедшее с момента создания ресурса |
|
Список методов, допустимых для данного ресурса |
|
Content-Language |
Языки, которые должен поддерживать клиент для того, чтобы корректно отобразить передаваемый ресурс |
MIME -тип данных, содержащихся в теле ответа сервера |
|
Число символов, содержащихся в теле ответа сервера |
|
Дата и время последнего изменения ресурса |
|
Дата и время, определяющие момент генерации ответа |
|
Дата и время, определяющие момент, после которого информация, переданная клиенту, считается устаревшей |
|
В этом поле указывается реальное расположение ресурса. Оно используется для перенаправления запроса |
|
Директивы управления кэшированием. Например, no-cache означает, что данные не должны кэшироваться |
В теле ответа содержится код ресурса, передаваемого клиенту в ответ на запрос. Это не обязательно должен быть HTML-текст веб-страницы. В составе ответа могут передаваться изображение, аудио-файл, фрагмент видеоинформации, а также любой другой тип данных, поддерживаемых клиентом. О том, как следует обрабатывать полученный ресурс, клиенту сообщает содержимое поля заголовка Content-type.
Ниже представлен пример ответа сервера на запрос, приведенный в предыдущем разделе. В теле ответа содержится исходный текст HTML-документа.
Server: Microsoft-IIS/5.1
X-Powered-By: ASP.NET
Content-Type: text/html
Accept-Ranges: bytes
ETag: "b66a667f948c92:8a5"
Content-Length: 426
Клиент-серверные технологии
Почти все модели организации взаимодействия пользователя с БД построены на основе клиент-серверной технологии. Предполагается, что каждое такое приложение отличается способом распределения функций: клиентская часть отвечает за целевую обработку данных и организацию взаимодействия с пользователем, серверная часть обеспечивает хранение данных - обрабатывает запросы и посылает результаты клиенту для специальной обработки. Типовая архитектура клиент-серверной технологии представлена на рис. 4.1:
Рис. 4.1. Типовая архитектура клиент-серверной технологии
Часть функций центральных ЭВМ взяли на себя локальные компьютеры. Любое программное приложение в этом случае представляется из трех компонентов: компонент представления, реализующий интерфейс с пользователем; прикладной компонент, обеспечивающий выполнение прикладных функций; компонент доступа к информационным ресурсам (менеджер ресурсов), выполняющий накопление информации и управление данными.
На основе распределения этих компонентов между рабочей станцией и сервером сети выделяют модели архитектуры «клиент-сервер»:
· модель доступа к удаленным данным (рис. 4.2). На сервере расположены только данные:
Рис. 4.2. Модель доступа к удаленным данным
Данная модель характеризуется невысокой производительностью, так как вся информация обрабатывается на рабочих станциях; кроме того, поддерживается низкая скорость обмена при передаче больших объемов информации с сервера на рабочие станции;
· модель сервера управления данными (рис. 4.3):
Рис. 4.3. Модель сервера управления данными
Особенности данной модели: уменьшение объемов информации, передаваемых по сети, так как выборка необходимых информационных элементов осуществляется на сервере, а не на рабочих станциях; унификация и широкий выбор средств создания приложений; отсутствие четкого разграничения между компонентом представления и прикладным компонентом, что затрудняет совершенствование вычислительной системы. Целесообразно использовать в случае обработки умеренных объемов информации, при этом сложность прикладного компонента должна быть невысокой,
· модель комплексного сервера (рис. 4.4):
Рис. 4.4. Модель комплексного сервера
Преимущества модели: высокая производительность, централизованное администрирование, экономия ресурсов сети. Такой сервер оптимален для крупных сетей, ориентированных на обработку больших и увеличивающихся со временем объемов информации;
· трехзвенная архитектура «клиент-сервер» (рис. 4.5). Используется при усложнении и увеличении ресурсоемкости прикладного компонента.
Рис. 4.5. Трехзвенная архитектура
В сервере приложений могут быть реализованы несколько прикладных функций, каждая из которых оформляется как отдельная служба, предоставляющая некоторые услуги всем программам. Таких серверов может быть несколько, каждый из них ориентирован на предоставление некоторого набора услуг. Данная архитектура базируется на дальнейшей специализации компонентов архитектуры: клиент занимается только организацией интерфейса с пользователем, сервер БД выполняет только стандартную обработку данных, для реализации логики обработки данных архитектура предусматривает отдельный слой - слой бизнес-логики, он может представлять собой либо выделенный сервер (сервер приложений), либо размещаться на клиенте в качестве библиотеки.
В рамках архитектуры «клиент-сервер» существуют два основных понятия:
· «тонкий» клиент. Используется мощный сервер БД и библиотека хранимых процедур, позволяющих производить вычисления, реализующие основную логику обработки данных, непосредственно на сервере. Клиентское приложение, соответственно, предъявляет невысокие требования к аппаратному обеспечению рабочей станции;
· «толстый» клиент реализует основную логику обработки на клиенте, а сервер представляет собой в чистом виде сервер БД, обеспечивающий исполнение только стандартных запросов на манипуляцию с данными (как правило - чтение, запись, модификацию данных в таблицах реляционной БД).
Сетевые ИТ
Электронная почта . Возникшая самой первой, эта форма обмена электронными сообщениями (e-mail) продемонстрировала саму возможность практически мгновенного общения посредством компьютерных сетей. Архитектурно предназначенная для обмена сообщениями между двумя абонентами, она позволила обмениваться информацией группам людей. Такой модификацией стали группы или списки рассылки. С помощью ПО для работы с электронной почтой можно создавать электронные сообщения и делать вложения в них. Функция вложения используется для отправки по почте документов любого типа, например текстовых документов, электронных таблиц, мультимедиа файлов, файлов БД и т.д. Разработанное позже ПО для фильтрации текста расширило возможности электронной почты, чтобы помочь пользователю в структурировании, направлении и фильтрации сообщений. Потребность в этих услугах обусловлена тем, что постоянно растет количество почты, которая почти или совсем не нужна пользователю (Spam). ПО для фильтрации может обеспечивать доставку пользователям только персональных сообщений, содержащих важные для них новости, а также помогает находить информацию, необходимую пользователям в процессе принятия решений.
Телеконференции или группы новостей . Телеконференции - следующий этап развития систем общения. Их особенностями стали, во-первых, хранение сообщений и предоставление заинтересованным лицам доступа ко всей истории обмена, а во-вторых, различные способы тематической группировки сообщений. Такие системы проведения конференций дают возможность группе совместно работающих, но территориально разделенных людей обмениваться в режиме on-line мнениями, идеями или информацией при обсуждении какого-либо вопроса, преодолев временные и пространственные барьеры. В настоящее время существует масса разновидностей систем проведения конференций, включая компьютерные конференции (совещания, проводимые с помощью электронной почты), селекторные совещания с возможностью подключения мобильных абонентов, конференции с использованием настольных ПК, средств мультимедиа, теле- и видеоконференции.
Интерактивное общение (чаты). С развитием телекоммуникаций все большее количество пользователей начинают работать в Интернете в режиме постоянного присутствия, поэтому появился сервис общения в режиме реального времени, когда абонент получает сообщение в течение незначительного промежутка времени после отправки его собеседником.
Наиболее распространенными современными средствами интерактивного общения являются Web-приложения, которые поддерживают следующие формы организации общения:
o Гостевые книги. Первая и самая простая форма. Простейшая гостевая книга представляет собой список сообщений, показанных от последних к первым, каждое из которых оставлено в ней каким-либо посетителем.
o Форумы . Первые форумы появились как усовершенствование гостевых книг и организовывали сообщения в ветви - как в телеконференциях. Сообщения пользователей в форумах группируются по темам, которые задаются, как правило, первыми сообщениями. Все посетители могут увидеть тему и разместить свое сообщение - в ответ на уже написанные. Темы группируются в тематические форумы, управление системой осуществляют неформальные администраторы и модераторы. Наиболее развитые форумы начинают обладать первыми признаками социальных сетей - между участниками могут быть установлены долговременные социальные связи по интересам.
o Блоги (Web Log - Web-журнал, Web-протокол). В этих сервисах каждый участник ведет собственный журнал - оставляет записи в хронологическом порядке. Темы записей могут быть любыми, самый распространенный подход - это ведение блога как собственного дневника. Другие посетители могут оставлять комментарии на эти записи. В этом случае пользователь, помимо возможности вести свой журнал, получает возможность организовывать листинговый просмотр - список записей из журналов «друзей», регулировать доступ к записям, искать себе собеседников по интересам. На базе таких систем создаются сообщества по интересам - журналы, которые ведутся коллективно. В таком сообществе его членом может быть свободно размещено любое сообщение по направлению деятельности сообщества.
В целом все современные системы обеспечения работы сетевых сообществ обладают несколькими общими чертами:
· В подавляющем большинстве сообществ предусматривается регистрация пользователей, т.е. на каждого участника должна быть заведена учетная запись. При регистрации пользователь указывает некоторую информацию о себе для идентификации. Почти все системы требуют ввода адреса электронной почты и проверяют его работоспособность, высылая письмо с кодом активации учетной записи. Если адрес неверен, то активировать запись может только администратор системы. Такой подход гарантирует до определенной степени уникальность участника и его идентифицируемость.
· Работа в среде проводится сеансами. Каждый сеанс начинается с того, что пользователь указывает свое имя и подтверждает свою личность вводом пароля. Для удобства сеансовость участия обычно скрывается от пользователя техническими средствами, но, тем не менее, идентификация пользователя происходит постоянно.
· Помимо учетных данных, пользователь настраивает окружение - внешний вид, дополнительные данные о себе, указывает свои интересы, желательные контакты, темы для общения и т.д.
· Социальные сети и поддерживающие их сервисы оказались чрезвычайно эффективным методом обеспечения посещаемости сайтов, обратной связи, они постепенно стали одним из средств наполнения контента сайта содержимым, имеющим реальную коммерческую и социальную ценность.
На основе последнего подхода появилось и быстро набрало популярность довольно большое количество социальных Web-сервисов, объединенных общим названием сервисы Web 2.0. Можно указать некоторые такие ресурсы:
o Социальные закладки . Некоторые веб-сайты позволяют пользователям предоставлять в распоряжение других список закладок или популярных веб-сайтов. Такие сайты также могут использоваться для поиска пользователей с общими интересами. Пример: Delicious.
o Социальные каталоги напоминают социальные закладки, но ориентированы на использование в академической сфере, позволяя пользователям работать с БД цитат из научных статей. Примеры: Academic Search Premier, LexisNexis Academic University, CiteULike, Connotea.
o Социальные библиотеки представляют собой приложения, позволяющие посетителям оставлять ссылки на их коллекции, книги, аудиозаписи, доступные другим. Предусмотрена поддержка системы рекомендаций и рейтингов. Примеры: discogs.com, IMDb.com.
o Многопользовательские сетевые игры имитируют виртуальные миры с различными системами подсчета очков, уровней, состязательности, победителей и проигравших. Пример: World of Warcraft.
o Многоязычные социальные сети позволяют налаживать социальные связи между людьми, говорящими на разных языках. При этом используется специальное ПО, позволяющее переводить фразы с одного языка на другой в режиме реального времени. Примеры: Dudu.
o Геосоциальные сети формируют социальные связи на основании географического положения пользователя. При этом используются различные инструменты геолокации (например, GPS или гибридные системы типа технологии AlterGeo), которые дают возможность определять текущее местонахождение того или иного пользователя и соотносить его позицию в пространстве с расположением различных мест и людей вокруг.
o Профессиональные социальные сети создаются для общения на профессиональные темы, обмена опытом и информацией, поиска и предложения вакансий, развития деловых связей. Примеры: Доктор на работе, Профессионалы.ру, MyStarWay.com, LinkedIn, MarketingPeople, Viadeo.
o Сервисные социальные сети позволяют пользователям объединяться в online режиме вокруг общих для них интересов, увлечений или по различным поводам. Например, некоторые сайты предоставляют сервисы, с помощью которых пользователи могут размещать для общего доступа персональную информацию, необходимую для поиска партнеров. Примеры: LinkedIn, ВКонтакте.
o Коммерческие социальные сети ориентированы на поддержку бизнес-транзакций и формирование доверия людей к брендам на основе учета их мнений о продукте, тем самым позволяя потребителям участвовать в продвижении продукта и расширяя их осведомленность.