RE: Myth of Loose coupling

I completely agree on this comparison.

Another interesting aspect of the html vs. purchase order comparison is the semantic coupling. Html provides completely open semantics (basically natural language + pictures, etc) and at the same time very loose semantic coupling. In other words the consumer of an html document (a human) can look at content never seen before and still make good sense out of it (unless it is in a foreign language, etc.).

In the case of the purchase order, the semantics is much more constrained than the html document, and yet the semantic coupling implied is much stronger. In other words, the system processing the purchase order has to know in advance about all the semantic details (for example, by reference to a well known vocabulary with predefined semantics) before being able to process the document effectively.

Ugo

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of David Orchard
> Sent: Thursday, October 02, 2003 4:38 PM
> To: 'He, Hao'; www-ws-arch@w3.org
> Subject: RE: Myth of Loose coupling
> 
> 
> 
> 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
> happening.
> 
> Cheers,
> Dave
> 
> > -----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 20:22:04 UTC