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

  • 3 мин

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

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

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

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

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

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

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

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

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

Маршрутизация внутри пространства имен служебная шина использует правила автоматической цепочки и подписки раздела. Маршрутизация между пространствами имен может выполняться с помощью Azure LogicApps. Свойство To зарезервировано для использования в будущем. Приложения, реализующие маршрутизацию, должны делать это на основе свойств пользователей и не опираться на To это свойство. Однако это не приведет к проблемам совместимости.

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

Во время передачи или хранения в служебной шине полезные данные всегда непрозрачны и имеют двоичный блок. Свойство 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 возникают проблемы с декодированием таких полезных данных.