(Harry is on a secret mission in uncharted space this week, so instead of the daily Morning Coffee post, you get a series of autoposted essays. This post builds on Harry’s recent epiphany about WCF and long running services)

Way, way, way back in March of 2003, IBM and Microsoft published an “overview and roadmap” white paper entitled “Reliable Message Delivery in a Web Services World“. It contained the following paragraph under the section “Exchanging Messages Reliably”:

WS-ReliableMessaging is not bound to underlying transport protocols or sessions. This means that the lifetime of a WS-ReliableMessaging conversation can span long periods of time (days, weeks) even when one or both systems are rebooted. This allows conversations to be suspended mid-stream (for example, to allow system maintenance) and then resumed without needing to retransmit the entire conversation. [emphasis added]

Now I know how I got confused about WCF and long running services in the first place. Support for long running services was part of the original web services vision!

About three years after that white paper was published, Shy Cohen wrote a post entitled Reliable Messaging Demystified on his blog. Shy was at one time the feature owner of WS-RM in WCF (according to his post) and wrote the following:

Reliable sessions [in WCF] 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.

At some point in the three years between March 2003 and February 2006, WS-RM went from being the enabler of long running services to “yet another misnamed WS-* protocol”. And with it, WCF lost (never had?) the ability to support long running services (as I’ve written previously).

Now all and all, this isn’t a big deal. I agree with Shy that WS-RM is under specified as mechanism for durable messaging (Shy calls this “queued messaging”). Attempting to build durable messaging on top of WS-RM sounds like it would have been both difficult and unlike to broadly interoperate. So implementing WS-RM for TCP style reliability and leveraging MSMQ as a transport for people that need durable messaging sounds like a pretty good compromise, especially for a v1 product. Of course, it is not exactly unheard of for a project’s end result not to completely live up to the original vision. But I have a specific requirements in this case, so I wanted to know more.

By calling it “misnamed”, it sounds like WS-RM was never really intended to be used for durable messaging. However, the July 2003 Reliable Messaging Feedback Workshop indicates that it was. In particular, Rodney Limprecht’s “Reliable Messaging Scenarios” deck describes WS-RM as supporting scenarios requiring “either volatile or durable endpoint state”. His list of scenarios included both an “Intermittent Connectivity” scenario where “messages pending transfer are staged to disk and exchanged when connected” as well as a “Message Queue Integration” scenario that used WS-RM to interop between JMS and MSMQ. Seems safe to say that WS-RM was originally intended to support durable messaging. So what happened? How did it become “misnamed”?

Rodney’s deck describes WS-RM as having the “flexibility to meet scenario requirements”. But flexibility comes at a cost. For example, the flexibility of WCF’s configuration comes at the cost of significant complexity. In the case of WS-RM, it appears that by trying to make it flexible enough to support both volatile and durable reliability, the authors might have made it too flexible. WS-RM implementers have broad latitude in building the capabilities Shy mentions (durability, acknowledgements, TTL, etc) as well as describing said capabilities in policy. By providing that latitude, we lost the ability to broadly interop durable messaging, which I would suspect is why it ended up out of scope for WCF v1.

As I said before, lack of support for WS-RM based durable messaging isn’t that big a deal. As long as you understand WCF’s sweet spot - the current version’s sweet spot anyway – and don’t try and make it be something it’s not, you should be fine. Furthermore, Shy mentions the need for an “interoperable Queued Messaging specification” and wrote that it’s something he “expect[s] that we will get to it in the near future”. Here’s hoping that spec is less flexible than WS-ReliableMessaging.

• Joel Dehlin, the CIO of the LDS church has an interesting blog entry on buy versus build this morning. His main point is that buying is often cheaper, but only if you can move your business processes to match the processes in the off-the-shelf software.
• The search for Jim Gray by his friends and colleagues has been called off. Even with a massive high-tech effort no new clues have been turned up. For the sake of his family I do hope that the mystery is solved. I would imagine it is very hard to not know what happened to him.
• I am currently running a Build and Deployment Task Force. We are trying to ensure that our team follows best practices when building new applications. The project that Harry and I are working on seems to be a good test bed for the process.
• For those of you who read my blog you know I am passionate about how we implement Service-Oriented Architecture in the real world. I have been reading a book titled Service-Oriented Architecture: A Planning and Implementation Guide for Business and Technology. I find the description of real business objections, and how to solve them quite refreshing.
• It appears that the San Diego Chargers are going to hire Norv Turner to replace Marty Schottenheimer as their head coach. I don’t see how fans of the Chargers can possibly see this as an improvement.

I realize yesterday I said I was on vacation starting today. In reality, I’m not going to the office today, but I have time to post this before my vacation starts in earnest.

