Все про промежуточное ПО

Программное обеспечение промежуточного слоя (middleware, MW) существует уже почти 30 лет. В 1969 году IBM выпустила монитор транзакций CICS (Customer Information Control Sustems) для приложений на мэйнфреймах и до недавнего времени для многих термин MW ассоциировался исключительно с мониторами транзакций, среди которых позже появился пакет TUXEDO и ряд других систем. Сегодня же, общее впечатление от современного рынка MW - обилие разнообразных продуктов, которые, казалось бы, должны делать примерно одно и то же. Тем не менее, к сегодняшнему дню появилось множество других решений для доступа к ресурсам и организации взаимодействия различных компонентов приложения - именно эти задачи решает MW. Многие западные аналитики отмечают, что примерно с 1997 года на рынке MW начался настоящий бум. Помимо небольших, специализирующихся в этой области компаний, созданием промежуточного ПО озаботились и такие гиганты, как IBM и Microsoft, а также ряд традиционных поставщиков средств разработки приложений, например, Inprise и PowerSoft.

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

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

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

Эволюция архитектуры клиент-сервер

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

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

Современная индустрия MW развивается вокруг этого среднего звена (middle-tier) модели клиент-сервер, а эволюция систем MW идет в сторону их усложнения. Поначалу назначение MW ограничивалось построением более высокого уровня абстракции для взаимодействия приложения с ресурсами данных или различных компонентов приложения между собой. Разработчик приложения получал возможность использовать общие API, которые скрывали различия специфических интерфейсов коммуникационных протоколов более низкого уровня, например, TCP/IP Sockets, SNA LU6.2 или DECNet. Однако теперь этого уже явно недостаточно для построения сложных распределенных приложений. Современные решения MW не только обеспечивают межпрограммное взаимодействие, но и реализуют платформу для среднего звена - сервера приложений, обеспечивая обширный набор необходимых служб: управления транзакциями, именования, защиты и т.д.

Определение и задачи MW

Но уже пора определиться и сформулировать, что же такое MW? Хотя сделать это довольно трудно - определений этого типа ПО в литературе можно встретить столько же, сколько существует разновидностей MW. Многие называют MW «клеем», соединяющим разрозненные части распределенного приложения, некоторые источники сводят MW к программному решению для прозрачного доступа к внешним ресурсам и унаследованным приложениям. Однако наиболее емким и отражающим суть этой категории ПО является определение, которое дает компания International Systems Group, специализирующаяся на разработке и консалтинге в области MW.

ISG определяет MW как специальный уровень прикладной системы, который расположен между бизнес-приложением и коммуникационным уровнем и изолирует приложение от сетевых протоколов и деталей операционных систем [1].

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

MW отвечает за возможность обмена разнородной информацией. Формат представления данных на мэйнфреймах отличается от представления в Unix- или Windows-системах, поэтому прозрачное для пользователя преобразование данных также входит в задачу MW. Таким образом, в распределенной неоднородной среде MW играет роль «информационной шины», надстроенной над сетевым уровнем и обеспечивающей доступ приложения к разнородным ресурсам, а также независимую от платформ взаимосвязь различных прикладных компонентов (рис.1).

Рис. 1. Промежуточное ПО изолирует логику приложений от уровня сетевого взаимодействия и ОС

Весь существующий на сегодняшний день спектр продуктов MW можно разделить на два основных типа - ПО доступа к базам данных и ПО для межпрограммного взаимодействия. К последнему относятся:

• системы, реализующие вызов удаленных процедур (RPC);
• мониторы обработки транзакций (transaction processing monitors - TP-мониторы);
• средства интеграции распределенных объектов;
• MW, ориентированное на обработку сообщений (МОМ).

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

Категории промежуточного ПО

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

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

