Re: Myth of loose coupling

I agree that web servers and browsers are tightly coupled at the HTTP, 
HTML, CSS, JPEG level.  However, at the application level (and by 
application I mean something like Amazon's site) I would argue that the 
client and server are not tightly coupled.  Amazon can make huge changes 
to its service offerings and layout without any changes being required 
of the client.  I believe it is this flexibility for the application to 
change and grow without breaking existing clients that most folks are 
aiming for when they say "loosely coupled"

David Jacobs

David Orchard wrote:

>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 Tuesday, 7 January 2003 02:39:48 UTC