Промежуточное ПО, ориентированное на сообщения - Message-oriented middleware

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Недостатки

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

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

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

Стандарты

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

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

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

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

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

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

Extensible Messaging and Presence Protocol ( XMPP ) - это протокол связи для промежуточного программного обеспечения, ориентированного на сообщения, на основе XML (Extensible Markup Language). Этот протокол, предназначенный для расширения, также использовался для систем публикации-подписки, сигнализации для 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 широко развертывается в Интернете и составляет основу Unified Capabilities Framework Министерства обороны США (DoD).

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

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

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

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

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

Тенденции

  • Advanced Message Queuing Protocol (AMQP) предоставляет открытый стандартный протокол уровня приложений для промежуточного программного обеспечения, ориентированного на сообщения.
  • Объект Group Management «s Распределение Data Service (DDS) добавил много новых стандартов в базовой спецификации DDS. Дополнительные сведения см. В Каталоге спецификаций службы распределения данных OMG (DDS) .
  • XMPP - это протокол связи для промежуточного программного обеспечения, ориентированного на сообщения, на основе XML (Extensible Markup Language).
  • Протокол потоковой передачи текстовых сообщений (STOMP) , ранее известный как TTMP, представляет собой простой текстовый протокол, обеспечивающий совместимость проводного формата, который позволяет клиентам STOMP общаться с любым брокером сообщений, поддерживающим протокол.
  • Еще одна тенденция заключается в том, что функции промежуточного программного обеспечения, ориентированные на сообщения, реализуются в аппаратном обеспечении - обычно в ПЛИС или других специализированных кремниевых микросхемах.

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

использованная литература

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