Подчас и сами SQL-шлюзы скрыты от программиста за ширмой средств разработки. Так, например сиcтема PowerBuilder от Sybase имеет встроенную поддержку большинства популярных баз данных. Использование MW доступа к БД оправдано прежде всего в корпоративных системах поддержки принятия решений (DSS), которые собирают и анализируют данные из множества разнородных источников и не требуют управления оперативными транзакциями. Примером такого приложения может быть система прогнозирования уровня продаж торговой или сервисной компании, которая консолидирует соответствующую информацию из баз данных, расположенных в различных регионах страны. Так, система EDA/SQL компании Information Builders позволит с помощью обычного интерфейса ODBC получить данные из СУБД DB2 на мэйнфрейме, Oracle на миникомпьютере и Sybase на Unix-системе. Подобные решения, помимо поддержки систем класса DSS, способны обеспечить постепенную миграцию важных для бизнеса приложений с унаследованных платформ в архитектуру клиент-сервер.

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

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

RPC

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

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

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

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

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

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

На базе собственной реализации RPC компания Sun в конце 80-х создала среду открытых сетевых вычислений ONC, которая, в частности, включает сетевую файловую систему NFS. Однако большинство систем этой категории MW базируется на стандарте Open Group DCЕ RPC. DCE (Distributed Computing Environment) свободно распространяется в виде исходных кодов и существует в реализациях ряда поставщиков, которые настраивают этот код на определенную операционную систему. Помимо базового механизма взаимодействия распределенных приложений, в DCE реализованы некоторые важные для распределенной среды службы, такие как служба каталогов, средства защиты и распределенная файловая система.

Несмотря на открытость текстов DCE рынок не отреагировал лавиной совместимых с этим стандартом систем. Для многих разработчиков низкоуровневые DCE API представляются слишком сложными для реализации и развертывания приложений. Кроме того, синхронный механизм взаимодействия порождает проблемы с производительностью и масштабируемостью системы. Сейчас у DСЕ появились такие сильные конкуренты на рынке MW, как архитектура распределенных объектов CORBA и МW, ориентированное на передачу сообщений. Правда, сама DCE может выступать в качестве дополнения к новейшим технологиям промежуточного слоя. Так, объектная модель MS DCOM базируется на объектном расширении DCE RPC.

Для полноты картины надо упомянуть о том, что существуют асинхронные реализации механизма RPC (например, NobleNet RPC или в системе Entera компании Inprise). Асинхронный RPC не блокирует выполнение клиентского процесса на время выполнения запроса. Этот вариант удаленного вызова обеспечивает более масштабируемые решения, поскольку значительно сокращает объем поддерживаемой информации о соединении и сеансе связи между клиентом и сервером.

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

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

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

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

• Atomicity (атомарность) - операции транзакции образуют неразделимый, атомарный блок («unit of work») с определенным началом и концом. Этот блок либо выполняется от начала до конца, либо не выполняется вообще. Если в процессе выполнения транзакции произошел сбой, происходит откат к исходному состоянию;
• Consistency (согласованность) - по завершении транзакции все задействованные ресурсы находятся в согласованном состоянии;
• Isolation (изолированность) - одновременный доступ транзакций различных приложений к разделяемым ресурсам координируется таким образом, чтобы эти транзакции не влияли друг на друга;
• Durability (долговременность) - все модификации ресурсов в процессе выполнения транзакции будут долговременными.

В системе без ТР-монитора, обеспечение свойств ACID берут на себя серверы распределенной базы данных (на основе протокола 2РС - two-phase commit). Протокол 2РС описывает двухфазный процесс, в котором перед началом распределенной транзакции все системы опрашиваются о готовности выполнить необходимые действия. Если каждый из серверов баз данных дает утвердительный ответ, транзакция выполняется на всех задействованных источниках данных. Если хотя бы в одном месте происходит какой-либо сбой, будет выполнен откат всех частей транзакции.

Однако в системе с распределенными базами данных выполнение протокола 2РС можно гарантировать только в том случае, если все источники данных принадлежат одному поставщику. Поэтому, для сложной распределенной среды, которая обслуживает тысячи клиентских мест и работает с десятками разнородных источников данных, без монитора транзакций не обойтись. ТР-мониторы способны координировать и управлять транзакциями, которые обращаются к серверам баз данных от различных поставщиков благодаря тому, что большинство этих продуктов помимо протокола 2РС поддерживают транзакционную архитектуру ХА, которая является стандартом для данной категории MW. ХА определяет интерфейс для взаимодействия ТР-монитора с менеджером ресурсов, например, СУБД Oracle или Sybase. Спецификация ХА является частью общего стандарта распределенной обработки транзакций (distributed transaction processing - DTP), разработанного X/Open (рис.2).

