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

[Michael Champion <mc@xegesis.org>]

SOA has no constraints on operators,  but in practice operators are late bound via service definitions and operands are fairly stongly typed by schemas/data contracts. 

 

ROA tightly constrains operators, but has no constraints on operands (i.e. "resource representations" other than MIME types I suppose).

There is beauty in both views of life. What we need in my opinion is a deeper and more empirical understanding of which set of architecural constraints and non-constraints is most associated with the various, somewhat conflicting values of "scalability, evolvability, visibility, simplicity, etc."  Likewise, what are the real bottlenecks that create problems in real world implementations of the abstract designs?  I'm not at all sure there are simple and obvious results here. For example, a lot of WS-* projects founder because of the HTTP-level performance and quality of service issues compared to proprietary message services, and because of XML parsing performance bottlenecks compared to that of the previous generation of more tightly coupled data exchange mechanisms.  A failed "SOA" project isn't necessarily an opportunity for REST, it's often a victory for the old proprietary stuff that shouldn't give comfort to either side in the SOA/ROA debate. Likewise, a REST project that founders due to performance or security concerns is not necessarily an opportunity for a SOA vendor, especially if the designers don't want to install a bunch of stuff (beyond the browser) on each potential client.

 

 

Mark Baker <mark@coactus.com> wrote:

Hi Mike,

On 12/6/07, Michael Champion wrote:
> 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 :-)

Well, I don't think it's particularly useful to argue who's sub and
who's super. From an architectural POV it only matters which style
adopts the constraints which induce the architectural properties that
are needed for a particular system in a particular environment.

> 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.

IMO, conceptualization has nothing to do with it. What does is, as
above, the architectural properties. So if you want scalability,
evolvability, visibility, simplicity, etc.. you're on your own with
SOA because it has no constraints (that everyone agrees upon at least)
and therefore no properties.

Mark.
--
Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
Coactus; Web-inspired integration strategies http://www.coactus.com