News You Can Bruise for 2006 November 14 (entry 0)

(2) Tue Nov 14 2006 00:31: This one's pretty short; I just want to respond to Pete's entry about the term "SOA". I have largely bought into Assaf's assertion that defining resource-oriented services out of the SOA cuts them away from a large source of largess and buzz for no real reason. I don't really care about "SOA", but I do care about people spending money in the right places, so I want to leave the rhetorical ground open for those who can make that happen.

Pete quotes Anne Thomas Manes as saying:

Service oriented architecture (SOA) is a software design discipline in which application and infrastructure functionality are implemented as shared, reusable services.

As Pete points out this definition has a dependency on the definition of "service". Pete's definition is "a network available collection of related operations".

Okay, I'll buy that, and I'll also buy a $0.50 contract on Pete's "a resource is not a service". I'd say a resource is a service, albeit a very limited one that can only operate on one piece of data. An RSS feed is a good example of a one-resource service. But a collection of resources is definitely a service. In fact, "service" is what we call a collection of related resources.

A single resource can't have arbitrary operations, but you can expose arbitrary operations by exposing combinations of resources. It's not the same design as an RPC service, but only intertia associates RPC with "service-oriented" in the first place, and a service-oriented system could easily consume a mix of resource-oriented and RPC-style services.

Comments:

Posted by Pete Lacey at Tue Nov 14 2006 09:59

I saw Assaf's post a few days ago and I'll admit I liked it. People who are not invested in the SOAP/REST debate want to interact with "services" not "resources." I caution you, however, that the SOAP/SOA/WS-* camp has co-opted the term "service," and their definition is the one I give. It will be incumbent on you to redefine a service to encompass RESTful, erm, services.

Even more strongly I caution you against bringing REST into the orbit of the term "SOA." Using Anne's definition of SOA and your definition of a service, then REST and SOA are compatible. But the term "SOA," from the point of view of those who advocate it and those who bash it, is inextricably linked to SOAP web-services and all the other baggage I've mentioned before. And to a certain audience there is so much antipathy towards SOA, that you risk undermining REST by association.

Pete

Posted by Sam Ruby at Tue Nov 14 2006 15:19

I feel stronger than Pete does: I firmly am under the belief that attempting to redefine a term that is so well entrenched is a loosing battle.

Spend a moment with:

http://en.wikipedia.org/wiki/Service-oriented_architecture

It starts out with "we are all things to all people", and then leads up to "lookie here - shiny tools!".

What we need to say is that while there *theoretically* is some overlap, in practice, there is *none*. You will find that if you try to steer towards the tiny spot on the Venn diagram where they overlap, you will find that all the extant tooling will pull you away from center.