Промежуточное программное обеспечение, ориентированное на сообщения

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

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

MOM предоставляет программные элементы, которые находятся во всех взаимодействующих компонентах архитектуры клиент/сервер и обычно поддерживают асинхронные вызовы между клиентскими и серверными приложениями. MOM снижает участие разработчиков приложений за счет сложности механизма «главный-подчиненный» механизма клиент/сервер.

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

• Удаленный вызов процедур или промежуточное программное обеспечение на основе RPC
• Брокер объектных запросов или промежуточное программное обеспечение на основе ORB
• Промежуточное программное обеспечение, ориентированное на сообщения , или промежуточное программное обеспечение на основе MOM

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

Преимущества

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

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

Асинхронность

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

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

Маршрутизация

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

Трансформация

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

Недостатки

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

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

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

Стандарты

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

Одним из давних стандартов для промежуточного программного обеспечения, ориентированного на сообщения, является спецификация XATMI группы X/Open (Обработка распределенных транзакций: Спецификация XATMI), которая стандартизирует API для межпроцессного взаимодействия . Известными реализациями этого API являются промежуточное программное обеспечение Enduro/X от ATR Baltic и Oracle от Tuxedo .

Расширенный протокол очереди сообщений (AMQP) — это одобренный OASIS протокол. и ИСО стандарт, который определяет протокол и форматы, используемые между участвующими компонентами приложения, поэтому реализации совместимы. AMQP может использоваться с гибкими схемами маршрутизации, включая общие парадигмы обмена сообщениями , такие как точка-точка , разветвление , публикация/подписка и запрос-ответ (они намеренно опущены в версии 1.0 самого стандарта протокола, но основаны на конкретная реализация и/или базовый сетевой протокол для маршрутизации). Он также поддерживает управление транзакциями, организацию очередей, распределение, безопасность, управление, кластеризацию, федерацию и гетерогенную многоплатформенную поддержку. Приложения Java, использующие AMQP, обычно пишутся на Java JMS. Другие реализации предоставляют API для C#, C++, PHP, Python, Ruby и других языков.

Архитектура высокого уровня (HLA IEEE 1516) — это стандарт IEEE и SISO для совместимости моделирования. Он определяет набор сервисов, предоставляемых через API на C++ или Java. Службы предлагают обмен информацией на основе публикации/подписки на основе модульной объектной модели федерации. Также существуют сервисы согласованного обмена данными и опережения времени, основанные на времени логического моделирования, а также точки синхронизации. Дополнительные услуги обеспечивают передачу права собственности, оптимизацию распределения данных, а также мониторинг и управление участвующими федерациями (системами).

( Транспорт телеметрии MQ MQTT) — это стандарт ISO (ISO/IEC PRF 20922), поддерживаемый организацией OASIS. Он обеспечивает легкий и надежный транспортный протокол публикации/подписки поверх TCP/IP, подходящий для связи в контекстах M2M/IoT, где требуется небольшой объем кода и/или пропускная способность сети имеет большое значение.

Служба управления объектами группы распределения данных (DDS) , ориентированный на сообщения предоставляет стандарт промежуточного программного обеспечения публикации/подписки (P/S) , целью которого является обеспечение масштабируемого, надежного, высокопроизводительного и совместимого обмена данными в режиме реального времени между издателями и подписчиками. Стандарт предоставляет интерфейсы для C++, C++11, C, Ada, Java и Ruby.

XMPP

Расширяемый протокол обмена сообщениями и присутствия (XMPP) — это протокол связи для промежуточного программного обеспечения, ориентированного на сообщения, на основе XML (расширяемый язык разметки). Разработанный как расширяемый, протокол также использовался для систем публикации-подписки, сигнализации для VoIP, видео, передачи файлов, игр, приложений Интернета вещей, таких как интеллектуальная сеть, и служб социальных сетей. В отличие от большинства протоколов обмена мгновенными сообщениями, XMPP определен в открытом стандарте и использует подход открытых систем к разработке и применению, с помощью которого любой может реализовать службу XMPP и взаимодействовать с реализациями других организаций. Поскольку XMPP является открытым протоколом, его реализации можно разрабатывать с использованием любой лицензии на программное обеспечение; хотя многие реализации серверов, клиентов и библиотек распространяются как бесплатное программное обеспечение и программное обеспечение с открытым исходным кодом, также существует множество реализаций бесплатного и проприетарного программного обеспечения. В 2002 году Инженерная группа Интернета (IETF) сформировала рабочую группу XMPP для формализации основных протоколов как технологии обмена мгновенными сообщениями и присутствия IETF. Рабочая группа XMPP разработала четыре спецификации (RFC 3920, RFC 3921, RFC 3922, RFC 3923), которые были утверждены в качестве предлагаемых стандартов в 2004 году. В 2011 году RFC 3920 и RFC 3921 были заменены RFC 6120 и RFC 6121 соответственно, на RFC. 6122, определяющий формат адреса XMPP. В дополнение к этим основным протоколам, стандартизированным в IETF, Фонд стандартов XMPP (ранее Jabber Software Foundation) активно занимается разработкой открытых расширений XMPP. По данным Фонда стандартов XMPP, программное обеспечение на основе XMPP широко распространено в Интернете и формирует основу для платформы унифицированных возможностей Министерства обороны (DoD).

Среда программирования Java EE предоставляет стандартный API под названием JMS (Java Message Service), который реализован большинством поставщиков MOM и предназначен для сокрытия конкретных реализаций API MOM; однако JMS не определяет формат обмениваемых сообщений, поэтому системы JMS несовместимы.

Аналогичные усилия предпринимаются в отношении активно развивающегося проекта OpenMAMA , целью которого является предоставление общего API, особенно для клиентов C. Однако на данный момент (август 2012 г.) он в первую очередь подходит для распространения рыночных данных (например, котировок акций) через промежуточное программное обеспечение pub-sub.

Очередь сообщений

См. также: Служба очереди сообщений.

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

Тенденции

• Advanced Message Queuing Protocol (AMQP) предоставляет открытый стандартный протокол прикладного уровня для промежуточного программного обеспечения, ориентированного на сообщения.
• Object Management Group добавила Служба распределения данных (DDS) множество новых стандартов к базовой спецификации DDS. см . Каталог спецификаций службы распределения данных OMG (DDS) . Для получения более подробной информации
• XMPP — это протокол связи для промежуточного программного обеспечения, ориентированного на сообщения, на основе XML (расширяемый язык разметки).
• Протокол потокового текстового обмена сообщениями (STOMP) , ранее известный как TTMP, представляет собой простой текстовый протокол, обеспечивающий совместимый проводной формат, который позволяет клиентам STOMP взаимодействовать с любым брокером сообщений, поддерживающим этот протокол.
• Дополнительная тенденция заключается в том, что функции промежуточного программного обеспечения, ориентированные на сообщения, реализуются в аппаратном обеспечении — обычно в FPGA или других специализированных кремниевых микросхемах.

См. также

• Шаблоны корпоративной интеграции (книга)
• Корпоративная система обмена сообщениями
• Корпоративная сервисная шина
• Программирование на основе потока
• Событийно-ориентированная архитектура

Внешние ссылки

• Начните работу с IBM MQ .