Аббревиатура ЛВС (она же LAN - Local Area Network) расшифровывается как локальная вычислительная сеть. Первые сети появились в 50 годы. Бурное развитие началось с появлением ПК (персонального компьютера).

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

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

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

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

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

Разделение прикладных программ. ЛВС позволяет двум пользователям использовать одну и ту же копию программы, например, текстового процессора MS Word. При этом, конечно, два пользователя не могут одновременно редактировать один и тот же документ.

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

Разделение принтера. ЛВС позволяет нескольким пользователям на различных рабочих станциях совместно использовать один или несколько дорогостоящих лазерных принтеров.

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

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

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

Рабочая станция - персональный компьютер, подключенный к сети, через который пользователь получает доступ к ее ресурсам. Рабочая станция сети функционирует как в сетевом, так и в локальном режиме. Она оснащена собственной операционной системой (Windows, Unix, MAC OS и т.д.), обеспечивает пользователя всеми необходимыми инструментами для решения прикладных задач.

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

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

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

Достоинства одноранговых сетей: низкая стоимость и высокая надежность.

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

ь зависимость эффективности работы сети от количества станций;

ь сложность управления сетью;

ь сложность обеспечения защиты информации;

ь трудности обновления и изменения программного обеспечения станций.

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

Взаимодействие между рабочими станциями в сети, как правило, осуществляется через сервер. Логическая организация такой сети может быть представлена топологией звезда. Роль центрального устройства выполняет сервер.

Достоинства сети с выделенным сервером:

ь надежная система защиты информации;

ь высокое быстродействие;

ь отсутствие ограничений на число рабочих станций;

ь простота управления по сравнению с одноранговыми сетями,

Недостатки сети:

ь высокая стоимость из-за выделения одного компьютера под сервер;

ь зависимость быстродействия и надежности сети от сервера;

ь меньшая гибкость по сравнению с одноранговой сетью.

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

1.1.2 Основные тенденции развития средств удаленного управления

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

Поэтому для современных средств удаленного доступа очень важны хорошая масштабируемость и поддержка большого количества удаленных клиентов.

Отличия между удаленным доступом и удаленным управлением

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

Удаленное управление

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

Преимущества удаленного управления

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

Удаленное управление может использоваться и как средство дистанционного обучения. Администратор может работать за другим ПК, подключенным к ПК пользователя, видеть экран пользователя, и помогать пользователю освоить программу в режиме демонстрации.

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

Недостатки удаленного управления

Программы удаленного управления имеют ряд ограничений. Большинство пакетов ограничены разрешением экрана, которое они могут воспроизвести. Клиенты Terminal Services поддерживают максимум 256 цветов. Кроме того, программы, использующие графику, сильно загружают каналы связи и могут свести на нет все преимущества удаленного управления. Citrix MetaFrame недавно выпустила Feature Release 1, дополнительный пакет для MetaFrame 1.8, который позволяет пользователям использовать 24-битный цвет.

Клиент Citrix может масштабировать графику сессии в зависимости от пропускной способности канала связи. Чем больше разрешение, тем больше загружается канал. Из-за этого некоторые программы, например, системы автоматизированного проектирования, не подходят для использования с Terminal Services или MetaFrame. Однако, приложения Windows Office - такие как Word и Excel, - идеально подходят для сеансов удаленного доступа.

Feature Release 1 доступен для обладателей Subscription Advantage. Он включает Service Pack 2 for MetaFrame 1.8, а также набор новых возможностей, таких как поддержка нескольких мониторов, большая глубина цвета, SecureICA.

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

Последний недостаток удаленного управления состоит в том, что скорость передачи файлов между локальным и удаленным ПК ограничена скоростью соединения. Большинство пользователей используют обычную телефонную сеть, позволяющую скорость максимум 56Кbps. Хотя MetaFrame неплохо работает и на модемном соединении 28.8 Kbps, рекомендуются высокоскоростные соединения типа ADSL или кабельные модемы.

Удаленный узел

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

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

Из-за этих ограничений вычисления на удаленном узле предъявляют высокие требования к пропускной способности канала связи. Это следует учитывать при проектировании. Как видно на рисунке, между клиентом на локальном ПК и клиентом удаленного узла есть небольшое различие. Сервер будет одинаково обрабатывать запросы от любой машины. Но если локальный клиент запрашивает 2Мб данных, сервер передаст их по локальной сети. Для удаленного клиента, по каналу 56К эта передача займет около 6 минут. Кроме того, после внесения изменений клиент должен отправить эти 2Мб обратно.

