Промежуточное программное обеспечение, ориентированное на сообщения
Тип программной или аппаратной инфраструктуры

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Недостатки

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

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

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

Стандарты

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

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

Advanced Message Queuing Protocol (AMQP) — это одобренный стандарт OASIS [5] и ISO [6] , который определяет протокол и форматы, используемые между участвующими компонентами приложения, поэтому реализации являются совместимыми. AMQP может использоваться с гибкими схемами маршрутизации, включая общие парадигмы обмена сообщениями, такие как point-to-point , fan-out , publish/subscribe и request-response (они намеренно опущены из v1.0 самого стандарта протокола, но полагаются на конкретную реализацию и/или базовый сетевой протокол для маршрутизации). Он также поддерживает управление транзакциями, очередями, распределением, безопасностью, управлением, кластеризацией, федерацией и гетерогенной многоплатформенной поддержкой. Приложения Java, использующие AMQP, обычно пишутся на Java JMS. Другие реализации предоставляют API для C# , C++ , PHP , Python , Ruby и других языков программирования .

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

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

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

XMPP

Расширяемый протокол обмена сообщениями и присутствия ( XMPP ) — это протокол связи для промежуточного программного обеспечения, ориентированного на сообщения, на основе расширяемого языка разметки ( XML ). Разработанный как расширяемый, протокол также использовался для систем публикации-подписки, сигнализации для VoIP, видео, передачи файлов, игр, приложений Интернета вещей, таких как интеллектуальная сеть, и социальных сетей. В отличие от большинства протоколов обмена мгновенными сообщениями, XMPP определен в открытом стандарте и использует подход открытых систем разработки и применения, с помощью которого любой может реализовать службу XMPP и взаимодействовать с реализациями других организаций. Поскольку XMPP является открытым протоколом, реализации могут быть разработаны с использованием любой лицензии на программное обеспечение; хотя многие реализации серверов, клиентов и библиотек распространяются как бесплатное и открытое программное обеспечение , также существует множество бесплатных и проприетарных реализаций программного обеспечения. Целевая группа по инжинирингу Интернета (IETF) сформировала рабочую группу XMPP в 2002 году для формализации основных протоколов как технологии обмена мгновенными сообщениями и присутствия 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 Standards Foundation (ранее Jabber Software Foundation) активно занимается разработкой открытых расширений XMPP. Согласно XMPP Standards Foundation, программное обеспечение на основе XMPP широко развернуто в Интернете и составляет основу для унифицированной структуры возможностей Министерства обороны (DoD). [8]

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

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

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

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

[14]

Смотрите также

Ссылки

  1. ^ Карри, Эдвард (2004). Промежуточное программное обеспечение, ориентированное на сообщения.. В Middleware for Communications, ред. Кусей Х. Махмуд, 1-28. Чичестер, Англия: John Wiley and Sons. doi :10.1002/0470862084.ch1. ISBN 978-0-470-86206-3 
  2. ^ ab Промежуточное программное обеспечение, ориентированное на сообщения.
  3. ^ ab Общая архитектура брокера объектных запросов.
  4. ^ "E. Curry, D. Chambers и G. Lyons, "Extending Message-Oriented Middleware using Interception", представлено на Третьем международном семинаре по распределенным системам на основе событий (DEBS '04), ICSE '04, Эдинбург, Шотландия, Великобритания, 2004" (PDF) . Архивировано из оригинала (PDF) 2011-07-26 . Получено 2011-08-09 .
  5. ^ 1.0 становится стандартом OASIS. AMQP (2012-10-31). Получено 2014-05-23.
  6. ^ "ИСО/МЭК 19464:2014". ИСО .
  7. ^ Служба распределения данных для систем реального времени (DDS), Object Management Group, версия 1.2, январь 2007 г.
  8. ^ [1] Архивировано 23 мая 2013 г. на Wayback Machine.
  9. ^ "MQ – Введение в ориентированное на сообщения промежуточное программное обеспечение и IBM MQ". itgix.com . 2018-08-30.
  10. ^ OASIS AMQP версия 1.0, разделы 2.6.7-2.6.8". Технический комитет OASIS AMQP. Получено 18 июня 2012 г.
  11. ^ Йоханссон, Лейф (18 апреля 2005 г.). "XMPP как MOM". Большой североевропейский симпозиум по промежуточному программному обеспечению (GNOMIS). Осло: Стокгольмский университет
  12. ^ "Спецификация протокола STOMP, версия 1.2". stomp.github.io . 22 октября 2012 г.
  13. ^ Вы мягкий в середине? Будущее корпоративных ИТ-систем зависит от аппаратных приложений Архивировано 2009-02-09 в Wayback Machine
  14. ^ ORBexpress для полевого программирования на вентильных матрицах ( FPGA )
  • Основы разработчика IBM MQ.
  • ORBexpress: Обзор.
Получено с "https://en.wikipedia.org/w/index.php?title=Message-oriented_middleware&oldid=1258718023"