May 10, 2006

briefly, on uniformity

One thing I don't think I made clear in the last entry was that I actually completely agree with the idea of uniform operations where-ever possible, particularly the universal GET and POST. And one can do a tremendous amount of good with just those primitives.

But I think it's too abstract for most. You can tell even on the web by the amount of abuse that's happening to the HTTP GET method (where people enact side-effects, contrary to the HTTP spec). Most people need to be able to have various levels of abstraction - and that means specific operations. Which is what I mean by a "governed interface" -- a contract among a group of service consumers and producers. It's a way of managing an enterprise's set of microformats and coordination languages, and perhaps mapping them to more general ones.

This is a mental journey for me, certainly... I get the point behind REST, but I also see the reality of multiple protocols behind the firewall, and thus the appeal of WS-*. Perhaps it's as Tim Bray noted, we should shoot the term "web services", as WS-* doesn't have a lot to do with the web -- it certainly is "Internet" friendly, but otherwise, it would be like calling the BitTorrent transfer protocol "part of the web". Trackers are, sure, but the protocol itself is more message-oriented, as is WS-*.

Posted by stu at 04:38 AM

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 01:03 AM

May 02, 2006

SOA's end?

Lots of interesting debates floating around the blogs lately. Tim Bray's The End of SOA is particularly apt. Yes, there's lots of vendor bullshit out there. But his story about why people prefer "SOA" over "Web Services" is cynical tripe, and very representative of the disappointing level of conversation out there.

Web 2.0 folks and REST (or "Web Style") folks are starting to sound like late 90's dot-commers, where if you associate the "Web" with something, there's a magical sauce (sometimes referred to as "lightweight" or "easy" or "open source") that gives you super-strength and solves most distributed system challenges.

There are two problems with this vision:

  1. Distributed systems are not "easy". The web rests on a lot of engineering, and has limits.

  2. Lightweight often means that means you have to solve all of the hard problems yourself, and most people don't have the knowledge to do this.

There's significant hypocrisy and hubris associated with the web 2.0 dev community's values. Web 2.0 is claimed to be a social phenomenon, whereas SOA is just vendor bullshit. Excuse me? Web 2.0 was introduced by vendors too -- it's just as much bullshit as the other terms. There's revenue streams, investment money, and vested interests behind all of these buzzwords, it just seems to be that Web 2.0 has a a more fertile ground for startups whereas SOA has too many entrenched multi-billion players in it, to the point that a startup can't compete. Thus the entrepreneurs and pundits with blogs are going to hype the area where there's money to be made for the little guy.

Web 2.0 is much less of a social phenomenon than people think it is. Blogs & podcasts, sure, that's a big deal (in the long run). Mashups and AJAX, on the other hand, aren't social phenomenas at all - they seem to be mainly just buzzwords that represent programmer hubris, and the triumph of adhocracy. But let's not kid ourselves -- these things are still very hard to put together -- it's not easy at all to create a consistent and quality experience for the user with these technologies.

The Web, HttpXMLRequest, Mashups, REST v. WS-*, are not the "answer" to enabling businesses to become more agile through distributed systems, any more than COM, or CORBA, or DCE RPC were the "answer". SOA was introduced as a concept by industry analysts and architects because they wanted to distill the principles that probably would enable business agility, if people recognized and adopted them. The reason these prior distributed systems standards did not bring about the advantages that SOA proponents claim has a lot less to do with technological limitations (which played a part), and alot more to do with business limitations.

The litmus test I use with CIOs and EA's when helping plan their SOA strategy, is when they claim they're "already doing SOA" , because they have web services, I ask to see how those interfaces are governed. And if they know what contract is in place. If all of this stuff is in people's heads, and there are no known ways to evolve the thing, then it's not likely an SOA. The web doesn't magically overcome the fundamental limits to human comprehension and communication when integrating systems without some kind of governance.

Thus, mashups are not an example of SOA. Blogs, podcasts probably are -- the governance was by the strong personalities behind the original specifications and extensions. Blogs are a good example of SOA solving a hard problem: taking a very simple technical problem in the small across an extremely large & diverse community in the large. They also serve as an interesting experiment on the challenges of extensibility. Most businesses have a smaller community to serve, but have much harder problems to solve.

Now, I don't agree with IBM's approach of providing 10,000 WebSphere products and 21 service offerings. If anything, the misguided positions & actions of larger vendors will kill SOA due to rampant cyncism and confusion. That doesn't mean it wasn't a good idea, it just means that some vendors desparately want SOA to fit with their business model -- IBM's happens to be consulting, BEA's is in selling more software and making sure people use it effectively, Microsoft's is in keeping Windows important.

Posted by stu at 07:41 AM