6.3 Виды промежуточного по

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

1. Программное обеспечение для межпрограммного взаимодействия (см. также IPC - Inter-Process Communication).

Метод	Реализуется (операционной системой или другим окружением)
Файл	Все операционные системы.
Сигнал	Большинство операционных систем; некоторые системы, как например, Windows, только реализуют сигналы в библиотеке запуска Си, но не обеспечивают их полноценной поддержки для использования методов IPC.
Сокет	Большинство операционных систем.
Канал	Все системы, соответствующие POSIX.
Именованный канал	Все системы, соответствующие POSIX.
Семафор	Все системы, соответствующие POSIX.
Разделяемая память	Все системы, соответствующие POSIX.
Обмен сообщениями (без разделения)	Используется в парадигме MPI, Java RMI, CORBA и других.
Проецируемый в память файл	Все системы, соответствующие POSIX; несет риск появления состояния гонки в случае использования временного файла. Windows также поддерживает эту технологию, но использует API отличный от POSIX.
Очередь сообщений	Большинство операционных систем.
Почтовый ящик	Некоторые операционные системы.

2. Программное обеспечение доступа к базам данных.

Промежуточное по межпрограммного взаимодействия

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

Концепция вызова удаленных процедур(remote procedure call — RPC) была разработана и реализована в компанией XEROX еще начале 80-х годов XX века. Общий смысл RPC можно представить так: программа может выполнять не только собственные (скомпилированные) процедуры и функции, но и обращаться к процедурам удаленного сервера (рис. 2).

Рис. 2. Вызов удаленных процедур

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

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

У RPC как средства организации сетевого взаимодействия есть ряд минусов, кроющихся в самой парадигме структурного программирования:

• Синхронные запросы — RPC приостанавливает выполнение приложения до тех пор, пока сервер не вернет требуемые данные.

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

Для устранения этих недостатков были разработаны более совершенные механизмы реализации RPC:

• асинхронные RPC, позволяющие избежать приостановки выполнения клиентского приложения посредством функций обратного вызова (call-back functions);

• код заглушек вынесен в динамически подключаемые библиотеки.

Протокол взаимодействия RPC также может повлиять на работу системы. Рассмотрим гипотетический фрагмент кода:

for (i = 0, i < 1000, i++)

for (j = 0, j < 1000, j++)

RPC_call();

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

См. также: RFC 1057 Remote Procedure Call Protocol Specification Version 2 (Sun Microsystems), C706 DCE 1.1: Remote Procedure Call (The OpenGroup Distributed Computing Environment (DCE))

Сервисы обработки сообщений(MOM — message-oriented middleware) —это системы, как правило асинхронные, в которых взаимодействие между клиентом и сервером основано на обмене сообщениями.Сообщения— это текстовые блоки, состоящие из управляющих команд и передаваемых данных. Для передачи сообщений используются байт-ориентированные протоколы, такие какHTTP, POP/SMTP и т.п.

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

Рис. 3. Промежуточное обеспечение, ориентированное на обработку сообщений (MOM)

Сервисы MOM хорошо зарекомендовали себя в сильно распределенных приложениях, используемых в гетерогенной сети с медленными и ненадежными соединениями. Это, во-многом, достигается благодаря поддержке уровней «качества обслуживания»:

• надежная доставка сообщений (reliable message delivery) — система MOM гарантирует, что в процессе обмена ни одно сообщение не будет утеряно;

• гарантированная доставка сообщений (guaranteed message delivery) — сообщение доставляется адресату немедленно или через заданный промежуток времени, не превышающий определенного значения (в случае, если сеть в данный момент не доступна);

• застрахованная доставка сообщений (assured message delivery) — каждое сообщение доставляется только один раз.

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

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

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

Сервисы MOM, обслуживающие клиентов по подписке/публикации (publish&subscribe) работают по принципу, напоминающему почтовую рассылку: одно приложение публикует информацию в сети, а другие подписываются на эту публикацию для получения необходимых данных. Взаимодействующие таким способом приложения полностью независимы друг от друга, что представляет возможности динамической реконфигурации всей распределенной системы.

Мониторы обработки транзакций(Transaction Processing monitors, TP-monitors) — это промежуточное программное обеспечение, обеспечивающее контроль передачи данных от клиента при работе с распределенными базами данных. Монитор транзакций обеспечивает целостность данных, следя за тем, чтобы не было потерянных или незавершенных транзакций.Транзакция– это законченный блок обращений к базе данных, для которого гарантируется выполнение четырех условий ACID:

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

• Согласованность (Consistency) – по завершении транзакции все задействованные ресурсы находятся в предопределенном и согласованном состоянии;

• Изолированность (Isolation) – одновременный доступ транзакций различных приложений к разделяемым ресурсам координируется таким образом, чтобы исключить их влияние друг на друга;

• Долговременность (Durability) – все модификации ресурсов в процессе выполнения транзакции будут долговременными.

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

Рис. 4. Монитор транзакций

Подробное описание открытой спецификации Distributed TPдоступно на сайте OpenGroup.

Распределенные объектные системы(Distributed object systems) — это промежуточное программное обеспечение, реализованное в виде взаимодействующих друг с другом программных объектов. Каждый такой объект уникальным образом идентифицируется в сети и обеспечивает доступ к представляемым им сервисам через публичные свойства и методы. Реализация объекта и платформа, на которой он выполняется, полностью прозрачны для клиента.

С точки зрения разработки, использование распределенных объектов оправданно при создании масштабных объектно-ориентированных систем. Фактически же, объектная «обертка» таких решений скрывает за собой ранее рассмотренные RPC, MOM и средства управления транзакциями. По-этому, в первом приближении общий принцип взаимодействия распределенных объектов очень похож на RPC (рис. 5). Это сходство заметно и в средствах описания интерфейсов — объекты используют все тот же IDL. Однако, в сравнении с RPC, распределенные объекты могут компоноваться динамически, т.е. не на этапе компиляции, а во время выполнения приложений.

Рис. 5. Распределенные объектные системы (stub и skeleton - клиентская и серверная заглушки)

Архитектура распределенных объектных систем стандартизована и наиболее распространены спецификации CORBA, COM/DCOM и EJB.

• CORBA (Common Object Request Broker Architecture, типовая архитектура брокера объектных запросов) — открытый стандарт, разработанный группой Object Management Group (OMG), который определяет интерфейсы между сетевыми объектами, позволяющие им работать совместно. Брокеры объектных запросов (object request brokers, ORB), созданные в соответствии с CORBA, представляют интерфейсы для разработки объектно-ориентированных систем «клиент-сервер».

• Microsoft COM (Component Object Model, компонентная объектная модель) — это семейство технологий, предназначенных для организации взаимодействия Windows-приложений (см. MSDN: The Component Object Model). В это семейство входят COM+, DCOM (Distributed COM) и ActiveX Controls. Microsoft позиционирует COM как платформу для разработки повторно используемых (re-usable) компонентов приложений. В случае DCOM — компонентов распределенных клиент-серверных систем.

• EJB (Enterprise JavaBeans) — технология, разработанная Sun Microsystems для корпоративных решений на платформе Java (Java EE/EJB). Спецификация EJB описывает архитектуру серверных компонентов и порядок их использования в клиент-серверных приложениях. Эта технология упрощает разработку распределенных систем на основе Java и обеспечивает наибольшую переносимость Java-приложений.