- 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>
> 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 UTC