Файл: Технология «клиент-сервер» (Клиент- серверная архитектура).pdf

-возможность, в большем числе случаев, распределить функции вычислительной системы между несколькими независимыми компьютерами в сети;

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

- поддержка многопользовательской работы;

- гарантия целостности данных.

К минусам данной архитектуры относятся:

-неработоспособность сервера может сделать неработоспособной всю вычислительную сеть;

-администрирование данной системы требует квалифицированного профессионала;

-высокая стоимость оборудования;

-бизнес логика приложений осталась в клиентском ПО.

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

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

2.3 Многоуровневая архитектура клиент-сервер

Multitier architecture (Многоуровневая архитектура клиент-сервер) - это разновидность архитектуры клиент-сервер, в которой функция обработки данных вынесена на один или некоторое количество отдельных серверов. Это позволяет разделить функции хранения, обработки и представления данных для более эффективного использования возможностей серверов и клиентов. Среди многоуровневой архитектуры клиент-сервер самой распространенной считается трехуровневая архитектура (трехзвенная архитектура, threetier), которая предполагает наличие следующих компонентов приложения: клиентское приложение (обычно говорят "тонкий клиент" или терминал), подключенное к серверу приложений, который в свою очередь подключен к серверу базы данных. Схематически такую архитектуру можно представить, как показано на рисунке 4.

Рисунок 4 – Многоуровневая архитектура "клиент-сервер"

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

- клиентское ПО не нуждается в администрировании

-масштабируемость

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

-высокая надежность

-высокая безопасность

-низкие требования к производительности и техническим характеристикам терминалов, как следствие снижение их стоимости

-низкие требования к скорости канала (сети) между терминалами и сервером приложений

К недостаткам данной архитектуры относятся:

-увеличение сложности серверной части и, как следствие, затраты на администрирование и обслуживание

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

- сложнее в разворачивании и администрировании

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

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

Еще в рамках технологии «клиент-сервер» было положено начало процессу развития корпоративного ПО в многозвенной архитектуре. В них наряду с клиентской частью приложения и сервером баз данных появились серверы приложений (Application Servers). В идеале:  программа-клиент реализует GUI, передает запросы серверу приложений и принимает от него ответ,  сервер приложений реализует бизнес-логику и обращается с запросами к серверу "третьего уровня" (например, серверу базы данных за данными),  сервер третьего уровня обслуживает запросы сервера приложений. Программа-клиент, таким образом, может быть "тонкой". Плюсами такой архитектуры являются:

- изменения на каждом из звеньев можно осуществлять независимо; - снижаются нагрузки на сеть, поскольку звенья не обмениваются между собой большими объемами информации;- обеспечивается масштабирование и простая модернизация оборудования и программного обеспечения, поддерживающего каждое из звеньев, в том числе обновление серверного парка и терминального оборудования, СУБД и т.п.; - приложения могут создаваться на стандартных языках третьего или четвертого поколения (Java, C/C++). Далее следующим логическим шагом является дальнейшее увеличение количества звеньев, причем возрастет не только за счет разбиения, когда "утоньшается" каждое из известных технических звеньев, но вся бизнес-модель строится как многозвенная. На данный момент времени, современные корпоративные программные системы представляют собой, как правило, сложные системы взаимодействующие между собой на разных уровнях компонентов, каждые из которых могут являться клиентами для одних компонентов и серверами для других. Главной проблемой систем, которые основаны на двухзвенной архитектуре "клиент-сервер", или тем более на многозвенной архитектуре, является то, что от них необходима мобильность в как можно более широком классе аппаратно-программных сред. Даже если ограничиться UNIXориентированными локальными сетями, в различных сетях используется разная аппаратура и протоколы связи. Попытки создания систем, поддерживающих все возможные протоколы, приводит к их перегрузке сетевыми деталями в ущерб работоспособности. Еще более трудный аспект этой проблемы связан с возможностью использования разныличных представлений данных в разных узлах неоднородной локальной сети. В разных компьютерах может существовать различная адресация, представление чисел, кодировка символов и т.п. В особой степени это важно для серверов высокого уровня: баз данных ,телекоммуникационных, вычислительных. Общим решением проблемы мобильности такого рода систем является использование технологий, которые реализуют протоколы удаленного вызова процедур (RPC - Remote Procedure Call) стандартизованным и платформо- независимым способом. Используя такие технологии обращение к сервису в удаленном узле выглядит как стандартный вызов процедуры (методов удаленных объектов). Средства RPC, в которых, конечно же, содержится вся информация о специфике аппаратуры локальной сети и сетевых протоколов, переводит вызов в последовательность сетевых взаимодействий. Это позволяет скрыть от прикладного программиста специфику сетевой среды и протоколов. Вызывая удаленную процедуру, программы RPC производят преобразование форматов данных клиента в промежуточные машино- независимые форматы, и потом преобразование в форматы данных сервера. Передавая ответные параметры- осуществляется обратное преобразование. Это значит, в случае если система реализована на основе стандартного пакета RPC, она может быть с легкостью перенесена в различные открытые среды. Некоторые авторы представляют многозвенную архитектуру (трехзвенную) в виде пяти уровней (рисунок 5) 1. Представление; 2. Уровень представления; 3. Уровень логики; 4. Уровень данных; 5. Данные.

