OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: FW: Myth of Loose coupling

Fred, Brian, Scott et al

Interesting in light of the WS-Change work and the Requirements for


-----Original Message-----
From: David Orchard [mailto:dorchard@bea.com] 
Sent: Friday, September 26, 2003 6:01 PM
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.


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
- 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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]