Промежуточное программное обеспечение. Категории middleware

Категории промежуточного программного обеспечения

1. Доступ к базам данных

В простых двухзвенных моделях клиент-сервер в роли встроенного MW доступа к данным могут выступать обычные ODBC-драйверы.

Необходимость в более сложных решениях возникает в больших, разнородных многозвенных системах, где множество приложений в параллельном режиме осуществляет доступ к разнообразным источникам данных, включая СУБД и хранилища данных от различных поставщиков. В таких системах между клиентами и серверами баз данных размещается промежуточное звено - SQL-шлюз, который представляет собой набор общих API, позволяющих разработчику строить унифицированные запросы к разнородным данным (в формате SQL или с помощью ODBC-интерфейса). SQL-шлюз выполняет синтаксический разбор такого запроса, анализирует и оптимизирует его и в конце концов выполняет преобразование в SQL-диалект нужной СУБД.

2. RPC

Впервые спецификация вызова удаленных процедур (remote procedure call - RPC) была разработана еще начале 80-х (компания XEROX).

RPC поддерживает синхронный режим коммуникаций между двумя прикладными модулями (клиентом и сервером). Для установки связи, передачи вызова и возврата результата клиентский и серверный процессы обращаются к специальным компонентам - клиентскому и серверному суррогатам (client stub и server stub). Эти stub-процедуры не реализуют никакой прикладной логики и предназначены только для организации взаимодействия удаленных (в общем случае) прикладных модулей. Каждая функция на сервере, которая может быть вызвана удаленным клиентом, должна иметь такой суррогатный процесс. Если клиент вызывает удаленную процедуру, вызов вместе с параметрами передается клиентскому суррогату. Он упаковывает эти данные в сетевое сообщение (этот процесс называется marshaling) и передает его серверному суррогату. Тот, в свою очередь, распаковывает полученные данные (unmarshaling), передает их реальной функции сервера и затем проделывает обратную процедуру с результатами. Таким образом, процедуры-суррогаты изолируют прикладные модули клиента и сервера от уровня сетевых коммуникаций.

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

Ключевым компонентом RPC является язык описания интерфейсов (Interface Definition language - IDL), предназначенный для определения интерфейсов, которые задают контрактные отношения между клиентом и сервером. Интерфейс содержит определение имени функции и полное описание передаваемых параметров и результатов выполнения. Язык IDL обеспечивает независимость механизма RPC от языков программирования - вызывая удаленную процедуру, клиент может использовать свои языковые конструкции, которые IDL-компилятор преобразует в свои описания. И обратно, на сервере IDL-описания преобразуются в конструкции языка программирования, на котором реализован серверный процесс.

Существующий уже не один десяток лет язык IDL пережил второе рождение в объектных моделях CORBA и СОМ. И та и другая используют RPC-подобный механизм взаимодействия распределенных объектов и свои собственные языки описания интерфейсов.

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

Порядка 20 лет мониторы обработки транзакций (transaction processing - TP) активно использовались на мэйнфреймах для реализации банковских, страховых и других высококритичных систем. К середине 90-х вместе с миграцией таких приложений в среду клиент-сервер на базе UNIX и Windows NT, старые ТР-мониторы стали переноситься на новые платформы. Одновременно появились разработки для UNIX.

Основная функция ТР-мониторов - автоматизированная поддержка целостности приложений, оформленных в виде последовательности транзакций. Каждая транзакция - это законченный блок обращений к ресурсу (как правило, базе данных) и некоторых действий над ним, для которого гарантируется выполнение четырех условий, так называемых свойств ACID (Atomicity, Consistency, Isolation, Durability).

В Относительно несложной системе обеспечение свойств ACID берут на себя серверы распределенной базы данных на основе протокола 2РС - two-phase commit.

Однако в системе с распределенными базами данных выполнение протокола 2РС можно гарантировать только в том случае, если распределенная система является однородной (все источники данных принадлежат одному поставщику). Поэтому, для сложной распределенной среды (тысячи клиентских мест, десятки разнородных источников данных) для координации и управления транзакциями используется стандарт X/Open DTP (X/Open - компания, Distributed Transaction Processing - группа). Стандарт определяет три взаимодействующих между собой компонента: приложение, менеджер транзакций (монитор транзакций) TM и менеджер ресурсов RM.

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

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

Прикладные программы взаимодействуют с ТР-монитором посредством специального интерфейса ТХ, позволяющего реализовать в приложении семантику транзакций, разбивая запросы на логические "unit of works". Интерфейс TX включает вызовы функций для определения границ транзакций, а также для фиксации и отмены транзакций.

ТР-мониторы взаимодействуют с менеджерами ресурсов (сервера баз данных от различных поставщиков) по другому стандарту - протоколу ХА. Наконец, приложение может взаимодействовать с менеджером ресурсов непосредственно через интерфейс SQL или API.

Дополнительные функции мониторов транзакций:

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

