Клиент-серверные технологии. Клиент-серверные технологии веб

Web-сервер - это совокупность аппаратно-программных средств, которая принимает HTTP-запросы от клиентов (как правило, web- браузеров) и выдает HTTP-ответы. В простом случае ответ web- сервера - это содержание расположенных на нем файлов: документов, изображений, фильмов и так далее. Такие данные называют статическими: если пользователь запросит несколько раз информацию по одному и тому же адресу, web-сервер выдаст в точности одно и то же содержимое. Для динамического подхода, то есть когда выдаваемая информация будет меняться во времени и/или зависеть от параметров запроса, одного web-сервера недостаточно. В этом случае web-сервер служит переходным звеном между клиентом и некой программной средой, формирующей содержимое HTML-страницы. И здесь напрашивается вопрос: а зачем тогда нужен web-сервер, если динамическую страницу все равно формирует приложение.

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

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

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

Все современные (полновесные ) web-серверы используют асинхронную обработку поступающих от клиентов запросов. То есть после получения запроса от клиента сервер переадресует этот запрос потоку обработчика (worker). Сам сервер при этом продолжает принимать запросы от клиентов и переадресовывать их обработчикам. Существует несколько стратегий работы с обработчиками.

• - Количество worker может быть жестко задано. При старте сервера запускается, например, 10 потоков. При получении 11-го запроса сервер выдаст клиенту ответ временно недоступен.
• - Worker могут порождаться сервером динамически в зависимости от загрузки. При этом оговаривается начальное число worker, максимально допустимое количество, минимальное и максимальное количество свободных worker.
• - Worker может быть как процессом, так и потоком. Различные процессы не взаимодействуют между собой и не могут разделять данные. В отличие от процессов, потоки имеют общее разделяемое пространство данных и могут обмениваться информацией между собой.
• - Worker-процессы могут запускаться как внутри родительского серверного процесса, так и снаружи. При последнем варианте worker могут быть распределены по разным компьютерам.
• - Worker - вне родительского сервера могут представлять собой непосредственно процессы среды web-приложения.
• - Сервер может отслеживать разные варианты распределения нагрузки между порожденными worker: равномерную или поочередную загрузку.

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

Для логического разделения, оптимального распределения нагрузки по вычислительным мощностям Worker могут запускаться и на другом (-их) компьютере (-ах), не обязательно на том же самом, где расположен сам принимающий запросы от клиентов сервер. В этом случае общение между сервером и worker происходит по определенному сетевому протоколу. Это уже не может быть HTTP, потому что вместе с полученным запросом worker передается расширенная информация об окружении сервера. В частности, в качестве такого протокола общения может применяться FastCGI.

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

БД, работающие по технологии ФАЙЛ-СЕРВЕР;

БД, работающие по технологии КЛИЕНТ-СЕРВЕР.

Файл-сервер

- Обращение к БД (запрос)
- Перекачка данных с блокировкой доступа других пользователей
- Обработка данных на компьютере пользователя

Для наглядности рассмотрим конкретные примеры. Допустим, Вам необходимо просмотреть отправленные платежные поручения за период с 19 по 25 мая на сумму 5000 рублей. Пользователю необходимо будет запустить на своем компьютере клиентское приложение, работающее в БД с платежными поручениями, и ввести нужные критерии отбора. После чего на Ваш компьютер перекачается с сервера базы данных и загрузится в оперативную память файл, содержащий все документы данного вида за весь период на любые суммы. Запущенное на компьютере пользователя клиентское приложение, работающее с БД, само проведет обработку этой информации (отсортирует их), после чего выдаст ответ (на экране появится список платежных поручений, удовлетворяющих Вашим критериям). После этого Вы выберете нужное платежное поручение и попытаетесь отредактировать (изменить) в нем одно поле - например, дату. Во время редактирования происходит блокировка источника данных, то есть всего файла, содержащего этот документ. Это означает, что файл будет либо совсем не доступен остальным пользователям, либо доступен только в режиме просмотра. Причем подобного рода захват происходит даже не на уровне записи, то есть одного документа, а заблокированным является целый файл - то есть вся таблица, содержащая аналогичные документы. Только после полной обработки этого поля и выхода из режима редактирования данный файл платежных поручений будет разблокирован от захвата пользователем. Если же данные хранятся в более объемных объектах, например, в одном файле содержатся платежные поручения и о поступлении средств, и об отправке, то еще большая часть информации будет не доступна. Вы будете работать с одним полем "дата" в одном документе - остальные сотрудники предприятия будут ждать, пока Вы не закончите.

