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.
Most
According to the documentation:
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:
Initializes a new instance of the BrokeredMessage class from a given object by using DataContractSerializer with a binary XmlDictionaryWriter.
This fits well with messages defined as DataContracts, as explained in this article.
Alternatively you could use surrogates as described in this answer.
You can also provide your own serializer or a stream.
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.
I've had good results using JSON serialization and dynamic objects.