RE: Myth of loose coupling

I thought I was understanding you until you compared using xml to driving a
car.  I don't quite see the value in some of the comparisons that are
popping up.

Isn't the trade-off between XML and URIs when invoking services pretty
clear?  I cannot use GET and pass xml data.  So I'd have to encode up all my
data in the URI.  Darn, length limits, no ways of doing modularity, have to
use html URL-encoding.  Or I could send the XML data as part of a POST
request.  Say I've got a conversation ID, or a username/password, or ticker
symbol, or whatever.  These parameters have to be sent somehow.  URI, SOAP
header, XML document, HTTP Header, some place has to have it.

As for the "Web" and XML, I've been part of a group working on a document
that talks about what makes up the web architecture.  And XML is playing a
bigger and bigger part of that, now that the group is spending less time on
URIs.  For example, section 3.3 [1], talks about all the properties that are
realized when using XML.

I know what constraint some group of people think is the defining
characteristic of the Web.  I also know that some people think that Web is
completely defined by REST.  Believe it or not, I'm not sure that the two
are completely the same, and I think it is XML that is the disconnect.  We
better figure out soon whether XML is part of the Web or not.  Who knows, if
XML isn't part of the Web then some people will want the TAG to nuke the XML
activity.

BTW, some people consider cookies with session IDs to be still stateless -
not stateless applications but stateless interactions.  And even ftp URIs
can be alleged to be stateless.

Cheers,
Dave

[1] http://www.w3.org/2001/tag/2002/webarch-20021206#format-specs

> -----Original Message-----
> From: Walden Mathews [mailto:waldenm@optonline.net]
> Sent: Tuesday, January 07, 2003 6:13 PM
> To: David Orchard; www-ws-arch@w3.org
> Subject: 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 22:23:43 UTC