Anyway, after carefully reading the article and blog entries, I believe Steve is not against RPC per se. He wants people to think before just automatically using it because it’s convenient.

Exactly!

Also spot on are the following postings:

• Bill de hÓra: Patterns of Web Architecture
• Three postings from Stu Charlton:
  • Convenience, Correctness, and Network Interactions
  • Can technology progress?
  • On changing industry mindsets

The beauty common to all these postings is the breadth, depth, and variety of thinking and reasoning they present. There’s a lot to read, but if you’re interested in critical thinking about the design and construction of distributed systems I encourage you to read them all the way through, including the comments, and to follow the links they offer as well.

Problem is, it never seemed to work out as easily as that. Most of the time, the interfaces people came up with were just too specific, and nobody could agree to apply them widely. Think of all the time people spent over the years in OMG, JSR, and W3C WS meetings trying to agree on just the infrastructure interfaces and not always succeeding. It’s therefore not surprising that there was never much success at defining broadly-accepted standard interfaces up at the application level; the scope is simply far too wide up there.

So, with technologies that promote interface variability, planned reuse is pretty hard. Consequently, serendipitous reuse, where services and facilities can be combined and reused beneficially in unforeseen ways, is virtually out of the question.

Stu Charlton’s blog was where I first saw those terms used, and I found them very enlightening. So did Bob Warfield.

One of the first things that attracted me to REST was the uniform interface constraint. Mark Baker first brought it to my attention nearly 8 years ago, and before I looked at it, I thought it was just a bad idea, like a totally generic doIt() interface, devoid of any meaningful semantics. But of course, there’s much more to it than that. The HTTP interface, for example, strikes a great balance that allows it to be efficiently reused across a very wide variety of applications. And when such a uniform interface is reused, the applications that use it stand a much better chance of being reusable themselves than if they were written against a non-uniform application-specific interface.

My latest Internet Computing column, entitled Serendipitous Reuse (and here’s the pdf if you prefer), explores how the uniform interface contributes to reuse of both the planned and serendipitous kinds.

Unless I’m missing something, Ganesh seems to be saying, “Hey, if we just stick SOAP directly onto TCP, we can scale beyond Web scale to Internet scale!” Oh, if it were only so easy. I would think that it’s fairly obvious that just because TCP scales well doesn’t mean that higher-level protocols sitting on top of it automatically scale to the same degree.

Why does the Web scale so well? Because of particular constraints deliberately imposed to induce specific architectural properties. The caching constraint contributes heavily to Web scalability, for example. Statelessness and the uniform interface also play a big role there. These constraints along with conditional GET allow messages to be significantly reduced in size or better yet, eliminated altogether. The resulting scalability impact is huge.

Ganesh talks about a lot of the things you’d have to add to the mix get a useful SOA ecosystem on top of SOAP/TCP, but nowhere does he talk about the specific architectural properties and constraints required to make it all scale. Without that, it just ain’t gonna happen. Furthermore, I don’t believe any system based either on interface specialization (i.e., the opposite of the uniform interface constraint) or on “processThis” can scale to Web scale. Interface specialization significantly increases coupling while reducing visibility and applicability, while “processThis” is so devoid of semantics that it offers nowhere to practically apply constraints like caching and statelessness that are so critical to scalability.

• Dan’s talk
• Pete’s talk
• Sanjiva’s talk
• my talk

I too agree with many of James’s insights. If you don’t regularly read his blog, you should subscribe immediately. I especially like this quote:

When I consider SOA and REST today, I do not see two competing visions, I see an evolution that has brought the industry back to a core set of fundamental design principles that we seemed to have lost sight of for a while.

How very true. However, I disagree with just one small point: his critique of the part of my talk where I said SOA has no constraints (as Mark Baker has been pointing out for years now).

James says that SOA has constraints, it’s just they’re just not well-documented. I know exactly what he’s saying, but I have to stick with what I said. The only official definition of SOA that I know of is the OASIS SOA Reference Model, which mentions several desirable properties for SOA systems, but it documents no constraints for inducing them AFAICS. Later in my talk, as Stefan’s notes indicate, I did say that I was willing to concede that the OASIS SOA RM promotes the client-server constraint. However, I was being really, really generous, since all the specification really does is hint that SOA systems should be distributed, and “distributed” has a lot more meanings than just “client-server.”

Since there are no official standard SOA constraints, the only constraints you get are the ones that each vendor or supplier of SOA platforms and systems decides to give you. Naturally, each different solution in this space will differ in those constraints.

As the quote from James above implies, pitting SOA and REST against each other doesn’t make a lot of sense. The reason I went to the trouble of pointing out in my talk that SOA is missing critical architectural requirements like constraints was to help illustrate the significant differences between SOA and REST. Fundamentally, as I also said in my talk, SOA isn’t really about architecture in the way that REST is. Rather, it’s about IT culture, best practices, breaking down the enterprise organizational and political barriers that needlessly increase IT costs, and following good fundamental software engineering principles like reuse, minimizing coupling, and maximizing cohesion.

My talk, “REST Eye for the SOA Guy” (title taken from here), went reasonably well. The only time it didn’t flow as smoothly as I would have liked was when some semi-anti-REST folk started questioning my assertions about specialized interfaces inhibiting scalability, and wondering whether REST just pushes all the coupling problems to the data. I felt like I was being pulled backwards in time by 5 years to the old W3C Web Services Architecture Working Group meetings, where very little was ever accomplished due to arguments like those. I’ll have more to say on those topics in some near-future blog postings.

An interesting thought struck me as the track progressed: in my experience it seems that most SOA/WS proponents who argue against REST on technical merits have never actually tried to build any RESTful applications. Many of their objections seem to be heavily based on emotional reactions, or based on conclusions reached only by blowing issues out of proportion (for example, I felt that many of the points in Sanjiva’s talk fell into this category). So it led me to wonder about how many, if any, dyed-in-the-wool WS advocates ever seriously, honestly, and fairly looked at REST, actually tried it, but then decided it didn’t work and so willingly chose to go back to WS. I don’t want to count those who had to go back to WS only to integrate with something else already implemented using WS, because that doesn’t fit the “willingly” part. (For example, I recently had to write a client to access a SOAP service, and I was definitely not in the “willingly” camp because the service was way more complicated than it needed to be, only because of SOAP.) I personally know of nobody who has ditched REST for WS like this, but if you have, or if you know of someone who has, I’d love to hear the whole tale, so feel free to leave it in a comment.

The conference itself was much like JAOO, which is not surprising given its JAOO roots. It was smaller, of course, given that this was the first QCon held in the U.S. And just like JAOO, there were times where I wanted to be in multiple places at the same time to see two or three different talks all scheduled concurrently. For example, I very much would have liked to sit all day in the Thursday “Architecture Quality” track, but couldn’t since it ran parallel to the track I was in.

In short, if you didn’t go to QCon, you missed a great conference. Stefan, thanks again for inviting me.