Недостатки ФАЙЛ-СЕРВЕРНОЙ системы очевидны:

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

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

Блокировка данных при редактировании одним пользователем делает невозможной работу с этими данными других пользователей.

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

Клиент-сервер

Обработка запроса одного пользователя:
- Обращение к БД (SQL-запрос)
- Передача ответа - результата обработки




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

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

Таким образом, все вышеперечисленные недостатки ФАЙЛ-СЕРВЕРНОЙ схемы устраняются в архитектуре КЛИЕНТ-СЕРВЕР:

Массивы данных не перекачиваются по сети от сервера БД на компьютер пользователя. Требования к пропускной способности сети понижаются. Это делает возможным одновременную работу большого числа пользователей с большими объемами данных.

Обработка данных осуществляется на сервере БД, а не в компьютере пользователей. Что позволяет использовать более простые, а значит, дешевые компьютеры на клиентских местах.

Блокировки (захвата) данных одним пользователем не происходит.

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

Рассмотрев отличие ФАЙЛ-СЕРВЕРА от КЛИЕНТ-СЕРВЕРА, можно завершить рассмотрение понятия "хранилище информации". Важно подчеркнуть, что от вида используемой СУБД во многом зависит работа корпоративной системы. Совершенно очевидно, что для крупных предприятий, с большим количеством пользователей, с огромным числом записей в БД, файл-серверная схема совершенно неприемлема. С другой стороны, отличия в базах данных есть и по другим параметрам и возможностям:

типам данных, которые могут храниться в БД (числа, даты, текст, рисунки, видео, звук и т.д);

по организуемым самой БД технологиям доступа к данным в базе и уровню защиты информации от несанкционированного доступа;

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

по предоставляемым средствам и методикам анализа информации (данных), которые могут быть применены в информационной системы на основе данной БД;

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

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

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

по уровню поддержки (сервиса), предоставляемого разработчиком базы данных или его авторизованным дилером;

по наличию хороших средств создания приложений, использующих данную базу данных и т.д.

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

Клиент-серверные технологии

Почти все модели организации взаимодействия пользователя с БД построены на основе клиент-серверной технологии. Предполагается, что каждое такое приложение отличается способом распределения функций: клиентская часть отвечает за целевую обработку данных и организацию взаимодействия с пользователем, серверная часть обеспечивает хранение данных - обрабатывает запросы и посылает результаты клиенту для специальной обработки. Типовая архитектура клиент-серверной технологии представлена на рис. 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 Коммерческие социальные сети ориентированы на поддержку бизнес-транзакций и формирование доверия людей к брендам на основе учета их мнений о продукте, тем самым позволяя потребителям участвовать в продвижении продукта и расширяя их осведомленность.

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

В дальнейших уроках я планирую рассказывать о создании информационных сетей с использованием:

• контроллеров локальной сети Ethernet;
• WiFi модемов;
• GSM модемов;
• Bluetooth модемов.

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

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

Технология клиент-сервер.

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

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

Программа-клиент является инициатором запроса, который может произвести в любой момент. В отличие от сервера клиент не должен быть постоянно включен. Достаточно подключиться в момент запроса.

Итак, в общих чертах система клиент-сервер выглядит так:

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

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

Передача данных пакетами.

