WCF is a very cool technology.  Microsoft has moved the goalposts in the messaging space with this one, and I’m a huge fan.  However, there is a limitation that is painful to live with: the lack of a routable, intermediable, declared message durability option.

Sure.  There’s MSMQ.  Great.  If you (a) control both ends, and (b) are willing to lose intermediability, (c) are happy with one-way communication and (d) have no network firewall or NAT issues.  Zowie. 

What about the real promise of WCF: to put cross-cutting concerns into the infrastructure, to let developers focus on the message while the infrastructure focuses on the transport.

Some folks are asking that WCF integrate with SSB.  I think that is a very short-sighted answer.  Messaging sits above storage on the stack, so the message infrastructure needs to control the storage.  SSB is written from the other angle: with storage first, and messaging below it.  It is possible to prop this up, but since SSB is doing a lot of the work that WCF is doing, the best way would be to take a different approach altogether.

In my opinion, we should be able to configure an adapter in WCF where we declare a durable endpoint and configure SQL Server (if we choose, or Oracle or MySQL) as the storage mechanism.  We can then rely on WCF to not only send the message but to send it in a way that it won’t be lost if the other side is down, or I crash before getting acknowledgement, etc.   ACID Transactions.  I know… I’m asking a lot.  Not more than others.  Consider me one more voice in the chorus. 

BTW: WCF does have reliable messaging… in memory.  It has durable messaging, in MSMQ.  The limitations of this approach were nicely described by Matevz Gacnik in a blog from last February.  Matevz is an MVP and I like his writing style.