Skip to content

John Bennett's blog

Our service bus – Part 4: Message types

Saturday, February 5, 2011

See the Intro to this series, which has links to all the parts.

Message types in our service bus are just regular .NET classes. We don’t have a base message class or an interface that message types must implement. The only requirement of a message type stems from our use of WCF: it must have DataContract and DataMember attributes so that WCF can use the DataContractSerializer to send it over the wire.

In Part 3, I talked about transactional messaging and how those messages are handled differently than non-transactional ones.  But how does a message type become transactional?

A developer declares whether a message type is transactional or non-transactional by convention: If the message type has a static bool property named IsTransactional, its value determines whether the message is tx. If the property does not exist, the default is non-tx. Developers must opt-in to make a message transactional.

A similar convention is used to determine message lifetime — a static TimeSpan property named TimeToLive. Messaging is asynchronous, and we need a way to tell the system, “If a message of this type isn’t handled within X time, consider it to have failed.”  The TimeToLive in our system defaults to 1 hour.

The default values for IsTransactional and TimeToLive are appropriate for our system, but will certainly not be appropriate for all systems. They form part of the contract for a message type, which is why we decided to bake them into the message type itself.

In Part 5, I’ll talk about message handling failures, poison messages and dead letters.