RE: Myth of Loose coupling

 

> -----Original Message-----
> From: Doug Kaye [mailto:doug@rds.com] 
> Sent: Wednesday, October 01, 2003 3:27 AM
> To: 'David Orchard'; www-ws-arch@w3.org
> Subject: RE: Myth of Loose coupling
> 
> 
 
> I like your list of loose-coupling properties. May I suggest 
> two others that I don't think are covered by your list?
> 
> 1. Data validation through published schema. (As opposed to 
> "by convention"
> [brittle] or as part of the service [too fine-grained and noisy].)

Hmmm, so there would be loose "meta-coupling" via schema publication and
validation, but tight coupling to actual schema?  That is, schema
inconsistency/uncontrolled evolution still breaks service invocations, but
does so in a predictable and manageable way?

Dave's point about the Web not being all that loosely coupled, it's just
that the formats have stabilized, seems appropriate here.  Would the Web
have been more loosely coupled, assuming that is a "good thing," if browsers
can cleanly and predictably choked on markup they didn't understand rather
than quietly ignoring it or trying to "guess" what the author had in mind?
In the services arena, do we have any reason to believe that there will be
published standard application-level message formats anytime soon? 

So, while I accept that "data validation through published schema" is often
a best practice in services architectures, it seems somewhat antithetical to
the loose coupling objective. Or more precisely, there is a tradeoff between
precise interface contracts/validation on one hand and flexibility in the
face of evolution ("loose coupling") on the other. While financial services
at international banks or nuclear reactor control services almost certainly
should perform intensive data validation through published schema, other
environments -- especially those involving numerous, diverse requesters and
relatively non-critical data -- may well choose to be more flexible and
heuristic.

Am I missing anything here?

Received on Wednesday, 1 October 2003 08:17:58 UTC