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

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

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

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

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

Понятие клиент-серверных  систем

Файловые реляционные базы данных — это мощные настольные СУБД, включающие ядро и хранилище данных. Однако в условиях сложных бизнес-правил и повышенных требований к вычислительной мощности на первый план выходят клиент-серверные  системы. На этом занятии мы познакомимся с компонентами клиент-серверных  систем.

 

 

 

Изучив материал этого  занятия, Вы сможете:

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

 

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

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

Рис. 6.5 Клиент, связывающийся  с сервером по сети

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

Преимущества клиент-серверных  систем

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

Проектирование  клиент-серверной системы

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

Стадии разработки

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

Рис. 6.6 Стадии проектирования клиент-серверной базы данных

Концепция

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

Логика

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

Физическое решение

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

Перспектива

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

Особенности клиента

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

Особенности сервера

В состав серверной части должны входить основные исполняемые файлы, библиотеки и все остальные файлы, необходимые для поддержки доступа  пользователей по сети. Кроме того, надо изучить требования к ресурсам сервера и на их основе принять  решение относительно аппаратной конфигурации, учитывая тип процессора (например, SQL Server поддерживает процессоры Alpha AXP, MIPS и 32-разрядные процессоры семейства Intel x86) и ресурс памяти (чем больше клиентов, тем больше потребуется ОЗУ для сохранения и увеличения быстродействия).

Системы клиент-сервер

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

• «интеллектуальные» клиенты;
• «интеллектуальный» сервер;
• смешанные системы;
• многоуровневые системы. Схему реализации выбирают на основе анализа требований к:
• сетевому графику;
• ресурсам клиента и сервера;
• производительности базы данных.

«Интеллектуальные» клиенты

Это один из самых распространенных методов реализации клиент-серверных  приложений (рис. 6.7). «Интеллектуальному»  клиенту можно доверить выполнение как бизнес-логики, так и сервисов представления данных.

Рис. 6.7 Бизнес-логика реализована на клиенте

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

Достоинства «интеллектуальных» клиентов

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

Недостатки «интеллектуальных» клиентов

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

«Интеллектуальные» серверы

Перенеся все бизнес-правила  на SQL Server, где они реализуются в виде хранимых процедур, Вы создадите «интеллектуальный» сервер (рис. 6.8). Роль сервера в такой клиент-серверной системе много шире простого хранилища файлов, доступных множеству пользователей сети. Интеллект сервера проявляется в способности выполнять команды (SQL-запросы) и возвращать результирующий набор данных.

Рис. 6.8 Бизнес-логика реализована на центральном сервере

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

Достоинства «интеллектуальных» серверов

• Увеличение производительности: бизнес-логика выполняется в том же адресном пространстве, что и код доступа к базе данных, и, кроме того, тесно интегрирована с механизмом поиска данных SQL Server. Это означает, что данные не нужно перемещать или копировать перед обработкой, а значит, сетевой трафик минимизируется.
• На сервере легче обеспечивать целостность данных.
• При необходимости бизнес-логика модифицируется централизованно, без изменения клиентов.

Недостатки «интеллектуальных» клиентов

• Повышение требований к ресурсам сервера, где выполняются все запросы и манипуляции с данными.
• Ограниченный выбор средств разработки: хранимые процедуры, например, создают на языке Transact-SQL. Хотя SQL Server поддерживает вызовы кода, написанного на других языках, этот подход сложен и в общем случае менее эффективен, нежели разработка тех же функций на Transact-SQL.

Смешанные системы

В рамках двухуровневой реализации возможны и смешанные варианты, обладающие достоинствами как интеллектуальных серверов, так и интеллектуальных клиентов (рис. 6.9). Например, клиентский компонент смешанного решения, разработанный средствами Visual Basic, может вызывать хранимые процедуры SQL Server.

Рис. 6.9 Смешанные системы: интеллектуальные клиенты и интеллектуальный сервер

Достоинства смешанных  систем

• Часть бизнес-логики может быть реализована в клиентской части.
• Серверный код (например, хранимые процедуры SQL Server) одновременно доступен многим клиентам, что снижает накладные затраты при выполнении однотипных запросов.
• Эффективность работы клиентов меньше зависит от сетевого трафика.