RE: Myth of loose coupling

> DESIGN OPTION A
> As a developer, I can decide to design the application as one service
> with 2 operations:
> Operation #1: processVisaRegistration( xmlVisaOnlyForm )
> Operation #2: processVisaAndMasterCard( xmlVisaAndMasterCard )
> This is what most developers using today's web services toolkit would be
> encouraged to do.
>
> DESIGN OPTION B
> As a developer, I create 2 Web Queue resources with a generic interface:
> WebQueue #1: https://www.verisign.com/payflow/visaOnly
> WebQueue #2: https://www.verisign.com/payflow/visaAndMasterCard
> Get on those resources returns the meta information regarding the XML
> data required by each queue. POSTing the correct XML document initiates
> an asynchronous process.

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 agree with you. Option A is bad. But nothing enforce you do to option A.
You have a variety of options and you need to pick the right one. I would
picke C or D, which means I would still get the benefits of decoupling that
you are talking about. So I won't discredit an approach that lets me do A, C
or D because I never elect to do A.

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.

arkin