Рис. 2. Архитектура распределенной обработки транзакций

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

Прикладные программы взаимодействуют с ТР-монитором посредством специального интерфейса ТХ, позволяющего реализовать в приложении семантику транзакций, разбивая запросы на логические «unit of works». Большинство ТР-мониторов для Unix-платформ и серверов баз данных поддерживают стандарт XA. Windows NT до недавнего времени не обеспечивала это соответствие, но этот недостаток возможно будет устранен в MS Transaction Server.

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

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

Таким образом, ТР-монитор - это не только механизм коммуникаций, но и мощная платформа для реализации логики приложения, хороший кандидат на промежуточное звено многозвенной архитектуры клиент-сервер. Среди присутствующих сегодня на рынке продуктов наибольшей популярностью пользуются: Tuxedo компании BEA Systems, интегрированная в ряд важных корпоративных приложений (например, в PeopleSoft); базирующийся на DCE RPC ТР-монитор Encina компании Transarc (теперь входит в IBM), NCR TopEnd и MS Transaction Server.

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

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

На сегодняшний день существуют два варианта объектного промежуточного ПО - стандартная архитектура брокеров объектных запросов CORBA, поддерживаемая консорциумом OMG, и разработка COM/DCOM компании Microsoft [2]. Обе распространяют принципы вызова удаленных процедур на объектные распределенные приложения и обеспечивают прозрачность реализации и физического размещения серверного объекта для клиентской части приложения; поддерживают возможность взаимодействия объектов, созданных на различных ОО-языках и скрывают от приложения детали сетевого взаимодействия. В DCOM взаимодействие удаленных объектов базируется на спецификации DCE RPC, а CORBA включает описание брокера объектных запросов (ORB), синхронный механизм которого во многом схож с RPC. ORB обеспечивает передачу объектных запросов, поиск необходимых объектных сервисов и возврат результатов клиенту. Как и в стандарте DCE RPC, ключевым компонентом архитектуры CORBA является язык описания интерфейсов IDL, на уровне которого поддерживаются «контрактные» отношения между клиентом и сервером и обеспечивается независимость от конкретного ОО-языка. В отличие от DCE IDL, CORBA IDL поддерживает основные понятия объектно-ориентированной парадигмы (инкапсуляцию, полиморфизм и наследование). В модели DCOM также может использоваться язык IDL собственной разработки Microsoft, который, однако, играет вспомогательную роль и используется в основном для удобства описания объектов. Реальная интеграция объектов в DCOM происходит не на уровне абстрактных интерфейсов, а на уровне бинарных кодов, и это одно из основных различий двух объектных моделей.

И DCOM, и CORBA, в отличие от процедурного RPC, дают возможность динамического связывания удаленных объектов (клиент может обратиться к серверу-объекту во время выполнения, не имея информации об этом объекте на этапе компиляции). В CORBA для этого существует специальный интерфейс динамического вызова DII, а СОМ использует механизм OLE Automation. Информацию о доступных объектах сервера на этапе выполнения клиентская часть программы получает из специального хранилища метаданных об объектах - репозитария интерфейсов Interface Repositary в случае CORBA и библиотеки типов (Type Library) в модели DCOM. Эта возможность очень ценна для больших распределенных приложений, поскольку позволяет менять и расширять функциональность серверов, не внося существенных изменений в код клиентских компонентов программы, которых в корпоративной системе может быть множество. Пример - банковское приложение, основная бизнес-логика которого поддерживается сервером в центральном оффисе, а клиентские системы разбросаны по филиалам в разных городах. Однако, многие отмечают, что механизм динамического вызова CORBA сложен в реализации. Архитектура CORBA - это спецификация, которая помимо механизма взаимодействия с помощью ORB включает в себя ряд общих служб CORBAServices (служба каталогов, защиты, оповещения о событиях, поддержки транзакций и ряд других), а также реализаций объектов для разных прикладных областей. Компании-поставщики используют эту спецификацию для создания собственных продуктов, которые могут взаимодейcтвовать друг с другом по протоколу IIOP.

