Re: Testing Understanding of Architectural Principles

> Also, the current document implies that the RESTful web is a particular
> instance of an SOA that provides the service of GETing, PUTing, POSTing,
and
> DELETEing representations of resources identified by a URI.  I don't think
> that "REST vs SOA" is a fruitful distinction.  "Uniform interface SOA" vs
> "Customized interface SOA" might be a useful distinction ... I need to
> harvest the discussion 10 days ago for the next draft of the document.

"Uniform interface" versus "Custom interface" is an easier distinction to
observe, but it falls critically short of usefulness also, because it
discusses
means, not ends.  There is a claim on the table that REST fails to
model *actions*, and those can only be modeled with a custom API.
Given time and patience and open minds, even that distinction may be
proved vacuous.

FWIW, I don't think "REST as a kind of SOA" is a useful classification,
but there it is.

>
> Actually <heresy> I'm not sure that "SOA" is anything more than the latest
> buzzword from the marketing weasels and the consultants who prey upon
them.
> </heresy> What they talk about as the *definition* of SOA (coarse-grained,
> loosely coupled, standards-based encapsulation of a distinct business
> service) seems to be a *best practice* IMHO that could apply to REST,
> SOAP/WSDL, or some combination thereof.  Anyone strongly disagree?

That's mighty encouraging. :-)

How does SOA address (ensure) coarse-grained-ness?
Loose coupling?
Standards-based encapsulation?

Same questions for REST.

(Okay, that's my "bandwidth" for the week.)

PS Mike, how'd you score on the quiz?

Walden

Received on Monday, 19 May 2003 13:01:38 UTC