Клиент-серверная архитектура. Системы "клиент-сервер"

5 Особенности и преимущества архитектуры "клиент/сервер"

Что же представляет собой архитектура клиент/сервер? В определенной степени ее можно назвать возвратом к модели "хост-компьютер + терминалы", так как ядром такой системы является сервер баз данных , представляющий собой приложение, осуществляющее комплекс действий по управлению данными - выполнение запросов, хранение и резервное копирование данных, отслеживание ссылочной целостности, проверка прав и привилегий пользователей, ведение журнала транзакций. При этом в качестве рабочего места может быть использован обычный персональный компьютер, что позволяет не отказываться от привычной рабочей среды (рис.5).

Рис.5. Этап 4: обработка данных в архитектуре "клиент/сервер"

В чем преимущества клиент-серверных информационных систем по сравнению с их аналогами, созданными на основе сетевых версий настольных СУБД?

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

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

Кроме того, для описания серверных бизнес-правил, в наиболее типичных ситуациях (как в примере с заказчиками и заказами) существуют весьма удобные инструменты - так называемые CASE-средства (CASE означает Computer-Aided System Engineering), позволяющие описать подобные правила и создавать реализующие их объекты базы данных (индексы, триггеры), буквально рисуя мышью связи между таблицами, без какого бы то ни было программирования. В этом случае клиентское приложение будет избавлено от значительной части кода, связанного с реализацией бизнес-правил непосредственно в приложении. Отметим также, что часть кода, связанного с обработкой данных, также может быть реализована в виде хранимых проце дур сервера, что позволяет еще более "облегчить" клиентское приложение, г это означает, что требования к рабочим станциям могут быть не столь высоки. Это в конечном итоге удешевляет стоимость информационной системы даже при использовании дорогостоящей серверной СУБД и мощного сервера баз данных.

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

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

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

Итак, клиент-серверная информационная система состоит в простейшем случае из трех основных компонентов:

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

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

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

Есть и более сложные реализации архитектуры "клиент/сервер", например трехуровневые информационные системы с использованием сервере приложений, а также информационные системы, использующие Web-сервер, под управлением которого выполняются приложения, доставляющие данные в Web-браузер пользователя.

1.6. Компоненты системы

Клиент

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

Сервер

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

Сеть

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

Приложения

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

Есть два различного рода программного обеспечения для технологии клиент-сервер. Программное обеспечение, установленное на сервере (back-end tool), обеспечивает сбор, хранение и обработку данных. Примером подобных программ может служить Oracle, Sybase и Ingres.

Программное обеспечение на компьютере-клиенте (front-end application, фронтальное, предварительной обработки данных) более интерактивное, простое в использовании и более дружественное к пользователю. В качестве примера можно привести такие программы, как Developer 2000, Power Builder и Designer 2000.

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

Каждая машина обработки данных имеет свое фронтальное программное обеспечение. Для Oracle это Developer 2000, а для Sybase – Power Builder. Особенностью системы является то, что каждый фронтальный компьютер может общаться с компьютером базы данных. Так, в случае базы данных Oracle, может использоваться приложение Power Builder с небольшими изменениями.

1.6.1 Соберем все части вместе

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

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

Рис.6. Устройство системы «клиент-сервер»

1.7 Многозвенные информационные системы Internet

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

Эти проблемы решаются путем создания многозвенных информационных систем с "тонким" клиентом (рис.7).

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

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

Рис.7. Этап 5: обработка данных в многозвенной архитектуре

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

Говоря об использовании Internet/Intranet, нельзя не остановиться на возможностях создания приложений для Web-серверов. Такие приложения, с одной стороны, могут являться клиентами серверных СУБД, а с другой стороны, обычно генерируют динамические HTML-страницы (в том числе с данными из этих СУБД) по запросу клиентского приложения, роль которого в данном случае выполняет Web-браузер (называемый в этом случае "ультратонким" клиентом, рис.8). Отметим, что в последнее время такие приложения получают все большее распространение.

Рис.8. Принципы работы Web-приложения

1.8 Зачем нужны многозвенные информационные системы