Технология клиент-сервер в общем случае предназначена для использования с объемными информационными сетями. От одного абонента до другого данные могут проходить сложный путь по разным физическим каналам и сетям. Путь доставки данных может меняться в зависимости от состояния отдельных элементов сети. Какие-то компоненты сети могут не работать в этот момент, тогда данные пойдут другим путем. Может изменяться время доставки. Данные могут даже пропасть, не дойти до адресата.

Поэтому простая передача данных в цикле, как мы передавали данные на компьютер в некоторых предыдущих уроках, в сложных сетях совершенно невозможна. Информация передается ограниченными порциями – пакетами. На передающей стороне информация разбивается на пакеты, а на приемной “склеивается” из пакетов в цельные данные. Объем пакетов обычно не больше нескольких килобайт.

Пакет это аналог обычного почтового письма. Он также, кроме информации, должен содержать адрес получателя и адрес отправителя.

Пакет состоит из заголовка и информационной части. Заголовок содержит адреса получателя и отправителя, а также служебную информацию, необходимую для “склейки” пакетов на приемной стороне. Сетевое оборудование использует заголовок для определения, куда передавать пакет.

Адресация пакетов.

На эту тему в интернете есть много подробной информации. Я хочу рассказать как можно ближе к практике.

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

• IP-адрес устройства;
• маску подсети;
• доменное имя;
• IP-адрес сетевого шлюза;
• MAC-адрес;
• порт.

Давайте разбираться, что это такое.

IP-адреса.

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

Каждой точке подключения устройства к сети присваивается уникальный номер – IP-адрес (Internet Protocol Address). IP-адрес присваивается не устройству (компьютеру), а интерфейсу подключения. В принципе устройства могут иметь несколько точек подключения, а значит несколько различных IP-адресов.

IP-адрес это 32х разрядное число или 4 байта. Для наглядности принято записывать его в виде 4 десятичных чисел от 0 до 255, разделенных точками. Например, IP-адрес моего сервера 31.31.196.216.

Для того чтобы сетевому оборудованию было проще выстраивать маршрут доставки пакетов в формат IP-адреса введена логическая адресация. IP-адрес разбит на 2 логических поля: номер сети и номер узла. Размеры этих полей зависят от значения первого (старшего) октета IP-адреса и разбиты на 5 групп – классов. Это так называемый метод классовой маршрутизации.

Класс A предназначен для применения в больших сетях. Класс B используется в сетях средних размеров. Класс C предназначен для сетей с небольшим числом узлов. Класс D используется для обращения к группам узлов, а адреса класса E зарезервированы.

Существуют ограничения на выбор IP-адресов. Я посчитал главными для нас следующие:

• Адрес 127.0.0.1 называется loopback и используется для тестирования программ в пределах одного устройства. Данные посланы по этому адресу не передаются по сети, а возвращаются программе верхнего уровня, как принятые.
• “Серые” адреса – это IP-адреса разрешенные только для устройств, работающих в локальных сетях без выхода в Интернет. Эти адреса никогда не обрабатываются маршрутизаторами. Их используют в локальных сетях.
  • Класс A: 10.0.0.0 – 10.255.255.255
  • Класс B: 172.16.0.0 – 172.31.255.255
  • Класс C: 192.168.0.0 – 192.168.255.255
• Если поле номера сети содержит все 0, то это означает, что узел принадлежит той же самой сети, что и узел, который отправил пакет.

Маски подсетей.

При классовом методе маршрутизации число битов адресов сети и узла в IP-адресе задается типом класса. А классов всего 5, реально используется 3. Поэтому метод классовой маршрутизации в большинстве случаях не позволяет оптимально выбрать размер сети. Что приводит к неэкономному использованию пространства IP-адресов.

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

Сетевому узлу присваивается не только IP-адрес, но и маска подсети. Она имеет такой же размер, как и IP-адрес, 32 бит. Маска подсети и определяет, какая часть IP-адреса относится к сети, а какая к узлу.

