I don't disagree with what you've written here, but we may not agree on the overall point I was trying to make.  I certainly agree that in the scenario you sketch out, it may be reasonable to conceptualize the various components of the package tracking system as "services", but actually implement them with plain HTTP.  No need to haul out the heavyweight SOAP infrastructure unless it adds some value, and the individual services here may not need to be protocol agnostic, reliable, secure, transactional, addressable by something other than a URI, have a policy attached to them, etc. (i.e., the various values that the WS-* stack adds).     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?  I think this is where the whole REST vs SOA discussion went off the rails a few years ago, and my overall point is that we might be able to put it back on track by distinguishing between an HTTP representation of a SOA and a RESTful implementation of a ROA.        SOA and ROA are useful distinctions at the level of architectural principles, but things will get confusing at the level of actual tools.  So, a pure-HTTP implementation of a SOA is not an oxymoron, nor is the use of ROA principles in management protocols that have "WS-" prefixes. You wouldn't see the difference in terms of the bits on the wire, of course, but this argument has never been about bits on the wire, it's been about archtectural principles and fruitful abstractions.  As an analogy, you wouldn't be able to easily distinguish OO from procedural code by looking at the instructions actually being
 executed (especially if the code was compiled using optimization).  That doesn't mean that this isn't a meaningful distinction, just that it is a useful description at the level of programming languages, not running programs.   
noah_mendelsohn@u... wrote:  Mike Champion writes:

> The recent thread on SOAP and SOA prompts me to wonder whether 
> the more appropriate comparison should be "Resource Oriented 
> Architecture vs Service Oriented Architecture", not whether 
> SOAP or REST is "better" or whether SOA implies SOAP or not. 

I'm not sure about that. Maybe I've shipped a package, and the shipper 
has given me a tracking number. I want to be able to write programs or 
scripts that, given the tracking number, contact the shipper and find out 
where my box was last sited or when
 it's expected to be delivered. Being 
able to decompose the work we do into these relatively high level and 
decoupled "services" seems to me the essence of SOA. I think the concept 
applies whether I decide to do a simple implementation using REST, or 
perhaps a more sophisticated one using WS*, in which the shipper uses Web 
Services Security to sign the promised shipping date, so I can prove that 
it's been committed. 

So, I think the SOA concept talks to how we structure the work we do, and 
what information flows between party; REST and WS* seem to me to be 
plumbing. I think they apply to partially overlapping sets of SOA use 
cases.

Noah

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








Michael Champion <MC@X...>
12/06/2007 01:08 AM

To:
 xml-dev@l...
cc: (bcc: Noah Mendelsohn/Cambridge/IBM)
Subject: [xml-dev] SOAP/SOA and REST/ROA ???


The recent thread on SOAP and SOA prompts me to wonder whether the more 
appropriate comparison should be "Resource Oriented Architecture vs 
Service Oriented Architecture", not whether SOAP or REST is "better" or 
whether SOA implies SOAP or not. 

My favorite definition of SOA is from Werner Vogels, describing Amazon's 
architecture: 
http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=388

"For us service orientation means encapsulating the data with the business 
logic that operates on the data, with the only access through a published 
service interface. No direct database access is allowed from outside the 
service, and there's no data sharing among the services."

The best discussion of ROA I've seen
 is
http://jooto.com/blog/index.php/2006/08/08/replacing-service-oriented-architecture-with-resource-oriented-architecture/

"Because of the uniqueness of the web as a medium, the only abstraction 
that does it true justice is resource. The web is a collection of 
resources. These resources are astronomically diverse, and it would be 
mathematically impossible to maintain any semblance of a reasonable 
inventory of web resources.
This reality then forces us to give up on trying to control and maintain 
the inventory."

I personally think that ROA is a subset of SOA that constrains the set of 
services to the HTTP verbs but opens up the types of data that the 
services can operate on to the very abstract notion of a resource. Others 
seem to think that SOA is the subset of ROA where the set of resources is 
constrained to be service endpoints. I've served my time in Hell trying to 
referee that debate (in the W3C Web Services
 Architecture WG) and don't 
want to participate anymore, but go to it if you want :-)

But maybe it wouldn't be too much to hope that we could all just get along 
by understanding that when a system is best conceptualized as a set of 
services, service-oriented technologies make a lot of sense ... and when a 
system is best conceptualized as a hyperlinked web of resources, REST 
technologies make a lot of sense. Of course, whether a proposed 
application is best conceptualized as a ROA or SOA is going to be an 
interesting discussion for the designers to have.

That doesn't mean that HTTP is the only tool to implement ROA or WS-* (or 
SCA, or whatever) to implement SOA. Vogels made it clear that Amazon uses 
all sorts of technologies to implement their various services. 
Furthermore, there are cases where a particular set of WS-* technologies 
is worth considering even when the fundamental abstraction is a 
"resource". For
 example, both the competing management-oriented web 
services stacks (WS-Management and WSDM) leverage the concept of a 
"resource" whose details are discovered via metadata to provide interfaces 
that are both general and useful. For WS-Management, the WS-Transfer 
spec is used underneath rather than HTTP because it must be 
transport-agnostic (e.g. it must support UDP, HTTP, or whatever underlying 
protocol a device uses to communicate with the management console). I'm 
not sure if these are using ROA tricks to provide generic services, or 
using SOA tools to implement ROA in environments where HTTP is not 
available. 

In any event, we *know* that it is unproductive to debate SOAP vs REST 
anymore -- the same arguments from late 2001 are still being recycled -- 
but maybe it would be fruitful to flesh out ROA, and provide case studies 
and best practices to help distinguish it from SOA and choose which is 
more appropriate
 for a given task.