XML Editor - Download a Free Trial >
See What's New >
Buy Now >

[Home] [By Thread] [By Date] [Recent Entries]

  • From: Michael Champion <mc@x...>
  • To: noah_mendelsohn@u...
  • Date: Thu, 6 Dec 2007 18:45:44 -0800 (PST)
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
12/06/2007 01:08 AM

To: xml-dev@l...
cc: (bcc: Noah Mendelsohn/Cambridge/IBM)
Subject: 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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

XML Editor - Download a 15 Day Free Trial Now >
See What's New in Stylus Studio >
Buy Stylus Studio - XML Editor - Now >
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member