Управление требованиями клиент-серверного программного обеспечения

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

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

     Для модификации бизнес-логики необходимо повторное развертывание всех клиентов.  

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

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

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

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

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

       На сервере легче обеспечивать  целостность данных.

       При необходимости бизнес-логика  модифицируется централизованно,  без изменения клиентов.  

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

     Повышение требований к ресурсам сервера, где  выполняются все запросы и  манипуляции с данными.

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

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

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

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

       Часть бизнес-логики может быть реализована в клиентской части.

       Серверный код (например, хранимые  процедуры SQL Server) одновременно доступен многим клиентам, что снижает накладные затраты при выполнении однотипных запросов.

       Эффективность работы клиентов  меньше зависит от сетевого  трафика.  

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

     Бизнес-логика распределена между клиентом и сервером.

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

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

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

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

     Классы  приложений.

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

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

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

терминала.

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

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

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

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

     

     Рис.4. Трехзвенная архитектура клиент-сервер. 

     В данной архитектуре прикладное программное обеспечение распределено между машинами трех типов: пользовательской машиной, промежуточным сервером и сервером базы данных. Машина пользователя представляет собой клиента, и в трехзвенной модели это, как правило, «тонкий» клиент. Промежуточные машины являются, по существу, шлюзами между «тонкими» клиентами и разнообразными серверами баз данных. Промежуточные машины должны уметь преобразовывать протоколы и отображать одни типы запросов к базам данных на другие. Вдобавок, промежуточные машины должны объединять результаты запросов от различных источников данных. Наконец, эти машины должны играть роль шлюзов между настольными приложениями и оставшимися у организации со старых времен системами управления базами данных, таким образом, являясь посредниками между двумя «мирами». 

     Промежуточное программное обеспечение.

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

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

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

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

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

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

     Передача  сообщений.

     Клиентский  процесс запрашивает некую услугу (например, прочитать или распечатать на принтере файл). Для этого он посылает сообщение с запросом данной услуги серверному процессу. Серверный процесс принимает сообщение, обрабатывает запрос и посылает ответное сообщение. В простейшем случае требуются только две функции: Send (отправить) и Receive (принять). Функции Send на входе необходимо указать получателя, а также содержимое сообщения. Функции Receive нужно указать, от кого ожидается сообщение (включая вариант «все») и адрес буфера, в который следует поместить принятое сообщение. Существует несколько вариантов реализации механизма распределенной передачи Сообщений:

     Надежная  передача сообщений

     Синхронные  и асинхронные системы передачи сообщений

     Уделенные вызовы процедур.

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

     · Вызов процедуры представляет собой  широко распространенную и

понятную  абстракцию.

     · Уделенные вызовы процедур позволяют  специфицировать удаленный

интерфейс в виде множества именованных  операций с объектами указанных

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

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

автоматически.

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