Промежуточное ПО, ориентированное на сообщения ( MOM ), — это программная или аппаратная инфраструктура, поддерживающая отправку и получение сообщений между распределенными системами. MOM позволяет распределять модули приложений по гетерогенным платформам и снижает сложность разработки приложений, охватывающих несколько операционных систем и сетевых протоколов. Промежуточное программное обеспечение создает уровень распределенной связи, который изолирует разработчика приложений от деталей различных операционных систем и сетевых интерфейсов. API, которые распространяются на различные платформы и сети, обычно предоставляются MOM. [1]
Этот уровень промежуточного программного обеспечения позволяет компонентам программного обеспечения (приложениям, Enterprise JavaBeans, сервлетам и другим компонентам), разработанным независимо и работающим на разных сетевых платформах, взаимодействовать друг с другом. Приложения, распределенные на разных узлах сети, используют для связи интерфейс приложения. Кроме того, предоставляя административный интерфейс, эту новую виртуальную систему взаимосвязанных приложений можно сделать отказоустойчивой и безопасной. [2]
MOM предоставляет программные элементы, которые находятся во всех взаимодействующих компонентах архитектуры клиент/сервер и обычно поддерживают асинхронные вызовы между клиентскими и серверными приложениями. MOM снижает участие разработчиков приложений за счет сложности механизма «главный-подчиненный» механизма клиент/сервер.
Все эти модели позволяют одному программному компоненту влиять на поведение другого компонента в сети. Они отличаются тем, что промежуточное программное обеспечение на основе RPC и ORB создает системы из тесно связанных компонентов, тогда как системы на основе MOM допускают слабую связь компонентов. В системе на основе RPC или ORB, когда одна процедура вызывает другую, она должна дождаться завершения вызванной процедуры, прежде чем она сможет сделать что-либо еще. В этих моделях синхронного обмена сообщениями промежуточное программное обеспечение частично функционирует как суперкомпоновщик, обнаруживая вызываемую процедуру в сети и используя сетевые службы для передачи параметров функции или метода процедуре, а затем для возврата результатов. [2]
Основные причины использования протокола связи на основе сообщений включают его способность хранить (буферизировать), маршрутизировать или преобразовывать сообщения при их передаче от отправителей к получателям.
Еще одним преимуществом обмена сообщениями между клиентами через провайдера обмена сообщениями является то, что, добавив административный интерфейс, вы можете отслеживать и настраивать производительность. Таким образом, клиентские приложения эффективно избавлены от всех проблем, кроме отправки, получения и обработки сообщений. Решение таких вопросов, как совместимость, надежность, безопасность, масштабируемость и производительность, зависит от кода, реализующего систему MOM, и от администратора.
Используя систему MOM, клиент выполняет вызов API для отправки сообщения в пункт назначения, управляемый провайдером. Вызов вызывает службы провайдера для маршрутизации и доставки сообщения. После отправки сообщения клиент может продолжать выполнять другую работу, будучи уверенным, что поставщик сохранит сообщение до тех пор, пока клиент-получатель не получит его. Модель на основе сообщений в сочетании с посредничеством провайдера позволяет создать систему слабосвязанных компонентов.
MOM включает в себя категорию программного обеспечения для межприложений , которое обычно опирается на асинхронную передачу сообщений , а не на архитектуру запрос-ответ . В асинхронных системах очереди сообщений обеспечивают временное хранилище, когда программа назначения занята или не подключена. Кроме того, большинство асинхронных систем MOM предоставляют постоянное хранилище для резервного копирования очереди сообщений. Это означает, что отправителю и получателю не требуется одновременное подключение к сети ( асинхронная доставка ), и проблемы с прерывистым подключением решены. Это также означает, что если приложение-получатель по какой-либо причине выйдет из строя, отправители могут продолжить работу без изменений, поскольку отправляемые ими сообщения будут просто накапливаться в очереди сообщений для последующей обработки при перезапуске получателя.
Многие реализации промежуточного программного обеспечения, ориентированного на сообщения, зависят от системы очередей сообщений . Некоторые реализации позволяют обеспечивать логику маршрутизации самим уровнем обмена сообщениями, в то время как другие зависят от клиентских приложений, предоставляющих информацию о маршрутизации, или допускают сочетание обеих парадигм. В некоторых реализациях используются парадигмы широковещательной или многоадресной рассылки.
В системе промежуточного программного обеспечения на основе сообщений сообщение, полученное в пункте назначения, не обязательно должно быть идентично первоначально отправленному сообщению. Система MOM со встроенным интеллектом может преобразовывать сообщения и маршрутизировать их в соответствии с требованиями отправителя или получателя. [3] В сочетании с возможностями маршрутизации и широковещательной/ многоадресной рассылки одно приложение может отправлять сообщение в своем собственном формате, а два или более других приложений могут получать копию сообщения в своем собственном формате. Многие современные системы MOM предоставляют сложные инструменты преобразования (или сопоставления) сообщений, которые позволяют программистам указывать правила преобразования, применимые к простой операции перетаскивания в графическом интерфейсе .
Основным недостатком многих систем промежуточного программного обеспечения, ориентированных на сообщения, является то, что они требуют дополнительного компонента в архитектуре — агента передачи сообщений ( брокера сообщений ). Как и в любой системе , добавление еще одного компонента может привести к снижению производительности и надежности, а также может сделать систему в целом более сложной и дорогой в обслуживании .
Кроме того, многие коммуникации между приложениями имеют по своей сути синхронный аспект: отправитель специально хочет дождаться ответа на сообщение, прежде чем продолжить (см. Вычисления в реальном времени и почти в реальном времени для крайних случаев). Поскольку коммуникация на основе сообщений по своей сути функционирует асинхронно, в таких ситуациях она может не подойти. Тем не менее, большинство систем MOM имеют возможность группировать запрос и ответ в одну псевдосинхронную транзакцию.
В системе синхронного обмена сообщениями вызывающая функция не возвращается до тех пор, пока вызываемая функция не завершит свою задачу. В слабосвязанной асинхронной системе вызывающий клиент может продолжать загружать работу получателя до тех пор, пока ресурсы, необходимые для выполнения этой работы, не будут исчерпаны и вызываемый компонент не выйдет из строя. Конечно, эти условия можно свести к минимуму или избежать, отслеживая производительность и регулируя поток сообщений, но в синхронной системе обмена сообщениями эта работа не требуется. Важно понимать преимущества и недостатки каждого вида системы. Каждая система подходит для разных задач. Иногда для получения желаемого поведения требуется комбинация двух типов систем.
Исторически сложилось так, что отсутствие стандартов , регулирующих использование промежуточного программного обеспечения, ориентированного на сообщения, вызывало проблемы. Большинство крупных поставщиков имеют свои собственные реализации, каждая со своим интерфейсом прикладного программирования (API) и инструментами управления.
Одним из давних стандартов для промежуточного программного обеспечения, ориентированного на сообщения, является спецификация XATMI группы X/Open (Обработка распределенных транзакций: Спецификация XATMI), которая стандартизирует API для межпроцессного взаимодействия . Известными реализациями этого API являются промежуточное ПО Enduro/X от ATR Baltic и Tuxedo от Oracle .
Расширенный протокол очереди сообщений (AMQP) — это утвержденный стандарт OASIS [4] и ISO [5] , который определяет протокол и форматы, используемые между участвующими компонентами приложения, поэтому реализации являются совместимыми. 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) Object Management Group предоставляет стандарт промежуточного программного обеспечения публикации/подписки (P/S), ориентированный на сообщения , целью которого является обеспечение масштабируемого, надежного, высокопроизводительного и совместимого обмена данными в режиме реального времени между издателями и подписчиками. [6] Стандарт предоставляет интерфейсы для C++, C++11, C, Ada, Java и Ruby.
Расширяемый протокол обмена сообщениями и присутствия (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). [7]
Среда программирования Java EE предоставляет стандартный API под названием JMS (Java Message Service), который реализуется большинством поставщиков MOM и предназначен для сокрытия конкретных реализаций API MOM; однако JMS не определяет формат обмениваемых сообщений, поэтому системы JMS несовместимы.
Аналогичные усилия предпринимаются в отношении активно развивающегося проекта OpenMAMA, целью которого является предоставление общего API, особенно для клиентов C. Однако на данный момент (август 2012 г.) он в первую очередь подходит для распространения рыночных данных (например, котировок акций) через промежуточное программное обеспечение pub-sub.
Очереди сообщений позволяют обмениваться информацией между распределенными приложениями. Очередь сообщений может находиться в памяти или на диске. Сообщения остаются в очереди до тех пор, пока они не будут обработаны потребителем службы. Через очередь сообщений приложение может быть реализовано независимо — им не нужно знать положение друг друга, или продолжать реализовывать процедуры, устраняющие необходимость ожидания получения этого сообщения. [8]