Yes, creating a duplicate web service on machine B sounds like a bad idea, both from a maintenance perspective and the potential extra errors it will introduce.
I once solved this problem by installing an Apache web server on machine B, and setting it up as a reverse proxy. This means that you expose the WSDL that is hosted on machine A via machine B. All web service clients will 'think' that they are talking to machine B, but they are actually talking to machine A. Apache then just stands for forwarding the web service requests from the client to machine A. This behavior is supported by Apache's mod_proxy module, using the ProxyPass
and ProxyPassReverse
directives.
There is one 'catch' with this solution: you expose the WSDL from machine A via machine B, and a WSDL always contains the hostname of the machine it is hosted on, in your case machine A. So, clients are talking to machine B and all of a sudden they receive a WSDL which contains a hostname that they don't know.
The solution for this: you need to configure the web service on A in such a way that it will contain the hostname of machine B instead. I don't know what framework you are using, but in WCF, this can be easily be configured using the WCFExtras project.