Архитектура «клиент-сервер»

Недостатки смешанных  систем

• Бизнес-логика распределена между клиентом и сервером.
• Модернизация приложения требует распространения новых версий клиентской части среди широкой аудитории.

Многоуровневые системы

Многоуровневая система (иногда ее называют трехуровневой) позволяет  разделить пользовательский интерфейс, бизнес-правила и базу данных (рис. 6.10).

Рис. 6.10 Пользовательский интерфейс, бизнес-правила и база данных размешены  отдельно

В многоуровневой системе бизнес-правила  реализуются как отдельные библиотеки (DLL). Их (например, написанные на Visual Basic) можно разместить на сервере. Клиент, библиотеки и база данных составляют распределенные сервисы многоуровневой системы.

Сервисы

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

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

Типы сервисов

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

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

Достоинства многоуровневых систем

Разделение компонентов интерфейса, бизнес-правил и хранения данных. Возможность  применения интеллектуальных клиентов. Возможность применения сервисов.

Недостатки многоуровневых систем

Необходимы сервер и сеть. Увеличивается сетевой трафик.

Резюме

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

• «интеллектуальные» клиенты;
• «интеллектуальный» сервер;
• смешанные системы;
• многоуровневые системы.

введение в СУБД (1-ИС)   к оглавлению

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

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

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

Модели серверов баз данных

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

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

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

Затем функции управления данными  были выделены в самостоятельную  группу — сервер, однако модель взаимодействия пользователя с сервером соответствовала  парадигме «один-к-одному» (рис. 10.8), то есть сервер обслуживал запросы только одного пользователя (клиента), и для обслуживания нескольких клиентов нужно было запустить эквивалентное число серверов.

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

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

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

Рис. 10.8. Взаимодействие пользовательских и клиентских процессов в модели «один-к-одному»

Проблемы, возникающие в модели «один-к-одному», решаются в архитектуре «систем с выделенным сервером», который способен обрабатывать запросы от многих клиентов. Сервер единственный обладает монополией на управление данными и взаимодействует одновременно со многими клиентами (рис. 10.9). Логически каждый клиент связан с сервером отдельной нитью («thread»), или потоком, по которому пересылаются запросы. Такая архитектура получила название многопотоковой односерверной («multi-threaded»).

Она позволяет значительно уменьшить  нагрузку на операционную систему, возникающую  при работе большого числа пользователей («trashing»).

Рис. 10.9. Многопотоковая односерверная архитектура

Кроме того, возможность взаимодействия с одним сервером многих клиентов позволяет в полной мере использовать разделяемые объекты (начиная с  открытых файлов и кончая данными  из системных каталогов), что значительно  уменьшает потребности в памяти и общее число процессов операционной системы. Например, системой с архитектурой «один-к-одному» будет создано 100 копий процессов СУБД для 100 пользователей, тогда как системе с многопотоковой архитектурой для этого понадобится только один серверный процесс.

Однако такое решение имеет  свои недостатки. Так как сервер может выполняться только на одном  процессоре, возникает естественное ограничение на применение СУБД для  мультипроцессорных платформ. Если компьютер  имеет, например, четыре процессора, то СУБД с одним сервером используют только один из них, не загружая оставшиеся три.

В некоторых системах эта проблема решается вводом промежуточного диспетчера. Подобная архитектура называется архитектурой виртуального сервера («virtual server») (рис. 10.10).

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

Однако и эта архитектура  не лишена недостатков, потому что здесь  в систему добавляется новый  слой, который размещается между  клиентом и сервером, что увеличивает  трату ресурсов на поддержку баланса  загрузки актуальных серверов («load balancing») и ограничивает возможности управления взаимодействием «клиент—сервер». Во-первых, становится невозможным направить запрос от конкретного клиента конкретному серверу, во-вторых, серверы становятся равноправными — нет возможности устанавливать приоритеты для обслуживания запросов.

Рис. 10.10. Архитектура с виртуальным сервером

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

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

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

Рис. 10.11. Многопотоковая мультисерверная архитектура

Существует несколько возможностей распараллеливания выполнения запроса. В этом случае пользовательский запрос разбивается на ряд подзапросов, которые могут выполняться параллельно, а результаты их выполнения потом  объединяются в общий результат  выполнения запроса. Тогда для обеспечения  оперативности выполнения запросов их подзапросы могут быть направлены отдельным серверным процессам, а потом полученные результаты объединены в общий результат (см. рис 10.12). В данном случае серверные процессы не являются независимыми процессами, такими, как рассматривались ранее. Эти серверные процессы принято называть нитями (treads), и управление нитями множества запросов пользователей требует дополнительных расходов от СУБД, однако при оперативной обработке информации в хранилищах данных такой подход наиболее перспективен.

Рис. 10.12. Многонитевая мультисерверная архитектура

Инструментальные  средства разработки клиент-серверных  приложений

Любое клиент-серверное приложение состоит  из клиентского и серверного приложений. Соответственно этому имеются инструментальные среды разработки клиентской части  и серверной. В качестве первых обычно выступают интегрированные среды  разработки, ИСР (Integrated Development Environment, IDE). В качестве вторых - системы управления базами данных, СУБД.

Инструментальные средства для  разработки клиентской части

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

Для того, чтобы воспользоваться многочисленными новейшими инструментальными средствами, предназначенными для создания клиентской части приложений, которые доступны сегодня на рынке программного обеспечения, разработчики должны уметь программировать на таких языках, как C++ и HTML, или на одном из множества других процедурных языков программирования, предназначенных для разработки Web-приложений. Раньше для разработки пользовательских корпоративных программ, работающих в основном в символьном режиме, использовались такие языки программирования, как ANSI С, COBOL, FORTRAN и Pascal. Сегодня большинство вновь разрабатываемых клиентских прикладных программ является GUI-приложениями - они содержат графический интерфейс пользователя. Большинство из доступных сегодня инструментальных средств являются дружественными по отношению к пользователю и объектно-ориентированными. В них широко используются пиктограммы, различного рода мастера, а также технология drag-and-drop. Наиболее популярными средствами для создания Web-приложений являются C++-Builder и IntraBuilder фирмы Borland, а также Visual J++ и Visual C++ компании Microsoft. Другие популярные средства разработки корпоративных приложений для локальных вычислительных сетей - PowerBuilder компании Powersoft, Developer/2000 корпорации Oracle, Visual Basic компании Microsoft и Delphi фирмы Borland.