Спектр поддерживаемых служб для разных систем варьируется. Существуют десятки реализаций CORBA, с полным списком которых можно познакомиться на сервере ОMG www.corba.org/vendors: Iona Orbix, Inprise VisiBroker и BEA ObjectBroker - лишь некоторые из наиболее известных названий коммерческих ORB. Основная реализация СОМ принадлежит Microsoft и интегрирована в Windows. Приобретая Windows 2000 или Windows 98, пользователь получит все возможности объектного взаимодейcтвия DCOM. С помощью своих партнеров Digital и Software AG компания Microsoft предпринимает попытки портировать СОМ и на другие операционные системы - Unix и OpenVMS. Однако, CORBA, изначально нацеленная на кроссплатформную поддержку и реализованная для всех разновидностей Unix, всех версий Windows и многих других важных ОС, имеет очевидное преимущество перед объектной моделью Microsoft.

С другой стороны, Microsoft стремится интегрировать DCOM со средствами разработки приложений, с тем чтобы максимально упростить создание клиент-серверных систем на базе этой технологии. Большинство популярных сред разработки, в том числе PowerBuilder, VisualC++, VisualBasic и Delphi имеют встроенную поддержку DCOM. Сама по себе достаточно сложная в реализации архитектура CORBA до недавнего времени была слабо интегрирована с традиционными средствами разработки, хотя системы объектно-ориентированного анализа и разработки приложений, например, Rational Rose, дают возможность создавать распределенные решения на базе CORBA. Однако сейчас складывается новая ситуация. Основные игроки рынка средств разработки клиентских компонентов распределенных систем, такие как Inprise и PowerSoft (вошедшая в состав Sybase), активно заявляют о себе на арене объектно-ориентированного MW. После приобретения компании Visigenic Inprise стала владельцем брокера объектных запросов VisiBroker, который теперь может использоваться вместе с системами Delphi и JBuilder. Sybase пошла еще дальше - ее Jaguar Component Transaction Server объединяет технологию ORB с возможностями монитора транзакций и, по существу, принадлежит к новой категории MW - Object Transaction Monitor. Основная идея этих компаний - дать разработчику средства размещения на удаленном сервере (среднем звене многозвенной распределенной системы) логики приложения, построенного из компонентов, причем создавать эту логику при помощи традиционных средств типа Delphi и PowerBuilder.

Технологии интеграции распределенных объектов OMG и Microsoft пока достаточно четко разграничивают сферы влияния - CORBA успешно обслуживает большие гетерогенные системы, а СОМ/DCOM используется в менее масштабных проектах из мира Windows. При этом во многих организациях стремятся объединить преимущества двух моделей, поэтому особую актуальность приобретают продукты, способные обеспечить взаимодействие объектов из разных объектных архитектур. В этом отношении инициативу берут на себя разработчики брокеров объектных запросов - в системах от Iona, Inprise, Visual Edge, NobleNet и ряда других поддерживается интероперабельность CORBA и СОМ.

MOM

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

Системы с передачей сообщений (message passing) обеспечивают непосредственное взаимодействие приложений друг с другом путем отправки и получения сообщения. Для этого между программными модулями устанавливается логическое соединение. Отсюда следует, что данное решение не подходит для слабо связанных программ, работающих в независимом временном режиме, например, приложений, определенные компоненты которых обслуживают мобильных пользователей. Обмен сообщениями может происходить в синхронном и асинхронном режиме. Кроме средства непосредственных коммуникаций, системы этого типа могут обеспечивать дополнительные службы промежуточного слоя. Так, например, один из самых развитых продуктов передачи сообщений, PIPES Platform компании PeerLogic, поддерживает мощную и надежную службу каталогов.

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

Рис. 3. Механизм очередей сообщений

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

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

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

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

