• What does it take to be an architect? Skyscrapr.net attempts to answer this question by asking a bunch of architects.
• I have started teaching my children about astronomy. I found an open source product called Stellarium that is excellent for learning about the celestial objects visible in your area.
• A Methodology for SOA adoption? I read an interesting blog on this subject from a couple of weeks ago. It’s not a long article, but the author makes some interesting points including an outline for SOA adoption.
• I finally picked up Gears of War on Friday. It really isn’t a game I can see playing much, although I can see why it’s popular. I guess the best and the worst part of the game is having to utilize cover so you don’t die right away.
• Windows Live Writer is a great tool! I use it to author the blogs for my website, and this week I have been using it on these Morning Doughnuts posts. My favorite feature is that you can preview your post and see exactly how it will appear on your website. This has been particularly useful since Devhawk and my site look quite different.

My wife wanted snow, and main Microsoft campus got it. Not much – less than an inch by my measurement – but enough to snarl traffic getting off campus. Jules and I decided it would make more sense for me to grab dinner in the campus cafe and wait out some of the crowds rather than brave the snow and traffic on a nearly empty tank of gas.

Of course, I don’t work on campus any more. My office is way down in Issaquah. Unluckily for me, I had a meeting on main campus today. It was a great meeting – talking about my project with some field architects. But I didn’t expect to get trapped on campus by snow or I would have blown it off. Next time, I need a meeting room with windows!

Update: It took me only 45 minutes to get home, which is actually fairly typical for me to get home from main campus in the evening. There must have been an accident on 520 because when I crossed the freeway by campus, it was bumper-to-bumper as far as I could see in both directions. But when I passed the 520 exit by my house, there was only a trickle of cars coming off it. The side streets were surprisingly empty. Maybe everyone was afraid they’d be impassible with snow? Takes more than an inch of snow to stop me and my 4WD Chevy Blazer.

I mentioned last week that WF “is one of two foundation technologies that my project absolutely depends on”. Sam Gentile assumes the other foundation technology is WCF. It’s not.

As a quick reminder, my day job these days is to architect and deliver shared service-oriented infrastructure for Microsoft’s IT division. These services will be automating long running business operations. And when I say long running, I mean days, weeks or longer. While there will surely be some atomic or stateless services, I expect most of the services we build will be long running. Thus, the infrastructure I’m responsible for has to enable and support long running services.

The other foundation technology my project depends on is Service Broker. Service Broker was expressly designed for building these types of long running services. It supports several capabilities that I consider absolutely critical for long running services:

• Service Initiated Interaction. Polling for changes is inefficient. Long running operations need support for the Solicit-Response and/or Notification message exchange patterns.
• Durable Messaging. The first fallacy of distributed computing is that the network is reliable. If you need to be 100% sure the message gets delivered, you have to write it to disk on both sides.
• Service Instance Dehydration. It’s both dangerous and inefficient to keep an instance of a long running service in memory when it’s idle. In order to maximize integrity (i.e. service instances survive a system crash) as well as resource utilization (i.e. we’re not wasting memory/CPU/etc on idle service instances), service instances must be dehydrated to disk.

In addition to these capabilities, Service Broker supports something called Conversation Group Locking, which turns out to be important when building highly scalable long running services. Furthermore, my understanding is that Conversation Group Locking is a feature unique to Service Broker, not only across Microsoft’s products but across the industry. Basically, it means that inbound messages for a specific long running service instance are locked so they can’t be processed on more than one thread at a time.

Here’s an example: let’s say I’m processing a Cancel Order message for a specific order when the Ready to Ship message arrives for that order arrives. With Conversation Group Locking, the Ready to Ship message stays locked in the queue until the Cancel Order message transaction is complete, regardless of the number of service threads there are. Without Conversation Group Locking, the Ready to Ship message might get processed by another service thread at the same time the Cancel Order message is being processed. The customer might get notified that the cancellation succeeded while the shipping service gets notified to ship the product. Oops.

There’s also an almost-natural fit between Service Broker and Windows Workflow. For example, a Service Broker Conversation Group and a WorkflowInstance are roughly analogous. They even both use a Guid for identification, making mapping between Conversation Group and WF Instance simple and direct. I was able to get prototype Service Broker / WF integration up and running in about a day. I’ll post more on that integration later this week.

Last but not least, Service Broker is wicked fast. Unfortunately, I don’t have any public benchmarks to point to, but the Service Broker team told me about a private customer benchmark that handled almost 9,000 messages per second! One of the reasons Service Broker is so fast is because it’s integrated into SQL Server 2005, which is is pretty fast in it’s own right. Since Service Broker is baked right in, you can do all your messaging work and your data manipulation within the scope of a local transaction.

Service Broker has a few rough areas and it lacks a supported managed api (though there is a sample managed api available). Probably the biggest issue is that Service Broker has almost no interop story. If you need to interop with a Service Broker service, you can use SQL Server’s native Web Service support. or the BizTalk adapter for Service Broker from AdapterWORX. However, I’m not sure how many of Service Broker’s native capabilities are exposed if you use these interop mechanisms. You would probably have to write a bunch of application code to make these capabilities work in an interop scenario.

Still, I feel Service Broker’s unique set of capabilities, its natural fit with WF and its high performance make it the best choice for building my project’s long running services. Is it the best choice for your project? I have no idea. One of the benefits of working for MSIT is that I get to focus on solving a specific problem and not on solving general problems. I would say that if you’re doing exclusively atomic or stateless services, Service Broker is probably overkill. If you’re doing any long running services at all, I would at least give Service Broker a serious look.

Even though I moved offices just a month ago, we moved again today. New office won’t be ready until Monday, so I “worked from home”. Of course, with two kids too young for school, getting much actual work done is essentially impossible. I did manage to get my blog upgraded to dasBlog 1.9 during the kids’ naps.

My new office building is “Issaquah Black” which is a much cooler name than “18″ or “Sammamish C”. The building used to be a Boeing building. In fact, my old next door neighbor used to work in this building, back when he and I lived a scant 2.5 mile / 6 minute commute from here. Boeing moved him to Everett and apparently decided to get rid of the building. A year ago, I moved to a new house on the outskirts of Redmond, so my commute is 12.5 miles / 20 minutes. Significantly longer than if I had never moved, but I love my house and can easily deal with a 20 minute commute. Even though main campus is closer (only 8 miles), with all the rush hour traffic it takes closer to 45 to get there!

This is even bigger than Scoble leaving, much less me moving to a new role.

Microsoft Announces Plans for July 2008 Transition for Bill Gates

Microsoft Corp. today announced that effective July 2008 Bill Gates, chairman, will transition out of a day-to-day role in the company to spend more time on his global health and education work at the Bill & Melinda Gates Foundation. The company announced a two-year transition process to ensure that there is a smooth and orderly transfer of Gates’ daily responsibilities, and said that after July 2008 Gates would continue to serve as the company’s chairman and an advisor on key development projects.

The company announced that Chief Technical Officer Ray Ozzie will immediately assume the title of chief software architect and begin working side by side with Gates on all technical architecture and product oversight responsibilities, to ensure a smooth transition. Similarly, Chief Technical Officer Craig Mundie will immediately take the new title of chief research and strategy officer and will work closely with Gates to assume his responsibility for the company’s research and incubation efforts; Mundie also will partner with general counsel Brad Smith to guide Microsoft’s intellectual property and technology policy efforts.

Wow.