Каждый бит маски подсети соответствует биту IP-адреса в том же разряде. Единица в бите маски говорит о том, что соответствующий бит IP-адреса принадлежит сетевому адресу, а бит маски со значением 0 определяет принадлежность бита IP-адреса к узлу.

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

По сути, маска позволяет одну большую сеть разбить на несколько подсетей. Размер любой подсети (число IP-адресов) должен быть кратным степени числа 2. Т.е. 4, 8, 16 и т.д. Это условие определяется тем, что биты полей адресов сети и узлов должны идти подряд. Нельзя задать, например, 5 битов - адрес сети, затем 8 битов – адрес узла, а затем опять биты адресации сети.

Пример формы записи сети с четырьмя узлами выглядит так:

Сеть 31.34.196.32, маска 255.255.255.252

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

Сеть 31.34.196.32/30

/30 это число единиц в маске подсети. В данном примере остается два нуля, что соответствует 2 разрядам адреса узла или четырем узлам.

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

Доменное имя.

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

Любому IP-адресу может быть присвоен буквенный идентификатор, более понятный человеку. Идентификатор называется доменным именем или доменом.

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

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

Но это все не так важно. Для нас главное, что любой клиент или сервер может обратиться к DNS-серверу с DNS-запросом, т.е. с запросом о соответствии IP-адрес – доменное имя или наоборот доменное имя – IP-адрес. Если DNS-сервер обладает информацией о соответствии IP-адреса и домена, то он отвечает. Если не знает, то ищет информацию на других DNS-серверах и после этого сообщает клиенту.

Сетевые шлюзы.

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

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

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

В общем случае использование сетевого шлюза выглядит так:

• Допустим у нас система из нескольких плат Ардуино, подключенных через локальную сеть Ethernet к маршрутизатору, который в свою очередь подключен к Интернету.
• В локальной сети мы используем ”серые” IP-адреса (выше об этом написано), которые не допускают выхода в Интернет. У маршрутизатора два интерфейса: нашей локальной сети с “серым” IP-адресом и интерфейс для подключения к Интернету с ”белым” адресом.
• В конфигурации узла мы указываем адрес шлюза, т.е. “белый” IP-адрес интерфейса маршрутизатора, подключенного к Интернету.
• Теперь, если маршрутизатор получает от устройства с ”серым” адресом пакет с запросом на получение информации из Интернета, он заменяет в заголовке пакета ”серый” адрес на свой ”белый” и отправляет его в глобальную сеть. Получив из Интернета ответ, он заменяет ”белый” адрес на запомненный при запросе ”серый” и передает пакет локальному устройству.

MAC-адрес.

MAC-адрес это уникальный идентификатор устройств локальной сети. Как правило, он записывается на заводе-производителе оборудования в постоянную память устройства.

Адрес состоит из 6 байтов. Принято записывать его в шестнадцатеричной системе исчисления в следующих форматах: c4-0b-cb-8b-c3-3a или c4:0b:cb:8b:c3:3a. Первые три байта это уникальный идентификатор организации-производителя. Остальные байты называются ”Номер интерфейса” и их значение является уникальным для каждого конкретного устройства.

IP-адрес является логическим и устанавливается администратором. MAC-адрес – это физический, постоянный адрес. Именно он используется для адресации фреймов, например, в локальных сетях Ethernet. При передаче пакета по определенному IP-адресу компьютер определяет соответствующий MAC-адрес с помощью специальной ARP-таблицы. Если в таблице отсутствуют данные о MAC-адресе, то компьютер запрашивает его с помощью специального протокола. Если MAC-адрес определить не удается, то пакеты этому устройству посылаться не будут.

Порты.

С помощью IP-адреса сетевое оборудование определяет получателя данных. Но на устройстве, например сервере, могут работать несколько приложений. Для того чтобы определить какому приложению предназначены данные в заголовок добавлено еще одно число – номер порта.