Очереди сообщений представляют собой мощный, гибкий и в то же время простой механизм межпрограммного взаимодействия. По существу, он приближает нас к новой парадигме разработки приложений - созданию программ, управляемых событиями. Событие одного приложения (представленное сообщением) вызывает определенное действие в другом. И такая модель наиболее близка к реальному взаимодействию процессов в бизнесе реальных компаний. Возможно поэтому, именно на базе очередей сообщений строится большинство продуктов в категории МОМ. Лидером этого сектора рынка является сиcтема MQSeries компании IBM. Ее основным конкурентом считается Microsoft Message Queuing Server (MSMQ). Кроме того, известность приобрели решения компаний BEA (MessageQ), Oracle (AQ), Sybase (dbQ).

Существует еще одна модель обмена сообщениями - модель подписки/публикации (publish&subscribe). Рынок этих систем пока не велик (можно упомянуть лишь решения компаний Tibco Software Rendezvous и Active Software ActiveWeb), но, вероятно, эта модель имеет определенные перспективы для создания гибких, управляемых событиями приложений. Одно приложение публикует информацию в сети, а другое подписывается для получения данных по интересующей его теме. Взаимодействующие таким способом приложения полностью независимы друг от друга и могут ничего не знать о существовании, физическом размещении и состоянии друг друга. Это открывает путь к динамической реконфигурации всей распределенной системы, добавлению и произвольному изменению любых клиентов и серверов без прерывания их работы и полной изоляции прикладных компонентов от любых аспектов реализации других частей системы. В конечном итоге, это означает возможность эффективной интеграции различных бизнес-приложений в единое корпоративное решение.

На рынке представлено уже довольно много систем МОМ, но для них не существует ни стандартного исходного кода, как в случае DCE RPC, ни стандартной спецификации архитектуры, подобной OMG CORBA. Кроме того, МОМ-системы практически не поддерживаются средами разработки. Отсутствие какой бы то ни было стандартизации не позволяет решениям от разных поставщиков взаимодействовать друг с другом и создает хаос на рынке. Чтобы справиться с этим недостатком, еще в 1994 году был создан консорциум Message-Oriented Middleware Association (МОМА), в который вошли компании ВЕА, IBM UK Labs, PeerLogic, Software AG, Sun Microsystems и др. Недавно ассоциация МОМА была переименована в International Middleware Association (IMWA, www.imwa.org). Ее главная цель - широкая пропаганда преимуществ использования систем промежуточного слоя вообще. В качестве корпоративного члена в состав IMWA вошел консорциум OMG и сегодня обе организации намерены объединить свои усилия в распространении и стандартизации различных категорий промежуточного ПО.

Попытка сравнительного анализа

Теперь будет полезно сравнить разные типы MW, тем более, что в реальной жизни они практически не существуют в изоляции друг от друга. Наоборот, происходит явное движение в сторону объединения возможностей разных категорий, и многие из ведущих игроков этого рынка, в том числе ВЕА, Inprise, Microsoft, IBM не ограничивают себя поддержкой какого-либо одного направления, а предлагают целый спектр продуктов для разных типов промежуточного программного обеспечения.

МОМ и RPC. RPC-механизм переносит в распределенную среду традиционную, процедурную модель программирования и практически не требует от разработчиков каких-либо новых знаний и навыков. Не нужно изучать специфические MW API - организация вызова удаленной процедуры ничем не отличается от вызова локальной подпрограммы, и все процессы преобразования типов данных и упаковки их в сетевой формат автоматизирует процедура marshaling, реализованная при помощи IDL-компилятора, клиентского и серверного суррогатов. Системы, ориентированные на передачу сообщений, предлагают пользователю каждая свой специфический набор API и, как правило, не поддерживают автоматизированных процедур marshaling/unmarshaling, требуя от разработчика определенных усилий по преобразованию различных форматов данных.

