Михаил Альперович , Microsoft Certified Systems Engineer
Первоисточник: http://www.ci.ru/inform2_97/astr1.htm
Введение
О технологии клиент-сервер написано уже очень много. Можно заметить, что некий ажиотаж вокруг этой темы, имевший место еще два года назад, теперь определенно спал. Статьи в прессе и разговоры в кулуарах приобрели спокойный, деловой тон и обсуждают теперь, как правило, конкретные аспекты применения этой технологии. Вопроса "Быть или не быть архитектуре клиент-сервер?" теперь уже никто не поднимает - все знают, что "Быть!".
Однако многие читатели, возможно, только недавно стали интересоваться этой темой, поэтому, на наш взгляд, стоит еще раз к ней вернуться и спокойно, по-деловому, обсудить - что такое архитектура клиент-сервер, зачем она нужна и как к ней подступиться.
Что такое архитектура клиент-сервер?
Вообще говоря, клиент-серверная система характеризуется наличием двух взаимодействующих самостоятельных процессов - клиента и сервера, которые, в общем случае, могут выполняться на разных компьютерах, обмениваясь данными по сети. По такой схеме могут быть построены системы обработки данных на основе СУБД, почтовые и другие системы. Мы будем говорить, конечно, о базах данных и системах на их основе. И здесь удобнее будет не просто рассматривать клиент-серверную архитектуру, а сравнить ее с другой - файл-серверной.
В файл-серверной системе данные хранятся на файловом сервере (например, Novell NetWare или Windows NT Server), а их обработка осуществляется на рабочих станциях, на которых, как правило, функционирует одна из, так называемых, "настольных СУБД" - Access, FoxPro, Paradox и т.п..
Приложение на рабочей станции "отвечает за все" - за формирование пользовательского интерфейса, логическую обработку данных и за непосредственное манипулирование данными. Файловый сервер предоставляет услуги только самого низкого уровня - открытие, закрытие и модификацию файлов, подчеркну - файлов, а не базы данных. База данных существует только в "мозгу" рабочей станции.
Таким образом, непосредственным манипулированием данными занимается несколько независимых и несогласованных между собой процессов. Кроме того, для осуществления любой обработки (поиск, модификация, суммирование и т.п.) все данные необходимо передать по сети с сервера на рабочую станцию ( см. рис. Сравнение файл-серверной и клиент-серверной моделей)
В клиент-серверной системе функционируют (как минимум) два приложения - клиент и сервер, делящие между собой те функции, которые в файл-серверной архитектуре целиком выполняет приложение на рабочей станции. Хранением и непосредственным манипулированием данными занимается сервер баз данных, в качестве которого может выступать Microsoft SQL Server, Oracle, Sybase и т.п..
Формированием пользовательского интерфейса занимается клиент, для построения которого можно использовать целый ряд специальных инструментов, а также большинство настольных СУБД. Логика обработки данных может выполняться как на клиенте, так и на сервере. Клиент посылает на сервер запросы, сформулированные, как правило, на языке SQL. Сервер обрабатывает эти запросы и передает клиенту результат (разумеется, клиентов может быть много).
Таким образом, непосредственным манипулированием данными занимается один процесс. При этом, обработка данных происходит там же, где данные хранятся - на сервере, что исключает необходимость передачи больших объемов данных по сети.
Когда вам нужна архитектура клиент-сервер?
Даже очень детальный анализ особенностей архитектуры клиент-сервер может не ответить на вопрос "А что мне это даст?" Посмотрим на данную архитектуру с точки зрения потребностей бизнеса. Какие же качества привносит клиент-сервер в информационную систему:
Надежность
Тот, кто хоть раз побывал в роли администратора базы данных в тот момент, когда эта база данных "погибла" по причине "зависания" сервера или рабочей станции, сбоя питания или еще какой-либо напасти, никогда уже не станет пренебрегать вопросами надежности (если, конечно, сумеет сохранить за собой эту роль). Если Вы еще не побывали в этой роли, надеюсь, у Вас достанет воображения, чтобы прокрутить этот триллер у себя в голове, и благоразумия, чтобы максимально обезопасить свою базу данных (и себя заодно). Чем же тут поможет архитектура клиент-сервер?
Сервер баз данных осуществляет модификацию данных на основе механизма транзакций, который придает любой совокупности операций, объявленных как транзакция, следующие свойства:
атомарность - при любых обстоятельствах будут либо выполнены все операции транзакции, либо не выполнена ни одна; целостность данных при завершении транзакции;
независимость - транзакции, инициированные разными пользователями, не вмешиваются в дела друг друга;
устойчивость к сбоям - после завершения транзакции, ее результаты уже не пропадут.
Механизм транзакций, поддерживаемый сервером баз данных, намного более эффективен, чем аналогичный механизм в настольных СУБД, т.к. сервер централизованно контролирует работу транзакций. Кроме того, в файл-серверной системе сбой на любой из рабочих станций может привести к потере данных и их недоступности для других рабочих станций, в то время, как в клиент-серверной системе сбой на клиенте, практически, никогда не сказывается на целостности данных и их доступности для других клиентов.
Масштабируемость
Масштабируемость - способность системы адаптироваться к росту количества пользователей и объема базы данных при адекватном повышении производительности аппаратной платформы, без замены программного обеспечения.
Общеизвестно, что возможности настольных СУБД серьезно ограничены - это пять-семь пользователей и 30-50 Мб, соответственно. Цифры, разумеется, представляют собой некие средние значения, в конкретных случаях они могут отклоняться как в ту, так и в другую сторону. Что наиболее существенно, эти барьеры нельзя преодолеть за счет наращивания возможностей аппаратуры.
Системы же на основе серверов баз данных могут поддерживать тысячи пользователей и сотни ГБ информации - дайте им только соответствующую аппаратную платформу.
Безопасность
Сервер баз данных предоставляет мощные средства защиты данных от несанкционированного доступа, невозможные в настольных СУБД. При этом, права доступа администрируются очень гибко - до уровня полей таблиц. Кроме того, можно вообще запретить прямое обращение к таблицам, осуществляя взаимодействие пользователя с данными через промежуточные объекты - представления и хранимые процедуры. Так что администратор может быть уверен - никакой слишком умный пользователь не прочитает то, что ему читать неположено.
Гибкость
В приложении, работающем с данными, можно выделить три логических слоя:
пользовательского интерфейса;
правил логической обработки (бизнес-правил);
управления данными (не следует только путать логические слои с физическими уровнями, о которых речь пойдет ниже).
Как уже говорилось, в файл-серверной архитектуре все три слоя реализуются в одном монолитном приложении, функционирующем на рабочей станции. Поэтому изменения в любом из слоев приводят однозначно к модификации приложения и последующему обновлению его версий на рабочих станциях.
В двухуровневом клиент-серверном приложении, показанном на рис. 1, как правило, все функции по формированию пользовательского интерфейса реализуются на клиенте, все функции по управлению данными - на сервере, а вот бизнес-правила можно реализовать как на сервере используя механизмы программирования сервера (хранимые процедуры, триггеры, представления и т.п.), так и на клиенте. В трехуровневом приложении появляется третий, промежуточный уровень, реализующий бизнес-правила, которые являются наиболее часто изменяемыми компонентами приложения ( см. рис. Трехуровневая модель клиент-серверного приложения )
Наличие не одного, а нескольких уровней позволяет гибко и с минимальными затратами адаптировать приложение к изменяющимся требованиям бизнеса.
Попробуем все вышеизложенное проиллюстрировать на маленьком примере. Предположим, в некоей организации изменились правила расчета заработной платы (бизнес-правила) и требуется обновить соответствующее программное обеспечение.
1) В файл-серверной системе мы "просто" вносим изменения в приложение и обновляем его версии на рабочих станциях. Но это "просто" влечет за собой максимальные трудозатраты.
2) В двухуровневой клиент-серверной системе, если алгоритм расчета зарплаты реализован на сервере в виде правила расчета зарплаты, его выполняет сервер бизнес-правил, выполненный, например, в виде OLE-сервера, и мы обновим один из его объектов, ничего не меняя ни в клиентском приложении, ни на сервере баз данных.
Этапы построения клиент-серверной системы.
Предположим, Вы сегодня используете приложение, реализованное в файл-серверной архитектуре, средствами, Microsoft Access, и думаете о его развитии. Можно рассмотреть следующие шаги.