[Discussion] Service Bus - Track 2 - Message Structure

The intent of this issue is to solicit feedback from the community in advance of the GA of the next major version of the Service Bus library (which will follow several Preview releases). As a reference, the .NET Azure SDK guidelines can be found here: https://azure.github.io/azure-sdk/dotnet_introduction.html Terminology: Track 0 refers to the WindowsAzure.ServiceBus library Track 1 refers to the Microsoft.Azure.ServiceBus library Track 2 refers to the new library, Azure.Messaging.ServiceBus, we are working on releasing.

In the previous versions of the Service Bus library, there was a single type for both sending and receiving messages. There are a couple downsides to this to go with the obvious upside of its simplicity:

1. System level properties would appear on the message that a user is constructing for sending. Although these properties are read-only, it adds some cognitive overhead to reasoning about the type.
2. When receiving a message, any of the settable properties can still be set. However, setting these properties doesn’t actually do anything even after settling the message. For instance a user might think that doing something like the below might actually change the messageId, which it wouldn’t. This concern is more pronounced with our proposed addition of overloads for settlement methods taking a message (it could be argued if the settlement only accepts a lock token, then no one would think that changing any of the other properties would affect the settlement).

var message = await receiver.ReceiveAsync();
message.MessageId = "newMessageId";
// in the new version, we are offering overloads for settlement methods
// that take a message in addition to the ones that take a lock token
await receiver.AbandonAsync(message);

In order to address these two issues, we are proposing having two separate types for messages:

• A ServiceBusMessage which is what a user would create for sending.
• A ServiceBusReceivedMessage which is what a user would get back when receiving a message.

Intially, we thought that ServiceBusReceivedMessage could derive from ServiceBusMessage, but the issue we ran into there was needing to somehow still make the received message properties read-only (we could do runtime validation or use “new” keyword), in addition to wanting to make it super clear to users that re-sending a message that has system properties set on it, will not end up having those same system properties set once it is processed by the service (these system properties would be thrown out before sending).

So our updated proposal is to not have ServiceBusReceivedMessage derive from ServiceBusMessage. This allows us to keep ServiceBusReceivedMessage immutable. It also means we don’t have to worry about a user sending a received message. In order to support re-sending a received message we offer a static factory method.

foreach (ServiceBusReceivedMessage msg in receivedMessages)
{
    ServiceBusMessage sendableMessage = ServiceBusMessage.CreateFrom(receivedMessage);
    await sender.SendAsync(sendableMessage);
}

The downside to breaking the hierarchy is that code that could be written to process a message in some way that should be agnostic to whether the message was sent or received, would now have to be duplicated somewhat. We would like to see what the community thinks about this tradeoff.

[SeanFeldman]

The downside to breaking the hierarchy is that code that could be written to process a message in some way that should be agnostic to whether the message was sent or received, would now have to be duplicated somewhat. We would like to see what the community thinks about this tradeoff.

Reuse but don’t abuse. In most scenarios I’ve encountered, the direction of the message matters. It always has to be a ServiceBusReceivedMessage to know till when it’s locked. And it always has to be a ServiceBusMessage to set Enqueued time. The split makes sense.

[SeanFeldman]

I can retire now 😂 Thanks for confirming @JoshLove-msft.