Service Orientation, the Hype Cycle, and a RESTaurant
Edd Dumbill has a funny retrospective on the SOA hype:
- 2005 Will Be the Year of SOA -- Are You Ready? (.NET Developer's Journal)
- 2004: The year of the SOA? (ZapThink, searchwebservices.com)
- Predicts 2003: SOA Comes of Age via Web Services (Gartner)
- Bowstreet Predicts 2002 Will Be The 'Year of Web Services' (Bowstreet press release)
Looking back on the OO "revolution" of 15 years or so ago, what would one think of a 1990 analyst report that pointed to a window of opportunity that would be closed by 1992 as C++ and CORBA mature and standardize? That's about where the SOA "revolution" is today.
I would be so nice if just once in my career I see a promising idea NOT go through the hype cycle.
I don't remember the early days of the OO/OOP revolution all that well, but I think we saw a lot of the same kinds of things as are happening with SO/SOA today: endless debates over what OO really means, attempts by vendors to conflate tools with the architectural principles they claim to facilitate, and a long slow process of sorting out the practical ideas that actually work from the prescriptions of the theorists. Whether or not it is true in hindsight about OO, it's my foresight about SO.
In a previous life I spent a fair amount of time trying to make sense out of web services architectures and SOA at W3C and promoting the SOA ideas at the Day Job. With some perspective, and from the vantage point of an organization that has no particular dog in any of these fights, it's interesting to re-examine previous posts about service orientation. I haven't found anything I would disavow, and at least one that I kindof like.
The way I see it, XML and web services just provide standard plumbing
for information. Plumbing is not sexy and it will not solve your
problems, but the *lack* of decent plumbing leads to a rather, uhh,
unsanitary situation. *Standardizing* the plumbing just makes it
easier to mass produce, create a workforce of people who know how to
use it, and generally turn it into a commodity rather than something
you have to worry about.
Anyone marketing SOA or web services as a Silver Bullet will be dodging
ordinary bullets from disgruntled customers. None of this stuff is
going to make "data transparently available everywhere in your
enterprise", but it *is* cheaper and easier to move the data around
and transform it using commodity "plumbing" rather than hand-crafted
"plumbing." That's the value proposition, and it appeals to those who
have been around long enough to know how much of a typical IT budget
has traditionally been spent on the software equivalent of hand-forging
connectors between odd-sized pipes.
In my very last performance as an SO evangelist, I took my best shot at explaining what service orientation was all about, taking a broad perspective and trying hard to avoid buzzwords.
In the real world, we use services all the time -- getting money from banks, ordering food from a restaurant, getting clothes dry cleaned, and so on. What makes these "services" is that we don't need to know anything about banking, cooking, cleaning, etc. in order to use them, we simply request them....
In a nutshell, service orientation is an approach to designing systems in which each component knows only how to request and consume the services provided by other components, and little about their internal algorithms, data structures, stored data formats, query languages, etc.
IMHO this gets at both the promise of SO and its main drawback: It promises to help us think about distributed software systems in ways that are more in synch with the ways our customers -- real business people and consumers -- think of what they want from us. On the other hand, that takes us away from the nice clean world of formats and protocols and into the messy world of actual customer needs and human foibles that tend to trip up nice neat software engineering theories. In short, I agree with the skeptics who don't think that the "Year of SOA" will come anytime soon, but disagree with those who think there is nothing but hype keeping the idea of service orientation aloft.
I hope (i hope i hope i hope) that the "SOAP vs REST" Godzilla-of-permathreads has returned to the ocean after stomping around the Web for a few weeks. The links in the previous sentence point to some wise summaries of where things really stand, which essentially comes down to the fact that both XML over HTTP and the WS-* technologies are useful things to have in one's toolbox, to be used as the situation demands: Pliers and a monkey wrench (XML over HTTP?) for the cheap and cheerful work, a set of carefully calibrated socket wrenches (XSD and WSDL?) for working with carefully engineered machinery, and maybe a pneumatic nut driver (WS-*?) for the industrial strength jobs.
Perhaps it is now time to look at the real differences between thinking of distributed systems as collections of resources to be manipulated vs thinking of them as services to be requested. That seems to be the essence of the real disagreement here -- it's pretty clear to me that services can be invoked with whatever combination of HTTP, XML, SOAP, WS-*, and [some technology to be designated later] is needed for a particular job. On the other hand, I looked back through the posts above and the highly regarded ones by Carlos Perez, and I don't get a good feel for how one would design a resource-oriented or "high REST" application for anything but information resources.
For example, we all know what a service-oriented automated restaurant would look like -- just like the human-powered service-oriented restaurants that have evolved over that last couple hundred years. What about a resource-oriented restaurant? I can see how that would work for fast food place (GET a menu, POST an order, which returns a URI one can GET the status of the order from ....). How about a real full-service restaurant, with a server who handles the details of the complex asynchronous interactions between a table full of people and a busy kitchen? Sure, one could implement those interactions with XML and HTTP, but would a system design that talks about resources and representations really be more sensible than one that talks about services and requests? Any RESTifarians out there want to take on the challenge?
More importantly, are there more real world distributed systems that work like libraries full of information resources to be transferred and manipulated, or more that work like restaurants that supply services which we learn how to request and consume?