W3C home > Mailing lists > Public > www-ws-arch@w3.org > January 2003

RE: Myth of loose coupling

From: Assaf Arkin <arkin@intalio.com>
Date: Tue, 7 Jan 2003 00:20:46 -0800
To: "David Jacobs" <djacobs@mitre.org>, "David Orchard" <dorchard@bea.com>
Cc: <edwink@collaxa.com>, "'Mark Baker'" <distobj@acm.org>, "'Ugo Corda'" <UCorda@seebeyond.com>, "'Champion, Mike'" <Mike.Champion@softwareag-usa.com>, <www-ws-arch@w3.org>

Here is a test for you. Can you tell me what I have just bought:



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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:02 UTC