Another of the topics that you’ll hear a lot about for asynchronous and decoupled programming in WCF 4.0 is queuing. WCF has previously supported queuing through the one-way channel shapes with a combination of datagram and session options. The session in a one-way queued session channel is just a way of defining a unit of work for the messages. You can think of the one-way datagram channel as being equivalent to a one-way session channel where each of the sessions contains a single message. The sessions are interesting when multiple or more messages need to be processed at once. However, just having a channel shape for one-way communication does not cover the common cases for building large-scale applications that use queues to decouple themselves into parts.
When a message is processed from a queue in the current system, it might either be processed in a non-transacted fashion (at most one attempt at delivery) or in a transacted fashion. Since part of the appeal of queued communication is the capability for reliable delivery, almost everyone chooses to process the messages in a transacted fashion. Transacted processing begins running into problems when you want to scale the application so that there are multiple readers competing for messages from the queue.
To reduce the cost of coordination between instances of receivers, it is desirable for the multitude of readers to not have to share common state apart from the queue itself. When a transaction rollback occurs after a message has been received, the rollback places the queue into the originally observed state. This results in the transacted message experiencing a second round of competition between the readers and a second round of processing that looks the same as the first round, which is good for the eventual processing of the message.
Unfortunately, you often want to be selective about replaying some things the same way and other things a different way the second time a message is processed. Similarity and differentiation between actions in processing attempts allows you to build error handling and alternative choices of execution. For example, you might want the same reader to process the message again but apply a different action the second time through. Enforcing that an action is the same as or different from before requires remembering what the time before was like. You can see how this requirement to remember actions might lead to additional state coordination between the readers to manage this collective memory.
The change to the queue model is an alternative state coordination approach that adds another choice to the selection between transacted and non-transacted processing. I’ll spend next time describing this state coordination pattern.
Even though these additions to queued communication enable implementing many more applications in a natural way, I don’t expect that we’ll be able to add everything that we want to for queuing in a single release. There’s a broad variety of scenarios that rely on decoupled communication between two parties and there’s really a lot more to do before we can say that WCF can represent every interesting way of linking together two systems.