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

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

Сервер — один или несколько многопользовательских процессоров с единым полем памяти, который в соответствии с потребностями пользователя обеспечивает им функции вычисления, коммуникации и доступа к базам данных. Сервер можно назвать программу, представляющая какие-то услуги другим программам. Примеры серверов - вебсервер Apache, серверы баз данных - MySQL, ORACLE, сетевые файловые системы и принтера Windows.

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

Часто люди клиентом или сервером просто называют компьютер, на котором работает какая-то из этих программ.

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

Если проводить аналогию с обществом - банк или магазин - «сервера». Они представляют какие-то услуги своим клиентам. Но банк может в то же время быть клиентом какой-то другой фирмы и т. д…

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

СУБД с персональных ЭВМ (такие, как Clipper, DBase, FoxPro, Paradox, Clarion имеют сетевые версии, которые просто совместно используют файлы баз данных тех же форматов для ПК, осуществляя при этом сетевые блокировки для разграничения доступа к таблицам и записям. При этом вся работа осуществляется на ПК. Сервер используется просто как общий удаленный диск большой емкости. Такой способ работы приводит к риску потери данных при аппаратных сбоях.

По сравнению с такими системами системы, построенные в архитектуре Клиент — Сервер, имеют следующие преимущества:

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


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


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


в несколько раз уменьшает объем информации, передаваемый по сети.


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


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


1.2. История…


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


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


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


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


1.3. Протоколы


Сервер и клиент в сети между собой «разговаривает» на «языке» (в широком смысле слов), понятном обеим сторонам. Этот «язык» называют протоколом.


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


В нашем же случае, примеры протоколов:


FTP (File Transfer Protocol)


HTTP (Hyper Text Transfer Protocol)


SMTP (Simple Mail Transfer Protocol)


IP (Internet Protocol)


MySQL Client/Server Protocol


Заметим, что протоколы может быть разных уровней. Классификационные системы уровней может быть разные, но одна из самых известных линеек - OSI (Open Systems Interconnection), в котором 7 уровней.


Например, HTTP - протокол прикладного (седьмого - самого высокого) уровня, а IP - протокол сетевого (третьего) уровня.


1.4. Распределение функций в архитектуре «клиент-сервер»


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


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


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


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


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


Сначала большая часть функций приложения решалась клиентом, сервер занимался только обработкой SQL-запросов. Такая архитектура получила название «толстый клиент - тонкий сервер».


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


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


рассмотренные выше модели имеют следующие недостатки.


1. «Толстый» клиент:


– сложность администрирования;


– усложняется обновление ПО, поскольку его замену нужно производить одновременно по всей системе;


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


– перегружается сеть вследствие передачи по ней необработанных данных;


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


2. «Толстый» сервер:


– усложняется реализация, так как языки типа PL/SQL не приспособлены для разработки подобного ПО и нет хороших средств отладки;


– производительность программ, написанных на языках типа PL/SQL, значительно ниже, чем созданных на других языках, что имеет важное значение для сложных систем;


– программы, написанные на СУБД-языках, обычно работают недостаточно надежно; ошибка в них может привести к выходу из строя всего сервера баз данных;


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


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


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


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





Рис. 1. Распределение функций между клиентом и сервером


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



СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

1. Информатика / Под ред. Н.В. Макаровой.–М.: Финансы и статистика, 1998.
   

   Евдокимов В.В. и др. Экономическая информатика. СПб.: Питер, 2004.
   

   Казаков С.И. Основы сетевых технологий – М.: Радио и связь, 2004.
   

   Когаловский М.Р., Технология баз данных на персональных ЭВМ, – М.: Финансы и статистика, 2003.
   

   Попов В.В. Основы компьютерных технологий. –М.: Финансы и статистика, 2001.
   

   Фигурнов В.Э. IBM PC для пользователя. М., 2000.
   

ОПЕРАЦИОННАЯ СИСТЕМА MS-DOS . ОСНОВНЫЕ ПОНЯТИЯ И КОМАНДЫ ОСНОВНЫЕ ПОНЯТИЯ: БАЗА ДАННЫХ, СУБД, СУЩНОСТЬ, АТРИБУТ, СВЯЗЬ (ОДИН-К-ОДНОМУ, ОДИН-КО-МНОГИМ, МНОГИМ-КО-МНОГИМ), ОТНОШЕНИЕ, ПЕРВИЧНЫЙ КЛЮЧ

Перевод с английского: Чернобай Ю. А.

Развитие клиент-серверных систем

Архитектура компьютерной системы развилась наряду со способностями аппаратных средств использовать запускаемые приложения. Самой простой (и самой ранней) из всех была «Mainframe Architecture», в которой все операции и функционирование производятся в пределах серверного (или "host") компьютера. Пользователи взаимодействовали с сервером через «dumb» терминалы, которые передали инструкции, захватив нажатие клавиши, серверу и показали результаты выполнения инструкций для пользователя. Такие приложения носили типичный характер и, несмотря на относительно большую вычислительную мощность серверных компьютеров, были в основном относительно медленными неудобными в использовании, из-за необходимости передавать каждое нажатие клавиши серверу.

Введение и широкое распространение PC, с его собственной вычислительной мощностью и графическим пользовательским интерфейсом позволяли приложениям стать более сложными, и расширение сетевых систем привело к второму главному типу архитектуры системы, "Файловому разделению". В этой архитектуре PC (или "рабочая станция") загружает файлы от специализированного "файл сервера" и затем управляет приложением (включая данные) локально. Это работает хорошо, когда невелико использование общих данных, обновление данных, и объем данных, которые будут переданы. Однако скоро стало ясно, что разделение файла все больше засоряло сеть, и приложения становились более сложными и требовали, чтобы все большее количество данных было передано в обоих направлениях.

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

Обычно для обмена данными между клиентом и сервером используется либо Structured Query Language (SQL) либо Remote Procedure Call (RPCs). Ниже описаны несколько основных вариантов организации архитектуры клиент-сервер.

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

Рисунок 1: Двухуровневая архитектура

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

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

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

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

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

Но, несмотря на это, двухуровневая архитектура нашли новую жизнь в эпоху интернета. Она может хорошо работать в разъединенной окружающей среде, где UI является «dumb» (например браузер). Однако, во многих отношениях это реализация представляет собой возврат к первоначальной архитектуре мэйнфреймов.

В стремлении преодолеть ограничения двухуровневой архитектуры, описанных общих чертах выше, был введен дополнительный уровень. Такая архитектура является стандартной моделью клиент-сервер с трехуровневой архитектурой. Цель дополнительного уровня (обычно его называют «middle» или «rules» уровень) - управлять прикладным выполнением и управлением базой данных. Как и с двухуровневой моделью, уровни могут располагаться или на различных компьютерах (рисунок 2), или на одном компьютере в тестовом режиме.

Рисунок 2: Трехуровневая архитектура

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

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

Есть много вариантов основных трехуровневых моделей, предназначенных для выполнения различных функций. К ним относятся обработка распределенных транзакций (когда несколько СУБД обновляются в одном протоколе), приложения, базирующиеся на сообщениях (где приложения не общаются в режиме реального времени) и кросс-платформенной совместимости (Object Request Broker или «ORB» приложения).

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

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

Рисунок 3: N-уровневая архитектура

Уровни против слоев

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

Главное, что нужно помнить о многоуровневой архитектуре является то, что запросы и ответы каждого потока в одном направлении проходят по всем слоям, и что слои никогда не может быть пропущены. Таким образом, в модели, показанной на рисунке 4, единственный слой, который может обратиться к слою "E" (слой доступа к данным) является слой "D" (слой правил). Аналогичным образом слой "C" (прикладной слой ратификации) может только отвечать на запросы из слоя "B" (слоя обработка ошибок).

Рисунок 4: Ряды разделены на логические слои

Клиент-серверная двухуровневая архитектура ИС

Ключевым отличием архитектуры клиент-сервер от архитектуры файл-сервер является абстрагирование от внутреннего представления данных (физической схемы данных). При такой архитектуре клиентские программы манипулируют данными на уровне логической схемы. Для реализации архитектуры клиент-сервер обычно используют многопользовательские СУБД, например, Oracle или Microsoft SQL Server.

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

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

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

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

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

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

· обеспечение целостности данных.

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

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

· Бизнес логика приложений осталась в клиентском ПО. При любом изменении алгоритмов, надо обновлять пользовательское ПО на каждом клиенте.

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

· Слабая защита данных от взлома, в особенности от недобросовестных пользователей системы.

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

· Необходимость использовать мощные ПК на клиентских местах.

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

БД , на структурном языке запросов SQL (Structured Query Language ), являющемся промышленным стандартом в мире реляционных БД . Удаленный сервер принимает запрос и переадресует его SQL -серверу БД . SQL - сервер – специальная программа , управляющая удаленной базой данных. SQL - сервер обеспечивает интерпретацию запроса, его выполнение в базе данных, формирование результата выполнения запроса и выдачу его приложению-клиенту. При этом ресурсы клиентского компьютера не участвуют в физическом выполнении запроса; клиентский компьютер лишь отсылает запрос к серверной БД и получает результат, после чего интерпретирует его необходимым образом и представляет пользователю. Так как клиентскому приложению посылается результат выполнения запроса, по сети "путешествуют" только те данные, которые необходимы клиенту. В итоге снижается нагрузка на сеть . Поскольку выполнение запроса происходит там же, где хранятся данные (на сервере), нет необходимости в пересылке больших пакетов данных. Кроме того, SQL - сервер , если это возможно, оптимизирует полученный запрос таким образом, чтобы он был выполнен в минимальное время с наименьшими накладными расходами [ [ 3.2 ] , [ 3.3 ] ]. системы представлена на рис. 3.3 .

Все это повышает быстродействие системы и снижает время ожидания результата запроса. При выполнении запросов сервером существенно повышается степень безопасности данных, поскольку правила целостности данных определяются в базе данных на сервере и являются едиными для всех приложений, использующих эту БД . Таким образом, исключается возможность определения противоречивых правил поддержания целостности. Мощный аппарат транзакций, поддерживаемый SQL -серверами, позволяет исключить одновременное изменение одних и тех же данных различными пользователями и предоставляет возможность откатов к первоначальным значениям при внесении в БД изменений, закончившихся аварийно [ [ 3.2 ] , [ 3.3 ] ].

Рис. 3.3. Архитектура "клиент – сервер"

• Существует локальная сеть, состоящая из клиентских компьютеров, на каждом из которых установлено клиентское приложение для работы с БД.
• На каждом из клиентских компьютеров пользователи имеют возможность запустить приложение. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к СУБД, расположенной на сервере, на выборку/обновление информации. Для общения используется специальный язык запросов SQL , т.е. по сети от клиента к серверу передается лишь текст запроса.
• СУБД инициирует обращения к данным, находящимся на сервере, в результате которых на сервере осуществляется вся обработка данных и лишь результат выполнения запроса копируется на клиентский компьютер. Таким образом СУБД возвращает результат в приложение.

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

• Функции приложения-клиента:
  • Посылка запросов серверу.
  • Интерпретация результатов запросов, полученных от сервера.
  • Представление результатов пользователю в некоторой форме (интерфейс пользователя).
• Функции серверной части:
  • Прием запросов от приложений-клиентов.
  • Интерпретация запросов.
  • Оптимизация и выполнение запросов к БД.
  • Отправка результатов приложению-клиенту.
  • Обеспечение системы безопасности и разграничение доступа.
  • Управление целостностью БД.
  • Реализация стабильности многопользовательского режима работы.

В архитектуре " клиент – сервер " работают так называемые "промышленные" СУБД . Промышленными они называются из-за того, что именно СУБД этого класса могут обеспечить работу информационных систем масштаба среднего и крупного предприятия, организации, банка. К разряду промышленных СУБД принадлежат MS SQL Server , Oracle , Gupta, Informix , Sybase , DB2 , InterBase и ряд других [ [ 3.2 ] ].

Как правило, SQL - сервер обслуживается отдельным сотрудником или группой сотрудников (администраторы SQL -сервера). Они управляют физическими характеристиками баз данных, производят оптимизацию, настройку и переопределение различных компонентов БД , создают новые БД , изменяют существующие и т.д., а также выдают привилегии (разрешения на доступ определенного уровня к конкретным БД , SQL -серверу) различным пользователям [ [ 3.2 ] ].

Рассмотрим основные достоинства данной архитектуры по сравнению с архитектурой " файл - сервер ":

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

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

3.4. Трехзвенная (многозвенная) архитектура "клиент – сервер".

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

Итак, в результате работа построена следующим образом:

• База данных в виде набора файлов находится на жестком диске специально выделенного компьютера (сервера сети).
• СУБД располагается также на сервере сети.
• Существует специально выделенный сервер приложений, на котором располагается программное обеспечение (ПО) делового анализа (бизнес-логика) [ [ 3.1 ] ].
• Существует множество клиентских компьютеров, на каждом из которых установлен так называемый "тонкий клиент" – клиентское приложение, реализующее интерфейс пользователя.
• На каждом из клиентских компьютеров пользователи имеют возможность запустить приложение – тонкий клиент. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к ПО делового анализа, расположенному на сервере приложений.
• Сервер приложений анализирует требования пользователя и формирует запросы к БД. Для общения используется специальный язык запросов SQL , т.е. по сети от сервера приложений к серверу БД передается лишь текст запроса.
• СУБД инкапсулирует внутри себя все сведения о физической структуре БД, расположенной на сервере.
• СУБД инициирует обращения к данным, находящимся на сервере, в результате которых результат выполнения запроса копируется на сервер приложений.
• Сервер приложений возвращает результат в клиентское приложение (пользователю).
• Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.

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

Классическая система клиент-сервер работает по схеме "запрос-ответ" (двухуровневая архитектура). Клиент выполняет активную функцию (запросы), сервер пассивно на них отвечает.

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

Каждая из этих частей может быть реализована независимо от двух других.

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

В классической архитектуре клиент-сервер три основные части приложения распределяются по двум физическим модулям. Обычно ПО хранения данных располагается на сервере (/: сервере базы данных), интерфейс с пользователем - на стороне клиента, а вот обработку данных приходится распределять между клиентской и серверной частями. В этом основной недостаток данной архитектуры. Разбиение алгоритмов обработки данных требует синхронизации действий обеих частей системы. Чтобы избежать несогласованности различных элементов архитектуры, пытаются выполнять обработку данных на одной из двух частей - либо на стороне клиента ("толстый" клиент), либо на сервере ("тонкий" клиент, или "2,5-уровневый клиент-сервер"). Каждый подход имеет свой недостаток: в первом случае неоправданно перегружается сеть, т.к. по ней передаются необработанные (избыточные) данные, усложняется поддержка и изменение системы, так как замена алгоритма вычислений или исправление ошибки требует одновременной полной замены всех интерфейсных программ, иначе последует несогласованность данных; во втором случае , когда вся обработка информации выполняется на сервере, возникает проблема описания встроенных процедур и их отладки (описание является декларативным и не допускает пошаговой отладки). Кроме того, систему с обработкой информации на сервере абсолютно невозможно перенести на другую платформу.

Большинство современных средств быстрой разработки приложений (RAD), которые работают с различными БД, реализует первую модель ("толстый" клиент), обеспечивающую интерфейс с сервером БД через язык SQL.. Этот вариант, кроме выше перечисленных недостатков, имеет низкий уровень безопасности.

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

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

1. "Толстый" клиент

F сложность администрирования;

F сложность в обновлении ПО, т.к. его замену необходимо производить одновременно по всей системе;

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

F перегрузка сети из-за передачи по ней необработанных данных;

F слабая защита данных.

2. "Толстый" сервер

ð усложняется реализация, так как языки PL/SQL не приспособлены для разработки подобного ПО и нет средств отладки;

ð производительность программ на языках PL/SQL ниже, чем на других языках, что важно для сложных систем;

ð программы, написанные на СУБД-языках, работают ненадежно, что может привести к выходу из строя всего сервера БД;

ð созданные таким образом программы полностью непереносимы на другие системы и платформы.

Для решения перечисленных проблем используются многоуровневые (три и более) модели клиент-сервер.

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

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

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

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

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

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

Менеджеры транзакций

МТ - позволяют одному серверу приложений одновременно обмениваться данными с несколькими серверами БД. Хотя серверы Oracle имеют механизм выполнения распределенных транзакций, но если пользователь хранит часть информации в БД Oracle, часть в БД Informix, а часть в текстовых файлах, то без МТ не обойтись. МТ используется для управления распределенными разнородными операциями и согласования действий различных компонентов информационной системы. Любое сложное ПО требует использования МТ.

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

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

Логически МТ делится на несколько частей:

· коммуникационный менеджер (контролирует обмен сообщениями между компонентами инф-ой системы;

· менеджер транзакций (управляет распределенными операциями);

· менеджер ведения журнальных записей (следит за восстановлением и откатом распределенных операций);

· менеджер блокировок (обеспечивает правильный доступ к совместно используемым данным).

Обычно М-коммуникационный объединен с М-авторизации, а М-транзакций с М-блокировок и системных записей. Причем такой М редко входит в комплект поставки, поскольку его функции (ведение записей, распределение ресурсов и контроль операций), как правило, выполняет сама БД (например, Oracle).

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

4.4. Системы технологической почты ­ -

это гарантированная доставка информации и средство для интеграции приложений

Проектирование информационных систем ставит перед системными аналитиками решения следующих проблем:

ð распределенность системы;

ð интеграция различных приложений;

ð удобство администрирования.

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

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

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

Один из них основывается на концепции соединения (рис.1), а другой - на идее обмена сообщениями.

1

Рис.1. Механизм взаимодействия с установлением соединения

Процесс взаимодействия приложений и использованием установления соединения можно разделить на три фазы:

1. установление соединения;

2. передача информации;

3. закрытие соединения.

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

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

Рис.2. Взаимодействие приложений с использованием технологии очередей сообщений

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

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

Преимvшecтвa использования СТП:

Ø Гарантированность доставки сообщения. Серверы очередей сообщений

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

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

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

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