Freigeben über

System Reliability requires Message Durability (immature WCF)

  • Artikel

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.

Comments

  • Anonymous
    May 30, 2007
    Is this where Biztalk "R2" WCF support is taking us?

  • Anonymous
    May 30, 2007
    BTS is the intermediary, not the endpoint.  Durability needs to exist in the endpoint in order to insure that you don't change one weakness for two.

  • Anonymous
    June 06, 2007
    One-way messaging is the basis of scalability. Anything else you need beyond that can be implemented with one-way messaging and some state management. Also, if you don't let the application dictate to where it wants to send the message, you've opened the door to routable and intermediable messages. Specifically, the use of publish/subscribe (which I've written extensively about here: http://udidahan.weblogs.us/category/pub-sub/) makes a lot of this possible. The reason we don't have a good pub/sub technology from Microsoft is really beyond me. For me, durability just ends up being, at the application level, an attribute I put on a message. The responsibility of "making it so" gets delegated to the infrastructure (like you mentioned before, a mixture of technology and code these days). I've also found these issues lead me to multi-process/multi-endpoint solutions even on a single server in order to handle higher-latency, more durable, and transactional messages beside lower-latency ones. Divide and conquer. Don't be ruled by technology. Keep these posts coming. Even though I can hardly keep up :)

  • Anonymous
    December 02, 2008
    My four year old daughter, Heather, had her first ballet recital last night. It was a very proud moment for me. She had to wear a little makeup for the lights and with hair up, she looked beautiful but older and that was emotional. I have some things