Порт используется для определения процесса приемника пакета в пределах одного IP-адреса.

Под номер порта выделено 16 бит, что соответствует числам от 0 до 65535. Первые 1024 портов зарезервированы под стандартные процессы, такие как почта, веб-сайты и т.п. В своих приложениях их лучше не использовать.

Статические и динамические IP-адреса. Протокол DHCP.

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

Проблема решается применением динамических IP-адресов. Динамические адреса выдаются клиентам на ограниченное время, пока они непрерывно находятся в сети. Распределение динамических адресов происходит под управлением протокола DHCP.

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

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

Просмотр параметров сетевых устройств с помощь командной строки.

Существует много способов, как узнать IP-адрес или MAC-адрес своей сетевой карты. Самый простой – это использовать CMD команды операционной системы. Я покажу, как это делать на примере Windows 7.

В папке Windows\System32 находится файл cmd.exe. Это интерпретатор командной строки. С помощь него можно получать системную информацию и конфигурировать систему.

Открываем окно выполнить. Для этого выполняем меню Пуск -> Выполнить или нажимаем комбинацию клавиш Win + R .

Набираем cmd и нажимаем OK или Enter. Появляется окно интерпретатора команд.

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

Прежде всего, это команда ipconfig , которая отображает настройки сетевых плат.

Подробный вариант ipconfig/all .

Только MAC-адреса показывает команда getmac .

Таблицу соответствия IP и MAC адресов (ARP таблицу) показывает команда arp –a .

Проверить связь с сетевым устройством можно командой ping .

• ping доменное имя
• ping IP-адрес

Сервер моего сайта отвечает.

Основные сетевые протоколы.

Я коротко расскажу о протоколах, необходимых нам в дальнейших уроках.

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

Протокол IP.

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

IP протокол работает без установления соединений. Он просто пытается доставить пакет по указанному IP-адресу.

IP обрабатывает каждый пакет данных, как отдельную независимую единицу, не связанную с другими пакетами. Невозможно используя только IP протокол, передать значительный объем связанных данных. Например, в сетях Ethernet максимальный объем данных одного IP-пакета составляет всего 1500 байт.

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

Если во время доставки пакета произошла ошибка, и пакет был потерян, то IP не пытается заново послать пакет. Т.е. IP не гарантирует, что пакет будет доставлен.

Коротко о протоколе IP можно сказать, что:

• он доставляет небольшие (не более 1500 байт) отдельные пакеты данных между IP-адресами;
• он не гарантирует, что доставленные данные будут правильными;

Протокол TCP.

Transmission Control Protocol (протокол управления передачей) основной протокол передачи данных Интернета. Он использует способность IP протокола доставлять информацию от одного узла другому. Но в отличии от IP он:

• Позволяет переносить большие объемы информации. Разделение данных на пакеты и “склеивание” данных на приемной стороне обеспечивает TCP.
• Данные передаются с предварительной установкой соединения.
• Производит контроль целостности данных.
• В случае потери данных инициирует повторные запросы потерянных пакетов, устраняет дублирование при получении копий одного пакета.

По сути, протокол TCP снимает все проблемы доставки данных. Если есть возможность, он их доставит. Не случайно это основной протокол передачи данных в сетях. Часто используют терминологию TCP/IP сети.

Протокол UDP.

User Datagram Protokol (протокол пользовательских датаграмм) простой протокол для передачи данных без установления соединения. Данные отправляются в одном направлении без проверки готовности приемника и без подтверждения доставки. Объем данных пакета может достигать 64 кБайт, но на практике многие сети поддерживают размер данных только 1500 байт.

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

Протоколу UDP свойственно:

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

Протокол HTTP.

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

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

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

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. "Потолстевший" клиент и "толстый" сервер в клиент-серверной архитектуре с поддержкой локального кэша на стороне клиентов

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

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

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