• I hit Zero Email Bounce in advance of my vacation. It’s been quite a while since the last time I got here and I hope to hit it much more often in the future.
• The DSL tools team shipped a Designer Integration PowerToy that allows you to integrate models from multiple DSL designers into a single authoring tool. Gareth has more here.
• Assorted PowerShell links: PowerShell Analyzer and PowerShellIDE. Both look interesting.
• Personally, I like Notepad2 but apparently the only way to add a new syntax highlight scheme requires modifying the source code. Ugh. Anyone out there already added PS support to Notepad2? How about a suggestion for a simple text editor that supports extensible syntax highlighting?
• Steve, Nick and Tomas all commented on my long running services WCF post. Tomas mentions Advanced Message Queuing Protocol (AMQP) which looks to be developing an open spec queuing system like MSMQ or MQ series. Interesting, but given the lack of involvement of the major MQ and DB vendors, I’m hard pressed to imagine this gaining any kind of critical mass.

Introduction

While Harry is out of the office on a well deserved vacation with his family I will be acting as a guest blogger for his website.

My name is Dale Churchward and I have been working at in Microsoft IT as an application architect since June 2006. Prior to coming to MS I worked in operations in both the telecommunications and healthcare industries. As Harry pointed out I tend to be very operations focused. While I love working on new technologies I am keenly interested in how a design will work in production, and try to ensure we have considered support considerations as part of our designs. Each member of our team comes in with a different background. This helps us as we are each strong in different areas. I also write to my own blog which can be found here. In my own blog I tend to write on a wide array of subjects, depending on my mood at the time. While Harry is away though, I will be posting on technology areas I am interested in, and staying true to his morning coffee vision, albeit with a slightly different take.

The Doughnuts

• The Build Master by Vincent Maraia is an excellent book if you are interested in the build process and how to make it as efficient as possible.
• We had a great meeting with the Patterns & Practices team the other day. Since I am still new to Microsoft it is still a bit overwhelming to meet the authors of documents you have read and used over the years.
• I recently have been spending some cycles working with System Center Operations Manager 2007. I believe that it provides some excellent tools to monitor and repair a system plus it’s designed to be service focused.
• Francis Stokes has produced 6 episodes showing what would happen if heaven was being run like a company named God Inc. There are currently 6 episodes. No matter what your belief or lack thereof in a supreme being the videos are hilarious.
  • Episode 1
  • Episode 2
  • Episode 3
  • Episode 4
  • Episode 5
  • Episode 6
• I have been spending a lot of time thinking about how heartbeat transactions between multiple services should operate. In the drawing below you can see 3 web services and a monitoring one. In the original design the monitoring service was sending heartbeats out to each of the web services to see if they were available. This seem inefficient to me as we really don’t care if the monitoring service can reach the web service. What we need to know is if any dependent web services are able to connect. In the drawing we have a web service residing in the extranet (Web Service 1) that sends data to a web service in the corporate network (Web Service 2). We really don’t care if the monitoring service can talk with web service 2, but we definitely want to know that web service 1 can get there. Once web service 1 realizes that is can’t connect to 2 we then notify the monitoring system so that the owner of web service 2 can take action. Web service 1 still continues sending heartbeats though so that it is aware of when the second web service becomes available again.

I’m taking some time off, starting tomorrow. I’ll be out all next week. That means that you’ll have to look elsewhere for your daily dose of Morning Coffee. I do have a few posts I’ve been holding back to auto post next week, so you don’t have to go completely DevHawk free. But if something big happens next week, don’t expect any immediate reaction from me.

In addition to various technical blogs, I read a variety of political blogs. Not sure why, but where most of the technical blogs I read are individual voices, political blogs seem to be more group efforts. And even on the individual political blogs, they still have guest posters that come in periodically and when the primary blog owner is on vacation. Since I’ve gotten into the habit of posting every day, I decided I’d try out a guest poster. So in addition to a few auto posted entries, my teammate Dale Churchward will be holding down the fort here at DevHawk in my absence. I’ve linked to Dale’s blog Half My Brain on many occasions, so you should have a passing familiarity with him.

One of the interesting things about having Dale posting here is how different he and I are. I’m a developer at heart but he’s an sysadmin at heart. I code, he scripts. I worry about developer productivity, he worries about management and operations. He carried a pager for ten years, I didn’t. I’m a Democrat and he’s <gasp> a Republican! (At least he’s not a Penguins fan.)

Seriously, one of the things that is great about working with Dale is the vast difference in experience. He’s forgotten more about management and operations than I know (though I am a fast learner) so we make a very good team. Have a good week and be nice to Dale while I’m gone.