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.

• Microsoft announces Surface Computing. When can you buy one for your house? Probably not anytime soon. TechMeme has lots more.
• The one piece of swag I want more than anything else at TechEd is an Evil Mastermind shirt.
• Nick Allen notes that WSDL 2.0 has reached “proposed recommendation” stage. I guess having a “recommended” version of WSDL is an improvement over the “note” version. But other than having a RESTful HTTP binding in addition to the SOAP binding – and being longer – what’s new?
• Speaking of description languages, Don Box writes about the Web Application Description Language which looks very REST-y in that it supports specifying both the URI as well as the payload format. Like Don, I agree with Erik Johnson who commented that “people attracted to REST (in whatever form) are rebelling against interface-based programming more than WS-* itself”. I have a longer post on this coming, but suffice to say I’m really souring on interface-based programming.
• Nick Malik writes that WCF is immature because of it’s “lack of a routable, intermediable, declared message durability option”. Yeah, that’s a huge problem in my book too. It also relates to the last bullet – since durable messaging is inherently async, it doesn’t fit well into the interface-based programming model.

Here is a roundup of some responses to my REST discussion with David Ing. Mostly, I’m passing them along with minimal comment so I figured I’d group them into one post.

David started by leaving me a comment, but decided instead to post the comments on his blog. His big worry seems to be how well REST as CRUD will interop with REST as protocol. but in general I’m not sure that’s a big worry. Bill de Hora’s example below about WebDAV transactions activities seems to demonstrate at least some RESTifarians are cool with a protocol view of the world.

Erik Johnson (who’s blog I mistakenly purged from my reader at some point, so needless to say I’ve resubscribed) writes that “real-world experience shows you rarely POST exactly what you GET” and that “even with the flawed cast of characters you see a lot of whining about…the pieces are there to build good systems that also make great constituents in anyone’s SOA.” I agree 100%. He goes on to agree with me agreeing with Tim for people “not to limit their comprehension of REST around entities accessed via GET and PUT”. Generally speaking, I agree with people when they agree with me, and this is no exception. Erik also has a REST post that predated my dustup with David^[It’s a very polite dustup, characterized mostly by agreement rather than disagreement. Which makes it, as dustups go, very boring.] where he reaches some interesting conclusions about designing REST style systems.

Bill de Hora weighs in, pointing out that “value exchange != transaction”. Given that I never suggested they were equal, I’m not sure what his point is (other than to be snarky). He also points to Subversion’s use of WebDAV as an example of…well, I’m not sure since it seems to prove my point that a simple CRUD style approach doesn’t cut it for many scenarios. According to the page Bill linked to:

“Subversion commits are modeled using the “activity” concept from DeltaV. An activity can be viewed as a transaction for a set of resources.” [emphasis mine]

While I’m sure this sounds snarky as well, I really don’t get what Bill is getting at here. It sounds like he took my disparaging of CRUD as a disparagement of REST, which is NOT how it was intended. This kind of layering of higher-level protocol concepts (like WebDAV’s activity) is exactly what I was thinking of when I wrote “I can spurn CRUD and still embrace REST”.

And though not a direct comment on my post, Omri Gazitt writes about REST vs. SOAP and the support for both in the next version of WCF. His main point is that “It seems like we’ll continue to live in a world where multiple integration paradigms and protocol choices exist for applications”. Of course, since he’s with the WCF product group, regardless of your integration paradigm or protocol choice, WCF is the way to build it (at least on Windows). We’ll have to wait a while to see if WCF is really “future-proof”, but the ability to add significant changes in a .5 release is a fairly good sign.