Информационные системы, созданные на основе классической архитектуры "клиент/сервер", называемые двухзвенными системами или системами с "толстым" клиентом, состоят из сервера баз данных, содержащего сгенерированные тем или иным способом таблицы, индексы, триггеры и другие объекты, реализующие бизнес-правила данной информационной системы, и одного или нескольких клиентских приложений, предоставляющих интерфейс пользователя и производящих проверку допустимости и обработку данных, согласно содержащимся в них алгоритмам. Если говорить о клиентских приложениях, созданных для доступа к источникам данных они применяют вызовы функций прикладных программных интерфейсов клиентских частей соответствующих серверных СУБД. Эти вызовы осуществляются например посредством использования библиотеки Borland Database Engine (BDE), хотя в целом это не является обязательным (например, некоторые пользователи Oracle непосредственно вызывают функции Oracle Call Interfase в своих приложениях). Соответственно подобное клиентское приложение требует наличия на компьютере Конечного пользователя клиентской части применяемой серверной СУБД (и наличия лицензии на ее использование) и присутствия в оперативной памяти набора динамически загружаемых библиотек как из клиентской части, так и из ВDE (либо иной заменяющей ее библиотеки), таких, как драйверы баз данных, библиотеки, содержащие функции API клиентских частей и др. При использовании доступа посредством ООВС требуется также наличие на рабочей станции соответствующего ODBC-драйвера и ODBC администратора. Это усложняет технические требования, предъявляемые аппаратной части клиентской рабочей станции, и в конечном итоге приводит к удорожанию всей системы в целом (рис.9).

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

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

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

Рис.-9. Классическое клиентское приложение («толстый» клиент).

Выходом из этой ситуации является создание систем с так называемым "тонким" клиентом, в частности с клиентом, не содержащим в своем составе BDE и клиентскую часть серверной СУБД. В этом случае функциональность, связанная с доступом к данным (а нередко и какая-либо иная функциональность), возлагается на другое приложение, называемое обычно сервером приложений и являющееся клиентом серверной СУБД. В свою очередь, клиентские приложения обращаются не непосредственно к серверной СУБД с помощью вызова функций клиентских API, а к серверу приложений, являющемуся для них источником данных, при этом собственно клиентская часть серверной СУБД и библиотеки типа BDE на рабочей станции, где используется такое клиентское приложение, присутствовать не обязаны. Вместо них (например) применяется одна-единственная динамически загружаемая библиотека. Таким образом, созданная информационная система становится трехзвенной, а сервер приложений является средним звеном в цепи "тонкий клиент - сервер приложений - сервер баз данных" и, соответственно, относится к классу продуктов middleware (рис.10).

Рис.10. Решение проблем: "тонкий" клиент и сервер приложении

Как может быть практически реализована данная технология? С одно стороны, с помощью набора компонентов и классов, обеспечивающих создание серверов приложений и клиентских частей, а с другой стороны, с помощью MIDAS, позволяющего осуществлять запуск удаленных серверов приложений, осуществлять межреестровый обмен сведениями об OLE-серверах и оптимизировать нагрузку в случае использования нескольких серверов приложений. В данной главе будут рассмотрены простейшие практические примеры реализации подобной трехзвенной системы.

1.9 ТЕРМИНОЛОГИЯ РАСПРЕДЕЛЕННЫХ СУБД

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

На сегодняшний день существуют три параллельно развивающиеся и конкурирующие технологии взаимодействия объектов и программ: MIDAS (Multitier Distributed Application Srevices Suite), СОМ (Common Object Model - компонентная модель объектов) корпорации Microsoft, CORBA (Common Object Require Broken Architecture - архитектура с поставщиком требуемых общих объектов) независимой группы OMG. Основные принципы этих технологий и использующиеся в них термины описываются ниже.

1.10 Технология MIDAS

Midas (Multitier Distributed Application Srevices Suite) - новый продукт компании Inprise (Borland), предназначенный для эксплуатации сервера приложений, созданных с помощью C++ Builder 3 и Delphi 3. Этот продукт расширяет возможности, предоставляемые разработчикам технологией Microsoft DCOM (Distributed Component Object Model). Этот продукт позволяет обеспечить высокую производительность, надежность и защиту от сбоев при эксплуатации подобных систем.

Архитектура трехзвенной информационной системы, построенной с использованием MIDAS, представлена на рис. 11.

