RE: Myth of loose coupling

hi, David,

I agree that changing the schema of XML could stuff applications. However,
XML has the capability of being extended without breaking compatibility by
simply providing redundant information. For example,
in a first version of my services, the server sends <name>Web Page</name> to
its clients.  In the
second version, the server sends <name surname="Page" givenName="Web">Web
Page</name> to its clients.
As long as I don't remove existing vocabularies, all my existing
applications will continue to work. Of course, applications can change to
take advantages of newly added features, but they don't have to.

IMO, XML to the Web is just as important as DNA to life. It is the
extensibility of XML and DNA that
allows the Web and life to EVOLVE continuously. 

BTW, loose coupling is not an absolute thing. It is not on and off but a
degree. So my definition
of loose coupling is:

1. coupling is the dependency between two interacting parties.
2. loose coupling means that the degree of dependency between two
interacting parties has reached its minimum.

Hao

-----Original Message-----
From: David Orchard [mailto:dorchard@bea.com]
Sent: Wednesday, January 08, 2003 6:07 AM
To: www-ws-arch@w3.org
Subject: RE: Myth of loose coupling



I completely understand the flexibility of changing web sites without
affecting the client.  My argument is that from the client's perspective,
this is a "data" change, and not an "application" change.  Imagine the
corollary in Web services.  Web model=use HTML.  Web services=use XML.
Instead of using the standardized HTML for offering a web site, Amazon
offers XML.  Now it creates it's own vocabulary of xml.  You write an app
for that XML.  If Amazon changes the data values - like adds a new book -
your app doesn't break.  But if Amazon changes the vocabulary of xml, your
app breaks.  My point is that HTML doesn't evolve very quickly, so the
clients don't break very often.  But in program to program via XML, this
situation is completely different.   And because XML allows for much quicker
changes to vocabularies, programs will break more often.  The browser and
the Web service client all have the same level of coupling, it's just that
the vocabularies can change at WAY different speeds.  In fact, I kind of
argue that XML is a two-edged sword because of this.  XML means we can very
quickly create new vocabularies.  But the converse of that is that
clients/servers will break more quickly.

Cheers,
Dave

> -----Original Message-----
> From: David Jacobs [mailto:djacobs@mitre.org]
> 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.
> >>
> >>
> >>
> >>
> >
> >
> >
>
>
>
>
>