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.