Представьте себе проект, над которым работает такая разношерстная команда, что один из ее членов говорит по-английски, другой - по-французски, а третий - по-китайски. И как быть, если участникам нужно прочитать и написать небольшое сообщение на китайском? Но для чтения и подготовки сообщений на китайском вовсе необязательно штудировать Конфуция.
Именно такого рода паллиативное решение предлагается программным обеспечением промежуточного уровня, ориентированным на сообщения и известным под названием MOM (message-oriented middleware). По своей сути MOM - это технология, которая позволяет одному приложению общаться с другими в распределенной среде, используя общие механизмы коммуникации. По мнению участников консорциума производителей Message Oriented Middleware Association (MOMA), технология эта действительно занимает промежуточный уровень между логикой приложения и лежащей в основе информационной системы сетевой средой. Концепция MOM проверена временем, поскольку этот метод используется десятилетиями, еще с тех пор, когда впервые начали внедряться среды исполнения программ, независимые от ОС.
С распространением идеи распределенных сред новые достижения в технологиях промежуточного ПО, в частности поддержка обмена сообщениями, способствуют возобновлению интереса к инструментарию MOM.
"Среды, поддерживающие передачу сообщений, существуют уже около 20 лет, - говорит Боб Шер, президент MOMA. - Самое поразительное, что поддержка сообщений является одновременно новейшей и очень старой технологией. Причина этого, в частности, в том, что уровни поддержки сообщений были отчуждены от размещения сообщений. Поэтому большая часть полезной информации добавлялась в само сообщение".
Главная особенность инструментария MOM в том, что он создает и/или передает сообщения. Сообщение обычно включает в себя информацию или инструкции для получающего его приложения. На этом сходство заканчивается: огромный спектр инструментария MOM предлагает широкий диапазон самых разных возможностей. У большинства это чаще всего интеграция разрозненных данных, обычно унаследованных из старых вычислительных систем.
"Компании используют поддержку сообщений как способ реконструкции методов, используемых для создания архитектуры приложений, - сказал Рой Шалт, вице-президент компании Gartner Group. - Они реконструируют приложения, касающиеся архитектуры, ориентированной на оказание услуг и используют обмен сообщений для ее реализации. Преимущество в том, что вы можете реконструировать приложения, не переписывая их".
Сейчас или позже
Все продукты MOM принимают и передают сообщения, но инструментальные средства у них во многом различны. Так, по словам представителей MOMA, их продукты можно разделить на две условные категории: продукты реального времени и с очередями сообщений. Системы поддержки сообщений реального времени передают информацию сразу; в большинстве случаев получающее приложение немедленно приступает к обработке запроса, либо отвечает отказом.
Когда представитель электронного магазина, разговаривая с покупателем по телефону, посылает запрос на данные о покупателе с настольной системы, запрос может активизировать много сообщений к различным клиентским системам. Эти сообщения посылают запросы к различным базам данных на получение счета, адреса, информации о состоянии заказа, получают требуемые сведения и немедленно перенаправляют эти данные на настольную систему.
К продуктам MOM реального времени относятся Pipes Platform компании PeerLogic; MDp компании Early Cloud и Rendezvous Information Bus компании Tibco.
Продукты, поддерживающие очередь сообщений, с другой стороны, допускают хранение сообщений в MOM и их обработку только тогда, когда получающее приложение свободно. Продукты этого типа предполагают, что задержка при обработке сообщений не обязательно помешает обработке запроса.
К достоинствам очередей сообщений относится то, что получающая программа при поступлении нового запроса не должна прекращать выполняемую в этот момент работу. Она может также переслать сообщение другому приложению. Системы с очередями сообщений используются для автоматизации процессов, в которых каждый следующий шаг зависит от предыдущего. Они также подходят для приложений, осуществляющих связь с клиентом, при которой нет прямых взаимодействий с пользователем. Кроме того, в интерактивном окружении системы с очередями сообщений могут быть использованы в зависимости от специфических требований; они также долгие годы применялись в качестве ключевых компонентов в мониторах обработки транзакций, таких как CICS компании IBM.
Среди продуктов, поддерживающих очереди сообщений, можно назвать MQSeries компании IBM; DECmessageQ компании Digital Equipment; XIPC компании Momentum Software и Enterprise Transaction Express компании Tibco. Microsoft тоже готова вступить в игру со своим МОМ-продуктом, получившим название Falcon.
К продуктам промежуточного типа относится следующее поколение системы Rendezvous, которая, как сказал Марк Боулес, вице-президент по продуктам Information Bus компании Tibco, будет осуществлять обработку сообщений как реального времени, так и с организацией очередей.
Возможные альтернативы
Самое сложное в технологии обмена сообщениями - это определить, в каких случаях использовать ее, а не конкурентные технологии промежуточного ПО. Функции, предлагаемые различными подходами к промежуточному ПО, иногда перекрываются. Самые острые споры развертываются между сторонниками обмена сообщениями и теми, кто предпочитает технологию вызова удаленных процедур (RPC, Remote Procedure Call).
При помощи механизма RPC приложение вызывает процедуры, размещенные в другой программе, возможно даже на другом компьютере - отсюда название "remote" (удаленные). В системах обмена сообщений вызовы могут быть сделаны к удаленным процедурам, находящимся где угодно в сети и на каких угодно платформах. Из-за столь существенного сходства между RPC и поддержкой сообщений, многие приложения могут быть разработаны с использованием любого из двух подходов.
Однако при использовании RPC управление передается от одной процедуры к другой; вызывающая программа блокируется до тех пор, пока не завершится удаленная процедура. Система по сути становится синхронной. Это означает, что другие функции не могут выполняться, пока обрабатывается вызов. Асинхронные или многозадачные коммуникации могут осуществляться системами с RPC через создание потоков, если они поддерживаются, но это увеличивает уровень сложности приложения. RPC прекрасно подходит для систем, в которых обязателен тесный контроль взаимодействия между процессами или там, где приложения всегда дожидаются ответа на свой запрос.
Современные продукты, связанные с поддержкой приложений, создаются обязательно асинхронными, что позволяет приложениям и компьютерам обрабатывать другие запросы во время ожидания возврата сообщения. В целом, системы, основанные на обмене сообщений, очень хорошо масштабируются. Они работают с тысячами пользователей, сообщений и компонентов приложений и весьма широко распространены. Они великолепно подходят для интегрированных проектов, которые используют элементы и составные части разрозненных приложений, для слабосвязанных сред или для систем с множеством разнородных клиентов.
К примеру, Motorola SPS (подразделение корпорации) работает с большим количеством измерительных и контролирующих программ, статистическими методиками управления процессом, автоматическими обрабатывающими устройствами и другими технологиями для управления производством полупроводников. Эти устройства, в свою очередь, управляются широким кругом разнородных аппаратных платформ и ПО, основанным на унаследованных системах и новых технологиях. Около четырех лет назад Motorola SPS начала применять продукты MOM компании Tibco для того, чтобы интегрировать эти разнообразные технологии в центральную систему мониторинга и контроля. Уровень технологии RPC при этом была признан слишком низким.
ORB по возможности
Продолжением темы "поддержка сообщений или RPC" является вопрос о "поддержке сообщений или брокерах объектных запросов". ORB - это среда разработки для объектов в распределенном окружении. ORB управляет размещением и получением объектов и взаимодействиями между объектами, где бы они ни находились. Большая часть существующих брокеров объектных запросов основаны на CORBA 2.0. Сейчас CORBA - это синхронная архитектура, поэтому, если приложение требует асинхронной обработки, ее необходимо реализовывать своими силами.
Причина, по которой ряд пользователей вместо обмена сообщениями предпочитают ORB, заключается в следующем. Зачем тратить деньги и время на то, чтобы сохранить безнадежно устаревшие унаследованные системы? Почему бы вместо этого не создать новые объектные приложения для выполнения необходимых задач? Именно поэтому компания Sprint сделала такой выбор. Она использует ORB для создания объектов, которые позволят ей управлять весьма разнообразным аппаратным обеспечением из одного специализированного приложения.
По мнению технических специалистов компании Sprint, обмен сообщений очень хорошо подходит для работы унаследованной архитектуры, но иметь дело с архаичной системой - тупиковый путь. Поиск общего интерфейса, который не сулит выигрыша в эффективности - это временная мера и отказ от полноценного решения проблемы.
Тот факт, что ORB соответствуют определенному стандарту - еще один аргумент в их пользу, поскольку инструментарий для поддержки сообщений каждого производителя является своего рода внутренней разработкой.
"Для поддержки сообщений нет подходящих стандартов, - сетуют представители Sprint. - Для ORB существует CORBA. Вам могут не нравиться имеющиеся спецификации, но, по крайней мере, вы знаете, что они есть".
Вопросы все же остаются. Например, являются ли инвестиции в поддержку сообщений вложениями средств в устаревающую технологию? Производители систем MOM считают, что обмен сообщениями и ORB - это не конкурирующие, а дополняющие друг друга технологии. ORB определяет использование и движение объектов; существующие ORB используют специальные формы обмена сообщениями (обычно RPC) для выполнения этой задачи. OMG рассматривает вопрос о расширении спецификации COBRA, намереваясь включить в них поддержку технологий обмена сообщениями.
Некоторые поставщики систем МОМ, такие как Tibco, производят ORB, использующие свои собственные схемы обмена сообщениями. Другие - организуют коалиции. К примеру, компания Modulus Technologies лицензировала свою технологию обмена сообщениями производителю ORB компании Expersoft, о чем фирмы объявили в августе этого года.
Трудноперевариваемые спагетти
Возможно, наилучший способ убедиться в целесообразности инвестиции в технологии MOM - это разрабатывать здравую стратегию, а не упорствовать и не писать интерфейсы между специальными приложениями. Возможно, самый короткий путь между двумя точками и есть прямая, но на самом деле многие прямые связи между отдельными приложениями порождают путаницу в управлении, а не обеспечивают работоспособность системы поддержки сообщений.
Возьмем брокер сообщений, концепцию, которой отдают сотрудники Gartner Group и другие аналитики. Это архитектура, позволяющая конструировать уровень среды обмена сообщениями, используя или звездообразную топологию, или топологию шины.
Пока ни один из производителей системы MOM не включает в свои продукты все возможности брокера сообщений, но многие предлагают самую важную функцию: структуру в виде шины или звезды. С этой функцией продукты MOM дадут быструю отдачу, а нагрузка управления будет меньше.
При наличии брокера сообщений от разработчика потребуется написать только один интерфейс - API брокера сообщений. А брокер позаботится о взаимодействии со всеми другими приложениями.
На сегодняшний день технологии MOM хорошо подходят к некоторым приложениям, для которых другие формы промежуточного ПО неприемлемы. В будущем, расширение интеграции разнообразных форм ПО промежуточного уровня будет еще больше запутывать и без того неопределенные связи между этими формами. В существующих гетерогенных компаниях, где не найти двух приложений "говорящих на одном языке", послать вразумительное сообщение - уже значит сделать полдела.
Что может сообщение?
- Передает часть информации
- Инициирует диалог с другим приложением
- Является частью последовательности сообщений
- Копируется и передается нескольким приложениям
- Объединяется с другими сообщениями в новое сообщение
- Разбивается на несколько частей, каждая из которых предназначена различным адресатам
- Изменяется и/или расширяется без компиляции программы по запросу.
Виды промежуточного ПО
Возникает ощущение, что практически все производители называют свои инструментальные средства промежуточным ПО. Ассоциация Message Oriented Middleware Association отстаивает следующие определения, позволяющие отнести эти продукты к различным категориям.
Среда разработки приложений
Включает в себя средства создания приложений в распределенном окружении и обычно используется для их развертывания такими службами, как сетевые коммуникации.
Среда разработки объектов
Предназначена для разработки повторно используемых программных компонентов, распределяемых по сети. Эти среды используют брокеры объектных запросов (ORB), которые размещают объекты и взаимодействуют с ними. Консорциум Object Management Group подготовил спецификацию для ORB, известную под названием CORBA 2.0. Большинство ORB соответствуют этой спецификации или вот-вот примут ее.
Электронная почта
Технология хранения и передачи, главным образом принятая на настольных системах и в локальных сетевых средах. Одна из новых областей - концепция "допускающих сообщения" приложений, которая позволяет приложениям взаимодействовать, используя ту же программную парадигму, что и традиционные протоколы электронной почты, такие как X.400 и SMTP.
Доступ к данным
Позволяет одному серверному приложению использовать информацию, расположенную в разнородных источниках на клиентских системах. Часто строится на основе промежуточной базы данных, позволяющей передавать данные из одного приложения в другое.
Промежуточное ПО, ориентированное на поддержку сообщений (MOM)
Программный уровень, располагающийся между бизнес-приложениями и сетевой инфраструктурой или между самими бизнес-приложениями (и обеспечивающий их стыковку).
Вызов удаленных процедур
Популярный метод обработки распределенных приложений. Часто позиционируется как технология, конкурирующая с системами обмена сообщениями, но не обладающая столь же высокой масштабируемостью.
Обработка распределенных транзакций
Форма промежуточного ПО, которая объединяет другие функции, такие как управление приложением или поддержка сообщений для гарантированного выполнения транзакций.
Управление рабочим процессом и обработкой
Системы, которые автоматизируют повторяющиеся процессы, например маршрутизацию документа.
Web-адрес ассоциации MOM: http://198.93.24.24