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

RE: Myth of loose coupling

From: Edwin Khodabakchian <edwink@collaxa.com>
Date: Mon, 6 Jan 2003 21:40:29 -0800
To: <www-ws-arch@w3.org>
Message-ID: <000401c2b60f$49ad6420$690aa8c0@collaxa.net>

Assaf,

> 
> What about DESIGN OPTION C:
> 
> Operation #1: processVisaRegistration( xmlVisaOnlyForm ) 
> WebQueue #1: https://www.verisign.com/payflow/visaOnly
> Operation #2: processVisaAndMasterCard( xmlVisaAndMasterCard 
> ) WebQueue #2: https://www.verisign.com/payflow/visaAndMasterCard
> 
> Or DESIGN OPTION D:
> 
> Operation #1: processCreditCard( xmlCreditCard )
> 
I am not sure I understand what Option C and D are. Could you please
elaborate?

> On the other hand if an architecture forces you to always do 
> the right thing, then I would elect not to use it. What I 
> learned by experience is: if you can't abuse it, it's pretty 
> much useless.

Architectures provides constraints. As a developer you can decide to
work around that constraint and loose its benefits: In this case you
could have a dispatcher behind the queue and encode the method in the
XML document or the header (emulation of case A).

The counter argument to C would be to find class of use cases where
being able to expose/group a set of non-generic methods as part of a
service reduced the cost of integrating that service into client
applications or maintaining, managing and updating that service. 

Edwin
Received on Tuesday, 7 January 2003 00:40:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:12 GMT