>We've been told to look at .NET 'remoting' and 'marshalling'. It's been suggested that this is faster and more efficient than sending and receiving datasets. I haven't been able to find much relevant information. Admittedly, I always thought that when the remote end sends a dataset to the Web Service [and then receives one back], it's essentially XML 'under the hood'.
>

With remoting, you still send/receive DataSets. Nothing about your architecture changes. Web Services uses remoting under the covers. The difference is that remoting is faster and more flexible. Web Services must use SOAP over HTTP. With remoting you can use a binary message format over TCP. The speed gain is something like a factor of 5. One big drawback of remoting: it can only be accessed by a .NET client. Therefore, if you are using .NET clients (homogeneous) on the intranet behind a firewall, use Remoting. If your clients are not .NET or are outside of the firewall, use Web Services.

The best solution is to use a combination of both:
COM/non-windows/business partner clients use web services front end using soap. The web server running the web service has the .net runtime so it can be a client to the .NET remoting server which runs your business objects. (The Web serivice becomes a facade, just mapping web methods back to the remoting server for the benefit of those clients who cannot talk to the remoting server directly). .NET clients within the intranet can talk directly to the .NET remoting server, so they would get full speed access to the business objects without the soap penaly.

See "ASP.NET Web Services or .NET Remoting: How to Choose" http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/bdadotnetarch16.asp