Re: Myth of loose coupling

That is why Amazon puts human readable labels on their links :-).  For a
machine readable version, you would need appropriate machine understandable
labels (URIs?) to help the computer figure out what the link was for.

David

----- Original Message -----
From: "Assaf Arkin" <arkin@intalio.com>
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>
Sent: Monday, January 06, 2003 10:20 PM
Subject: 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:39:02 UTC