RE: Myth of loose coupling

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