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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Недостатки

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

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

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

Стандарты

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

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

В Расширенный протокол очереди сообщений (AMQP) является утвержденным ОАЗИС[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 Telemetry Transport (MQTT) - это стандарт ISO (ISO / IEC PRF 20922), поддерживаемый организацией OASIS. Он предоставляет легкий транспортный протокол публикации / подписки для надежного обмена сообщениями поверх TCP / IP, подходящий для связи в контекстах M2M / IoT, где требуется небольшой объем кода и / или пропускная способность сети имеет большое значение.

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

Расширяемый протокол обмена сообщениями и присутствия (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 Министерства обороны США.[7]

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

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

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

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

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

Тенденции

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

Рекомендации

  1. ^ Карри, Эдвард. 2004 г. «По промежуточного слоя, ориентированного на сообщения»[постоянная мертвая ссылка ]. В промежуточном программном обеспечении для коммуникаций, изд. Кусай Х. Махмуд, 1-28. Чичестер, Англия: Джон Уайли и сыновья. Дои:10.1002 / 0470862084.ch1. ISBN  978-0-470-86206-3
  2. ^ а б По промежуточного слоя, ориентированного на сообщения.CS1 maint: ref = harv (связь)
  3. ^ «Э. Карри, Д. Чемберс и Дж. Лайонс,« Расширение ориентированного на сообщения промежуточного программного обеспечения с помощью перехвата », представленный на Третьем международном семинаре по распределенным системам, основанным на событиях (DEBS '04), ICSE '04, Эдинбург, Шотландия, Великобритания , 2004 " (PDF). Архивировано из оригинал (PDF) на 2011-07-26. Получено 2011-08-09.
  4. ^ 1.0 Становится стандартом OASIS. AMQP (31.10.2012). Проверено 23 мая 2014.
  5. ^ «ISO / IEC 19464: 2014». ISO.
  6. ^ Служба распространения данных для систем реального времени (DDS), Object Management Group, версия 1.2, январь 2007 г.
  7. ^ [1] В архиве 23 мая 2013 г. Wayback Machine
  8. ^ "网 客户 端: 404 錯誤 提示 的 界面". www.tutorialsto.com.
  9. ^ OASIS AMQP версии 1.0, разделы 2.6.7–2.6.8 ". Технический комитет OASIS AMQP. Проверено 18 июня 2012 г.
  10. ^ Йоханссон, Лейф (18 апреля 2005 г.). «XMPP как МАМА». Большой нормальный симпозиум по среднему программному обеспечению (GNOMIS). Осло: Стокгольмский университет
  11. ^ Спецификация протокола STOMP, версия 1.2, 22 октября 2012 г.
  12. ^ Вы мягкий посередине? Будущее корпоративных ИТ - за аппаратными приложениями В архиве 2009-02-09 в Wayback Machine

внешняя ссылка