Рис.11. Архитектура трехзвенной информационной системы с использованием MIDAS

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

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

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

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

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

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

Отметим также, что удаленные модули данных (объекты Remote Data Module), входящие в состав серверной части Remote Data Broker, позволяют предоставить DCOM-интерфейс для| соответствующих объектов, делая их управляемыми извне и превращая, таким образом, сервер приложений в DCOM-сервер. Осуществляется такая публикация объектов путем выбора опции экспорта из удаленного модуля данных та контекстного меню соответствующего компонента при разработке сервера приложений.

Business Object Broker осуществляет для "тонкого" клиента поиск нужного сервера приложений среди доступных извне серверов, опубликованных в глобальном реестре - global registry, представляющем собой открытые части реестров компьютеров, содержащих серверы приложений. Применяется он в случае, когда требуется дублирование серверов приложений и возможность при сбое работы используемого сервера приложений подключить Клиентское приложение к другому серверу, либо при необходимости равномерного распределения клиентов по серверам приложений. Еще одной важной составляющей частью MIDAS является ConstraintBroker, дающий возможность использовать бизнес-правила сервера баз данных "тонким" клиентом. Обычно при проектировании баз данных бизнес-правила и правила ссылочной целостности реализуются в виде объектов базы данных, таких, как индексы, триггеры, хранимые процедуры. Такой подход к проектированию данных позволяет использовать эти объекты различными клиентскими приложениями без написания дополнительного кода.

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

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

При использовании ConstraintBroker эта проблема решается по-другому. В этом случае Remote Data Broker не только доставляет данные клиентскому приложению, но и обращается к словарю данных сервера приложений с целью получения ограничений сервера и передачи их клиенту. Соответственно при попытке передачи записи на сервер приложений анализ соответствия записи правилам сервера производится непосредственно в клиентском приложении без обращения к серверу баз данных, что снижает загрузку серверов и сети. Отметим, что при изменении бизнес-правил следует внести соответствующие изменения в словарь данных сервера приложений, что можно сделать с помощью входящей в состав MIDAS утилиты, позволяющей помимо этого вносить серверные ограничения, создавать и изменять таблицы, индексы, триггеры, хранимые процедуры, правила ссылочной целостности на сервере баз данных.

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

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

Но это еще не все. Именно трехзвенная архитектура позволяет реально осуществить централизацию хранения и обработки данных с одновременным доступом к актуальной информации I случае, когда рабочая станция находится на значительном расстоянии от сервера приложений исключающем прокладку локальной сети, так как доступ к серверу приложений может осуществляться » иными способами, такими, как модемное соединение или доступ через Internet. Требования к надежности такого соединения невысоки, так как при использовании подобной архитектуры активно применяется кеширование данных на рабочей станции, и при этом применение ConstraintBroker позволяет проверять соответствие изменяемых данных правилам сервера непосредственно на рабочей станции, поэтому применение "тонких" клиентов и серверов приложений, управляемых MIDAS, является одним из решений для территориально разбросанных предприятий, организаций с удаленными филиалами, в том числе в других городах и странах.

1.11 Технология СОМ

Технология СОМ разрабатывается корпорацией Microsoft и предназначена для того, чтобы одна программа (клиент) смогла заставить работать объект, являющийся частью другой программы (частью сервера), так, как если бы этот объект был частью клиента, причем обе программы в общем случае могут быть расположены на разных компьютерах (в том числе - находящихся в разных частях света), написаны на разных языках и исполняться под управлением разных операционных систем. Более того, сами компьютеры могут быть разного типа - например, IBM-совместимый ПК и рабочая станция SUN.

Ключевым аспектом СОМ является так называемый интерфейс. Интерфейс имеет уникальный идентификатор и набор параметров, описывающих методы, события и свойства общего объекта. Идентификатор интерфейса ID (Interface Identifier) является частным случаем GUID (Global Unique Identifier - глобально уникальный идентификатор). В состав Windows32 включены функции, генерирующие GUID, причем вероятность совпадения двух GUID ничтожно мала. Параметры интерфейса в общем случае описывают некоторый класс с идентификатором CLSID (Class ID реализуется как GUID), т. е. типы и имена используемых в нем полей, количество и типы параметров обращения к доступным методам и свойствам, имена методов и свойств и т. д. Получив интерфейс внешнего СОМ-объекта, клиент может его использовать так же, как свои собственные объекты. Любой СОМ-объект имеет интерфейс IUnknow, с помощью которого он может получить доступ к основному интерфейсу объекта.

