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

Поэтому в настоящем разделе будет рассказано о базовых понятиях и терминах. Будут приведены основные определения, иллюстрированные в максимальной степени.

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

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

В дальнейшем будем придерживаться такого соглашения: если на рисунке какое-либо наименование написано на "экране дисплея" (как на рис.1-1 - "Прикладная программа"), то это именно ПРОГРАММА, а не аппаратура или файл. Если наименование написано в овале ("Файлы БД"), то это именно ФАЙЛЫ (то есть хранящаяся в долговременной памяти компьютера информация). Если наименование на рисунке написано "над дисплеем" ("возле системного блока"), например, "Файловый сервер" - рис. 1-2, то это именуется АППАРАТУРА, т.е. компьютер.

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

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

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

Сейчас самое время объяснить термины "сервер" и "клиент". Тот объект, который предоставляет услуги (сервисы) другому объекту, называется "сервером", а тот объект, который потребляет такую услугу - называется "клиентом". Вот так и никак иначе!

Очень важно! Один и тот же объект может быть и клиентом и сервером. Все определяется текущими отношениями - "поставлять услугу - потреблять услугу". Например, прачечная, поставщик моющих средств, обыватель. В отношениях "прачечная-обыватель" прачечная есть СЕРВЕР, а обыватель КЛИЕНТ (отсюда понятие "сервиса" - предоставляемая услуга), а в отношениях "поставщик моющих средств - прачечная" поставщик есть СЕРВЕР, а прачечная КЛИЕНТ. Теперь должно быть понятно, что сервером (и клиентом) может быть и программа и компьютер. Это обстоятельство очень часто приводит к недоразумениям.

Вернемся к рис.1-2. Обратите внимание, что на "файловом сервере" (называется он так потому, что предоставляет другим компьютерам услуги по хранению файлов) не показана программа ("экран" - серый). Это очень важное обстоятельство для понимания дальнейшего. Файловый сервер не обрабатывает информацию. Он просто хранит файлы. Все прикладные программы пользуются базой данных с файлового сервера в коллективном режиме. С их точки зрения файловый сервер не более, чем медленно работающий накопитель на жестких магнитных дисках (он же НГМД, "винчестер" и т.п...). Прикладные программы должны сами заботиться о "правилах хорошего тона" вроде, "пока другие записывают в базу, я должен ждать" и т.п. Для этого служат всевозможные механизмы блокировок, оповещений и другие потенциально ненадежные вещи. Например, типична ситуация - одна рабочая станция (точнее программа, которая выполняется на ней) оповестила другие рабочие станции о своем намерении модифицировать файл базы данных (для этого она "заблокировала" файл). Все ждут окончания модификации. А компьютер, который вызвал блокировку, обесточили. Разблокировать некому. Все ожидающие будут ждать вечно... Причем существует еще очень "узкое место" (рис. 1-2)! Это фрагмент компьютерной сети, который связывает файловый сервер с локальной сетью. Через этот фрагмент передаются все данные для работы прикладных программ! Чтобы понять всю "узость" и проблемность этого фрагмента сети, рассмотрим пример. Предположим, что прикладной программе нужна всего одна (всего одна!) цифра. А именно - остаток конкретного товара на складе. Один из способов (не лучший, но для примера подойдет) - это подсчет остатка нарастающим итогом. То есть берутся все движения товара (приходы и расходы) и суммируются-вычитаются. То есть, чтобы получить одну цифру, прикладной программе приходится "перетаскивать" через "очень узкое место" все документы (записи), касающихся всех движений товара. И этим занимаются все прикладные программы на всех рабочих станциях!.. Запомним этот пример на будущее - для получения остатко внужно просуммировать все приходы товара и вычесть все расходы. Эту процедуру назовем "расчет остатка".

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

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

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

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

Сервер базы данных

Такое решение не снимает всех проблем, но значительно улучшает ситуацию. В качестве сервера базы данных обычно используют так называемые "SQL-сервера". Это в высокой степени специализированные программы, понимающие специальный язык доступа к данным - SQL. То есть SQL-сервер это такая программа (программа, а не компьютер!), которая предоставляет сервис всем программам-клиентам, способным выразить свои потребности на языке SQL. Компьютер, на котором выполняется сервер базы данных, будем называть серверным. Если ограничиться только этим, то исчезает проблема коллективного доступа, но далеко не обязательно решается проблема высокой загрузки сети. Это еще не клиент-серверная архитектура!

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

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

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

Двухзвенная клиент-серверная архитектура

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

На рис. 1-4 показана такая система.

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

Такое положение вещей предоставляет возможность оптимально распределить функции между тремя звеньями системы:

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

Это, в свою очередь, делает возможным:

• оптимально решать задачи ограничения доступа в терминах документов, что затруднено при двухзвенной архитектуре. Это означает, что администратор системы будет разрешать (запрещать, ограничивать) доступ конкретного пользователя к конкретным группам документов (по типу - накладные, счета... по дате создания, авторству и т.п.), то есть в прикладной терминологии, а не в категориях имен таблиц и полей. Гораздо удобней ограничивать право доступа, например, к расходной накладной, а не к группе таблиц вроде "nakl006, d85n1...". Администратор системы (а тем более менеджер фирмы, отвечающий за безопасность) вовсе не обязан знать устройство базы данных;
• оптимально отслеживать проблемы и коллизии при коллективном доступе к одной информации. При сосредоточении практически всех вычислений в сервере приложений последний "знает", кто из пользователей какой документ редактирует, какой ресурс использует... Что дает возможность управлять коллективным доступом к общим ресурсам, полагаясь не только на механизмы транзакций и блокировок;
• сервер приложений может использовать для реализации своих сервисов доступ более чем к одной базе данных. Если прикладной задаче нужен консолидированный отчет из нескольких источников, то нет необходимости связывать клиентскую программу с разными базами данных... Это очень сильно упрощает администрирование системы и увеличивает ее надежность.

Немногим лучше обстоит дело с двухзвенной клиент-серверной архитектурой. Да. Здесь отсутствует "бутылочное горлышко" в виде пропускной способности компьютерной сети. Да. Многие действия (вроде сортировок, группировок, подбора данных...) может выполнять сервер базы данных. Но он по определению один. Чем больше нагружать сервер базы данных работой, тем выше вероятность возникновения ограничений вычислительных возможностей серверного компьютера. А отдавать вычисления клиентскому приложению нельзя.

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

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

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

Важным свойством трехзвенной клиент-серверной архитектуры есть то, что максимально разгружается сервер базы данных. А он, по определению, всегда один (если говорить о работе с одной "коллективной" базой данных). А вот серверов приложений может быть много - рис. 1-6.

А вот использование отдельных компьютеров для сервера приложений и сервера базы данных может быть очень полезным с точки зрения повышения надежности. Если посмотреть на рис. 1-5, то становится понятно, что тот компьютер, на котором установлен сервер базы данных, ничем кроме хранения базы данных не занимается. То есть он не выполняет никаких сложных программ, постоянно подверженных прикладным изменениям. Это фактически "машина базы данных". Если учесть, что в качестве сервера базы данных используются промышленные SQL-сервера (то есть программы, разработанные специализированными фирмами), которые используются очень многими потребителями, а значит - они хорошо испытаны, то становится понятно, что работа такой "машины базы данных" может быть очень надежной. А поскольку администрирование SQL-серверов может осуществляться в режиме удаленного доступа, то такую машину вообще можно установить в отдельной комнате...

Но главным остается то, что на этом компьютере не выполняются прикладные программы. И как следствие - никто не запрещает использовать для компьютера базы данных другую операционную систему (например, UNIX) - это обеспечивается тем, что для многих SQL-серверов существуют версии для OC-UNIX.

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

Но существует еще одно следствие разгрузки сервера базы данных за счет прикладных функций. Как уже говорилось, в качестве сервера базы данных используют промышленные SQL-сервера. А они "понимают" в высокой степени стандартизированный язык SQL (это язык запросов к базам данных). Строго говоря, SQL-сервера и были задуманы в качестве независимого от прикладной задачи хранилища информации. Причем унифицированного хранилища. Унифицированного в том смысле, что если прикладная программа использует "стандартный SQL", то ей должно быть все равно с каким конкретно SQL-сервером работать. А конкурирующих SQL-серверов существует довольно большое количество. Вот некоторые названия - Oracle, MS-SQL, Sybase, Informix, Interbase... Причем существуют их варианты для разных операционных систем... И очень разные возможности... и очень разная цена - от бесплатных и до очень дорогих. Замысел универсального хранилища данных очень красив и не менее полезен. И, как это не удивительно, этот замысел реализован. У конкретных реализаций от разных фирм есть языковые отличия (если говорить про SQL), но их довольно легко учесть. Однако беда в том, что для реализации концепции двухзвенной клиент-серверной архитектуры (рис. 1-3) языковых средств SQL недостаточно. Поэтому SQL-сервера снабдили еще одним языком программирования. И вот этот язык не стандартизирован. Как следствие - при использовании "двухзвенки" от идеи "универсального (взаимозаменяемого)" хранилища данных приходится отказываться. Такая программа всегда делается под конкретный SQL-сервер.

Но совсем другое дело при трехзвенной клиент-серверной архитектуре (рис. 1-4). Здесь практически полностью используется только SQL. И хотя приходится использовать и встроенный язык программирования (для т.н. "триггеров", например) - это не является (в силу куда более малых объемов таких "нестандартностей") препятствием для возврата к унифицированному применению SQL-серверов. Коротко говоря "трехзвенную" программу можно сделать относительно независимой от сервера базы данных. Поэтому пользователь может выбирать какой SQL-сервер использовать - от бесплатного (но весьма надежного и мощного) FireBird до очень дорогого и мощного Oracle.

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