RE: Myth of loose coupling

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

http://www.amazon.co.jp/exec/obidos/ASIN/B00006RT6E/ref=ed_ec_gw_cs_1_2/249-
5515888-2202702

arkin

> -----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