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

Re: Myth of loose coupling

From: Walden Mathews <waldenm@optonline.net>
Date: Tue, 07 Jan 2003 21:13:24 -0500
To: David Orchard <dorchard@bea.com>, www-ws-arch@w3.org
Message-id: <002301c2b6bb$8698dde0$1702a8c0@WorkGroup>

> Maybe SOAP Web services advantage over CORBA/DCOM is:
> 1) Human understandable and widely deployed conceptually simple
> (URIs)
> 2) Human understandable and widely deployable vocabularies and tools (XML)
> 3) Human understandable and widely deployed starting protocol (HTTP)
> My kind of argument is just that it's way easier for a developer to look
> and understand the protocol, identifiers, and formats with Web services.

There may be more to this than meets the eye.  Again your message has
given me deja vu.  In 1988 when that same quote vendor* defined its
networking protocol over X.25, a decision was made to craft endpoint
addresses as 10-byte ascii strings "so you could read them off the
I, for one, am more comfortable looking at xml on the wire than iiop
objects, unless the xml was compressed(!).  Developers do have to test the
out of these applications, and their interests shall not be ignored.

*see my previous post

> BTW, this does lead us to a really interesting discussion area.  If part
> being "on the Web" has to deal with XML, then I see that using XML is a
> "Constraint" on the Web architecture.

Well, no, that would be the same as saying that you cannot construct an
information "web" without xml, which is of course not true.  XML has nothing
to do with what makes a web a web.  If it does, please explain.  That's not
to say that extensible schemas don't improve some properties of the web, but
that's not a constraint in my book.

 > So now there is a trade-off (REST vs
> whatever) between usage of XML and URI for service identification and

What is the tradeoff?  Is it XML versus URI?  (I don't follow.)

> The question is: what does XML have to do with Web architecture?  Is XML
> simply a best practice, or is it more significant and indeed a new
> constraint?  I think the latter.  Similar to following the uniform
> interface, or stateless interaction constraints, following XML accrues
> certain benefits.  And following SOAP accrues more benefits (like headers,
> processing model).

I'd say the best practice is to use XML in situations where the structure,
etc. of
data need to be described inline, and to avoid it when there is no such
Kind of like the best practice to use my car when I have to go more than a
mile, but never use it when I have to go less than a meter.  You wouldn't
your car to the kitchen, would you?

> Here's a way of looking at this that is new to me.  We could say that SOAP
> and WSDL are "constraints" of Web services, and XML is a new constraint on
> the Web.

The first part you can get away with, because you get to define the phrase
services" (although not without creating a stir).  The second part is harder
for you
to get away with, because "The Web" already means something, and for better
or worse, it doesn't mean "gotta have XML".

 > If people don't follow those constraints, then they don't get
> certain benefits.  So just because a Web site doesn't follow the stateless
> constraint, that doesn't mean it's no longer "on the Web".

That's true, you can have stateful servers and still be "on the web", but
if you violate a different constraint, it takes you "off the web", by
of "web".  You know which one I mean?

> Back to the "loose-coupling" - this is turning out to be a low-cohesion
> message :-)
> I think that marketing has polluted the computer science definition of
> coupling.  And I'm trying to get us thinking about dealing with the fact
> that we actually have highly-coupled systems, and our architecture should
> help with that.

Can they be "highly-coupled" and "loosely-coupled" at the same time?  I
actually think that's a pretty good way of describing a healthy system.

> Should we start defining things like loose-coupling, applications,
> constraints in our arch document?

Here's a vote for 'constraints'.  Thanks for these thoughtful expositions.

Received on Tuesday, 7 January 2003 21:15:58 UTC

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