Re: Myth of loose coupling

hmm...I think we are in violent agreement here :-).

David

----- Original Message -----
From: "Assaf Arkin" <arkin@intalio.com>
To: "Jacobs,David B." <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:44 PM
Subject: 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 11:42:04 UTC