Service Orientation, the Hype Cycle, and a RESTaurant

Edd Dumbill has a funny retrospective on the SOA hype:

I remember having a bit of a tiff with someone from ZapThink about the time that "2004: The year of the SOA" piece came out:

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?