Re: Myth of loose coupling

Dave,
>
> Maybe SOAP Web services advantage over CORBA/DCOM is:
> 1) Human understandable and widely deployed conceptually simple
identifiers
> (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
at
> 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
proprietary
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
datascope".
I, for one, am more comfortable looking at xml on the wire than iiop
post-marshalled
objects, unless the xml was compressed(!).  Developers do have to test the
hell
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
of
> being "on the Web" has to deal with XML, then I see that using XML is a
new
> "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
usage.

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
need.
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
drive
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
"Web
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
definition
of "web".  You know which one I mean?

>
> Back to the "loose-coupling" - this is turning out to be a low-cohesion
> message :-)
>
[snip]
>
> I think that marketing has polluted the computer science definition of
loose
> 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.

Walden

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