Re: [xml-dev] SOAP/SOA and REST/ROA ???

[Michael Champion <mc@xegesis.org>]

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@us.ibm.com 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@XEGESIS.ORG>
> 12/06/2007 01:08 AM
>
> To:
>  xml-dev@lists.xml.org
> 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.