• 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.

There appear to be several posts from several blogs that have spawned from my discussion about REST with David. I’ll catch up on them and respond here in the next day or so. In the meantime…

• Saw PotC: At World’s End over the weekend, due to a fluke last minute babysitter availability. It’s gotten mediocre reviews, but I liked it. Not as much as the first two, but certainly better than Spiderman 3. June looks fairly bleak @ the box office. We’ll probably take the kids to see Surf’s Up And Ratatouille. (Remember back when there was only one kids movie per summer?) Evan Almighty might be funny and I remember reading 1408, but I think they’re both rentals. The only thing I’m otherwise remotely interested in is Sunshine.
• Speaking of storytelling, Lost and Heroes wrapped their seasons last week. While early on, it looked like Heroes was going to be the new Lost, Lost’s season finally was awesome. If you don’t watch Lost, you’re really missing out on the best show on TV right now. You have eight months to catch up before season four. Heroes may not be lost, but they’re keeping the interest up with their online comic book plus while Lost scales back to 16 episodes for each of three more seasons, Heroes is bulking up, adding six “Heroes: Origins” and bringing the total to 30 for next season.
• Larry O’Brien fantasizes about his dream PDC. Aren’t there lots of conferences about learning how to “create great applications” on and for the Microsoft/Windows Platform? What about TechEd? (which is where I’ll be next week)
• Sam Gentle continues to dig into WF, examining the various ways you can extend the WF runtime by replacing the persistence, loader and scheduler services. He’s also taking my advice to scrap ExternalDataService and work directly with the WorkflowQueuingService.
• Steve Jones compares SOA to trains and I don’t get it. I mean, his advice on the value of batch processes makes sense, but his train/car analogy seems a bit strained, esp. when he calls the railway system “event based”. Can’t a car be “event based” too? There’s just a much smaller number of people who care about a given car’s events…
• Ted Neward debated OR/M with Ayende on .NET Rocks. Based on Ted’s post, the show must have been a doozy. Sounds like Ted took some controversial positions, including advocating OO databases. Of course, “shies away from controversy” isn’t how I would describe Ted.