Серийный номер шины обслуживания Azure

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

Большая часть документации понятна; однако я с трудом определяю, какой тип сериализации использует BrokeredMessage, если он снабжен телом.

Например, скажем, я создаю экземпляр объекта BrokeredMessage, как показано ниже:

ICommand sendMessageCommand = new SendMessageCommand
{
    Title = "A new message title",
    Body = "A new message body"
};

BrokeredMessage brokeredMessage = new BrokeredMessage(sendMessageCommand);

queueClient.Send(brokeredMessage);

SendMessageCommand - это простой DTO, помеченный атрибутом [Serializable]; в наших старых очередях это было бинарным сериализованным, чтобы оно могло храниться быстрее и иметь метаданные. Это важно для нас, поскольку мы используем очереди для отправки команд с использованием шаблона описанного здесь, при этом получающая роль рабочего десериализует команду со смесью дженериков и динамической типизации.

Однако согласно статье ЭТО тело, переданное конструктору BrokeredMessage, является "двоичным XML-сериализованным". Мое предположение заключается в том, что это стандартная сериализация XML, а затем передается через двоичный форматтер, верно ли это?

Далее; означает ли это, что если бы я использовал функциональность тела сообщения BrokeredMessage по умолчанию; Я должен был бы обеспечить, чтобы все объекты были XML Serializable, включая все проблемы, которые представляют? (Потеря частных полей, метаданных для десериализации с использованием дженериков, атрибутов сериализации xml)

Наконец; если это так; есть ли простой способ обойти это? Я рассматривал возможность создания собственной бинарной сериализации, а затем сохранил byte[] в свойстве BrokeredMessage.

Ответ 1

В соответствии с документация:

Приложение может установить тело сообщения, передав любой сериализуемый объект для конструктора BrokeredMessage и соответствующий DataContractSerializer затем будет использоваться для сериализации объект. В качестве альтернативы может быть предоставлен System.IO.Stream.

Используемый конструктор эта документация:

Инициализирует новый экземпляр класса BrokeredMessage из заданного объекта с помощью DataContractSerializer с двоичным XmlDictionaryWriter.

Это хорошо соответствует сообщениям, определенным как DataContracts, как описано в этой статье.

В качестве альтернативы вы можете использовать суррогаты, как описано в этом ответе.

Вы также можете предоставить собственный сериализатор или поток.

Альтернативой может быть ваша собственная сериализация и использование байтового массива или строки в качестве сериализуемого объекта, предоставленного конструктору (в отличие от свойства сообщения). Это адекватный подход к взаимодействию, поскольку вы можете использовать форматы сериализации, такие как JSON или protobuf. Microsoft "Лучшие практики для производительности в приложениях Windows Azure" рекомендует использовать пользовательскую или стороннюю сериализацию, когда это влияет на производительность.

У меня были хорошие результаты с использованием сериализации JSON и динамических объектов.