Особенности проектирования клиент-серверных ис.
Архитектура клиент-сервер
Архитектура клиент-сервер предъявляет специфические требования как к клиенту, так и к серверу. Программа, удовлетворяющая этим требованиям, может считаться клиент-серверным приложением, выполняющим распределенную обработку данных (рис. 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) одновременно доступен многим клиентам, что снижает накладные затраты при выполнении однотипных запросов.
Эффективность работы клиентов меньше зависит от сетевого трафика.
Недостатки смешанных систем
Бизнес-логика распределена между клиентом и сервером.
Модернизация приложения требует распространения новых версий клиентской части среди широкой аудитории.
Многоуровневые системы
Многоуровневая система (иногда ее называют трехуровневой) позволяет разделить пользовательский интерфейс, бизнес-правила и базу данных (рис. 6.10).
Рис. 6.10 Пользовательский интерфейс, бизнес-правила и база данных размешены отдельно
В многоуровневой системе бизнес-правила реализуются как отдельные библиотеки (DLL). Их (например, написанные на Visual Basic) можно разместить на сервере. Клиент, библиотеки и база данных составляют распределенные сервисы многоуровневой системы.
Сервисы
Сервис — это набор связанных функций, выполняющих определенные действия и/или предоставляющих информацию на основе взаимодействия с пользователем. Доступ к сервису обеспечивает интерфейс, инкапсулирующий его реализацию.
Сервисная модель — это метод рассмотрения приложения как набора средств или сервисов, которые удовлетворяют запросы клиентов. Моделирование программы в виде набора отдельных сервисов позволяет повторно использовать компоненты, предоставляет доступ к ним другим приложениям и помогает распределять их выполнение между несколькими компьютерами сети.
Типы сервисов
В типичных бизнес-приложениях возможны сервисы трех категорий.
Тип сервиса |
Размещение |
Назначение |
Пользовательский |
Клиент |
Представление информации и доступа к функциям приложения, навигация, сохранение целостности и непротиворечивости пользовательского интерфейса |
Бизнес-сервис |
Сервер |
Реализация основных стратегий, генерация информации на основе данных и поддержка целостности среды принятия бизнес-решений |
Сервис данных |
Сервер |
Структуризация данных, их хранение, извлечение и поддержка целостности |
Достоинства многоуровневых систем
Разделение компонентов интерфейса, бизнес-правил и хранения данных. Возможность применения интеллектуальных клиентов. Возможность применения сервисов.
Недостатки многоуровневых систем
Необходимы сервер и сеть. Увеличивается сетевой трафик.