RE: Myth of loose coupling

There's a difference between breaking because of errors in data etc. versus
interface changes.  I never claimed that the only reason why software would
break is interfaces.  We're talking about loose coupling, not errors/faults
etc.

Dave

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Walden Mathews
> Sent: Tuesday, January 07, 2003 5:40 PM
> To: David Orchard; [email protected]
> Subject: Re: Myth of loose coupling
>
>
>
>
> ----- Original Message -----
> From: "David Orchard" <[email protected]>
> To: <[email protected]>
> 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.
>
>