В архитектуре программного обеспечения шаблон обмена сообщениями — это архитектурный шаблон , который описывает, как две разные части приложения или разные системы соединяются и общаются друг с другом. Существует много аспектов концепции обмена сообщениями, которые можно разделить на следующие категории: обмен сообщениями между аппаратными устройствами (телекоммуникации, компьютерные сети, IoT и т. д.) и программный обмен данными (различные форматы обмена данными и программные возможности такого обмена данными). Несмотря на разницу в контексте, обе категории демонстрируют общие черты для обмена данными.
В телекоммуникациях шаблон обмена сообщениями ( MEP ) описывает шаблон сообщений , требуемых протоколом связи для установления или использования канала связи . Протокол связи — это формат, используемый для представления сообщения, с которым согласны все общающиеся стороны (или который они способны обработать). Канал связи — это инфраструктура, которая позволяет сообщениям «путешествовать» между общающимися сторонами. Шаблоны обмена сообщениями описывают поток сообщений между сторонами в процессе связи, существует два основных шаблона обмена сообщениями — шаблон «запрос-ответ» и односторонний шаблон.
Например, при просмотре контента в Интернете (канал), веб-браузер (общающаяся сторона) будет использовать HTTP (протокол связи) для запроса веб-страницы с сервера (другой общающейся стороны), а затем отображать возвращенные данные в визуальной форме. Так работает шаблон обмена сообщениями «запрос-ответ» .
В качестве альтернативы в компьютерных сетях у нас есть сетевой протокол UDP . Он используется с шаблоном одностороннего обмена сообщениями, [1] где отправляющая сторона не заинтересована в том, дойдет ли сообщение до какой-либо принимающей стороны, и не ожидает, что какая-либо из принимающих сторон выдаст «ответное» сообщение.
Этот раздел посвящен обмену данными между аппаратными устройствами. Для того чтобы устройства могли считывать и обмениваться данными, они должны использовать аппаратно-специфический протокол (например, радиосигнал), который генерируется аппаратным устройством, выступающим в качестве отправляющей стороны (радиовышка), и может быть интерпретирован другим аппаратным устройством, являющимся принимающей стороной (например, вашим кухонным радио). В примере с радио у нас есть односторонняя модель связи, а протокол обмена сообщениями — это сам радиосигнал.
Коммуникация устройств может также относиться к тому, как аппаратные устройства в системе обмена сообщениями обеспечивают обмен сообщениями. Например, при просмотре Интернета ряд различных устройств работают в тандеме для доставки сообщения через интернет-трафик — маршрутизаторы, коммутаторы и сетевые адаптеры, которые на аппаратном уровне отправляют и получают сигналы в форме пакетов TCP или UDP. Каждый такой пакет сам по себе может называться сообщением, если мы сузим наше представление до пары аппаратных устройств, взаимодействующих друг с другом, в то время как в общем смысле интернет-коммуникации ряд последовательно расположенных пакетов вместе образуют осмысленное сообщение, такое как изображение или веб-страница.
В отличие от связи между устройствами, где форма данных сообщений ограничена протоколами, поддерживаемыми типом и возможностями задействованных устройств (например, в компьютерных сетях у нас есть протоколы TCP и UDP, рация посылает радиоволны на определенной частоте, а маяк мигает последовательностями азбуки Морзе, которые может прочитать человек), программное обеспечение может устанавливать более сложные и надежные форматы обмена данными.
Эти форматы будут переведены отправляющей стороной в форму, доставляемую базовым оборудованием, а затем декодированы принимающей стороной из формата, специфичного для оборудования, в форму, соответствующую исходному протоколу, установленному общающимися программными системами. Этот обмен данными более высокого уровня позволяет передавать информацию в более удобной для восприятия человеком форме, а также позволяет использовать программные методы шифрования и дешифрования для обеспечения безопасности обмена сообщениями. Кроме того, программный обмен сообщениями позволяет использовать больше вариаций шаблона обмена сообщениями , которые больше не ограничиваются простыми запросами-ответами и односторонними подходами. И последнее, но не менее важное: программные коммуникационные системы способны предоставлять различные каналы для обмена данными, которые могут использоваться для оптимизации доставки сообщений или для установления сложных правил выбора и фильтрации , которые помогают решать, какие стороны должны получать определенные сообщения. Это дает возможность для программно организованной маршрутизации сообщений . В результате последнего появились концепции темы ( где всем принимающим сторонам в целевой группе будет доставлена копия сообщения) и очереди (где только одна сторона в целевой группе получит сообщение).
Как упоминалось ранее, программные сообщения предоставляют больше возможностей и свободы в протоколах обмена данными. Однако это не было бы очень полезным, если бы общающиеся стороны не договорились о деталях задействованного протокола, поэтому существует ряд стандартизированных программных протоколов обмена сообщениями. Эта стандартизация позволяет различным программным системам, обычно создаваемым и поддерживаемым отдельными организациями и которые могут работать на разных аппаратных устройствах (серверах, компьютерах, интеллектуальных устройствах или контроллерах IoT), участвовать в обмене данными в реальном времени.
Ниже перечислены некоторые из самых популярных протоколов обмена сообщениями, которые используются и по сей день. Каждый из них предоставляет расширенные значения концепции обмена сообщениями, описанной в предыдущем разделе.
Термин «шаблон обмена сообщениями» имеет расширенное значение в протоколе простого доступа к объектам ( SOAP ). [2] [3] Типы SOAP MEP включают в себя:
Библиотека очередей сообщений ØMQ предоставляет так называемые сокеты (своего рода обобщение традиционных сокетов IP и Unix ), которые требуют указания шаблона обмена сообщениями, который будет использоваться, и оптимизированы для каждого шаблона. Основные шаблоны ØMQ: [4]
Каждый шаблон определяет определенную топологию сети. Запрос-ответ определяет так называемую "сервисную шину", публикация-подписка определяет "дерево распределения данных", push-pull определяет "распараллеленный конвейер". Все шаблоны намеренно разработаны таким образом, чтобы быть бесконечно масштабируемыми и, таким образом, пригодными для использования в масштабах Интернета. [5]
Протокол REST — это протокол обмена сообщениями, построенный поверх протокола HTTP , и, аналогично, использует шаблон «запрос-ответ» обмена сообщениями. В то время как основная цель HTTP — доставлять веб-страницы и файлы через Интернет, которые предназначены для конечного пользователя-человека, протокол REST в основном используется для связи между различными программными системами и играет ключевую роль в шаблоне архитектуры программного обеспечения микросервисов . Среди примечательных качеств протокола REST — то, что он достаточно универсален, чтобы представлять данные во многих других форматах (обычно JSON и XML), и что он предоставляет дополнительные дескрипторы метаданных для представляемого им сообщения. Дескрипторы метаданных следуют стандартам HTTP, представляясь как заголовки HTTP (которые стандартизированы базовым протоколом HTTP), и поэтому их можно использовать в качестве инструкций для принимающей стороны о том, как интерпретировать полезную нагрузку сообщения. Благодаря этому REST значительно улучшает разработку программной системы, способной взаимодействовать с другой программной системой, поскольку разработчикам нужно знать только о более высоком уровне формата полезной нагрузки сообщения (модель JSON или XML). Фактическое HTTP-соединение обычно обрабатывается программной библиотекой или фреймворком.
Еще одним замечательным качеством протокола REST является то, что он подходит для построения семантики других протоколов поверх него, примером чего является HATEOAS .