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

I hope to post my thoughts on protocol state next week. In the meantime, you can check out Isolation Support for Service-based Applications as well as Consistency for Web Services Applications. The papers (from the same authors) deal with the C and I of ACID, but in service scenarios where ACID transactions aren’t feasible. Both papers have dramatically impacted my thinking in this space.

Since David Ing responded to my REST/CRUD/CRAP entry on his blog, I guess that means I respond to his response here, right?

Actually, this is going to be very short^[Wow, this post wasn’t that short at all. Can you imagine how long this would have been if I had mostly disagreed with David?] because I mostly agree with what David wrote. For example:

If we say stuff like ‘REST shall/must replace all foolish WS-* SOAP systems (insert Nelson-style HaHa here)’ then we are just repeating the same lessons as before – One size won’t fit all and there is no One Ring to Bind Them illusion in REST as well. If you have something complex that fits the WS-* style then maybe REST isn’t the droid you are looking for.

Of course, this begs the question “what is complex?” David described complex as “long running transaction updating multiple distributed stores”. Personally, I’d replace “stores” with “systems” and I hate term “long running transaction” so I would have written “long running operation” or “business process”, but grammatical nitpicking aside that certainly seems like a fair description. Certainly, most of the scenarios I’m looking at in my day job could be described as being long running and updating multiple systems. David says later that he thinks “a lot of apps don’t need to be modeled that way”, but I’m not aware of the alternatives so I’ll let him expand on this on his own blog. I’ll try to get to writing about my thoughts around protocol state next week.

I did disagree with this one point:

We may say REST is really about a protocol state and not CRUD, but unless the rest of the world gravitates to that view then I’m afraid it just won’t be. If, say, through some ongoing groundswell of common usage, people start modelling entities as dereferenceable URI’s and using POST to do Create and Updates, then REST will be about CRUD by default. This is all very unacademic and unjust, but thems the breaks peachy. The lesson from SOAP is not to fight it by trying to re-educate the masses after they get a perception in their head.

I think it doesn’t really matter how the rest of the world gravitates, it only matters how you as the the service provider choose to expose your service. If you’re doing something simple like ATOM publishing, you can probably get away with REST as CRUD. (Would that be hi or lo REST?) If you’re doing something more complex, either in terms of being long running or needing multiple updates in one atomic operation like Tim’s airline example, you’ll probably need to gravitate towards REST as protocol state. But can’t the two models can co-exist nicely, even in the same app? No re-education required.

Update: – From Fielding’s Dissertation: “REST relies instead on the author choosing a resource identifier that best fits the nature of the concept being identified”. My point exactly.

• Dottie Shaw – PM on Rome – has a post on Durable Messaging and why she cares. Needless to say, I care about durable messaging too, for all the same reasons…
• PDC07 has been “rescheduled“. Feel free to theorize amongst yourselves the reasons why.
• Friend and ex-boss John deVadoss speaks on Software+Services @ the Enterprise Architect Summit. He finds time to present, but his blog remains quiet…
• JD Meier announces a p&p twofer: beta 1 of both their TFS Guide and their Perf Testing Guide. The TFS guide looks like a packaged doc version of their VSTS Guidance Project wiki.
• Facebook announces their Facebook Platform and Microsoft is supporting it with PopFly and Silverlight. TechMeme has much more.
• Pandora on the Go delivers their service to Sprint cell phones for $3 a month. Raging deal, but where’s the support for Windows Mobile phones? (via Knowing.NET)