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.

Being at TechEd without thousands of things to worry about is somewhat strange. But I could get used to coming and going as I please, not tracking down speakers, ordering whiteboards and the rest of the responsibility that comes with track ownership.

My first session is right after lunch – 1:15 @ Green TLC Theater 4 if you’re on site. Our Technical Learning Center (aka “the cabana”) is fairly sparsely attended, at least for the moment. MSIT has never had this significant a presence at TechEd before, so I wouldn’t be surprised if the attendees aren’t quite sure what to make of it. I went over to the Architecture and SOA & Web Services area and ran into quite a few people I knew. I expect I’ll spend more time down there than in my cabana.

I skipped the keynote this morning, apparently they did a Back to the Future parody. Had I known, I might have gotten up. But my flight got in at midnight last night, I didn’t get to the hotel until 1am and an 8:30 keynote on the east coast feels like a 5:30 keynote to my still jet-lagged system. Since I skipped it, I’m not sure what was announced, but the opening press release salvo mentions the first CTP of SQL Server 2008, Visual Studio 2008 (aka the Visual Studio version formally known as “Orcas”) and the Open XML SDK among other things. I’ve been hacking some Open XML lately, so I’ll have to check that last thing out. Apparently, there was some also discussion of the Dynamic Systems Initiative, but in the press release it came across as Infrastructure Optimization. Not sure if those are one in the same or not.

BTW, for those not attending TechEd, you can check out Virtual TechEd and the TechEd Virtual Pressroom. Not the same as being here – no conversations, no swag and no roller coasters. But at least you can keep up on what’s being announced, presented and spoken about.

I’m off to lunch. Missing the keynotes == missing breakfast. My session is in about an hour, so I’ll probably post again afterwards. I’m hoping for more conversation and less presentation, so the only prep I’ve done is to iron my speaker shirt.

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.

• Google announces Gears, a browser plugin for taking your web application offline. Developer docs are also available. TechMeme has lots more, but obviously this is yet another significant bow shot in the upcoming unified client platform war. By my count, there are four horses in this race: Microsoft with .NET and Silverlight, Adobe with Flash and Apollo, Google with AJAX and Gears and Sun with Java and JavaFX. Did I miss anyone? (via Dare Obasanjo and Scott Hanselman)
• Alex James writes that REST is about intent and shows a pseudo-code sample posting multiple changes to a single endpoint as a way of demonstrating your intent that they be applied atomically. Andres Aguiar left a comment saying that Astoria does something similar. Personally, I like that model for transactions better than the transaction factory approach Jon Udell describes. But either way, you’ve moved beyond simple CRUD style services and into the world of protocol. Surfacing intent via protocol aligns with what Tim described as making the protocol explicit
• Windows Live posted new beta versions of Writer, Mail and Messenger. I’ve been on an internal build of the new Writer for a while and I’ve really been impressed. There’s also a new Provider Customization API, so I can’t wait to see what the DasBlog folks do with that.
• Scott Guthrie’s LINQ series continues, this time covering how to build the LINQ to SQL data model. Looks like they used the DSL toolkit to build the LINQ to SQL data model designer, cool!
• Martin Fowler digs intoracc, a yacc-esque compiler compiler for Ruby. Looks interesting as a internal DSL example (better than the now-canonical rake example). But why is the sexy new language on the block using old school CFG’s instead of new hotness PEG’s?
• Speaking of Martin, he writes about the opportunity Ruby presents to Microsoft, building on Scott Hanselman’s concerns that Microsoft is losing the Alpha Geeks. Sam Gentile also weighs in, suggesting that Microsoft is at the crossroads. Frankly, I don’t work in evangelism anymore so I’m going pass these links along without comment except to say that Scott, Martin and Sam are all folks I have much much respect for.

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.