Зачем использовать удаленный доступ?

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

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

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

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

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

Недостатки вычисления на удаленном узле

Как было сказано выше, скорость является ключевым аспектом, поскольку передается намного больше данных, чем при удаленном управлении. Частично проблему можно решить использованием кабельных модемов и ADSL, но даже в этом случае скорость будет составлять лишь 1/5 от скорости в ЛВС, если только пользователь не платит ежемесячно $1,000 за персональный канал T1.

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

И последнее замечание по поводу удаленного доступа касается совместимости аппаратных платформ. Заранее не зная конфигурации ПК клиента, часто приходится строго ограничивать список поддерживаемых конфигураций. Это часто ограничивает пользователя

1.1.3 Архитектуры прикладных систем

В составе прикладной системы удобно выделить прикладное программное обеспечение и платформу. Формирующие (наряду с аппаратурой) платформу операционную систему, СУБД и программное обеспечение промежуточного слоя [1-4] вместе называют системным ПО.

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

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

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

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

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

Рассмотрим приложение, которое производит поиск в базе данных согласно определенным пользователем критериям (рис. 1). Пользователь заполняет формы и нажимает кнопку «Поиск». Эта информация передается блоку бизнес-логики для формирования одного или более запросов. Эти запросы один за другим передаются блоку логики доступа к данным, который преобразует данные и запросы в формат, совместимый с СУБД, выполняет каждый запрос, получает результат и преобразует его в формат приложения. Наконец, он возвращает результат блоку бизнес-логики, который объединяет результаты нескольких запросов в порцию информации, передаваемую блоку логики представления; тот помещает эти данные в удобочитаемую форму и показывает ее пользователю.

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

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

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

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

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

Архитектуры прикладных систем

В таблице 1 перечислены наиболее часто встречающиеся архитектуры прикладных систем. Колонка «максимальное число пользователей» может рассматриваться как некоторая мера масштабируемости. Все архитектуры, кроме первой, являются архитектурами распределенных систем.

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

Централизованная архитектура

Одна мощная универсальная ЭВМ была единственной платформой, выполняющей все алгоритмы логики приложения (рис. 2). У централизованной архитектуры множество достоинств: простая разработка приложений, легкость обслуживания и управления. Именно они и обеспечили столь долгую жизнь «унаследованных» систем. Смерть универсальных ЭВМ неоднократно провозглашалась после появления четырех- и восьмиразрядных ПК в начале 80-х годов (компьютеры PET и VIC-20 компании Commodore, TRS-80 компании Radio Shack и множество других машин на базе процессоров Z-80, а также 6502 и 6800 производства Motorola). Однако они продолжали работать, переваривая десятки миллионов транзакций в день, приспосабливаясь к постоянно увеличивающимся нагрузкам.

Разделение файлов

Особое внимание следует уделить одному из типов серверов - файловому серверу (File Server). В распространенной терминологии для него принято сокращенное название - файл-сервер.

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

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

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

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

Подобная архитектура была особенно популярна при использовании продуктов наподобие dBASE, FoxPro и Clipper. Первоначально сети персональных компьютеров были основаны на метафоре совместного использования файлов, потому что это было просто. Однако она хорошо работала лишь в некоторых случаях. Во-первых, все приложения должны вписаться в единственный ПК. Во-вторых, совместное использование и конфликты обновления чрезвычайно снижают производительность. Наконец, учитывая пропускную способность сети, объем данных, которые могут передаваться, также невелик. Все эти факторы крайне ограничивают число параллельных пользователей, которое способна поддерживать архитектура разделения файлов [6-8].

Клиент-сервер

Стремление исправить архитектуру разделения файлов привело к замене файлового сервера сервером баз данных (рис. 4). Вместо передачи файлов целиком он пересылает только ответы на запросы клиентов, уменьшая нагрузку на сеть. Эта стратегия вызвала появление архитектуры клиент-сервер. Появившись в 80-х годах, она ввела понятие «клиента» (сторона, запрашивающая функции/обслуживание) и «сервера» (сторона, предоставляющая функции/обслуживание). На уровне программного обеспечения разделение на клиента и сервер является логическим: процессы клиента и сервера могут физически размещаться как на одной, так и на разных машинах. Под общим концептуальным названием скрываются три варианта архитектуры: двухзвенная, трехзвенная и многозвенная.

