“Looks like I picked the wrong week to stop sniffing glue”
Steve McCroskey, Airplane!

• So it’s been a while since my last post. Just over a month, not including The F5 High, which wasn’t “original IP”. Frankly, I just stopped reading pretty much cold turkey. I wanted and needed to go heads down on day job stuff for a while. Since I haven’t been reading, Morning Coffee is going to be a little cold while I ramp back up.
• The new NHL season is upon us, and the Caps are looking good so far. Obviously, they have the new uniforms, but they’re also out to a 2-0 start for the first time in five years. And in those two games, they’ve only allowed one goal and are 100% on the PK. It’s nice to see them start strong, but obviously there’s a long way to go. Here’s hoping the can stay strong all season.
• Speaking of staying strong, the wheels that were rattling last week came off the Trojan bandwagon completely this week. I’m not sure it’s as big an upset as Appalachian State beating Michigan but it’s close. What happened to the team that scored 5 TD’s in a row on Nebraska?
• Big news last week is that MSFT is going to release the source code to much of the .NET Framework. Scott Guthrie has the details. Frankly, between Rotor & Reflector, it wasn’t like you couldn’t see the source code anyway, so this seems like a no-brainer. But integrating it directly into the VS Debugging experience, that’s frakking brilliant.
• I haven’t had a chance to install the new XML Schema Designer (Aug 07 CTP)  but I was really impressed with this video. The XML Team blog has more details. However, I’m not sure what the ship vehicle is. The CTP install on top of VS08 beta 2, but in the video they keep saying “a future version” of VS, implying that it’s not going to be in VS08.
• Dare is spending some time investigating SSB. I think it’s interesting that some of the REST crowd are starting to see the need for durable messaging. Dare argues that the features and usage models are more important than wire protocol. As long as it’s standardized, I don’t care that much about the protocol. Several of the REST folks mentioned AMQP. While I’ve got nothing against AMQP technically (frankly, I haven’t read the spec), but what does it say about durable messaging vendors (including MSFT) that a financial institution felt the need to drive an interoperable durable messaging specification?

• Libor Soucek continues our conversation about durable messaging. We still don’t agree, but he says he “fine” with durable messaging. He does go out of his way to differentiate between enterprise and supporting systems. But when you’re building connected systems, does that differentiation still matter?
• After taking a few months off, John deVadoss is back at the blog. Check out his Big SOA/Little SOA post. I especially like his snowball analogy “How do you build a big snowball? You start with a small snowball.”) though he’s also on this “middle out” bandwagon. Do we really believe “middle out” works, or are we just saying it because we know top down and bottom up don’t? And John: You’re welcome!
• Anyone coming to the Microsoft SOA & Business Process Conference this fall? Maybe we can have a shindig / blogger dinner / unconference / something?
• Remus Rusanu writes about SSB’s dynamic routing. One of the (many) cool things about SSB is that all the addressing is logical, not physical. Routing is what binds logical addresses to physical addresses, and it’s extensible.
• Martin Fowler discusses the value of sticking to one language. I agree with his points about large frameworks being as difficult to learn as a new language. I’ve said for a long time “If you build a framework, build tools to make it easy to use your framework”. Language is obviously a core example of a tool. Another interesting point Martin makes is the traditional “intimate relationship” between scripting languages and C, but that the rise of JVM & CLR makes them impossible to ignore. Does the need to play well in a managed environment hinder a C based language like Ruby when compared to a natively managed scripting language like Powershell? Finally, Martin’s “jigger of 80 proof ugliness” quote made me laugh.
• Politics 2.0 Watch: EJ Dionne says that DailyKos is doing for Democrats what Rush Limbaugh did for Republicans almost twenty years ago: mobilization. Josh Marshall points out that “what’s happening today is vastly more participatory and distributed…than anything happening back then.”

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.

These morning meetings are really cramping the “morning” style of these posts. But better late than never, I guess.

• Politics 2.0 Watch: Democrats pwn Republicans online. (via Balloon Juice)
• Roger Wolter writes about integrating SSB with WF, something I’ve experimented with myself. I didn’t find the integration quite as natural as Roger did – transactions are a real PITA, and Roger apparently he hasn’t looked into that yet - but I agree 100% with the idea that “most SSB programs end up looking a lot like a workflow.” Looking forward to seeing your code, Roger.
• Pat explains his Newton vs. Einstein view of distributed systems and then rants about Consistency, Availability and Partition-tolerance. In particular, he discusses the evolution of what consistency (and to less extent availability) means in the face of loose coupling. Do yourself a favor and give up on distributed transactions now. Also, Pat points to another paper from CIDR dealing with isolation in services. Haven’t read it yet, but I’ve added it to “the pile”.
• David Chappell writes about Service Component Architecture vs. Service Oriented Architecture. Since I don’t “do” evangelism anymore, I don’t spend much time watching what our competitors are doing. According to the SCA website, SCA is supposedly a “a model for building applications and systems using a Service-Oriented Architecture.” But according to David, SCA 1.0 focuses on “portability, not interoperability, and so they don’t fully define the interactions between components necessary to create composites that cross vendor boundaries.” I realize that we don’t industry agreement on all the details of what SOA means, but I think we all agree that it’s cross platform and cross vendor. Or maybe we can’t even agree on that much.

• Scott Hanselman details how the “unblock” feature in Windows works. Basically, when you download a file with IE, it adds an alternate data stream that specifies the zone the file came from (Internet, Intranet, Trusted, etc.). Even more details on Bart de Smet’s blog.
• Nick Carr gets off on a rant on Wikipedia, Citizedium and “the truth” that’s pretty funny.
• Remus Rusanu shows how to to reuse SSB conversations in a data syndication scenario. A while back, he wrote about a lightweight pub/sub SSB implementation – barely 200 lines of T-SQL code – that would also be very useful in data syndication scenarios. I’ve got data syndication on the brain right now, so this stuff is very timely.