In a comparison of SSH and WTS at WhatIsWrongWithTerminalServices:

''SSH allows you to tunnel other services securely through a FireWall, including (for example) mail, file transfers, http, and so on.''

I consider tunneling through FireWall''''''s very bad practice. I also don't like SOAP over standard HTTP on port 80 for this reason. It just means that firewalls have to get more complex and therefore the network becomes less secure.

Why would you do it? ''Because getting your (or someone else's) sysadmins to change the FireWall policies is too difficult. This is not a good reason, but I think it is the reason.''

On the other hand, building one really secure pipe through which you can put "ordinary non-secure" services can be a really good thing for security:
You can focus your efforts on making the one pipe very secure, rather than having to worry about the weakest link of many independent security systems.

On the other other hand
''(having three hands now!  ;-)''
I've "violated corporate security" by tunneling other protocols through SecureId access through a FireWall.
(This was done with full knowledge and cooperation of managers of two of three companies involved in a partnership.  Yes, it was done to the 3rd without their knowledge, but we had our white hats on and it was done because it was needed to achieve the business objectives of the 3rd party.)
-- JG

Tunnelling is not always bad. Often with RPC services the alternative is to open up every dynamic port it might choose. Secondly, no matter how good your firewall security, you also need application security. If for some reason you need to expose a service with known security weaknesses over an uncontrolled network, then a secure tunnel wrapper is a ''good'' solution to your problem. Thirdly, SSH's tunnel is not as pernicious as a VPN can be. In a VPN extranet you often expose parts of your network you hadn't thought about to people in another company you can't fire, no matter how much you'd like to. SSH exposes a single point on your network. If you trust the administrator of that machine enough to let him expose an SSH tunnel to that one machine through your firewall, you are delegating to application security just as much as if it was simply a webserver. 

In short, FireWall''''''s don't 'have to' get more complicated to handle tunnelled services because they already delegate responsibility for application security to only those applications the FireWall has explicitly exposed. A ''secure'' wrapper around those applications at least reduces some of the worry. 

PS SOAP actually includes some considerations to allow coarse-grained control at a FireWall anyway.

PPS if you thought SOAP was bad you must have choked on RFC3093!!! (http://www.isi.edu/in-notes/rfc3093.txt) --BrianEwins

And now what's the point of having OS with ability to open 65000 different ports when we have firewall? For security?
But then they can wrap every call in XML-RPC and passed it over port 80. So that we can build XML RPC Firewall on top of it? More secure? I don't think so.. seems like it's recursive call.