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

Сервер баз данных осуществляет модификацию данных на основе механизма транзакций, который придает любой совокупности операций, объявленных как транзакция, следующие свойства:

• атомарность - при различных обстоятельствах будут либо выполнены все операции транзакции, либо не выполнена ни одна; целостность данных при завершении транзакции;

• независимость - транзакции, инициированные разными пользователями, никак не вмешиваются в дела друг друга;

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

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

Еще одним преимуществом является масштабируемость.

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

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

Системы на основе серверов баз данных могут поддерживать тысячи пользователей и сотни ГБ информации - при соответствующей аппаратной платформе.

Так же преимуществом является безопасность.

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

Еще одним преимуществом является гибкость.

В приложении, работающем с данными, можно отметить три логических слоя:

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

• правил логической обработки

• управления данными

Вывод:

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

2. Двух уровневая и многоуровневая архитектура «клиент-сервер»

2.1. Двухуровневая архитектура «клиент-сервер»

Двухуровневая архитектура начала распространяться с 1990-х годов, когда рос рынок персональных компьютеров и снижался спрос на мэйнфреймы.[6]

Изначально, описанная система выше, базировались на классической двухуровневой клиент-серверной архитектуре (Two-tierarchitecture). Под клиент-серверным приложением подразумевается информационная система, основанная на использовании серверов баз данных

Схематически такую архитектуру можно представить, как показано на рис.1

Рис. 1. Классическое представление архитектуры «клиент-сервер»

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

Рис. 2. Классификация двухзвенных моделей взаимодействия «клиент-сервер»

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

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

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

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

Преимущества такого подхода:

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

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

Недостаток - такого подхода ограниченность средств разработки хранимых процедур по сравнению с языками общего назначения (C и Pascal). [7]

На практике обычно используется смешанный подход:

• простейшие прикладные функции выполняются хранимыми процедурами на сервере;

• более трудные прикладные функции реализуются на клиенте непосредственно в прикладной программе

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

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

В следствии чего клиентская часть сервера баз данных, используя средства сетевого доступа, обращается к серверу базы данных, передавая текст оператора языка SQL.[14]

В программных продуктах практически всех компаний сервер получает от клиента текст оператора на языке SQL. Сервер проводит компиляцию полученного оператора. В случае если компиляция завершилась успешно, то происходит выполнение оператора.

Пользователи и разработчики информационных систем, основанных на архитектуре «клиент-сервер» часто бывают не удовлетворены постоянно существующими сетевыми накладными расходами, которые исходят из потребности обращаться от клиента к серверу с каждым очередным запросом. На практике очень распространена ситуация, когда для эффективной работы отдельной клиентской составляющей информационной системы в действительности необходима только небольшая часть общей базы данных. Это все приводит к идее поддержки локального кэша общей базы данных на стороне каждого клиента. Практически, концепция локального кэширования базы данных является частным случаем концепции реплицированных баз данных. Как в случае, для поддержки локального кэша базы данных программное обеспечение рабочих станций должно иметь компонент управления базами данных – более упрощенный вариант сервера баз данных, который может не обеспечивать многопользовательский режим доступа. [2]

Отдельной проблемным вопросом является обеспечение согласованности кэшей и общей базы данных. В данном случае возможны различные решения – от автоматической поддержки согласованности за счет средств базового программного обеспечения до полного перекладывания этой задачи на прикладной уровень.[7]

Преимуществами данной архитектуры являются:

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

Недостатками данной архитектуры являются:

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

Во время проектирования информационной системы, основанной на архитектуре «клиент-сервер», большее внимание следует обращать на грамотность общих решений. Технические средства пилотной версии могут быть совершенно минимальными (например, в качестве аппаратной основы сервера баз данных может быть использована одна из рабочих станций). Уже после создания пилотной версии нужно провести дополнительную исследовательскую работу, чтобы выяснить узкие места системы. Только лишь после этого необходимо принимать решение о выборе аппаратуры сервера, которая будет использоваться на практике.[1]

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

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

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

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

Самая распространенная трехуровневая архитектура (трехзвенная архитектура, threetier), которая относится к многоуровневой архитектуры «клиент-сервер».[3]

У трехуровневой архитектуры должно быть наличие следующих компонентов приложения:

клиентское приложение (обычно называют «тонкий клиент» или терминал), подключенное к серверу приложений, который уже подключен к серверу базы данных.

Схематически такую архитектуру можно представить, как показано на рис. 3