4. Интеграция распределенных объектов

На сегодняшний день существуют два варианта объектного промежуточного ПО:

В DCOM взаимодействие удаленных объектов базируется на спецификации DCE RPC, а CORBA включает описание брокера объектных запросов (ORB), синхронный механизм которого во многом схож с RPC. ORB обеспечивает передачу объектных запросов, поиск необходимых объектных сервисов и возврат результатов клиенту.

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

Общее между ними:

  1. обе технологии распространяют принципы вызова удаленных процедур на объектные распределенные приложения и обеспечивают прозрачность реализации серверного объекта для клиентской части приложения;
  2. оба инструмента поддерживают возможность взаимодействия объектов, созданных на различных ОО-языках и скрывают от приложения детали сетевого взаимодействия;
  3. и DCOM, и CORBA, в отличие от процедурного RPC, дают возможность динамического связывания удаленных объектов (клиент может обратиться к серверу-объекту во время выполнения, не имея информации об этом объекте на этапе компиляции).
  4. в обоих стандартах для работы с объектами используется язык описания интерфейсов IDL, на уровне которого поддерживаются "контрактные" отношения между клиентом и сервером и обеспечивается независимость от конкретного объектно-ориентированного языка.

Различия:

  1. В отличии от CORBA в модели DCOM язык IDL играет вспомогательную роль и используется в основном для удобства описания объектов. Реальная интеграция объектов в DCOM происходит не на уровне абстрактных интерфейсов, а на уровне бинарных кодов, и это одно из основных различий двух объектных моделей.
  2. Основная реализация СОМ принадлежит Microsoft и интегрирована в Windows. CORBA, изначально нацеленная на кроссплатформную поддержку и реализованная для всех разновидностей Unix, всех версий Windows и многих других важных ОС, имеет очевидное преимущество перед объектной моделью Microsoft. Отсюда расграничение сферы влияния: CORBA успешно обслуживает большие гетерогенные системы, а СОМ/DCOM используется в менее масштабных проектах из мира Windows.

Замечание: с другой стороны, Microsoft опережает в интеграции DCOM со средствами разработки приложений, с тем чтобы максимально упростить создание клиент-серверных систем на базе этой технологии. Большинство популярных сред разработки, в том числе PowerBuilder, VisualC++, VisualBasic и Delphi имеют встроенную поддержку DCOM. Сама по себе достаточно сложная в реализации архитектура CORBA до недавнего времени была слабо интегрирована с традиционными средствами разработки (исключение VisiBroker от ).

5. Промежуточное программное обеспечение, ориентированное на обработку сообщений

Message Oriented Middleware (MOM) - промежуточное ПО, ориентированное на обработку сообщений. Согласно этой модели приложения обмениваются байтовыми строками - сообщениями, обращаясь к АPI-интерфейсу системы МОМ, который изолирует их от непосредственного взаимодействия с ОС и сетевыми протоколами. В отличие от всех уже рассмотренных модел - промежуточное ПО, ориентированное на обработку сообщений. Согласно этой модели приложения обмениваются байтовыми строками - сообщениями, обращаясь к АPI-интерфейсу системы МОМ, который изолирует их от непосредственного взаимодействия с ОС и сетевыми протоколами. В отличие от всех уже рассмотренных моделей промежуточного ПО, МОМ реализует скорее равноправные (peer-to-peer), чем подчиненные (клиент-сервер) отношения между модулями приложениями.

По способу обмена сообщениями все продукты МОМ разбиваются на две подгруппы:

Системы с передачей сообщений (message passing) обеспечивают непосредственное взаимодействие приложений друг с другом путем отправки и получения сообщения. Для этого между программными модулями устанавливается логическое соединение на время взаимодействия.

Большая часть МОМ-систем реализует асинхронный механизм очередей сообщений (message queuing - MQ). В отличие от передачи сообщений, эта модель межпрограммного взаимодействия не требует поддержки непосредственного соединения одного прикладного модуля с другим, но гарантирует доставку сообщения даже в том случае, если программа-адресат в данный момент не доступна. Программа-отправитель передает сообщение MQ-системе и продолжает выполнение. Сообщение помещается в локальное промежуточное хранилище - очередь сообщений, размещенную в оперативной памяти или на диске, откуда оно может быть немедленно или через какое-то время передано программе-получателю. Таким образом, приложения, которые используют эту модель связи, могут работать практически независимо друг от друга без временной синхронизации. Поэтому механизм очередей сообщений является удачным решением для реализации потоков работ и поддержки приложений в глобальных сетях с медленными и не очень надежными соединениями.

Большинство MQ-систем включает менеджер очереди (Queue Manager), который управляет локальными очередями, гарантирует передачу сообщений нужному адресату и, взаимодействуя с менеджерами на других узлах, следит за сетевым маршрутом передачи сообщения, выбирая альтернативный путь, если по тем или иным причинам основной оказывается недоступен.

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

6. Сервера приложений

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