W3C home > Mailing lists > Public > www-ws-arch@w3.org > October 2003

RE: Myth of Loose coupling

From: David Orchard <dorchard@bea.com>
Date: Thu, 2 Oct 2003 16:38:19 -0700
To: "'He, Hao'" <Hao.He@thomson.com.au>, <www-ws-arch@w3.org>
Message-ID: <052f01c3893e$435de330$470ba8c0@beasys.com>

sure.  HTML went through a fairly slow change in interface.  V2 to v3.2 to
v4 took many years.  In the same way, if a purchase order goes from v1 to v2
to v3 in many years, then applications can gradually change.  If the PO goes
v1->v2->v3 in a year, then the systems have to change more rapidly.

In my mind, loose coupling is about the dependency between systems and the
degree to which they are isolated.  If the systems are changing rapidly,
then it becomes more difficult to deploy them in the necessary manners.

In a strict sense, rapidity of change does not effect the degree of
coupling.  But systems always seem to change, so it's easier to deploy
systems when there are longer intervals between the changes.

It should be obvious by now that part of my motivation is to say that deploy
html over synchronous http is as coupled as purchase order over synchronous
http.  That is, there is nothing about html per se that makes it loosely
coupled.  Some people have argued that because your browser works on a whole
lotta different sites without change, it's loosely coupled.  But that's
because all the different sites grok http and html.  If everybody grokked
the same version of a purchase order, we might be able to deploy purchase
order clients as widely as web browsers.  But I can't really see that


> -----Original Message-----
> From: He, Hao [mailto:Hao.He@thomson.com.au]
> Sent: Thursday, October 02, 2003 3:58 PM
> To: 'David Orchard'; www-ws-arch@w3.org
> Subject: RE: Myth of Loose coupling
> hi, David,
> I don't quite get how " rapidity of changes in the interface " would
> increase loose coupling?  Could you please explain?
> Thanks.
> Hao
> -----Original Message-----
> From: David Orchard [mailto:dorchard@bea.com]
> Sent: Sunday, September 28, 2003 3:49 AM
> To: www-ws-arch@w3.org
> Subject: Myth of Loose coupling
> I'm posting a link as I was asked to before on the start of a
> discussion on
> loose coupling.
> http://lists.w3.org/Archives/Public/www-ws-arch/2003Jan/0115.html
> I will say that I have come to have a somewhat revised view on loose
> coupling.  I would say that loose coupling is a combination
> of properties:
> - extensibility, so that additional information can be added without
> breaking receivers
> - evolvable changes in the interface, so compatible changes
> can be made.
> - rapidity of changes in the interface
> - on the web, the generic interface constraint, means that
> applications
> (browsers/search engines) are not dependent upon each site's protocol.
> - asynchrony, so that senders and receivers are decoupled in time
> - stateless messaging, so that senders need fewer messages
> and hence less
> chance of communication errors
> - use of URIs for identifying resources.  This means that
> identifiers are
> very constrained and easily transferred.
> - No vendor specific or platform specific constraints on any of the
> technologies used.
> I think one can then say that loose coupling is a property that is a
> combination of other properties as I've listed above.  And it
> seems that
> changing each property/constraint increases the coupling.
> For example, a
> web service with no extensibility, that evolves rapidly in
> incompatible
> ways, an application specific interface, synchronous,
> stateful messages is
> tightly coupled with it's clients.
> This would show that the Web is "mostly" loosely coupled
> because of the
> extensibility/evolvability in http/html, slow changes in html
> vocabularies,
> stateless messaging, vendor/platform agnostic.  Yet it is
> tightly coupled in
> being synchronous.
> Another way of looking at this is that Web service
> technologies do not per
> se mean a service is loosely coupled, it is only through the
> application of
> constraints to be loosely coupled.
> Seem reasonable?
> I think this notion of a "combination" property is similar to
> the visibility
> property, which I argue is a combination of simplicity and percieved
> performance properties.
> Cheers,
> Dave
Received on Thursday, 2 October 2003 19:37:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:09 UTC