• Huge perk of the new job: new hardware. I had to give up my Dell workstation but I got a Lenovo T61p dual core widescreen laptop, an HP dc7800 dual monitor quad core desktop and a Polycom CX700 IP phone. I’m really digging the Lenovo’s integrated fingerprint reader – no more password login – but I’m most impressed with their integrated driver management software. Sure beats the heck out of hunting for dozens of updated drivers all over the place like most vendors for you to.
• Minor downside to all my new toys: I spent most of my first week on the job installing and configuring said new toys.
• Caps will face the Flyers in the first round of the playoffs which starts Friday. I have a feeling that I’ll be feeling poorly Friday around 3pm and have to head home early. 😄

DyLang Stuff

• Apparently, Michael Foord isn’t getting enough exposure on this blog. 😄 He left a comment to remind me to mention the IronPython URLs link blog he writes along with Mark Rees and Seo Sanghyeon.
• Speaking of Michael, his employer Resolver Systems just launched a new product: Resolver One Quant.
• Still speaking of Michael, he’s quoted in the InternetNews article Python Fans Take Aim at the Enterprise.
• My teammate Jimmy Schementi posts a preview of his spare time project “Silverlight on Rails”. This RoR plugin lets you declaratively specify if you want your RoR controller code to be accessed remotely via AJAX and run on the server or if you want that code to be downloaded to the client and run in SilverLight. Very cool stuff.

Other Stuff

• Don Syme provides some insight into the F# producization process. There’s going to be an update to the “Research release” later this month and a CTP of the “Product release” later this summer (Brian McNamara has the CTP details). I am looking forward to these releases, though I’ll probably be too busy w/ IPy to experiment much with them.
• Speaking of F#, Matt Podwysocki continues his adventures with F# with a look at tuples, records and discriminated unions. Of the three, I find discriminated unions the most interesting since there isn’t anything like it in other languages I’ve used.
• Gregori and Chris both announce the release of Unity 1.0. Congrats guys! But if I don’t have time to hack around with the latest F# release, you can imagine I won’t be getting to Unity any time soon…
• Jeff Atwood recommends you build your application UI first. Furthermore, he does a good job selling the value of paper prototyping as well as introducing the concept of PowerPoint prototyping. Money quote: “You don’t want something too powerful.”
• Via LiveSide I discovered James Hamilton’s blog. Normally, hardware infrastructure isn’t really my bag, but I find his ideas around using ISO standard shipping containers as modular data center building blocks fascinating. For example, check out this post that suggests sticking modular data centers in condos would be cheaper than building data centers! Subscribed.
• Speaking of ISO, you may have heard Open Office XML was ratified as an ISO standard. Obviously, there was a lot of controversy around this, but Miguel de Icaza lists of what he considers major community wins from the standardization process. Anything that “pushed Microsoft into more open directions” is a good thing IMO.

• Joel Dehlin, a former Microsoft employee and the CIO of the LDS church is conducting a series of tech talks. The next one is being planned for the bay area. If you are interested you can respond to his post here. The dates would be between April 22 – 26 with a tentative agenda as follows:

  • Keynote
  • Infrastructure breakout
  • Development breakout
  • Interaction Design breakout
  • Community breakout
  • Building to building video breakout

• Everything needs a 12 step program now. CNN has a 12 step program to cure your email addiction here. I started thinking about this after Harry’s post saying he had hit zero email bounce prior to going on his secret mission.

• I read an interesting blog on XNA and how it fits into Microsoft’s strategy in gaming. I am not sure I agree with all of the points, but I found the arguments to be compelling.

• My BYU Cougars are now up to 21 in the AP Poll. I can’t think of a year when both the football and basketball teams have both had such successful seasons.

• Between today and tomorrow I will be finalizing my vision document for how I think monitoring should work in the Service-Oriented Infrastructure project I am on. As I was outlining my vision it really hit me how much there is to do.

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.

Regular readers of DevHawk are likely aware of my obsession interest in SQL Service Broker (aka SSB). I’ve also been doing a lot of WCF work lately. While there are parts of WCF that I think rock, overall I’ve found WCF lacking due to it’s lack of support for long running services, which SSB excels at.

So it was with great interest that I read this recent article on Integrating WF and WCF. WF is expressly designed for long running systems, so I wanted to see how the article dealt with the WCF’s lack of support for such scenarios. Unfortunately, the article basically sidesteps the issue. While it has lots of great info about hosting WF inside a WCF service, the article uses duplex channels for communication between the service and its clients. As I have pointed out before, this approach is impractical because it requires that both the service and its consumer remain alive in memory until the WF end.

Remember this quote from Essential WF?

“It is wishful thinking to assume that the operating system process (or CLR application domain) in which the program begins execution will survive for the required duration.”

So basically this WCF/WF sample is wishful thinking. Fine for a demo, but given the severe lack of information out there on integrating these two technologies, I’m worried that many people will read this article as best practice guidance, which in my opinion would be a mistake.

But instead of firing up my blog (that is, like last time) to write a scathing post about how broken this sample is, I emailed Paul which led to a concall with Shy to discuss WCF’s lack of support for long running services. Imagine my surprise when Shy agreed with me completely, furthermore saying that support for long running services had been “out of scope” for v1 of WCF. I thought that the whole point of duplex channels was for long running services. But apparently I was wrong.

Shy said to think of the duplex channel in terms of sockets, rather than long running conversations. And just like that, WCF made a ton more sense to me. I had been directly comparing the SSB and WCF communication models, but that’s apples and oranges. It would be like comparing SSB to TCP.

