RE: Calling web services - Application Architecture question

["Walden H. Leverich" <WaldenL@xxxxxxxxxxxxxxx>]

Charles,

Obviously, it's an "it depends" question. :) But things I'd consider
are:

If you implement a gateway or proxy to the remote service can you
simplify the call? For example, does the remote call need a
username/password? Is that the same for all requests? If so, the gateway
needs to send it to the remote machine, but you don't need to send it to
the gateway. Of if the remote services has 20 parms and you use 3, your
internal-facing implementation can just expose 3, and handle the rest
itself.

Does implementing a gateway allow you to cache requests? Depending on
what the webservice call is, if it's deterministic then can/should you
cache results for increased performance? If it's a "GetCityStateForZip"
call, you could cache the last n zips requested and serve back the
response w/out hitting the remote site. That would both be a performance
increase, and perhaps a cost savings, if you're paying per request.
Obviously if the call is an "authorize this CC" or "enter this order"
request, caching is out the window.

Do you need/want to log requests? A gateway allows you a single point to
catch requests.

Do you need/want to handle test vs. live urls? Your gateway can "know"
that requests from these machines are tests while requests from those
machines are live and redirect the call to the appropriave test/live
implementation of the webservice. Or return a "default" response for
tests and forward only live requests to the remote host.

Can you consume the web-service the way it's written on the remote host?
OK, yes, web services are "Standard" and you can consume them from
anyway, but it may be easier to have a totally different implementation
of a webservice for some applications/platforms. 

On the down side, as Aaron pointed out, there's a single point of
failure, but that's only true if you only implement the service on one
machine. Implement it on two and they're redundant.

-Walden