Сервер СОМ представляет собой исполняемую программу или DLL, содержащую один или несколько объектов СОМ.

В зависимости от местоположения клиента и сервера возможны три варианта:

Клиент и сервер располагаются на одной машине и запускаются в одном процессе (именно так взаимодействует программа Delphi с компонентами ActiveX)", в этом случае сервер представляет собой DLL; клиент и сервер располагаются на одной машине, но запускаются в разных процессах (например, таблицы Exel вставлены в документ Word); в этом случае сервер представляет собой программу;

Клиент и сервер располагаются на разных машинах; сервером может быть как программа, так и DLL, используется распределенный вариант СОМ, который называется DСОМ (DСОМ).

В первом случае клиент с помощью интерфейса объекта непосредственно обращается к методам объекта в своем собственном адресном пространстве (рис.12).

Рис.12 Взаимодействие клиента и сервера в одном процессе.

Если сервер запускается в другом процессе или на другой машине, между объектом и клиентом располагаются два посредника - Proxy (уполномоченный) и Stub (заглушка) (рис.13). Клиент помещает параметры вызова в стек и обращается к методу интерфейса объекта. Однако это обращение перехватывает Proxy, упаковывает параметры вызова в пакет СОМ и направляет его в Stub другого процесса, возможно, на другой машине. Stub распаковывает параметры, помещает их в стек и делает вызов нужного метода объекта. Таким образом, метод объекта выполняется в собственном адресном пространстве процесса сервера.

1.12 Технология CORBA

Подобно СОМ, в CORBA активно используется интерфейс объекта. Главным отличием CORBA от СОМ является интегрированный в нее слой, реализующий доступ к удаленным объектам.

В соответствии с этой технологией схема взаимодействия клиента и сервера выглядит следующим образом (рис.14).

На машине клиента создаются два объекта-посредника: Stub (заглушка) и ORB (Object Require Broker - брокер требуемого объекта). Stub выступает как полномочный представитель объекта: с помощью интерфейса объекта клиент обращается к Stub так, как если бы это был сам объект.

Рис.13. Взаимодействие клиента и сервера в разных процессах.

Рис. 14. Взаимодействие клиента и сервера в CORBA.

