Well, I'm hardly an expert on the subject but I have studied it a bit and I am very interested in Distributed object architectures.

Responses inline

>1) In the code samples that I've seen for remoting, the TCP channel (or HTTP channel) that is used is referenced through 'localhost'. If I want to call a DLL/assembly that's on another machine, how would I reference it? (or...just by virtue of the fact that the server object is loaded and running, would the client 'find' it, or does there need to be another reference?
>

The client needs the name or ip address of the server machine. Most of the examples just use localhost, but you can specify any URI as in this example:

System.Object o =
  System.Activator.GetObject (
     typeof (Calculator),                        // Type of proxy
     "http://www.wintellect.com/Math/SharedCalc"); // Endpoint

> a- Why do we even need the Web Service? Can't we just use HTTP and have the local WinForm use remoting to call the middle-tier? However, is that even a 'web-based' strategy, and is it potentially less secure?

Yes, if your middle tier server is accessible from the internet, then you could just call the object directly using http. However it has less security build in. Web services are build on top of ASP.NET so it has all the security of asp.net available to it (including authentication, authorization, certificates, etc).

Remoting is like a lower level protocol underneath web services. If you are going to use http and soap, then you might as well use web services because its programming model is much simpler than remoting.

>
> b- Is the approach of
> 'Client calls Web Service',
> 'Web Service remotes with Middle-Tier',
> 'Middle-Tier calls SQL Server',
> 'Middle Tier returns dataset back to Web Service',
> 'Web Service sends dataset back to WinForm'...
>
> ...an overall sound method, or is there excessive overhead?
>
> While not definite, we've been told to expect that our client may place a firewall in front of the Web Service, and might also place a firewall between the Web Service and the middle-tier for additional security...I mention this in case that factors in to the best overall approach.
>

To go through the firewall, you would either need to use http or open up some tcp ports on the firewall to let tcp traffic through.

I think the choice between remoting and web services comes down to performance vs. security and ease of programming. These are exactly the issues you are trying to deal with now.

I think the way you are going is the correct one. Basically, think of your middle tier business object running on a separate server behind the firewall. Those services can be exposed to clients outside the firewall through web services. This way you get the security of and ease of programming of web services. Inside your organization, the clients can call the middle tier objects directly through remoting and tcp (giving you approximately 10 times the performance vs web services).

The other way to do it without remoting would be to copy the dll containing the middle tier and put it on the web server. Also, you would have to copy it to each client computer that is running the application inside the firewall. Then each of these computers access sql directly. This is still 3 tier because all data access is through the middle tier, but the middle tier is running on each client computer. Then you would have a potential deployment hassle when business rules change because each client computer would need to be upated.

The experts in the area of remoting are Ingo Rammer (http://www.dotnetremoting.cc) who wrote the most important book to date on the subject of remoting: Advanced .NET Remoting. Although it has "advanced" in the title, the first few chapters give you a full account of the basics of remoting too. I have not read the whole thing, just a few chapters.
The other guy a learned a lot from is Brent Rector of Wintellect, who explained that Web Services are about exchanging DATA between applications and Remoting is about exchanging OBJECTS between application.