Azure服务总线序列化类型 [英] Azure Service Bus Serialization Type

问题描述

随着我们朝着面向服务的体系结构迈进，我们已经开始研究使用Windows Azure Service Bus替代我们当前的队列.

We've started investigating the use of the Windows Azure Service Bus as a replacement for our current queues as we move towards a service orientated architecture.

大多数文档都很清楚；但是我很难确定BrokeredMessage在提供正文时使用哪种序列化类型.

Most of the documentation is clear; however I having a hard time ascertaining which type of serialization the BrokeredMessage uses when provided with a body.

例如，假设我实例化一个BrokeredMessage对象，如下所示:

For example, let's say I instantiate a BrokeredMessage object as below:

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

BrokeredMessage brokeredMessage = new BrokeredMessage(sendMessageCommand);

queueClient.Send(brokeredMessage); 

SendMessageCommand是带有[Serializable]属性标记的简单DTO.在我们的旧队列中，它是二进制序列化的，因此可以更快地存储并保留其元数据.这对我们很重要，因为我们使用队列使用此处概述的模式发送命令接收方的工作人员角色将泛型和动态类型混合使用，反序列化命令.

SendMessageCommand is a simple DTO marked with the [Serializable] attribute; in our old queues this was binary serialized so it could be stored faster and have it's meta data preserved. This is important to us as we use the queues to send commands using the pattern outlined here with the receiving Worker Role deserialzing the command with a mixture of generics and dynamic typing.

但是，根据此文章，正文已传递给BrokeredMessage是二进制XML序列化".我当时的假设是这是标准的XML序列化，然后通过二进制格式化程序传递，对吗?

However according to THIS article the body passed in to the constructor of the BrokeredMessage is "Binary XML Serialized". My assumption then is that this is standard XML serialization then passed through a binary formatter, is that correct?

进一步；这是否意味着如果我要使用默认的BrokeredMessage消息正文功能；我是否必须确保所有对象都是XML可序列化的，包括所有出现的问题? (私有字段丢失，没有使用泛型，xml序列化属性进行反序列化的元数据)

Further to this; does that mean that if I was to use the default BrokeredMessage message body functionality; I would have to ensure all objects are XML Serializable, inclusive of all the issues that presents? (Loss of private fields, no meta data for deserializing using generics, xml serialization attributes)

最后；如果是这样的话；有没有一种简单的方法可以解决这个问题?我正在考虑进行自己的二进制序列化，然后将byte[]存储在BrokeredMessage的属性中.

Finally; if this is the case; is there a simple way around this? I was considering doing our own binary serialization then storing the byte[] in a property on the BrokeredMessage.

推荐答案

根据

应用程序可以通过传递任何内容来设置消息的正文 可序列化的对象，指向BrokeredMessage的构造函数，以及 然后将使用适当的DataContractSerializer来序列化 目的.或者，可以提供System.IO.Stream.

An application can set the body of the message by passing any serializable object to the constructor of the BrokeredMessage, and the appropriate DataContractSerializer will then be used to serialize the object. Alternatively, a System.IO.Stream can be provided.

您使用的构造函数具有此文档 :

The constructor you're using has this documentation:

根据给定的值初始化BrokeredMessage类的新实例 通过使用DataContractSerializer与二进制对象 XmlDictionaryWriter.

Initializes a new instance of the BrokeredMessage class from a given object by using DataContractSerializer with a binary XmlDictionaryWriter.

这非常适合定义为DataContracts的消息，如本文中所述.

This fits well with messages defined as DataContracts, as explained in this article.

或者，您也可以使用此答案中所述的代理人.

Alternatively you could use surrogates as described in this answer.

您还可以提供您自己的序列化器或流.

另一种选择是进行自己的序列化，并使用字节数组或字符串作为提供给构造函数的可序列化对象(与message属性相反).这是实现互操作性的适当方法，因为您可以使用序列化格式，例如JSON或协议. Microsoft自己的 Windows Azure应用程序中的最佳性能最佳实践建议在影响性能时使用自定义序列或第三方序列化.

An alternative would be to do your own serialization and use a byte array or string as the serializable object provided to the constructor (as opposed to in a message property). This is an adequate approach for interoperability, since you can use serialization formats such as JSON or protobuf. Microsoft's own Best Practices for Performance in Windows Azure Applications recommends using custom or third-party serialization when it impacts performance.

使用JSON序列化和动态对象取得了不错的结果.

I've had good results using JSON serialization and dynamic objects.

这篇关于Azure服务总线序列化类型的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！