Получив вызов метода, Stub транслирует этот вызов объекту ORB, который посылает в сеть широковещательное сообщение. На это сообщение откликается один из объектов Smart Agent((«умный» агент), установленный в сетевом окружении клиента (как в локальной сети, так и в Internet). Smart Agent моделирует сетевой каталог, в котором зарегистрированы известные ему серверы объектов. Он отыскивает нужный сетевой адрес сервера и передает запрос объекту ORB на машине сервера. Заметим, что обмен данными между ORB (клиента и сервера) и Smart Agent осуществляется с использованием специального протокола UDP, который более бережно использует сетевые ресурсы, чем протокол ТСР. Через ВОА (Basic Object Adapter - базовый объектный адаптер) данные получает особый объект сервера, который называется Skeleton (скелет). Skeleton помещает параметры вызова в стек адресного пространства объекта и реализует собственно вызов. Роль объекта ВОА заключается в фильтрации обращений к объекту сервера: с помощью его методов сервер через Skeleton может объявить некоторые свои поля и свойства доступными только для чтения иди вовсе срытыми от данного клиента. (Поскольку в рамках технологии данные, которыми обмениваются клиент и сервер, рассматриваются просто как цепочки байт, клиент должен поместить в буфер вызова свой авторизованный ключ в системах, защищенных от «посторонних» клиентов.)

«Изюминкой» CORBA является способ описания интерфейса объекта. Для этих целей разработан специальный язык IDL (Interface Definition Language - язык описания интерфейса), очень напоминающий язык С++. После описания интерфейса в терминах этого языка компилятор IDL автоматически создает объекты Stub и Skeleton. Обмен информацией об интерфейсе между разработчиками осуществляется в терминах языка высокого уровня, в то время как компилятор описания интерфейса переводит его текст в машинные инструкции конкретного компьютера (клиента или сервера). В результате достигается высокая степень независимости обмена данными от аппаратных средств клиента и пользователя.

Для реализации технологии в сетевом окружении клиента должен существовать хотя бы один Smart Agent. Если обмен данными осуществляется в локальной сети офиса, Smart Agent устанавливается на головную машину (на файл-сервер или машину с SQL-сервером), а при обмене данными по Internet - на одном из ее узлов. При создании сервера осуществляется автоматическая регистрация объектов в одном или нескольких Smart Agent. Таким образом, Smart Agent «знает», по каким сетевым адресам расположены его серверы. Это позволяет системе повысить свою надежность: если в одном из серверов произошел сбой, Smart Agent повторит вызов и при повторном сбое переключится на другой сервер.

1.13 Некоторые выводы

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

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

1.14. Применение систем Клиент/Сервер

Применение систем клиент-сервер в основном сконцентрировано в:

Банковском деле;

Системе продаж авиа билетов;

Сети Интернет.

Банковское дело

Все мы хорошо знакомы с основными банковскими операциями . Вот они:

2. Размещение и снятие с депозита наличных и безналичных денег ;

3. Предоставление займов;

4. Инвестиции;

5. Следование инструкциям банковского клиента.

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

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

Как происходит перевод?

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

Система продаж авиабилетов

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

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

Интеренет

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

Известно, что Интернет представляет собой совокупность малых сетей, расположенных по всему миру. Для того, чтобы все сети могли понимать друг друга, необходимо, чтобы они изъяснялись на одном и том же языке, названном ТСР/IР. Вне зависимости от географического расстояния и платформы становится возможным клиентским и серверным машинам разговаривать друг с другом.

Давайте посмотрим, почему Мировая Паутина (WWW) может быть названа наиболее популярным программным приложением к/с в сети Интернет.

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

1.15. Примеры развития серверов индивидуальных баз данных

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

Совместимость между собой;

Оптимизация и производительность;

Контроль за целостностью данных;

Обработка переводов;

Конкурентоспособность, защита от зависаний и контроль многопользовательского доступа;

Защита от несанкционированного доступа и проверка подлинности клиента;

Резервирование, восстановление данных и другие функции базы.

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

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

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

Данные в файл-серверной системе сохраняются на файловом сервере (Novell NetWare или WindowsNT Server), а обрабатываются они на рабочих станциях посредством функционирования "настольных СУБД", таких как Access, Paradox, FoxPro и т.п.

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

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

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

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

Преимущества архитектуры клиент-сервер

Технология клиент-сервер привносит в информационную систему такие качества:

• Надежность

Модификация данных осуществляется сервером баз данных при помощи механизма транзакций, придающего совокупности операций такие свойства, как: 1) атомарность, которая обеспечивает целостность данных при любом завершении транзакции; 2) независимость транзакций разных пользователей; 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 , т.е. по сети от сервера приложений к серверу БД передается лишь текст запроса.
• СУБД инкапсулирует внутри себя все сведения о физической структуре БД, расположенной на сервере.
• СУБД инициирует обращения к данным, находящимся на сервере, в результате которых результат выполнения запроса копируется на сервер приложений.
• Сервер приложений возвращает результат в клиентское приложение (пользователю).
• Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.

Департамент общего и профессионального образования Брянской области

Государственное образовательное учреждение

Клинцовский текстильный техникум

ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ АВТОМАТИЗИРОВАННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ

Технология «Клиент – сервер»

Студент гр. А-90______________________(Петроченко А.О.)

Преподаватель _______________________ (Широкова А.Л.)

Клинцы – 2011

1. Серверы. Основные понятия серверов

2. Модель клиент-сервер

3. Классификация стандартных серверов

4. Вывод

1. Серверы. Основные понятия серверов

Сервер (от англ. server, обслуживающий). В зависимости от предназначения существует несколько определений понятия сервер.

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

2. Сервер (программное обеспечение) - программное обеспечение, принимающее запросы от клиентов (в архитектуре клиент-сервер).

3. Сервер (аппаратное обеспечение) - компьютер (или специальное компьютерное оборудование) выделенный и/или специализированный для выполнения определенных сервисных функций.