RPC в большинстве случаев реализует синхронные коммуникации, тогда как большая часть МОМ-продуктов ориентирована на асинхронный режим связи между прикладными компонентами. То есть, ни одна из взаимодействующих процедур не будет блокирована на время передачи и обработки сообщения и может вообще не рассчитывать на какой-либо ответ от удаленной процедуры. Это, несомненно, более гибкий и более масштабируемый подход к взаимодействию удаленных частей приложения и даже разных приложений. Кроме того, большинство продуктов МОМ обеспечивают поддержку различных сетевых протоколов, а некоторые имеют в своем арсенале такую возможность, как context bridge - средство прозрачной передачи сообщения через несколько различных протоколов. RPC обычно требует использования стека протоколов TCP/IP. Поэтому МОМ-система, в особенности продукты, использующие механизм очередей сообщений, может оказаться более подходящим для современной корпоративной системы, компоненты которой работают в независимом временном режиме, разнесены географически, используют разнородную сетевую среду и включают поддержку мобильных пользователей. А RPC-системы больше подойдут для традиционных клиент-серверных приложений, в том числе двухзвенных с реализацией логики приложения в хранимых процедурах баз данных. В основе таких приложений лежит модель «запрос/ответ» с передачей управления от одного модуля приложения к другому.

В качестве примера интеграции возможностей обеих категорий можно привести систему Inprise Entera/Qx, которая с одной стороны, организует унифицированный RPC-интерфейс к различным MQ-системам, скрывая от пользователя детали частных MQ API различных поставщиков, а с другой, предоставляет традиционным DCE-приложениям, в частности, Inprise Entera, доступ к гибким средствам межпрограммных коммуникаций на базе очередей сообщений.

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

Объектно-ориентированные системы перестают быть данью моде и становятся настоятельной необходимостью для многих корпоративных приложений. Работая в объектной среде, разработчик получает удобную, четко организованную базовую архитектуру построения приложения из бизнес-объектов. Высокий уровень абстракции брокера объектных запросов полностью скрывает от пользователя механику коммуникаций между объектами - как и в случае RPC, ОRB автоматизируют процессы marshaling/unmarshaling и не требуют написания какого-либо кода для организации сетевых коммуникаций, необходимого при использовании МОМ и ТР-мониторов. Кроме того, многие ORB-системы обеспечивают возможность разработки Web-приложений и интеграцию с Java.

Однако, ORB-системы, как и DCE RPC, по большей части поддерживают синхронную связь и, в отличие от МОМ, не всегда подходят для интеграции унаследованных систем, поскольку не реализованы, например, для ОС MVS. Поэтому объектно-ориентированное MW - наилучший вариант именно для объектно-ориентированных приложений с не очень высокими требованиями к масштабируемости. Категория МОМ, прежде всего MQ-системы, как правило, поддерживают широчайший спектр сетевых и операционных платформ, в том числе мэйнфреймов, поэтому они успешно справятся с проблемой построения сильно распределенной и очень неоднородной среды.

Компании-разработчики стремятся объединить преимущества этих двух наиболее интенсивно развивающихся категорий MW, используя очереди сообщений как нижний коммуникационный уровень для брокеров объектных запросов. BEA Systems интегрирует свой ObjectBroker c MessageQ, брокер объектных запросов IONA Orbix будет поддерживать IBM MQSeries, а доступ к сервисам MSMQ может осуществляться посредством интерфейсов объектной модели СОМ. Объединение двух технологий позволит строить гибкую структуру MW для интеграции приложений на разных платформах, в том числе и мэйнфреймах. Брокеры объектных запросов скрывают реализацию унаследованных приложений за IDL-интерфейсом, позволяя таким образом включить традиционные системы в общую объектную среду. Миллион строк на Коболе могут быть представлены как один большой объект, если написать для них интерфейс на IDL. А для связи с теми платформами, которые не поддерживает ORB, можно использовать механизм очереди сообщений.

Отражая эту тенденцию к интеграции, новая версия CORBA 3.0 включает спецификацию службы asynchronous messaging, а также описание asynchronous method invocation, которое определяет возможности и способы асинхронных вызовов методов в соответствии с предусмотренным качеством обслуживания.

Но есть и примеры обратной связи - реализующая механизм подписки/публикации система Tibco Software Rendezvous базируется на ORB этой же компании.

МОМ и ТРМ

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

