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.