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

RE: Myth of loose coupling

From: Assaf Arkin <arkin@intalio.com>
Date: Mon, 6 Jan 2003 21:16:47 -0800
To: <edwink@collaxa.com>, "'David Orchard'" <dorchard@bea.com>, "'Mark Baker'" <distobj@acm.org>, "'Ugo Corda'" <UCorda@SeeBeyond.com>, "'Champion, Mike'" <Mike.Champion@SoftwareAG-USA.com>
Cc: <www-ws-arch@w3.org>
Message-ID: <IGEJLEPAJBPHKACOOKHNIEAGDAAA.arkin@intalio.com>


> 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
Received on Tuesday, 7 January 2003 00:18:03 GMT

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