Промежуточные системы на базе очередей сообщений могут поддерживать обработку транзакций, разбивая большие синхронные транзакции, которые модифицируют несколько распределенных, разнородных баз данных, на меньшие асинхронные транзакции, взаимодействующие друг с другом посредством очередей. Однако сами МОМ-системы не обеспечивают поддержку свойств ACID, не гарантируют целостности синхронных транзакций для множества программных компонентов, и не реализуют такого набора сервисов, который характерен для ТР-мониторов. Поэтому МОМ не годятся на роль инфраструктуры для систем OLTP. Но они для этого и не предназначаются. Хотя, как и в случае интеграции с ОRB, могут использоваться как более производительный асинхронный коммуникационный уровень для ТР-монитора. Компания ВЕА, например, планирует применять средства MessageQ в своем мониторе транзакций Tuxedo, IBM Encina может использовать MQSeries, а Microsoft интегрирует MTS и Message Queuing Sever.

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

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

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

Рис. 4. Корпоративный сервер приложений

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

Индустрия серверов приложений нацелена на создание объектно-ориентированных распределенных систем и в ближайшей перспективе - на построение прикладных программ из готовых компонентов. Поэтому существующие на сегодняшний день и находящиеся в стадии разработки решения базируются на одной из двух компонентных моделей - MTS/DСОМ (в перспективе СОМ+) и CORBA/EJB. Microsoft намерена сделать Windows NT и Windows 2000 базовой платформой для серверов приложений, которые, однако, впишутся в информационную инфраструктуру только тех компаний, которые предпочитают продукты MS всему остальному.

Многоплатформные Web-системы должны делать ставку на CORBA/EJB. Еще недавно модель построения серверных компонентов Enterprise JavaBeans, которая имеет свой собственный механизм взаимодействия клиентских и серверных Java-объектов RMI (remote method invocation) рассматривалась как конкурент архитектуре распределенных объектов CORBA. Однако, сегодня их создатели, OMG и Sun, рассматривают EJB и CORBA как взаимодополняющие решения. Объекты CORBA и компоненты EJB инкапсулируют бизнес-логику. Для взаимодействия удаленных объектов может использоваться как ORB, так и RMI API, надстроенные над протоколом IIOP. EJB будет поддерживать механизм транзакций в соответствии со спецификацией JTS, которая, в свою очередь, базируется на CORBA Object Transaction Service. CORBA предоставляет ряд необходимых для сервера приложений служб: службу каталогов для поиска объектов в сети по имени, а не физическому адресу, службу оповещения о событиях, службу защиты, которая обеспечивает аутентификацию клиентов и серверных компонентов и при необходимости шифрование сообщений, а также ряд других. Наконец, EJB обеспечивает кроссплатформность реализации («написано однажды, выполняется везде»), а брокеры объектных запросов позволят интегрировать различные платформы.

Среди разработчиков первых серверов приложений фигурируют как небольшие компании, бизнес которых связан имено с этой категорией ПО (Bluestone, GemStone, Novera, Persistance и др.), так и уже знакомые нам имена. Известные поставщики различных систем MW стремятся объединить лучшие их коммуникационные и сервисные возможности под крышей сервера приложений. После приобретения компании WebLogic, которая разработала сервер приложений на базе EJB, BEA Systems намерена активно осваивать этот рынок и привнести в сервер приложений WebLogic весь опыт, накопленный за время работы с мониторами транзакций и ORB. IBM создает свой сервер приложений под названием WebSphere как базовую платформу разработки и развертывания корпоративных приложений и будет использовать в ней ОTM ComponentBroker. Inprise имеет в свое арсенале интегрированный комплекс средств Inprise Application Server для поддержки всех стадий жизненного цикла информационной системы. Этот продукт использует ORB VisiBroker, реализует службы именования, событий и транзакций CORBA и в ближайшее время будет поддерживать EJB.

Литература

1. Middleware — the essential component for enterprise client/server applications. ISG White Paper, 1997
2. Наталья Дубова. СОМ или CORBA?, «Открытые системы», №3, 1999

Наталья Дубова (dubova@osp.ru) -- научный редактор,"Открытые системы. СУБД", (Москва).