W3C home > Mailing lists > Public > www-ws-arch@w3.org > January 2003

Re: Myth of loose coupling

From: Walden Mathews <waldenm@optonline.net>
Date: Wed, 08 Jan 2003 11:22:37 -0500
To: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>, www-ws-arch@w3.org
Message-id: <002001c2b732$28d39d40$1702a8c0@WorkGroup>


> Hmmm.  I've been trying to reconcile the RESTful and SOAP/WSDL web
> perspectives by asserting that it's NOT a paradigm shift, but an
> 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
> on both sides to integrate over the Web (the most typical business case
> 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
> 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
> 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,
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
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
> of us point out repeatedly, even hard-core WS people acknowledge the
> scalability problems and fragility of the pure RPC approach. Likewise
> 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
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
> a remote procedure call, e.g. "query parameters", "business process
> parameters", etc. I do agree that as a best practice guideline, "long
> 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
> suggestions how to build web services that scale to the Web.  Let's not
> 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.

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:02 UTC