Share via

Service Orientation, the Hype Cycle, and a RESTaurant

  • Article

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?

Comments

  • Anonymous
    March 25, 2005
    Thinking REST, when I go to a restaurant (full-service or not), I expect to simply order a e.g., taco, by it's name on the menu (GET). Thinking SOAP, I would have to create and submit a recipe, and the cook would have to interpret the recipe and produce the result (SOAP Req/Res).

    I prefer the former (and so would the restaurant).

    Of course, a full-service restaurant offers options, in which case a faceted classification system to navigate the possible order combinations via GETs can be implemented--think of it as a parameterized query engine. One then still navigates to a precise GET with just a few clicks.

    Consider also that the number of valid/relevant queries for a given service are orders of magnitude less than the possible permutations. It works. Plus, SOAP security issues are eliminated because adhoc queries are eliminated.


    Use REST. If you can't think of a REST solution, think some more. If you still can't think of a REST solution, think some more. If you still can't think of a REST solution. Consider SOAP.

  • Anonymous
    March 25, 2005
    I'm trying to steer the conversation away from "REST vs SOAP" and toward "resource orientation vs service orientation." One could use HTTP/XML or SOAP to invoke services, and I disagree that SOAP implies a "create and submit the recipe" leval of granularity.

    Grr, I'm going to just write another post about my attempts to think through how a RESTaurant would be designed, something I've been trying to talk myself out of for a week :-)

  • Anonymous
    March 25, 2005
    I used to work in a restaurant. The staff had a very efficient, highly specialized vocabulary for communicating with each other, including a written micro-langauge for communicating orders to cooks.

    Interactions with customers were basically scripted, request/response exchanges.

    Waiter:
    "Here's our menu [collection of entrees]"

    Customer:
    "I would like to know more about this dish"

    Waiter:
    "Let me ask the other waiter, who knows a lot about fish" [redirect]

    Waiter 2:
    "Something enlightening about fish..." [200 OK]


    Interactions of this type usually get translated into the same semi-graphic microlanguage in the kitchen, no matter how strange the customer request might seem. It was very rare for the cooks to look at an order and be mystified to the point that they required a conversation with the waiter.

  • Anonymous
    March 26, 2005
    Robert's restaurant micro-language analogy makes sense to me. Note, however, that the micro-language is used between waiter and cook, not between customer and waiter. The customer doesn't need to know the micro-language (i.e., knowledge of API or implementation details), which is the point of REST.

    Regarding service oriented vs resource oriented, it would be helpful if Mike defined more fully his distinction between 'service' and 'resource' in this discussion. Because, by my experience, SOA refers to both REST and SOAPish solutions; In REST both a static web page and a dynamic search page is called a resource---with perfect understanding that the search page may also be a service, preferably one that can be accessed via GET.

  • Anonymous
    March 30, 2005
    Honnestly, what's the big deal with a little marketing hype? It's not ss if Microsoft has never hyped a technology of their own. (Windows DNA? Hailstorm? what happened to those?).

  • Anonymous
    June 15, 2009
    PingBack from http://mydebtconsolidator.info/story.php?id=5208

  • Anonymous
    June 17, 2009
    PingBack from http://pooltoysite.info/story.php?id=5564

  • Anonymous
    June 18, 2009
    PingBack from http://barstoolsite.info/story.php?id=6751