Трехзвенные схемы

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

(рис. 9.2).

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

Сервер баз данных, как и в двухзвенной модели, выполняет функции двух последних слоев — операции внутри базы данных и файловые операции. Примером такой схемы может служить неоднородная архитектура, включающая клиентские компьютеры под управлением Windows 95/98, сервер приложений с монитором транзакций TUXEDO в среде Solaris на компьютере компании Sun Microsystems и сервер баз данных Огас1е в среде Windows 2000 на компьютере компании Соmpag.

Вывод:

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

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

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

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

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

· Основными характеристиками коммуникационных примитивов являются:

1. способ адресации;

2. наличие синхронизации;

3. способ буферизации;

4. степень надежности доставки.

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

· Еще одним удобным механизмом, облегчающим взаимодействие операцион­ных систем и приложений по сети, является механизм вызова удаленных про­цедур (Remote Procedure Call, RPC). Идея, положенная в основу КРС, состоит в том, чтобы вызов удаленной процедуры по возможности выглядел так же, как и вызов локальной процедуры.

Рис. 9.2.Трехзвенная схема распределения частей приложения

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

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

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

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

· средства асинхронной обработки сообщений (message-oriented middleware MOM);

· средства удаленного вызова процедур (Remote Procedure Call, RPC);

· брокеры запроса объектов (Object Request Broker, ORB), которые находят объекты, хранящиеся на различных компьютерах, и помогают их использо­вать в одном приложении или документе.

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

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