I personally feel that this response is quite harsh ... and inaccurate.   “A web service” is simply a program that takes (usually) an XML-encoded input and produces an XML-encoded response, both by means of a TCP/IP socket.   There are many CPAN modules that implement such web services, and the only thing which you have to do to run it “without a web service installed” is to, well, run it.   You cannot tell it to bind to an HTTP port below 1024, and its URI-name will probably be localhost (unless you define a host-name of your own, e.g. with a hosts file or an equivalent Windows registry-entry, but otherwise, “voilá, a fully-functional web service, albeit not on-the-web, ready for developer testing.”   To the client, it makes no difference.

It is extremely inefficient for a developer to futz around with starting and restarting actual service-processes in order to test his/her stuff.   So, this is the way it’s done, instead.   Instead of www.myclientsite.com:80 (for HTTP), it might be dev.myclientsite.com:8080 (defined on the developer’s own machine).   After changing the code, hit control-C on the command line, up-arrow to reselect the previous command entered, and Enter to restart it.   The client can’t tell, and doesn’t particularly care, where the host is.

The developer is now able to write, test, and debug exactly the same body of code that will, eventually, provide the same set of services “in production.”   No changes will be required to the source-code when the software “goes live,” and software that is already “live” does not need to be disturbed by, or upon, the developer’s own machine.   Offhand, I can’t think of any environment, whether for web services or for web pages, that does not provide this capability to software developers.