Полезные данные сообщений и сериализация в Служебной шине

  • 3 мин

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

Объектная модель официальных клиентов служебная шина для .NET и Java сопоставляется с служебная шина проводных протоколов.

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

Маршрутизация и корреляция сообщений

Подмножество свойств брокера, в частностиToReplyTo, , ReplyToSessionId, MessageIdи CorrelationIdSessionId, помогает приложениям направлять сообщения в определенные назначения. В следующих шаблонах описана маршрутизация:

  • Простой запрос и ответ: Издатель отправляет сообщение в очередь и ожидает ответа от потребителя сообщения. Издатель владеет очередью для получения ответов. Адрес этой очереди содержится в ReplyTo свойстве исходящего сообщения. Когда потребитель отвечает, он копирует MessageId обработанного сообщения в свойство CorrelationId ответного сообщения и доставляет сообщение в назначение, указанное свойством ReplyTo. Одно сообщение может выдавать несколько ответов в зависимости от контекста приложения.

  • Многоадресный запрос/ответ: В качестве варианта предыдущего шаблона издатель отправляет сообщение в тему, и несколько подписчиков могут получить доступ к сообщению. Каждый подписчик может ответить описанным выше образом. Если ReplyTo указывает на раздел, такой набор ответов обнаружения может распространяться на аудиторию.

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

  • Мультиплексированные запросы и ответы: Эта функция сеанса обеспечивает возможность мультиплексирования ответов, что позволяет нескольким отправителям совместно использовать очередь ответа. Задав параметр ReplyToSessionId, издатель может указать одному или нескольким потребителям скопировать это значение в SessionId свойство ответа. Очередь или раздел публикации не должны учитывать сеансы. Когда сообщение отправляется издателю, он может ожидать сеанса с заданным SessionId , чтобы материализоваться в очереди, условно принимая приемник сеанса.

Сериализация полезных данных

Во время передачи или хранения в служебной шине полезные данные всегда непрозрачны и имеют двоичный блок. Свойство ContentType позволяет приложению описывать полезные данные, используя предполагаемый формат для значений свойств, и является описанием типа содержимого MIME в соответствии с IETF RFC2045, например application/json;charset=utf-8.

В отличие от Java и .NET Standard версия .NET Framework служебной шины поддерживает создание экземпляров BrokeredMessage путем передачи произвольных объектов .NET в конструктор.

Устаревший протокол SBMP сериализует объекты с двоичным сериализатором по умолчанию или сериализатором, который поставляется вне страны. Протокол AMQP сериализует объекты в объект AMQP. Получатель может получить эти объекты с помощью метода GetBody<T>(), указав ожидаемый тип. При использовании AMQP объекты сериализуются в граф AMQP, состоящий из объектов ArrayList и IDictionary<string,object>, и любой клиент AMQP может декодировать их.

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