Файл: Варианты архитектуры «клиент - сервер»..pdf

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

ГЛАВА.3 ОСНОВНЫЕ ХАРАКТЕРИСТИКИ ПРОМЕЖУТОЧНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

3.1.Общая характеристика промежуточного программного обеспечения.

Компания International System Group дает следующее определение этому звену клиент-серверного приложения: это специальный уровень прикладной системы, который расположен между бизнес-приложением и коммуникационным уровнем и изолирует приложение от сетевых протоколов и деталей операционных систем [12].

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

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

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

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

Вторая группа включает в себя:

• ПО, обеспечивающее вызов удаленных процедур (RPC)
• мониторы обработки транзакций
• средства интеграции распределенных объектов
• ПО, реализующее обработку сообщений

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

Рассмотрим отдельные типы промежуточного ПО.

3.2.Системы доступа к БД.

Системы доступа к БД — один из наиболее распространенных типов ПО. Необходимость в подобных решениях возникает в разнородных системах, обеспечивающих одновременный доступ к различным источникам данных, включая СУБД и хранилища данных от разных поставщиков [12]. При этом на сервере приложений развертывается SQL-шлюз, представляющий собой комплекс интерфейсов приложений, предоставляющих возможность построения унифицированных запросов к разнородным данным. Промежуточное ПО данного типа проводит анализ запроса с последующим его преобразованием в SQL-диалект требуемой СУБД. При этом используется синхронный механизм коммуникации, при котором исполнение приложения, осуществившего запрос, приостанавливается до получения данных. Подобный механизм коммуникации может создавать сложности с масштабированием приложения [14]. Применение подобного ПО востребовано в системах поддержки принятия решений, которые агрегируют данные из большого количества разнородных источников, но при этом не требуют управления оперативными транзакциями, например система, выстраивающая прогноз уровня продаж.

3.3.Вызов удаленных процедур.

Вызов удаленных процедур (remote procedure call) — программно обеспечение, реализующее организацию взаимодействия удаленных прикладных компонентов. Данный тип ПО организует синхронный тип коммуникации между прикладными модулями на клиентской и серверной сторонах. Чтобы обеспечить связь, вызов функции и передачу результата создаются специальные модули, называемые суррогатами (клиентский и серверный), к которым и происходит обращение. Суррогаты не содержат компонентов, реализующих бизнес-логику, и служат для обеспечения взаимодействия прикладных компонентов [12]. Любая функция, к которой может произойти обращение из удаленного клиента, обязана иметь реализацию подобного суррогатного процесса. При выполнении вызова клиентской программой удаленной процедуры он, включая параметры, поступает к клиентскокму суррогату. Тот выполняет преобразование вызова в форму сетевого сообщения и передает на сторону серверного суррогата. Тот производит распаковку полученных данных и их передачу прикладному серверу, выполняя затем обратную операцию с полученными результатами. Таким образом происходит изоляция прикладных модулей как на стороне сервера, так и клиента от уровня сетевых коммуникаций.

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

Данный механизм имеет свои недостатки, в частности клиентская часть привязана к конкретным серверным суррогатам с этапа компиляции приложения, и не имеет возможности изменения в период выполнения [14].

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

В основе ПО вызова удаленных процедур лежит язык описания интерфейсов (interface definition language), посредством которого создаются интерфейсы, определяющие контрактные отношения между клиентской и серверной сторонами. Интерфейс включает определение имени функции, а также описание параметров вызова и результатов его обработки. Подобный инструмент обеспечивает независимость механизма вызова удаленных процедур от конкретных языков программирования: при вызове удаленной процедуры на стороне клиента могут применять свои языковые конструкции, которые модифицируются IDL-компилятором в собственный формат. Соответственно, на стороне сервера происходят преобразования в форму языка программирования, с помощью которого реализована серверная часть приложения [12].

В основе некоторой части программного обеспечения этого типа лежит стандарт Open Group DCT RPC.

DCE (Distributed Computer Environment) относится к категории свободно распространяемого программного обеспечения и представлено в виде нескольких реализаций, предназначенных под конкретные операционные системы. Кроме основного механизма обеспечения взаимодействия компонентов распределенного приложения, DCE включает в себя реализацию некоторых востребованных в подобной среде служб, таких как распределенная файловая система, служба каталогов, средства обеспечения безопасности (Рис.6).

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

Рисунок 6. Служба вызова удаленных процедур

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

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

Мониторы обработки транзакций — тип промежуточного программного обеспечения, который широко применялся на мэйнфреймах для развертывания банковских и страховых систем, и использовал специфическое окружение, предназначенное для этих машин [13]. В 90-х годах прошлого столетия появились реализации данного ПО в среде Unix и Windows (Рис.7).

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

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

Каждая транзакция представляет собой некий комплекс обращений к базе данных (или иному ресурсу) и некоторых действий над ней, который характеризуется наличием четырех свойств: атомарность, согласованность, изолированность и долговременность (ACID: Atomicity, Consistency, Isolation, Durability) [12].

• Атомарность — операции транзакции представлены минимальным неделимым блоком, у которого определены начало и конец. Данный блок либо выполняется в полном объеме, либо не исполняется вовсе. В случае возникновения сбоя в процессе исполнения транзакции, выполняется откат к исходному состоянию.
• Согласованность — после исполнения блока транзакции все используемые ресурсы имеют согласованное состояние.
• Изолированность — механизм монитора обработки транзакций реализован таким образом, что при одновременном доступе транзакций, поступающих от различных приложений к разделяемым ресурсам не происходит их взаимного влияния.
• Долговременность — изменения ресурсов, произошедшие в ходе исполнения транзакции являются долговременными.

Рисунок 7. Монитор обработки транзакций.

Те системы, в которых не реализован механизм монитора обработки транзакций, выполнение принципа ACID возлагается на серверы распределенной базы данных, использующей протокол 2PC.

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

Но исполнение протокола P2C может быть гарантированно исполнено в системе с распределенными базами данных лишь при условии, что все источники данных относятся к одному поставщику. Поэтому в масштабных распределенных средах, включающих тысячи терминалов и работающих с множеством разнородных источников данных возникает необходимость в использовании мониторов обработки транзакций [14]. Они обеспечивают эффективную координацию при работе с разнородными данными от различных поставщиков за счет применения транзакционной архитектуры XA, являющейся стандартом для этого типа промежуточного программного обеспечения. Данная архитектура предоставляет интерфейс для обеспечения взаимодействия монитора транзакций с менеджеров ресурсов, таким как СУБД.

Спецификация XA входит в общий стандарт распределенной обработки транзакций (DTP - distributed transaction processing), разработанного группой X/Open [13].

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

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

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

Мониторы транзакций предоставляют мультиплексирование запросов от нескольких терминалов к ресурсам. Для большинства приложений непосредственный доступ клиентского приложения к базе данных составляет лишь некоторую часть от общего времени соединения. С применением мониторов транзакций становится возможным обслуживание 100 клиентских терминалов за счет 10 активных соединений с сервером, на котором развернуты требуемые ресурсы. Это позволяет преодолевать одно из наиболее «узких мест» в обеспечении производительности и масштабируемости распредленных приложений — необходимости поддержки индивидуального соединения с ресурсом для каждого из клиентских приложений. Часть современных мониторов транзакций содержат функционал, позволяющий оптимизировать нагрузку на серверы и обеспечивающий восстановление после сбоя.