Средства middleware и их классификация

Александр Касаткин

К средствам middleware (промежуточного, или межплатформного, программного обеспечения) сейчас проявляется большой интерес. Рынок этих средств рос в последнее время экспоненциально, и, по различным оценкам, в ближайшие годы такая тенденция сохранится. В данной статье делается попытка ответить на вопрос “Что такое middleware?”, предлагается классификация средств middleware и определение области их применения.

Термин “промежуточное программное обеспечение” (ППО) является довольно устоявшимся, но в то же время его нередко используют для обозначения разных понятий. С самой общей точки зрения ППО является типом программного обеспечения, предоставляющим API между приложением и ресурсами, необходимыми ему для нормального функционирования. Исходя из этого, промежуточным может быть названо любое ПО, позволяющее упростить процесс взаимодействия приложений друг с другом или с ресурсами. Возникает логичный вопрос: а является ли операционная система ППО? В общепринятом смысле - нет, поэтому представляется целесообразным более узкое определение: промежуточным называется программное обеспечение, предоставляющее интерфейсы между приложением и необходимыми ему программными ресурсами (которые также могут являться приложениями).

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

Классификация middleware

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

Классификация средств middleware

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

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

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

К этому типу ППО относятся средства реализации спецификаций ODBC (Object Database Connectivity), OLE DB, JDBC (Java Object Database Connectivity). Средства ODBC, в частности, дают разработчику некоторый “базовый” набор функций, поддерживаемых различными серверами реляционных баз данных. Программист, использующий этот API, не заботится о том, к какому серверу он обращается, - эти функции переложены на ODBC, что позволяет уделять больше внимания основной логике создаваемого приложения.

Мониторы транзакций. Если ППО доступа к БД решает именно проблему взаимодействия с БД, то мониторы обработки транзакций (в англоязычной спец. литературе - TP-мониторы) оптимизируют работу системы. TP-мониторы располагаются между клиентом и сервером БД и являются вторым уровнем трехзвенной архитектуры. Клиентское приложение инициирует транзакцию в мониторе. Тот, в свою очередь, запускает при необходимости транзакцию базы данных, получает ее результат и перенаправляет его обратно клиентскому приложению.

Основное преимущество транзакций в том, что они позволяют “оформить” часть приложения как транзакцию. Транзакция отличается от простой последовательности команд своей целостностью: если во время ее выполнения возникает та или иная критическая ситуация (например, отказ одного из ресурсов), ТР-монитор может автоматически вернуть систему в исходное состояние (осуществить откат транзакции). Поддержка транзакционности присуща многим системам, а не только ТР-мониторам. Что же заставляет выделять их в отдельную группу ППО? Такой отличительной чертой является способность оптимизации доступа к ресурсам. В частности, поскольку клиенты в трехзвенной архитектуре напрямую к СУБД не подключаются, монитор транзакций может осуществлять мультиплексирование (накопление или смешивание) запросов, направляя целую их пачку в рамках одного подключения к БД. Кроме того, клиентское приложение может инициировать транзакцию, содержащую запросы на изменение информации в нескольких базах данных, не обязательно однородных. Монитор транзакций и в этом случае выполняет функции ППО, предоставляя приложению виртуальный доступ к различным БД.

Наиболее популярными мониторами транзакций являются Microsoft Transaction Server, Tuxedo фирмы BEA Systems, CICS производства IBM, Encina компании Transarc и др.

ППО второго типа

ППО, отнесенное по нашей классификации ко второй группе (middleware, обеспечивающее взаимодействие между активными приложениями), может быть условно разбито на три основных типа: ППО удаленного вызова процедур (RPC, Remots Procedure Call), ППО передачи сообщений (MOM, Message Orientet middleware) и ППО брокеров объектных запросов (ORB, Object Request Broker).

Технология RPC. RPC была первой на рынке промежуточного ПО (хотя в то время такого понятия не существовало). Средства RPC появились в начале 80-х годов, а их главным предназначением было обеспечение возможности выделения части создаваемого приложения для выполнения на удаленной машине. При использовании RPC разработчик организует вызов удаленного метода программы так, как если бы код этой функции находился в локальной машине. Код RPC “присоединяется” к обоим приложениям - источнику и приемнику, осуществляет необходимые преобразования данных и запускает подпрограммы передачи данных по сети.

До недавнего времени применение RPC было сопряжено с немалыми сложностями, когда приходилось обращаться к приложению, написанному на другом языке программирования или работающему под другой ОС. Современные средства RPC позволяют разработчику действовать на более высоком уровне абстракции, не задумываясь о специфике языка программирования и ОС, - RPC стала удобным механизмом для взаимодействия приложений на различных программно-аппаратных платформах. Распространение Java вызвало к жизни аналог RPC для Java-приложений - RMI (Remote Method Invocation).

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

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

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

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

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

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

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

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

В настоящее время основная доля рынка MOM принадлежит двум компаниям - IBM с ее продуктом IBM MQSeries и Microsoft с MSMQ. IBM MQSeries отличается многоплатформностью, поддержкой различных сетевых протоколов и открытостью интерфейсов, позволяющих легко наращивать функциональность системы. Главное достоинство MSMQ - его тесная интеграция с OC Windows, а также поддержка COM.

ORB. Технология брокеров запросов к объектам является наряду с MOM наиболее бурно развивающимся типом ППО. ORB управляют обменом сообщениями в сети. Подобно “человеческому” брокеру, ORB выполняет функции интеллектуального посредника, т. е. принимает запросы от клиента (клиентского приложения), осуществляет поиск и активизацию удаленных объектов, которые принципиально могут ответить на запрос, и передает ответ объектам запрашивающего приложения. ORB, как и RPC и MOM, скрывает от пользователя процесс доступа к удаленным объектам. Запрашивающий объект должен знать имя активизируемого объекта и передать ему некоторые параметры (как правило, это информация об интерфейсе вызываемого объекта - своего рода API для ORB). Интерес к ORB подогревается тем, что это middleware поддерживает объектную модель, ставшую де-факто стандартом при разработке больших информационных систем. В настоящее время на рынке конкурируют стандарт CORBA и технология COM корпорации Microsoft.

Области применения middleware

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

Но вернемся к вопросу о применении конкретных типов middleware. Здесь можно дать следующие рекомендации. При работе с базами данных одного типа следует применять ППО баз данных. Если необходимо осуществлять работу с различными типами БД или оптимизировать процесс доступа, то целесообразно применение мониторов транзакций. При взаимодействии приложений для обеспечения синхронного соединения можно использовать средства RPC, а для организации совместной работы слабосвязанных приложений, соединение между которыми не всегда надежно, - средства MOM. Вообще, MOM и ORB являются наиболее универсальными средствами middleware и могут применяться в большинстве случаев для организации связи между приложениями.

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

Александр Касаткин - начальник отдела разработки корпоративных систем Digital Design. К нему можно обратиться по адресу: akas@digdes.com.