4.3. Многоуровневые системы клиент-сервер

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• менеджер авторизации (обеспечивает аутентификацию пользователей и проверку их прав доступа);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приложение 1

2

3

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

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

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

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

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

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

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

Q1

Приложение 1