|
|
|
| Главная | О компании | Новости | Обучение | Обратная связь | Форум |
ABACUS Financial ABACUS Builder ABACUS Professional
|
Некоторые аспекты использования трехуровневой архитектуры
В настоящее время все большее количество информационных систем разрабатываются с использованием так называемой трехуровневой архитектуры, представляющей информационную систему в виде совокупности трех компонент: сервера баз данных, клиентского приложения и сервера приложений, отвечающего за выполнение логики приложения. Основными преимуществами выделения логики приложения в отдельную составляющую являются возможность повторного использования логики приложения, повышение производительности используемого сервера базы данных, возможность масштабирования системы в целом и относительная независимость системы от конкретного производителя системы управления базами данных (СУБД) [1,2]. Преимущества трехуровневой архитектуры проявляются в достаточно крупных системах, к которым можно отнести, например, централизованную систему управления университетом. Однако при выборе трехуровневой архитектуры в качестве основы информационной системы следует учитывать тот факт, что при реализации системы придется решать целый ряд вопросов, нехарактерных для архитектуры клиент-сервер. Некоторые из этих вопросов будут описаны ниже. Прежде чем рассматривать трехуровневую архитектуру посмотрим, какими недостатками обладает наиболее распространенная в настоящее время архитектура клиент-сервер. В архитектуре клиент-сервер логика приложения выполняется либо на клиентской стороне (“толстый” клиент), либо на серверной стороне, обычно, в виде хранимых процедур базы данных (“тонкий” клиент). Оба этих подхода имеют определенные достоинства и недостатки. Так, например, использование “толстого” клиента позволяет снизить загрузку сервера базы данных, но при этом может произойти значительное увеличение загрузки сети и увеличиваются затраты на администрирование рабочих мест, связанные с необходимостью контроля и обновления программного обеспечения. Использование же “тонкого” клиента, т.е. клиента, отвечающего только за представление и ввод информации, требует наличия высокопроизводительного сервера. Основной, помимо сложности масштабирования, проблемой архитектуры клиент-сервер, наиболее ярко проявляющейся в крупных системах, является необходимость установления соединения между базой данных и каждым работающим с системой пользователем, независимо от того, работает он в настоящий момент или нет. Поскольку на каждое соединение сервер баз данных требует значительное количество системных ресурсов, то часто возникает ситуация, при которой сервер может справиться с рабочей загрузкой, т.е. способен обрабатывать поступающие запросы, но не справляется с “загрузкой соединений” (например, если общее количество пользователей системы на порядок больше среднего количества активных пользователей). Во многом именно это обстоятельство и привело к необходимости использования трехуровневой архитектуры. В трехуровневой модели сервер баз данных отвечает только за хранение данных и обработку запросов. Характерные для современных баз данных возможности по созданию хранимых процедур, как правило, не используются. С одной стороны это связано с тем, что на сегодняшний день язык описания хранимых процедур не стандартизован, а значит, использование хранимых процедур приведет к зависимости от конкретного производителя СУБД. С другой стороны, использование хранимых процедур означает наличие бизнес логики на стороне базы данных, что противоречит общему принципу выделения специального компонента, отвечающего за ее выполнение. Само приложение, функционирующее на сервере приложений, представляет собой совокупность некоторого количества служб или сервисов, выполняющих характерные для данного приложения операции. Пользователем службы может являться как клиентское приложение, так и другая служба. Таким образом, вместо термина “трехуровневая модель” можно использовать термин “многоуровневая модель”. Как правило, приложение состоит из нескольких групп служб, реализующих операции различного уровня абстракции. Эти группы можно представить в виде концентрических кругов, наименьший из которых соответствует службам подсистемы доступа к данным, реализующим интерфейс с базой данных (назовем их службами нулевого уровня), а наибольший – самым абстрактным функциям приложения. Выделение группы служб, отвечающих за обеспечение интерфейса с базой данных, позволяет добиться высокой степени независимости всего приложения от конкретной СУБД. При необходимости миграции на другую СУБД изменению подлежат службы только этой группы; вся остальная часть приложения останется без изменения. Использование при реализации служб нулевого уровня стандартных механизмов взаимодействия с СУБД, таких как ODBC или встраиваемый SQL (embedded SQL), сведет объем необходимых изменений до минимума. Кроме того, наличие служб нулевого уровня позволяет существенно снизить “загрузку соединений” базы данных, поскольку сервер приложений имеет возможность мультиплексирования запросов к базе данных по относительно небольшому количеству соединений. Действительно, сервер приложений может управлять количеством соединений с базой данных, определяя количество запущенных экземпляров службы нулевого уровня. Если приложение допускает наличие некоторых задержек при выполнении запросов, то количество запущенных экземпляров службы (соединений с СУБД) может оказаться не только меньше общего числа пользователей, но даже и меньше числа активных пользователей, чего невозможно достичь в рамках архитектуры клиент-сервер. Однако за подобное повышение производительности приходится расплачиваться введением дополнительных структурных элементов, необходимых для нормального функционирования системы. В первую очередь следует отметить, что ввиду того, что процедура создания нового экземпляра службы может требовать значительного промежутка времени, большое значение имеет наличие механизма управления пулом освободившихся экземпляров служб. Политика управления пулом служб может сильно варьироваться в зависимости от типа службы. Так, например, поскольку процедура установления и уничтожения соединения с СУБД отнимает значительное количество времени, для служб нулевого уровня следует предусматривать некоторый запас свободных экземпляров и возможность повторного использования освободившихся экземпляров, что позволит сократить среднее время отклика системы. Службы более высокого уровня абстракции, не требующие установления сетевых соединений, могут создаваться и уничтожаться динамически, по мере необходимости. В любом случае, к выбору алгоритма управления пулом экземпляров служб следует относиться с большой осторожностью, поскольку это может сказаться на общей производительности системы; возможно, что динамические алгоритмы, т.е. алгоритмы, использующие информацию об истории интенсивности использования службы, окажутся наиболее эффективными. Более значительные трудности представляет взаимодействие служб нулевого уровня с СУБД. Даже несмотря на то, что при работе системы может использоваться только одна база данных, возникает необходимость применения механизма обработки распределенных транзакций – монитора транзакций, взаимодействующего с СУБД по протоколу XA [3,4]. Это связано с тем, что клиентское приложение, использующее в рамках одной транзакции несколько служб нулевого уровня, каждая из которых может функционировать на выделенном компьютере, и имеет собственное соединение с СУБД, фактически работает с базой данных по нескольким независимым соединениям. Без применения специальных программных средств, все операции, выполняемые различными службами нулевого уровня, окажутся в различных транзакциях СУБД, а значит, будут невидимы друг другу. Помимо очевидных трудностей для клиентского приложения (мы произвели какие-то изменения в базе, но следующая операция, использующая другую службу, считает, что их не было) это может привести к нарушению целостности базы данных, поскольку процедура фиксации изменений будет реализовываться последовательностью фиксаций изменений каждой из используемых служб. Использование монитора транзакций, как внешнего по отношению к СУБД средства управления транзакциями, позволит избежать этих трудностей. Служба нулевого уровня должна устанавливать соединение с СУБД посредством вызовов XA, позволяющих указывать идентификатор глобальной транзакции, в рамках которой будут выполняться все последующие операции. Таким образом, все изменения базы данных будут производиться как одна транзакция, независимо от реального количества подключений к СУБД.
1. Tuxedo System: разработка систем клиент-сервер [Г.М. Ладыженский, СУБД №№ 1, 2 1996].
|
|
|
|
||
