RE: Myth of loose coupling

David,

Loose-coupling is not black or white. It is about minimizing the impact
of change: when you start deploying system across a set of nodes, you
have to assume that nodes will evolve. It would be difficult to argue
that the web does not know how to adapt to change: the web is the only
application that I know of that is always on and millions of pages are
updated and structure of web sites are changes on a daily basis.

You are right that changes on data structures have deeper impacts and
that building a system that can automatically adapt and understand these
kind of changes is a little futuristic.

But there are a lot of cases where you want to change the implementation
without changing the input and output data structures. In those cases, I
believe that Web services designed as a resource with a generic
interface will be able to evolve with less impact, even more so if the
service is designed to work asynchronously.

The point here is that forcing developers to break down services with
multiple methods into resources with unified interface will create
applications and systems that are easier to evolve and adapt. I am happy
to demonstrate this point further will a real world use case if you
think that this assertion is far fetched. 

[Note: I am not claiming that the application is easier to develop: like
I said earlier, RPC is the most developer-friendly abstraction and the
one that fits the best into current programming languages].

Edwin


> -----Original Message-----
> From: www-ws-arch-request@w3.org 
> [mailto:www-ws-arch-request@w3.org] On Behalf Of David Orchard
> Sent: Monday, January 06, 2003 11:22 AM
> To: 'Assaf Arkin'; edwink@collaxa.com; 'Mark Baker'; 'Ugo 
> Corda'; 'Champion, Mike'
> Cc: www-ws-arch@w3.org
> Subject: 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 16:05:01 UTC