다음을 통해 공유

Reliable Messaging demystified

  • 아티클

Recently I hear many questions about Reliable Messaging in WCF. In fact, I just had an IM chat with Clemens which resulted in this blog entry. I want to expand on his comments with a little more of the insight I got being a past owner for this feature.

The first thing we should clear out is terminology - Reliable Messaging means a lot of things to a lot of people so I like to use 2 separate terms when it comes to WCF features: Reliable Sessions and Queued Messaging.

Reliable Sessions provide the equivalent of “TCP at the SOAP level” and give you exactly-once, in-order message delivery. TCP is reliable like that too (at the packet level), but only hop-to-hop. If all you ever have is a single, un-bridged connection on a super-reliable network then reliable sessions don’t give you much. However, this is rarely the case both inside the corporate network and obviously across the Internet. Reliable sessions overcome failures at the transport level (e.g. wireless network connection blinks in and out), at the transport intermediary level (e.g. a web proxy drops the request or the response), and at the SOAP intermediary level (e.g. a SOAP router blinks or drops your message due to load issues). Without this feature it is very hard to write “connected” applications that work correctly in the face of communication errors. Reliable sessions also track the connection liveliness and let you free resources on the server side if the client “goes away” for longer than a given amount of time. On top of all of that, reliable sessions give you network-adaptive congestion control which will adjust the rate of sending to the network’s ability to handle the communication load, and end-to-end flow control which will adapt the rate of sending to the server’s ability to handle the communication load. Both these features result in better network utilization. Reliable sessions are a wonderful thing for the “connected” case where both sides are up and running at the same time and allows you to use request-reply operations and alike safely.

Queued Messaging is all about having a buffer between the client and the service that decouples them in terms of availability (they don’t have to be up at the same time), processing capacity (the service only needs to be able to process the average, not peak client load), and allows wonderful things like offline support for the client (i.e. send messages to the server when it is unreachable or even not running), load-sharing and load-curve-smoothing on the service side, etc. Obviously, when you don’t know when the other side is going to process your message you don’t assume connectivity and would never block a thread waiting for the service to respond. In WCF terms this means that all your operations would be one-way.

Reliable sessions are implemented using the WS-ReliableMessaging protocol. This protocol is yet another misnamed WS-* protocol, as it actually only deals with the reliability of the transfer and says nothing about durability, delivery acknowledgments, TTL for a message, long running sessions where a particular message is lost forever, etc. Currently, there is no active work going on to develop an interoperable Queued Messaging specification, but I expect that we will get to it in the near future.

With no WS-* interoperable spec for Queued Messaging we have implemented this capability on top of the known and trusted infrastructure provided by MSMQ. We did this in a way that gives the programmer all the benefits and capabilities of working in the WCF programming model combined with the durability and transacted capture/delivery features of MSMQ. In addition, and some would say more importantly, it gives the administrator the familiar MSMQ management and administration features. In an enterprise environment one can’t just “stick” a new durable resource into the application model without getting the IT folks to buy off on it – they need to manage this resource, including doing backups, troubleshooting it when something goes wring, etc., and building this feature on a familiar V3 product like MSMQ (V4 in Windows Vista), with well documented tools and practices, is a boon for the IT guys.

We do hear what folks are saying though, and we are actively working on a set of features that will allow Queued Messaging implementations to leverage WCF’s WS-ReliableMessaging implementation. With this feature set you’d be able to “bring your own durable store” and have an interoperable Queued Messaging channel that fits nicely and naturally into the WCF architecture. In fact, if we do the job right then at the programming model level one would see no difference between the MSMQ cannel and the BYODS channel (not including configuration and error handling of course). We also expect to, at the least, have a reference Queued Messaging implementation that uses these features and illustrates the model. All I can say with any level of certainty at this point though is that we expect this to be available some time after v1 ships.

Comments

  • Anonymous
    February 20, 2006
    What's happening with the work I heard about to be able to use SQL Server 2005 Service Broker as a durable message store for WCF?

  • Anonymous
    February 20, 2006
    The comment has been removed

  • Anonymous
    February 20, 2006
    Oran, the stuff you pulled out on Google is ancient. It represents a conceptual model that we have abandoned years ago. This model had a fatal flaw – when you were writing your code you couldn’t know if you’re working in a “direct” (online, connected) mode or in a “queued” mode, which meant that you could never do request-response type communication and block a thread waiting for a response. After realizing our mistake we split the model into “direct” communication which covers most of the channels in WCF, and “queued” communication, which is currently available through the queued channels. The old functionality doesn’t live anywhere today.

    Queued Messaging works today. The bindings for it are netMsmqBinding (which you would use if you’re writing a new queued app) and MsmqIntegrationBinding (which you would use if you need to talk to an existing MSMQ app).

    As noted above, we are working to create a set of features that will let you re-use our implementation of WS-ReliableMessaging while providing your own store (after V1 ships though). That said, if WS-* interoperability is not a factor you’re considering you can use the built in implementation for Queued Channels today (it can even transfers messages over HTTP using the MSMQ’s SRMP protocol).

    Cheers,
    Shy.

  • Anonymous
    February 26, 2006
    PingBack from http://randyh.wordpress.com/2006/02/26/making-loose-coupling-real/

  • Anonymous
    February 26, 2006
    PingBack from http://netzooid.com/blog/2006/02/26/ws-and-queued-messaging/

  • Anonymous
    February 27, 2006
    Reliable Messaging demystifiedRecently I hear many questions about Reliable Messaging in WCF. In fact,...

  • Anonymous
    May 18, 2006
    Debunking the misconceptions around WS-ReliableMessaging.

  • Anonymous
    May 18, 2006
    Debunking the misconceptions around WS-ReliableMessaging.

  • Anonymous
    May 07, 2007
    Egy végtelenül hosszú linklista következik itt...

  • Anonymous
    May 07, 2007
    ¾ Step 1 – Read Principles of Service Design: Patterns and Anti-Patterns for an overview of SOA basics

  • Anonymous
    July 17, 2008
    ¾ Step 1 – Read Principles of Service Design: Patterns and Anti-Patterns for an overview of SOA basics

  • Anonymous
    July 17, 2008
    ¾ Step 1 – Read Principles of Service Design: Patterns and Anti-Patterns for an overview