A few points on the SOAP discussion:
- SOAP itself does not mandate transmission over HTTP. You could, for example, use BEEP as a transport.
- SOAP over HTTP was definitely designed to get through firewalls and HTTP proxies. This is the reason why people use HTTP and not a superior transport like BEEP (that would allow communication from the server to the client without pulling). If it did not use HTTP all those web services would not work for many problems, it would require a huge change in the infrastructure. Basically everybody who can access the web only over a www proxy could not use those web services.
- If your problem with SOAP is that you can not prevent a user/client from using it, read my last entry - you can not effectively limit the user's communication anyway.
- if your problem with SOAP is tunneling the firewall on the server side: you dont want SOAP to run on port 80, use another port. If you dont want to use HTTP, you are free to use another protocol. You will lose a lot of users/customers, of course, because many of them wil not be able to use it.
- I also don't buy the 'build an abstraction layer around the interface' argument. Basically SOAP is the abstraction layer. If you write one yourself you write more new and unproven code and introduce more potential security leaks. And, of course, you will lose a lot of time that you can also spend on making your code more secure.
- If your problem with SOAP is that it makes it too easy for server developers to shoot themselves in the foot: if you really take a COM object and make it available via SOAP without a security audit then, well, it is your fault. But the technology is not bad only because it allows stupid people to do stupid things. If that was true Unix would be the worst of all operating systems...