Re: Myth of loose coupling

----- Original Message -----
From: "David Orchard" <dorchard@bea.com>
To: <www-ws-arch@w3.org>
Sent: Tuesday, January 07, 2003 2:07 PM
Subject: RE: Myth of loose coupling


>
> I completely understand the flexibility of changing web sites without
> affecting the client.  My argument is that from the client's perspective,
> this is a "data" change, and not an "application" change.

This is sounding very familiar.  I used to manage ticker plant development
for a quote vendor; we had to deal with changes in the feeds published by
the financial exchanges.  Some of those required new software releases;
some didn't.  I'd say there are two ways an application can "break":

(1) syntax of the vocabulary changes so that the client can no
     longer access the meaning of the encoded data,

(2) values encoded exceed expected limits, or meaningful combinations
     of values for a given data set -- i.e., the data model invariants are
     violated resulting in invalid object states.

>  Imagine the
> corollary in Web services.  Web model=use HTML.  Web services=use XML.
> Instead of using the standardized HTML for offering a web site, Amazon
> offers XML.  Now it creates it's own vocabulary of xml.  You write an app
> for that XML.  If Amazon changes the data values - like adds a new book -
> your app doesn't break.

Not usually, but if the price of the book is US1,000,000,000.00, something
might break.  There was one stock I remember that was notorious for this; it
set off all the validation alarms and had to be custom coded for.

 > But if Amazon changes the vocabulary of xml, your
> app breaks.

Sometime, yes, but not if the vocabulary is changed by _extension_, which
afterall is what the 'X' in XML is all about.  Extensible data structures
have
been around for a long time.  What makes XML special in this area is that
you can "append" stuff to an XML schema right in the middle of a document.
With binary formats, you have to design extension areas at the end of the
structure, which eventually makes data structures ugly.

 > My point is that HTML doesn't evolve very quickly, so the
> clients don't break very often.  But in program to program via XML, this
> situation is completely different.   And because XML allows for much
quicker
> changes to vocabularies, programs will break more often.  The browser and
> the Web service client all have the same level of coupling, it's just that
> the vocabularies can change at WAY different speeds.

I think the real crux of "loose coupling" is in the idea that servers will
evolve
at a different rate than clients (usually in that order), and that iff
clients are
written so as to be immune to changes that are pure extensions, then
evolution
can indeed proceed _somewhat_ independently.  This is a huge improvement
over what the commodities exchanges used to do to us!

But if two peer applications are hell bent on going in different directions,
then
I think we'd agree there's little hope.


>  In fact, I kind of
> argue that XML is a two-edged sword because of this.  XML means we can
very
> quickly create new vocabularies.  But the converse of that is that
> clients/servers will break more quickly.

We need to keep "eXtensible" in mind when we design our XML vocabs,
no?*  Even so, stuff will drift into the "sunset" zone (that's what they
told me
about my Quicken Deluxe 2000 today when I called customer support).  The
price of keeping "sunset" functionality in the loop justifies the avoidance
of
breakage, I think, as long as there's a way to dump it eventually.

The ultimate "loosely coupled" applications don't understand each other,
so add no value.  We have to avoid thinking of these things in the absolute
if we're going to make progress here.

Regards,

Walden

* Else we can have plain ole CML = changeable markup language.  Naw.

Received on Tuesday, 7 January 2003 20:40:41 UTC