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

Today is my father’s birthday. Yes, I realize mine was Monday. To make it even weirder, my brother Ted’s birthday was yesterday. Let’s just say this week was hard on my mother when Ted and I were kids.

Happy Birthday Dad! He’s on the road today, so he won’t see it until after his birthday is officially over, but it’s the thought that counts, right?

In the wake of my praise for CRUD is CRAP, David Ingasked “how do you reconcile something like REST (astoria etc) with being CRUD-adverse? Is there a happy place where the two can go for coffee?” Sure there is: I hear Tim Ewald’s XML Nation serves great coffee and the scones are pretty good. ^[Actually, I have no idea if Tim even likes coffee or scones. FYI, DevHawk Nation would not feature great coffee or pretty good scones. We would, however, have Arrogant Bastard Ale on tap.]

Seriously, the key observation that Tim recently made is that REST != CRUD. Sure, it can be used that way and for simple scenarios it works fine. (I’ll define “simple scenarios” in a second.) But I don’t believe CRUD style REST works in the large. Tim said you can’t build with just CRUD because it’s “to simplistic to be useful”. I’ll go even more fundamental, using REST for CRUD means having giving up transactions entirely. I’ve already accepted that building loosely coupled services means giving up distributed transactions. But the idea of giving up transactions entirely is just crazy talk.

So when I said “simple scenarios” above, I meant “scenarios that don’t need transactions”. (I take it as a given that RESTifarians aren’t hot for WS-AtomicTransaction.) ATOM Publishing is a simple scenario because the web resource authoring scenario doesn’t need transactions to protect updates to multiple resources at a time. If it did, I don’t believe the REST as CRUD approach they use would work.

As you might guess then, I’m not a fan of Astoria. I believe the sweet spot for so called “data services” will be read only (because they don’t need transactions, natch). I’m sure there are some read/write scenarios Astoria will be useful for, but I think they will be limited – at least within the enterprise.

If REST != CRUD, then what is it? Let’s go back to Tim’s post:

Every communication protocol has a state machine. For some protocols they are very simple, for others they are more complex. When you implement a protocol via RPC, you build methods that modify the state of the communication. That state is maintained as a black box at the endpoint. Because the protocol state is hidden, it is easy to get things wrong. For instance, you might call Process before calling Init. People have been looking for ways to avoid these problems by annotating interface type information for a long time, but I’m not aware of any mainstream solutions. The fact that the state of the protocol is encapsulated behind method invocations that modify that state in non-obvious ways also makes versioning interesting.

The essence of REST is to make the states of the protocol explicit and addressable by URIs. The current state of the protocol state machine is represented by the URI you just operated on and the state representation you retrieved. You change state by operating on the URI of the state you’re moving to, making that your new state. A state’s representation includes the links (arcs in the graph) to the other states that you can move to from the current state. This is exactly how browser based apps work, and there is no reason that your app’s protocol can’t work that way too. (The ATOM Publishing protocol is the canonical example, though its easy to think that its about entities, not a state machine.)

While I disagree with Tim’s disagreement of ATOM (i.e. I believe APP is about entities, but it works because it doesn’t need transactions), I agree 100% that REST is about protocol state. Tim lays this very clear in his airline reservation sample. Thus, I can spurn CRUD and still embrace REST if I want to.

Further, Tim’s points on the opaque nature of RPC style interactions (which web services appear to have fallen into despite the best of intentions) are spot on. If you’re doing simple request/response services, the protocol state is trivial, so that works fine. However, in the scenarios I face, long running services are the norm and managing the protocol state is critical. I’ve got some ideas on how to do that, but that’s a future blog post.

• Dare reached a similar conclusion about Silverlight and Apollo that I did. But newly minted Adobe RIA evangelist Ryan Stewart writes that calling Silverlight vs. Apollo the next platform competition is overblown. However, he then reiterates my point that MSFT is moving in on Adobe’s traditional stronghold (aka the web) while Adobe is moving in on MSFT’s traditional stronghold (aka the desktop). The upshot is that both companies are trying to deliver a unified “client” platform that spans desktop, devices and browser. That sounds like “platform competition” to me.
• Apparently I’m missing the this years compiler dev lab. 😦 John Lam is there, with slides from his talk on the DLR. Miguel de Icaza is there, with fairly extensive notes. Hopefully they will post talks like they did last year.
• Speaking of languages, Scott Hanselman explains why he thinks Ruby is “the tits”. Personally, on the scale between “I can’t see where Ruby is such hot shit” and “Ruby is the tits”, I’m somewhere near the middle, leaning towards tits. I love the expressiveness of Ruby’s syntax, but I miss the static typing. Call me over the hill, but I like the compiler catching mistakes at compile time. I realize it’s not for everyone, but I like what I like.
• This talk about Ruby’s expressiveness reminds me of something Larry O’Brien said in the wake of the IronRuby announcement: “I am surprised by the IronRuby announcement. I really thought we were going to see some form of Ruby#:Ruby::C#:Java. Although I’m happy, I was actually hoping to see a new language.” The expressiveness of Ruby that Scott describes (which is to say, not all of Ruby’s expressiveness) would be completely achievable in a statically typed language. Personally, I’d like to see that language…
• My birthday is past, but I want a Lego Ice Cube Tray. (via Geekdad)

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.