Morning Coffee 84

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 controversyisn’t how I would describe Ted.

Follow My Breadcrumbs

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.

This Isn’t The Droid I’m Looking For

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.

Morning Coffee 83

Happy Birthday Dad!

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?