One of the big controversies with Web services is that as long as they continue traveling over HTTP, they'll be insecure.
Analysts and vendors alike have long suggested that enterprises shouldn't use the standard HTTP communications over port 80, where firewalls are set up with a special port, or "hole," to allow inbound and outbound Web-oriented traffic. Because Web services ride on the HTTP protocol, any Web service traffic can get in and out through the firewall. Says Gartner analyst John Pescatore, "With Web services, it's basically putting a big tunnel right through the firewall--and that is a big risk."
Continuing to use the HTTP protocol with Web services isn't workable, because you encounter two major risk areas. First, your internal Web services access becomes exposed to outsiders. Because you can't close port 80, this is difficult to protect against, especially if your company Web server is on the same network.
Second, you could run up against someone--perhaps a disgruntled employee--finding a way to insert a trojan horse in the form of an unauthorized Web service on your network. Again, you'd have to track down and remove this service to prevent a security problem, because you couldn't just close that port. Because such an attack might be there for a while before you discover it--and is unlikely to be detected by anti-virus software--your network will be vulnerable to unfriendly visitors.
Until the industry completes the work necessary to make Web services secure, I think companies should limit activity to internal networks. Depending on the details of your network, it's possible to open your intranet to Web services, but you'd have to consider whether you'd want your business partners to have unrestricted access to that same network. Until then, hold off on deploying Web services until a more secure option comes along.