Шаблон обмена сообщениями

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

Общие понятия о шаблоне обмена сообщениями

В телекоммуникациях шаблон обмена сообщениями ( MEP ) описывает шаблон требуемый сообщений, протоколом связи для установления или использования канала связи . Протокол связи — это формат, используемый для представления сообщения, с которым согласны все взаимодействующие стороны (или которые способны обработать). Канал связи — это инфраструктура, которая позволяет сообщениям «путешествовать» между взаимодействующими сторонами. Шаблоны обмена сообщениями описывают поток сообщений между сторонами в процессе связи. Существует два основных шаблона обмена сообщениями — шаблон запрос-ответ и односторонний шаблон.

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

В качестве альтернативы в компьютерных сетях у нас есть сетевой протокол UDP . Он используется с шаблоном одностороннего обмена сообщениями, ^[1] когда отправляющую сторону не интересует, дойдет ли сообщение какой-либо принимающей стороне, и она не ожидает, что какая-либо из принимающих сторон выдаст «ответное» сообщение.

Связь с устройством

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

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

Программное обеспечение связи

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

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

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

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

МЫЛО

Термин «шаблон обмена сообщениями» имеет расширенное значение в протоколе простого доступа к объектам ( SOAP ). ^[2]^[3] Типы SOAP MEP включают:

In-Only : это эквивалентно одностороннему . Стандартный односторонний обмен сообщениями, при котором потребитель отправляет сообщение поставщику, который не отправляет никакого ответа.
Robust In-Only : этот шаблон предназначен для надежного одностороннего обмена сообщениями. Потребитель инициирует отправку сообщения, на которое поставщик отвечает статусом. Если ответ представляет собой статус, обмен завершен, но если ответ представляет собой ошибку, потребитель должен ответить статусом.
In-Out : это эквивалентно запросу-ответу . Стандартный двусторонний обмен сообщениями, при котором потребитель инициирует сообщение, поставщик отвечает сообщением или ошибкой, а потребитель отвечает статусом.
In-Optional-Out : стандартный двусторонний обмен сообщениями, при котором ответ провайдера не является обязательным.
Только выход : противоположность «Только вход». В первую очередь он поддерживает уведомление о событиях. Он не может вызвать сообщение о неисправности.
Robust Out-Only : Аналогичен шаблону «Только выход», за исключением того, что он может вызвать сообщение об ошибке. Исходящее сообщение инициирует передачу.
Out-In : обратная функция In-Out. Провайдер передает запрос и инициирует обмен.
Out-Optional-In : противоположность In-Optional-Out. Служба создает исходящее сообщение. Входящее сообщение является необязательным («Необязательный вход»).

ØMQ

Библиотека очередей сообщений ØMQ предоставляет так называемые сокеты (своего рода обобщение традиционных сокетов IP и Unix ), которые требуют указания используемого шаблона обмена сообщениями и оптимизированы для каждого шаблона. Основные шаблоны ØMQ: ^[4]

Запрос-ответ соединяет набор клиентов с набором услуг. Это шаблон удаленного вызова процедур и распределения задач. ^{[ нужны разъяснения ]}
Публикация-подписка соединяет набор издателей с набором подписчиков. Это шаблон распределения данных. ^{[ нужны разъяснения ]}
Push-pull соединяет узлы в виде разветвления /входа, который может состоять из нескольких шагов и циклов. Это параллельный шаблон распределения и сбора задач. ^{[ нужны разъяснения ]}
Эксклюзивная пара соединяет две розетки в эксклюзивную пару. Это низкоуровневый шаблон для конкретных, сложных случаев использования.

Каждый шаблон определяет конкретную топологию сети. Запрос-ответ определяет так называемую «служебную шину», публикация-подписка определяет «дерево распределения данных», двухтактная определяет «параллельный конвейер». Все шаблоны намеренно разработаны таким образом, чтобы их можно было бесконечно масштабировать и, следовательно, можно было использовать в масштабах Интернета. ^[5]

ОТДЫХ

Протокол REST — это протокол обмена сообщениями, построенный на основе протокола HTTP и аналогично использующий запрос-ответ шаблон обмена сообщениями . Хотя основной целью HTTP является доставка веб-страниц и файлов через Интернет, предназначенных для конечного пользователя, протокол REST в основном используется для связи между различными программными системами и играет ключевую роль в шаблоне архитектуры программного обеспечения микросервисов . Среди примечательных качеств протокола REST — то, что он достаточно универсален для представления данных во многих других форматах (обычно JSON и XML) и предоставляет дополнительные дескрипторы метаданных для сообщения, которое он представляет. Дескрипторы метаданных соответствуют стандартам HTTP, поскольку они представлены в виде заголовков HTTP (которые стандартизированы базовым протоколом HTTP) и поэтому могут использоваться в качестве инструкций для принимающей стороны о том, как интерпретировать полезную нагрузку сообщения. По этой причине REST значительно улучшает разработку программной системы, способной взаимодействовать с другой программной системой, поскольку разработчикам необходимо знать только формат полезной нагрузки сообщения более высокого уровня (модель JSON или XML). Фактическая HTTP-связь обычно обрабатывается программной библиотекой или платформой.

Еще одним замечательным качеством протокола REST является то, что на его основе можно создавать семантику другого протокола, как это показано в примере с HATEOAS .

См. также

Ссылки

^ Эрл, Томас (2005). Сервис-ориентированная архитектура: концепции, технологии и дизайн . Индиана: Образование Пирсона. п. 171. ИСБН 0-13-185858-0 .
^ http://www.w3.org/TR/soap12-part1/#soapmep Представители SOAP в рекомендации SOAP W3C v1.2
^ Язык описания веб-служб (WSDL), версия 2.0: дополнительные MEP.
^ Руководство пользователя ØMQ
^ «Уровень масштабируемости попадает в стек Интернета» . Архивировано из оригинала 28 мая 2019 г. Проверено 3 февраля 2011 г.

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

[1] Эрл, Томас (2005). Сервис-ориентированная архитектура: концепции, технологии и дизайн . Индиана: Образование Пирсона. п. 171. ИСБН 0-13-185858-0 .

[2] ttp://www.w3.org/TR/soap12-part1/#soapmep Представители SOAP в рекомендации SOAP W3C v1.2

[3] Язык описания веб-служб (WSDL), версия 2.0: дополнительные MEP.

[4] Руководство пользователя ØMQ

[5] «Уровень масштабируемости попадает в стек Интернета» . Архивировано из оригинала 28 мая 2019 г. Проверено 3 февраля 2011 г.

[1]

[2]

[3]

[4]

[5]