3. Сервер в информационных технологиях - программный компонент вычислительной системы, выполняющий сервисные функции по запросу клиента, предоставляя ему доступ к определённым ресурсам.

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

2. Модель клиент-сервер

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

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

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

В файл-серверной системе данные хранятся на файловом сервере (например, Novell NetWare или Windows NT Server), а их обработка осуществляется на рабочих станциях, на которых, как правило, функционирует одна из, так называемых, "настольных СУБД" - Access, FoxPro, Paradox и т.п..

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

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

Рис. Сравнение файл-серверной и клиент-серверной моделей

В клиент-серверной системе функционируют (как минимум) два приложения - клиент и сервер, делящие между собой те функции, которые в файл-серверной архитектуре целиком выполняет приложение на рабочей станции. Хранением и непосредственным манипулированием данными занимается сервер баз данных, в качестве которого может выступать Microsoft SQL Server, Oracle, Sybase и т.п..

Формированием пользовательского интерфейса занимается клиент, для построения которого можно использовать целый ряд специальных инструментов, а также большинство настольных СУБД. Логика обработки данных может выполняться как на клиенте, так и на сервере. Клиент посылает на сервер запросы, сформулированные, как правило, на языке SQL. Сервер обрабатывает эти запросы и передает клиенту результат (разумеется, клиентов может быть много).

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

Что дает архитектура клиент-сервер?

Посмотрим на данную архитектуру с точки зрения потребностей бизнеса. Какие же качества привносит клиент-сервер в информационную систему?

Надежность

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

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

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

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

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

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

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

Безопасность

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

Гибкость

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

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

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

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

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

Рис. Трехуровневая модель клиент-серверного приложения

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

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

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

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

Файл-серверная архитектура

Традиционные архитектуры информационных систем.

Базовые функции информационных систем.

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

С точки зрения программно-аппаратной реализации можно выделить ряд типовых архитектур ИС.

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

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

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

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

Появились локальные сети. Файлы начали передаваться по сети. Сначала были одноранговые сети - всœе компьютеры равноправны. 3

Потом возникла идея хранения всœех общедоступных файлов на выделœенном компьютере в сети - файл-сервере.

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

Количество клиентов ограничено десятками.

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

2. Удобство централизованного управления доступом;

3. Низкая стоимость разработки;

1. Низкая производительность;

2. Низкая надежность;

3. Слабые возможности расширения;

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

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

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

Основные особенности: 5

 Клиентская программа работает с данными через запросы к серверному ПО.

 Базовые функции приложения разделœены между клиентом и сервером.

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

 Гарантия целостности данных

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

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

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

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

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

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

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

Переходная к трехслойной архитектуре (2.5 слоя)

Использование хранимых процедур и вычисление данных на стороне сервера сокращают трафик, увеличивают безопасность. Клиент всœе равно реализует часть бизнес-логики.

Как видно, такая организация системы весьма напоминает организацию первых унитарных систем с той лишь разницей, что на пользовательском месте стоит не терминал (с пресловутым зелœеным экраном), а персональный компьютер, обеспечивающий ГИП, к примеру, в последнее время в качестве клиентских программ часто применяют стандартные www-броузеры. Конечно, такой возврат к почти унитарным системам произошел уже на ином технологическом уровне. Обязательным стало использование СУБД со всœеми их преимуществами. Программы для серверной части пишут, в основном, на специализированных языках, пользуясь механизмом хранимых процедур сервера БД. Τᴀᴋᴎᴍ ᴏϬᴩᴀᴈᴏᴍ, на уровне логической организации, ИС в архитектуре клиент-сервер с тонким клиентом расщепляется на три слоя - слой данных, слой бизнес-функций (хранимые процедуры) и слой представления. К сожалению, обычно, в такой схеме построения ИС не удается написать всю бизнес-логику приложения на не предназначенных для этого встроенных языках СУБД. По этой причине, очень часто часть бизнес-функций реализуется в клиентской части систем, которая от этого неотвратимо "толстеет". Отчасти в связи с этим, отчасти потому, что физически такие ИС состоят из двух компонентов, эту архитектуру часто называют 2.5-слойный клиент-сервер.

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