Самая старая -- двухзвенная (рис. 5). Она разделяет приложение на две части, клиентскую и серверную. Сторона клиента содержит логику представления, а логика доступа к данным, СУБД и сама база находятся на стороне сервера.

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

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

Но еще хуже имеющее фундаментальный характер ограничения на число одновременных соединений с сервером. Сервер поддерживает открытое соединение со всеми активными клиентами, даже если никакой работы нет. Это необходимо, чтобы сервер мог получать сигналы тактового импульса, что не так страшно, когда клиентов менее 100 [9-12]; однако сверх этого числа производительность начинает быстро деградировать до недопустимо низкого уровня. Хорошим примером возникновения подобной проблемы может служить работа прокси-сервера.

В некоторых прикладных системах бизнес-логику пытаются реализовать, используя хранимые процедуры. Идея состоит в том, чтобы в соответствии с «тонкой» конфигурацией клиента переместить алгоритмы бизнес-логики на серверную машину, ближе к данным, которые требуются им постоянно. Это выглядит как хорошая идея, однако только усугубляет главную проблему. Так как осуществляющие бизнес-правила процессы теперь управляются СУБД, число пользователей, которых может поддерживать такая система, ограничено максимумом возможных активных соединений с СУБД. Кроме того, от СУБД к СУБД механизмы хранимых процедур разнятся. Тем не менее, двухзвенная архитектура хорошо работает в маленьких рабочих группах [9-12]. С начала 90-х годов появилась масса инструментальных средств, упрощающих создание систем в такой архитектуре, в том числе Delphi и PowerBuilder.


Рис. 6. Трехзвенная архитектура

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

Именно выделение бизнес-логики в отдельное звено позволяет преодолеть фундаментальные ограничения двухзвенной архитектуры. Клиенты не поддерживают постоянного соединения с базой данных, а обмениваются информацией со средним звеном только тогда, когда это необходимо. В то же время процесс среднего звена поддерживает всего несколько активных соединений с базой данных, но использует их многократно; поэтому процессы в среднем звене могут предоставлять обслуживание теоретически неограниченному числу клиентов. В сравнении со всеми другими моделями трехзвенная архитектура обладает столь многими преимуществами. Но преимущества не даются даром. Разработка прикладных программ, основанных на трехзвенной архитектуре, -- более трудное дело, чем для двухзвенной архитектуры или при использовании централизованного подхода. Преодолеть возникающие проблемы помогает программное обеспечение промежуточного слоя [5-9].

Трехзвенная архитектура

Рассмотрим четыре варианта распределенных систем, основанных на трехзвенной архитектуре: с сервером приложений, с монитором обработки транзакций, с сервером передачи сообщений и с брокером объектных запросов.

Сервер приложений


Рис. 7. Трехзвенная архитектура с сервером приложений

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

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

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

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

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

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

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

Мониторы обработки транзакций

Мониторы обработки транзакций (transaction processing monitor, TPM) -- самый старый тип технологии распределенных систем, которая появилась в 70-х годах в среде больших универсальных ЭВМ [9-12]. Одной из первых прикладных систем была интерактивная среда поддержки, созданная компанией Atlantic Power and Light для совместного использования прикладных служб и информационных ресурсов в режимах пакетной обработки и с применением среды с разделением времени. TPM (например, IBM CICS) стали главным инструментом построения высоко масштабируемых решений для сетевых прикладных систем. Однако в начале 90-х популярность TPM начала падать; причиной стало появление продуктов категории TPM «Lite» -- мониторов обработки транзакций внутри СУБД. Их функциональные возможности были близки к обычным TPM, и с возрастающей тогда популярностью двухзвенной архитектуры они первоначально обеспечили хорошее решение для создания распределенных прикладных систем.

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

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

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


Рис. 8. Трехзвенная архитектура с монитором обработки транзакций

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

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

В этой конфигурации мониторы могут также обеспечить инфраструктуру для разработки систем, способных обрабатывать ошибки. Например, как видно из рис. 8, Клиент-C и Клиент-D могут обращаться к одним и тем же источникам данных (Сервер Данных C и Сервер Данных D) либо через TPM-C, либо через TPM-D, причем каждый монитор выполняется на своем собственном компьютере. Если один из мониторов выходит из строя, то все клиенты могут переключаться на все еще работающий монитор. Система в этом случае замедлится, но будет способна обеспечить исходный набор функций.

Сервер сообщений

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

Страницы: 1, 2