Mike Champion writes:

> Where I might disagree is using the label REST to describe the 
> implementation of a *service* via HTTP: If the fundamantal 
> abstraction is a "service", what value does the "resource" 
> abstraction add here, and why is it useful to talk about exchanging 
> a representation of the resource as opposed to invoking a service? 

From a customer's or system integrator's perspective:  I want to access 
the service that tells me where my package is.

From the network architect's perspective:  I've chosen to use REST.  The 
way REST models this is to provide a "resource" that has as its state the 
location of the package, mint a URI a for that resource, and use HTTP GET 
to get a representation that tells me where the package is. 

I think you are going just a bit to far in identifying SOA with plumbing. 
SOA is, I think, closer to what I've set out as the customer's and system 
implementor's perspective above. 

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------