Рисунок 5 - Пять уровней многозвенной архитектуры "клиент-сервер"

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

2.4 Модели клиент-сервер

По меньшей мере, три модели клиент-сервер существует на сегодняшний день:

-модель доступа к удаленным данным (RDA-модель)

-модель сервера базы данных (DBS-модель)

- модель сервера приложений (AS-модель)

Первые две модели относятся к двухзвенными и не могут рассматриваться в качестве базовой модели распределенной системы. Третья модель — трехзвенная. Ее плюсом (как и всех многозвенных моделей) является то, что в ней интерфейс работы с пользователем в полной мере не зависит от компонента обработки данных. А это значит, трехзвенной ее можно считать из за того, что в ней явно выделены:

-компонент интерфейса с пользователем

-программное обеспечение промежуточного слоя (middleware) компонент управления данными

Middleware — это главный компонент трехзвенных распределенных систем. Он выполняет функции управления транзакциями и коммуникациями, транспортировки запросов, управления именами и иные функции. Различие между технологией типа "сервер запросов — клиент запросов" и трехзвенными технологиями - огромнейшее. В первом случае клиент явным образом запрашивает данные, зная при этом структуру базы данных (имеет место так называемая "поставка данных" клиенту). Клиент передает СУБД, к примеру, SQL-запрос, а в ответ получает данные. Происходит жесткая связь типов, реализация которой, у всех СУБД используется закрытый SQL-канал. Строится он двумя процессами: SQL/Net на компьютере-клиенте и SQL/Net на компьютере-сервере и порождается по инициативе клиента оператором connect. Канал называется закрытым из за того, что невозможно, к примеру, написать программу, которая будет шифровать SQL-запросы по специальному алгоритму или иным образом будет мешать процессу передачи данных между клиентским и серверным приложением. В случае трехзвенной схемы клиент явно запрашивает один из сервисов (которые предоставляются прикладным компонентом), к примеру, передавая ему некоторое сообщение, и получая ответ также в виде сообщения. Клиент направляет запрос во внешнюю среду, ничего не зная о месте расположения сервиса. Имеет место так называемая "поставка функций" клиенту. Самому клиенту база данных видна исключительно посредством набора сервисов. Более того, он вообще ничего не знает о ее существовании, т. к. все операции над базой данных выполняются внутри сервисов. Таким образом, речь идет о двух принципиально разных подходах к построению информационных систем клиент-сервер. Двухзвенная архитектура на сегодняшний день может считаться очень устаревшей и, в связи с развитием распределенных информационных систем, постепенно отходит на второй план. В случае, если для быстрого создания несложных приложений с небольшим числом пользователей этот метод подходит как нельзя лучше, то при построении корпоративных распределенных информационных систем он абсолютно непригоден в силу вышеперечисленных причин.

2.5 Клиент-серверная архитектура применительно к ИС

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