Re: Proposed text for section 1.6.2 and 1.6.3

Hi Mike,

> The World Wide Web is a SOA that operates as a networked information system 
> that  imposes some additional constraints: Agents identify objects in the 
> system, called "resources," with Uniform Resource Identifiers (URIs).
> Agents represent, describe, and communicate resource state via 
> "representations" of the resource in a variety of widely-understood data 
> formats (e.g. XML, HTML, CSS, JPEG, PDF ). Agents exchange representations 
> via  protocols that use URIs to identify and directly or indirectly address 
> the agents and resources. [W3C Technical Architecture Group, "Architecture 
> of the World Wide Web"  http://www.w3.org/TR/webarch/]
> 
> An even more constrained architectural style  for reliable Web applications 
> known as "Representation State Transfer" or REST has been proposed by Roy 
> Fielding and has inspired both the TAG's Architecture document and many who 
> see it as a model for how to build web services  ["Architectural Styles and 
> the Design of Network-based Software Architectures" 
> http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm].  The REST Web 
> is the  subset of the WWW in which agents are constrained to, amongst 
> other  things, expose and use services via uniform interface semantics, 
> manipulate  resources only by the exchange of "representations",  and thus 
> use "hypermedia as the engine of application state."

Hmm, it's hard to distinguish between the two lists of constraints in
those two paragraphs.  I'd suggest that adding the RESTful constraint
of statelessness would help to distinguish the two, since clearly much
of the Web isn't stateless.

So you might consider adding "maintain application state on the client"
to the list of REST constraints.

> The scope of "Web services" as that term is used by this working group is 
> somewhat different.  It encompasses not only the Web and REST Web services 
> whose purpose is to create, retrieve, update, and delete information 
> resources but extends the scope to consider services that perform an 
> arbitrarily complex set of operations on resources that may not be "on the 
> Web."  Although the distrinctions here are murky and controversial,  a "Web 
> service" invocation may lead to services being performed by people, 
> physical objects being moved around (e.g. books delivered). 

I'm surprised to see that distinction drawn.  I think it's quite clear
that RESTful Web services can do that too, because I order books through
my browser, and people move around to deliver me those books as a
result.  8-)

What I thought was the widely held misconception about RESTful Web
services, was that automata could not be clients and automate arbitrary
processes (i.e. a human is required).  If you wanted to write that
(while keeping the word "controversial" there 8-), I'd be ok with it.

> Both classes of "Web services"  use URIs to identify resources and use Web 
> protocols and XML data formats for messaging. Where.they fundamentally 
> differ is that "distributed object" [Ed note: or "mediated services"]  use

The Web is a distributed object system too, so I'd suggest another term.

> application specific vocabularies as the engine of application state, 
> rather than hypermedia.  Also, they achieve some of their benefits in a 
> somewhat different way. The emphasis on messages, rather than on the 
> actions that are caused by messages, means that SOAs have good 
> "visibility":

I thought we had agreed that REST had superior visibility than
SOAs?  And while I agree that XML improves visibility, I strongly
disagree that the visibility of SOAs is "good"; on the contrary, it's
*very* poor.  I suppose this isn't the right time for that discussion,
so I'll just raise an issue when it's published.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis

Received on Wednesday, 7 May 2003 15:29:41 UTC