If you think about it, vanilla HTTP works a lot more like UDP, even though it’s layered on top of TCP. Both UDP and HTTP support connectionless operations and neither UDP nor HTTP are reliable or provide message ordering. The comparison isn’t perfect: for example, UDP isn’t limited to a single response for an incoming request. But by and large, HTTP is a very UDP style protocol.

If HTTP is basically UDP, then WS-* is trying to be TCP. Frankly, I never understood the point of WS-ReliableMessaging. I always thought reliability == durability == SSB or MSMQ. But when you realize that HTTP lacks TCP-like reliability and ordering capabilities, suddenly this WS spec makes sense. In fact, Shy made this exact point almost a year ago. At the time, I didn’t get it because I didn’t understand the duplex channel as sockets analogy. Now, I see the value of adding these capabilities to HTTP.

What Shy said was clear and to the point but unfortunately completely missing in the official WCF documentation. For example, the docs on Duplex Services say this:

A duplex service contract is a message exchange pattern in which both endpoints can send messages to the other independently. A duplex service, therefore, can send messages back to the client endpoint, providing event-like behavior. Duplex communication occurs when a client connects to a service and provides the service with a channel on which the service can send messages back to the client.

The docs make no mention that the “event-like behavior” of duplex services only works within a session. And I’m not the only one who mistakenly believed that duplex services could be used for long running services (here’s an article in DDJ that makes the same mistake). Shy used the term “episodic” to describe services that span session boundaries. I’d like to see the docs updated to include that concept.

Taking the TCP/UDP analogy even further, I think it demonstrates how pointless the REST vs. SOAP debate is. As UDP is a thin layer on top of IP, REST is a thin layer on top of HTTP. But nobody argues much about UDP vs. TCP these days. I was in grade school when UDP and TCP were standardized, so maybe there were big TCP vs UDP flame wars at the time. But twenty five years later, it’s pretty clear that TCP vs UDP is not an either-or proposition. Some protocols are better built on UDP while others are better built on TCP. I’m guessing we’ll see a similar evolution with SOAP and REST.

Personally, I would expect that message exchanges between services will become more complex over time. Complex message exchanges would seem to favor stateful SOAP over stateless REST for the same reason complex network protocols favor connection-oriented TCP over connectionless UDP. But SOAP could never displace REST any more than TCP could ever displace UDP. Furthermore, as Larry O’Brien recently wrote “the onus is on the WS-* advocates to prove the need”. TCP standardization only lagged a year behind UDP standardization where WS-* has lagged at least six years behind REST. I wonder if UDP would be more prevalent today if it had gotten a six year head start on TCP.

Finally, this “SOAP as Sockets” flash of understanding has also helped me understand how SSB / WCF can evolve together in the future. Some folks have suggested an SSB transport for WCF and I’ve personally looked into such an approach. But given since SSB is at a higher level of abstraction than WCF, it makes much more sense to layer SSB on top of WCF instead of the other way around. Today, SSB uses two protocol layers: the top level Dialog Protocol, which is built on top of the lower-level Adjacent Broker Protocol (ABP), which in turn is built on TCP. I’d like to see a version of ABP that was built on top of WCF instead of directly on top of TCP. SSB’s Dialog Protocol would tie together the WCF duplex sessions into a long-running conversation the same way that it ties together TCP sessions today.

Eventually, I would love to see something that has the programming semantics of SSB and the interoperability of WCF. That would be like the the Reese’s Peanut Butter Cup of service messaging.

So now that I’m back, we’re beginning work in earnest on my project. For those not following along at home, my project is to deliver shared service oriented infrastructure for Microsoft’s internal IT department. We’ve spent the time since I moved over working on our business justification, and now we’re moving into specifications and prototyping. That is, I get to starting getting my hands dirty.

As part of the prototyping efforts, we’re looking to build some sample business services on top of our prototype infrastructure. The idea being to both illustrate what we’re building as well as have a playground where we can experiment with new ideas. During the prototyping, I’ll be pretty involved with the development. But once we start writing production code, the dev team will take that over but I will continue to own the service playground. I’ve been kicking a playground idea like this around for several years, so I’m pretty excited about it.

The question is, what kind of business scenario should we build? I want the sample business services to be something interesting and real-world-esque. But of course, it can’t be too complex since I wasn’t hired to build a playground as my primary job function.

So far, we have two primary ideas:

• Enterprise Management System: AdventureWorks is the primary sample database that ships with SQL Server. They have business scenarios around Sales & Marketing, Product Management, Purchasing and Manufacturing. This sounds suspiciously like an ERP/CRM/SFA type enterprise system. On the plus side, MS is an enterprise so things like ERP/CRM/SFA are the types of solutions we need/use/buy/build internally. On the negative side, it’s complex to do real-world and teams that actually do ERP/CRM/SFA inside Microsoft might dismiss the infrastructure if the playground isn’t real-world enough.
• Prediction Market: If you’ve ever seen Hollywood Stock Exchange (HSX) or Tradesports, those are prediction markets. The basic idea is that you trade on predictions, rather than companies like you would in a stock market. Using HSX as an example, you get 2 million “Hollywood Dollars” (i.e. play money) to invest in upcoming movies and / or movie stars. Those movies and stars pay out based on the money they make at the box office. They also have derivatives for opening weekend, blockbusters and the Oscars. HSX even sells forecasting and prediction services based on the HSX market. Of course, I can’t build something quite so extensive, but we could get pretty far with this idea. The upside is that it’s relatively simple (compared to enterprise management systems) and there’s little conflict with existing systems inside Microsoft. The downside also is that it’s relatively simple and not like anything we’re building inside Microsoft.

I’m leaning towards the prediction market, as it sounds more fun to build and experiment with. What do you think?