Смекни!
smekni.com

Информационные системы 3 (стр. 3 из 14)

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

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

Объектами разработки в файл - серверном приложении являются компоненты приложения, определяющие логику диалогаPL, а также логику обработки BL и управления данными DL. Разработанное приложение реализуется либо в виде законченного загрузочного модуля, либо в виде специального кода для интер­претации.

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

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

ПРИМЕЧАНИЕ:Одним из традиционных средств, на основе которых создаются файл-серверные си­стемы, являются локальные СУБД. Однако такие системы, как правило, не отвечают требованиям обеспечения целостности данных (в частности, они не поддерживают транзакции). Поэтому при их использовании задача обеспечения целостности дан­ных возлагается на программы клиентов, что приводит к усложнению клиентских при­ложений. Однако эти инструменты привлекают своей простотой, удобством исполь­зования и доступностью. Поэтому файл-серверные информационные системы до сих пор представляют интерес для малых рабочих групп и, более того, нередко использу­ются в качестве информационных систем масштаба предприятия.

ПРИМЕР:


Архитектура клиент-сервер

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

Особенностью архитектуры клиент-сервер является использование выделенных серверов баз данных, пони­мающих запросы на языке структурированных запросов SQL (StructuredQueryLanguage) и выполняющих поиск, сортировку и агрегирование информации.

Большинство конфигураций клиент-сервер использует двухуровневую модель, в ко­торой клиент обращается к услугам сервера. Предполагается, что диалоговые ком­поненты PS и PL размещаются на клиенте, что позволяет обеспечить графиче­ский интерфейс. Компоненты управления данными DS и FS размещаются на сервере, а диалог (PS, PL), логика BL и DL - на клиенте. Двухуровневое опреде­ление архитектуры клиент-сервер использует именно этот вариант: приложение работает у клиента, СУБД - на сервере (рис. 1.4.).

Рис. 1.4. Классический вариант клиент - серверной информационной системы

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

Для сокращения нагрузки на сеть и упрощения администрирования приложений компонентBL можно разместить на сервере. При этом вся логика принятия реше­ний оформляется в виде хранимых процедур и выполняется на сервере БД.

Хранимая процедура - процедура с операторами SQL для доступа к БД, вызывае­мая по имени с передачей требуемых параметров и выполняемая на сервере БД. Хранимые процедуры могут компилироваться, что повышает скорость их выпол­нения и сокращает нагрузку на сервер.

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

ПРИМЕЧАНИЕ: Следует помнить, что перегрузка хранимых процедур прикладной логикой может пе­регрузить сервер, что приведет к потере производительности. Эта проблема особен­но актуальна при разработке крупных информационных систем, в которых к серверу может одновременно обращаться большое количество клиентов. Поэтому в большин­стве случаев следует принимать компромиссные решения: часть логики приложения размещать на стороне сервера, часть - на стороне клиента. Такие клиент-серверные системы называются системами с разделенной логикой. Данная схема при удачном разделении логики позволяет получить более сбалансированную загрузку клиентов и сервера, но при этом затрудняется сопровождение приложений.

Двухуровневые схемы архитектуры клиент-сервер могут привести к некоторым проблемам в сложных информационных приложениях с множеством пользовате­лей и запутанной логикой. Решением этих проблем может стать использование многоуровневой архитектуры.

ПРИМЕР:


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

Многоуровневая архитектура стала развитием архитектуры клиент-сервер и в своей классической форме состоит из трех уровней:

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

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

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

Подобную концепцию обработки данных пропагандируют, в частности, фирмы Oracle, Sun, Borland и др.

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

Централизация логики приложения упрощает администрирование и сопровожде­ние. Четко разделяются платформы и инструменты для реализации интерфейса и прикладной логики, что позволяет с наибольшей отдачей реализовывать их спе­циалистам узкого профиля. Наконец, изменения прикладной логики не затраги­вают интерфейса, и наоборот. Но поскольку границы между компонентамиPL, BL и DL размыты, прикладная логика может появиться на всех трех уровнях. Сер­вер приложений с помощью монитора транзакций обеспечивает интерфейс с кли­ентами и другими серверами, может управлять транзакциями и гарантировать це­лостность распределенной базы данных. Средства удаленного вызова процедур наиболее соответствуют идее распределенных вычислений: они обеспечивают из любого узла сети вызов прикладной процедуры, расположенной на другом узле, передачу параметров, удаленную обработку и возврат результатов.

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

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