• I am a few days behind on this, but Joe McKendrick writes an interesting piece on if businesspeople are begging for SOA. It is fascinating because I believe that SOA should come from the business, not because of the delivery mechanism, but because of the results. If services will truly make a business more adaptable and responsive to change shouldn’t all business people desire those results? At the same time they don’t care how that end is achieved, just that it is. That’s where we in the IT industry need to do a better job of working out the details amongst ourselves and show the business how SOA can benefit them. Once we do that we should see more SOA adoptions go smoother and real ROI can be seen.
• Joel Dehlin has blogged on the myth of youth being the ones that use instant messaging, publish and read blogs, participate in social networks, etc. I agree that the technology has been integrated into every layer of society. If you have ever been at the airport or at a Starbucks you know what I mean. Who is it exactly that has a Crackberry addiction? It seems technology has really become a part of our culture, and that it’s not just one age group that is adopting the changes.
• Visual Studio 2008 shell was announced at TechEd yesterday. Even Harry who was on-site missed the release, but it certainly looks cool.
• If you have ever met me you would quickly discover I have quite a background in Unix. That being the case I couldn’t ignore the news that Sun is releasing new blades for the desktop. I had a blade on my desk for several years and it was really a nice system to use. For those that would bash me since I work at Microsoft now I will just say that when you support Solaris boxes, having one on your desk is quite helpful. I don’t take sides in the Holy War. 😄 (via Scoble)

Due to a temporary reassignment this morning, I spent my usual blogging time moving all of my computer equipment from one cube to another.

• Sam Gentile writes about the ALT.NET moniker. My favorite of his principles is number 4 where he discusses the importance of tools versus principles and knowledge. I really agree that knowledge and principles are more important because the best tools in the world can’t help us if we don’t know how and when to use them.
• I find Mark Cuban’s ideas (here and here) about how advertising on the Internet is different than traditional media advertising. He points out that the ability of a provider to deliver higher simultaneous views is more important and valuable than delivering views for a longer period of time. I think he right on here, even if I believe his football league is going to fail. (via Blog Maverick)
• Worse Than Failure has been running an unusual contest to get the most interesting, buggy, and unusual way of writing a calculator application. They have 12 finalists for readers to review. I find that the descriptions of how the programs work (or don’t) to be hilarious.
• As I have been working on service-oriented management and monitoring I have given a lot of thought to the best way to present the data. Doesn’t it make the most sense to primarily display information from the business process point of view? I would be interested in your feedback.

Once again I get the chance to fill in for Harry while he is gone. I will attempt to keep up with the high standard he has set.

• Be careful with trampolines. I have a four year old that was bouncing on a trampoline this weekend. He twisted his knee slightly on landing, and decided that the fastest way to get comfort was to jump off the edge. His knee gave out and he fractured his tibia. I don’t think this was how he planned to start his summer. At least he is pretty calm about the whole thing.
• It looks like there is a good product out there named CliSecure to obfuscate .net code. From what I was able to read it looks like a pretty decent product, even hiding the code while its in memory. (via Larkware)
• TechEd started this morning. While I am sure Harry will be giving some on-site reports there is a link to the virtual site here.
• There is a great video showing Gregor Hohpe talking about SOA, and the many unrealistic claims in the industry. If you have read any of Hohpe’s work it is clear that he has a great understanding of the topic. (via Nick Malik)
• The NBA Finals will begin this week with the Spurs playing the Cavaliers and King LeBron. I wonder if this will help rescue the NBA from what seems to be a real apathy on the part of the average fan. Other than the series between Dallas and Golden State earlier in the play-offs it really seems there haven’t been any compelling stories. The NBA really needs a shot in the arm to become relevant again.

FYI, I’m at TechEd all next week. Given that WiFi access at conferences usually blows, I’m not planning on regular morning coffee posts. I’ve asked Dale again to keep the lights on around here and he’s graciously said yes. Since I’m not on vacation, I’ll be lurking around as well, but I’ll be in an out. See you in Orlando!

• Jeff Atwood proclaims that developers are their own worst enemy, because they write too much code. Add in a pinch of “not invented here” syndrome and I think you’ve got it. This is one of the reasons why people think Ruby is the tits.
• Scott Hanselman has already taken advantage of the new WLWriter provider customization API.
• Erik Johnson writes about the thunderous REST bandwagon. He doesn’t explicitly say it, but my take is that he thinks this all ends up in some middle ground between REST and WS-*. I hear that, at least, if that’s what he’s saying. I’m not sold on “HTTP is all you need” – I need durability and async messaging, but I don’t see how to get there from here with just HTTP.

Nick jumps on the durable messaging bandwagon, pointing out that it’s HUGE. Not just huge, or Huge but HUGE. But for my taste, he could emphasis it even more – HUGE – and still not capture just how important I think durable messaging is. But while he could use more bolding and italics, he certainly explains the problem well:

The reason that [reliability] becomes a problem in SOA is because the basic strength of SOA is the message, and the weakest link is the mechanism used to move the message. If we create a message but we cannot be certain that it gets delivered, then we have created a point of failure that is difficult to surpass.

Durable messaging solves two fundamental reliability issues:

1. Transactional Message Send. I want to send a message to some external service as part of a transaction. That is, I only want to send the message if the transaction commits. If the transaction aborts, I don’t want to send the message. The only way to do this is to durably record the intent to send the message within the transaction and then deliver the message after the transaction successfully commits.
2. External System Unavailable. I’m sending a message to an external service that is unavailable at the moment. Maybe it’s a temporary network condition, maybe it’s scheduled downtime, maybe the data center burned down, I don’t know. But because the message is durably stored, I can retry long after the sending transaction has committed. Furthermore, I can continue to retry (until success of course) even if my sending system reboots, fails over to a hot standby or has to be restored from backup (assuming you backed up after message was sent).

However, Nick points out that reliability has to be considered as part of our design, so do Agility, Flexibility, Scalability, Maintainability, etc. etc. etc. Agility and flexibility require standard transport protocols while scalability and maintainability require intermediation. Unfortunately, at this time there is no standard transport that provides intermediation and durability. Nick says that Microsoft’s “platform is lacking here”, but I’d say it’s an industry wide problem.

Nick mentions least three Microsoft technologies that provide some sort of durable messaging – MSMQ, SSB and BizTalk – but they’re all proprietary. The market leader in this space is MQ Series, which is also proprietary. WS-RM was supposed to be support durable messaging, but doesn’t. There is the Advanced Message Queuing Protocol group, which is defining an open protocol for MQ style systems, but without involvement from any major platform vendors I’m hard pressed to see this go anywhere. Personally, I’d love to see the SSB protocol published, and apparently the SSB wire protocol was designed “to be completely SQL Server agnostic.” Here’s hoping that happens.

Nick goes on to call WCF “immature” because of the lack support for message durability. I think that’s somewhat unfair: I think it’s WS-* that’s immature here, not WCF. It’s easy to confuse the two since they’re so joined at the hip in WCF v1. But WCF’s support for MSMQ shows that it can handle durable messaging, even though there is no usable standard for durable messaging in the WS-* stable. Over time, I think WCF will evolve to support a larger variety of messaging scenarios – WS-*, REST, durable messaging, etc. – out of the box. But for those of us who care deeply about durable messaging, WCF’s current lack of support is pretty frustrating.