I have found a really strange behavior in the Service Bus interoperability implementation.
I am sending data from a .net client (WindowsAzure.ServiceBus 2.7.3) to Proton-C Clients on various platforms (Win32, Linux, ...)
For the sake of simplicity I decided to use AMQP map format.
According to the table under the following MSDN article the .NET DataType IDictionary is mapped to AMQP map.
https://msdn.microsoft.com/en-us/library/azure/jj841075.aspx
Sender:
var brokeredMessages =
pointEvents.Select(pointEvent => new BrokeredMessage((IDictionary) pointEvent.AsDictionary())
{
MessageId = pointEvent.Id.ToString()
});
This is correctly mapped to AMQP MAP and can be deserialized on the Proton-C side with
Receiver:
const char * format = pn_message_get_content_type(message);
pn_data_t *body = pn_message_body(message);
pn_data_next(body);
pn_type_t type = pn_data_type(body);
size_t mapsize = pn_data_get_map(body);
the message type in the body is PN_MAP(25) as long as .NET client uses TransportType=Amqp in connection string.
If the .NET client however switches the TransportType to NetMessaging (as I wanted to do because of some firewall issues) the message body is serialized as PN_BINARY(19) instead.
The .NET library implies that AMQP is just a transport type, but it has actually a significant impact on the semantic of the communication.
I guess one might argue that you have to use AMQP Transport to have AMQP serialization, but I think this is at least an API design problem if not a straight forward bug....