|In the scenario you described, your solution is correct. But again don't consider simple socket communications. .NET Remoting can work over any port without IIS, you just need a different host. Windows Services, for example (those deriving from
ServiceBase and installed with the
ServiceProcessInstaller classes), make great hosts.
The solution depends entirely on your network topology. If your external web servers sits in a DMZ and has limited access to the inside network through well-known ports (like HTTP), then one solution is to use .NET Remoting or Web Services to talk to an internal web server (perhaps a virtual end-point for SQL Server, even) through port 80 (or whatever port the web server is configured on).
There's not a single solution for any given scenario.
To learn more about .NET Remoting, I recommend picking up "Microsoft .NET Remoting" from Microsoft Press[^] or "Advanced .NET Remoting" from Ingo Rammer[^], both very good books (although the latter is for intermediate and advanced .NET Remoting developers, while the former is for beginning and intermediate .NET Remoting developers).
The only point I was making before was that the wire protocol isn't enough. You still need to define a data transfer protocol with any application and platform. .NET Remoting and Web Services (which are an industry standard and not specific to .NET) describe both. .NET Remoting is comrised of independant wire and transfer protocols (i.e., binary or SOAP over HTTP or TCP - "out of the box"), while Web Services use SOAP over HTTP.
If you want to use sockets, you'll need to define your own protocols.
This also depends on legacy systems, too. If you have a legacy socket server in place and want to continue using it, then you'll have to use the protocol you already defined with the socket classes in the BCL.
The nice thing about Web Services is, though, that many legacy servers now support HTTP daemons, which aren't too hard to implement (basically) anyway. Developing a Web Services need not be hard, either, so long as you explore the SOAP and WSDL specifications and implement them accordingly. I've seem scenarios where older AS/400s implemented Web Services. IBM was a key player in the push for Web Services, so many of their upgraded OS images support them through WebSphere or some other system (I must admit I don't follow IBM these days).
This posting is provided "AS IS" with no warranties, and confers no rights.
Software Design Engineer
Developer Division Sustained Engineering