Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

Промежуточное программное обеспечение, ориентированное на сообщения ( 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 является ATR прибалтийского Enduro / X промежуточного слоя и Oracle «s смокинг .

Расширенный протокол очереди сообщений (AMQP) является утвержденным OASIS [4] и ИСО [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 (ИСО / МЭК PRF 20922) поддерживается OASIS организации. Он предоставляет легкий транспортный протокол публикации / подписки для надежного обмена сообщениями поверх TCP / IP, подходящий для связи в контекстах M2M / IoT, где требуется небольшой объем кода и / или пропускная способность сети имеет большое значение.

Объект Group Management «s Service Распределения данных (DDS) обеспечивает сообщение-ориентированная Publish / Subscribe (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 Министерства обороны США (DoD). [7]

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

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

Очередь сообщений [ править ]

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

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

Тенденции [ править ]

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

См. Также [ править ]

  • Шаблоны корпоративной интеграции
  • Система обмена сообщениями предприятия
  • Сервисная шина предприятия
  • Программирование на основе потоков

Ссылки [ править ]

  1. ^ Карри, Эдвард. 2004. «Посредник, ориентированный на сообщения» [ постоянная мертвая ссылка ] . В промежуточном программном обеспечении для коммуникаций, изд. Кусай Х. Махмуд, 1-28. Чичестер, Англия: Джон Уайли и сыновья. DOI : 10.1002 / 0470862084.ch1 . ISBN  978-0-470-86206-3
  2. ^ a b По промежуточного слоя, ориентированного на сообщения .CS1 maint: ref = harv ( ссылка )
  3. ^ "Э. Карри, Д. Чемберс и Г. Лайонс," Расширение ориентированного на сообщения промежуточного программного обеспечения с помощью перехвата ", представленный на Третьем международном семинаре по распределенным системам, основанным на событиях (DEBS '04), ICSE '04, Эдинбург, Шотландия, Великобритания, 2004 г. » (PDF) . Архивировано из оригинального (PDF) 26 июля 2011 года . Проверено 9 августа 2011 .
  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. ^ Вы мягки в середине? Будущее корпоративных информационных технологий - в аппаратных приложениях. Архивировано 9 февраля 2009 г. на Wayback Machine.

Внешние ссылки [ править ]

  • Начните работу с IBM MQ .CS1 maint: ref = harv ( ссылка )