Re: Myth of loose coupling

Mike,

> Hmmm.  I've been trying to reconcile the RESTful and SOAP/WSDL web
services
> perspectives by asserting that it's NOT a paradigm shift, but an
engineering
> decision about optimizing specific scarce resources in specific scenarios.

I think you can go ahead and make that engineering decision, but
figuring out how to do that optimization involves (I think in this case)
a "jump" into a pattern that looks different enough to use the "P" word,
but I won't use that word anymore if it offends.

Sometimes you can average good things together and get something
good.  In this case, I don't think so (see below).

> SOAP/WSDL tends to optimize programmer resources when there is existing
code
> on both sides to integrate over the Web (the most typical business case
for
> this technology today), REST tends to optimize re-use of exisiting Web
> resources, integration with Web technologies, and discovery in much more
> loosely coupled (and written for the Web) applications. I think that's
close
> to the position I thought you were taking at the beginning of this
> incarnation of the thread, i.e., that there was a big middle ground
between
> the REST and SOAP/WSDL approaches.

Not really.  Eric Newcomer took that position, and I practically begged
him to explain it in detail, but didn't get satisfaction.  On the contrary,
I
think REST *is* the middle ground you get when you remove RPC (in
the sense that Mark means) and then follow up that commitment until
your system is strongly coherent again, based on Web-power.  I've been
thru that process.  Once. I'd like to do it again.  Anyone need an
application
developed (pay optional)?


>
> Sure, the *extremes* of a pure SOAP-RPC and a pure hypermedia/SW REST
> architecture could be thought of as different "paradigms". Still, as
several
> of us point out repeatedly, even hard-core WS people acknowledge the
> scalability problems and fragility of the pure RPC approach. Likewise
(ahem)
> the pure hypermedia/Semantic Web approach to addressing the use cases that
> Web services people talk about [as opposed to spiders, cows, and
> circles/rectangles :-) ] looks a bit vaporous when it comes down to actual
> implementations in the field.   So as a practical matter today, we're all
> somewhere in the middle.

Okay, I get your drift.  You're saying the extremes of the two approaches
look extremely different.  I'm going a bit further and saying they are in
fact
two distinct patterns, based on two different (strong) attractors, which you
have identified above.  The attractors won't allow an average to stabilize,
IMO.  They want a choice.

>
> So, I (if that was me who said "these parameters have to be sent somehow")
> was referring to "parameters" in a very abstract sense, not as arguments
to
> a remote procedure call, e.g. "query parameters", "business process
> parameters", etc. I do agree that as a best practice guideline, "long
lists
> of parameters in queries" is a symptom of a too-tight  coupling or a
> too-desperate attempt to throw some stuff at the service and hope it can
> make sense out of it.

Then we're talking about the same thing.  I don't think the level of
abstraction matters, FWIW.  A "web" is a response to that which takes
things to the opposite extreme by loading all the burden on one side.
Thinking in those extreme terms is part of the shift.

>
> So, my bottom line remains: let's mine REST for best practice guidelines
and
> suggestions how to build web services that scale to the Web.  Let's not
get
> caught up ideological struggles between contending paradigms.

Absolute agreement.  I regret having used the word, but on reflection,
I used it for the purpose opposite that of creating contention.  Please
mine away.

Walden

Received on Wednesday, 8 January 2003 11:25:37 UTC