RE: Myth of loose coupling

That's exactly the point.

An interaction with Amazon involves three layers. The HTTP client, the HTML
client and the human client. As long as you keep using the same version of
HTTP and HTML, the first two clients do not percieve any change to the
Amazon Web site. They could care less if it's English or Japanese. But when
you introduce a change to the Web site the human client gets affected.

The service is only loosely coupled if you are talking about the ability to
send/recieve HTML over HTTP, but if you are talking about the ability to buy
something, it is no longer loosely coupled. When Amazon changes their Web
site, for example switching to Japanese (how did that happen?), it affects
the buyer client.

arkin

> 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_c
> s_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:45:02 UTC