Myth of loose coupling

I'm baffled that people consider the web to be "loosely-coupled" systems.
Guess what, when HTML changed versions, people had to upgrade their
browsers.  The app (browser) changed whenever the user needed more
functionality.  Say a new version of HTML comes out, maybe even XHTML!  Then
a whack of servers upgrade to say they will produce according to the new
interface.  And new apps (the updated browsers) come along and can grok the
xhtml.

It just so happens that HTML, XHTML, CSS, JPEG, etc. have followed a fairly
lengthy centralized standardization process.  And we've kind of settled down
to our current versions.  To prove this point, the current angst over how
XHTML 2.0 should define link constructs CLEARLY indicates that the app
(browser) is tightly coupled to the interface schema.

Maybe it will be the same with PurchaseOrders, Invoices, etc.  But for now,
we actually want to have it where the interfaces are defined in a
decentralized manner, rather than through a centralized ever-speedy
standards process.

<rant>
I think we should stop kidding ourselves that we are building loosely
coupled systems when we have well-defined interfaces and protocols.

We certainly have loose coupling between the applications environments, like
Perl/Java/Python; OSes; app server environments; and the messages.  Heck,
our software provides about a few  different "mapping" layers between xml
and Java.  But fundamentally, if the interface changes, software on both
sides has to change.  It can sometimes be nicely isolated from the
application by the mapping layer, but more often than not it can't.  I
highly doubt that I could change a purchase order schema, and not change the
application.  Try just changing a string Name into a structure of
firstname/lastname and you are doomed.  There are over 10 000 rules for how
to figure out firstnames from last names in a string, so the darned sending
software is going to be in hell trying to figure the separation rules in
this "mythical" mapping layer that's supposed to insulate it from change.
"Just put XSLT in between" doesn't cut it in any way.  We are living through
the agony of this in all the darned infrastructure vocabularies - like the
changes that occur in the ws-security schemas - so why wouldn't the app
vocabs?

The web isn't loosely coupled between the interface schema and the
implementations, it's just that the evolution has almost stopped and we
don't remember all the times we had to rev our browser.  And we've now got
cool "auto-update" features that allow us to get the latest flash player
without much effort.  The browser has been built to modularize the various
places that the changes can occur, so it doesn't appear as disruptive.  But
it's all still tightly coupled.  Change the interface=change a piece of
software.  Nowhere to hide.  The only question is: can you isolate the
change to a small piece of software that's on a faster rev cycle than the
bigger "container" software?

Web services can't run from this problem either.  At least we have some
great infrastructure pieces to help us deal with change, like soap headers,
xml and namespaces, WSDL.

</rant>

Cheers,
Dave

> What we are seeing in practice is that all too often
> developers take the
> easy approach. Rather than defining an interface - whether
> RPC of document
> style - that is decoupled from the implementation, they use tools that
> produce a service definition directly from the implementation API.
> Obviously, as the implementation changes so would every
> application that
> needs to use this interface. Not a Good Thing(tm).
>
> However, nothing precludes you from following best practice,
> defining an
> interface that is decoupled from the implementation,
> performing mapping
> between the abstract interface and the particular
> implementation, and using
> RPC style to represent that abstract interface. WSDL does not
> say that RPC
> has to conform to an API, bad practice makes it happen.
>
>

Received on Monday, 6 January 2003 15:01:39 UTC