May 06, 2006

Why 'Web Style' is not enough for SOA

I've always felt that Roy Fielding's thesis on architectural styles was about highlighting tradeoffs among architectural styles when applying them to a set of networked system requirements, not about touting the style to rule them all. But it seems that in their excitement, REST, or "web style" proponents are claiming just that -- forget this complex SOA crap, all you need is HTTP and plain old XML!

Here's my problem with this argument: REST's major innovation, the uniform interface, is something that most businesses or business networks precisely _cannot_ define. You're unlikely going to get a large business to agree on common terminology or definitions of ideas as "simple" as a "Customer", or what operations / architectural constraints are possible when interacting with a customer! All of this is required if you're going to have a truly uniform interface and thus a scalable and extensible system. It's a very different problem to access hypermedia through a uniform interface: the target audience is a human, the actual media types / representations are (generally) opaque for any intermediaries. In enterprise systems, we need intermediaries to transform between disjoint or overlapping representations, between legacy transfer and transport protocols, identity and entitlement representations, all the while recognizing that there are no widely agreed upon representations or media types, or even resource identification schemes! And that's within a SINGLE company, let alone networks of companies.

The best we can do is approximate the lesson of the power of uniformity through having sets of overlapping explicit interfaces, with deterministic and/or probabilstic transforms among them, and a governance process to evolve them.

That, at a rather technical level, is what I see SOA being all about -- you still get the visibility property with a governed interface, but you don't have quite the level of simplicity as you would with a uniform interface. And the reason for this has nothing to do with technology, it's a social problem (cue Cory Doctorow's Metacrap argument). It's similar to the efforts that Toyota had to go through to build quality into its supplier network to make lean manufacturing a reality.

Thus, I see the disappointing REST vs. WS or SOA vs. Web 2.0 arguments going down the same rat holes that CORBA vs. COM did... the intergalactic object web would emerge IF ONLY a) everybody agreed or was forced to agree to The One Right Way, b) what matters are the technical properties of picking the protocol (minor differences in elegance or perceived simplicity, adherence to certain constraints, debates over interpretation of sacred texts, etc.).

The main reason SOA is gaining traction in IT shops is that it's a metaphor that non-techncial people can wrap their heads around to understand the value of architecture in tackling the financial, social, and organizational challenges of decentralized and networked computing. Yes, the message is being polluted by vendors out to fit it to their business model, but I see signs that CIOs aren't buying into this spin; they're developing a nose for pragmatic, results-driven work vs. boil-the-ocean approaches to this architectural style.

Posted by stu at May 6, 2006 01:03 AM