I've worked a fair amount with SOAP, WSDL, and XSD both in and out of .NET, though I had no experience with any remoting.
As I've finally gotten around to reading more in-depth about .NET remoting, I immediately started to wonder what the differences were between a WebService and remoting over an HTTP channel with a SOAP formatter. Both are a SOAP (XML) message transported on HTTP. And message sinks could, in some respects, be implemented as an HTTPModule or the like.
A quick google turned up a great article written by Priya Dhawan and Tim Ewald on just these points.
As the introduction points out,
A .NET Remoting object using the SOAP formatter can be exposed as an XML Web service when hosted in IIS with ASP.NET. Since the payload is encoded in SOAP over HTTP, any client that supports the SOAP Encoding format can access the objects over the Internet.
Hmmm.. Ok. This is explored more in-depth in the aptly-titled section, "Muddying the Waters".
The presence of a SOAP formatter and an HTTP channel begs the question: Can .NET Remoting be used to build Web services? The answer is yes and no.
There are of course limitations and differences between the two models, which the article nicely walks through, so I won't rehash that here.
Besides whether the consumer will be aware of runtime specifications of the CLR, performance is also a key consideration.
In almost all the tests that we carried out to compare the relative performance of ASP.NET Web services and .NET Remoting, ASP.NET Web services outperformed .NET Remoting endpoints that used the SOAP formatter with either the HTTP or the TCP channel. More interestingly, ASP.NET and .NET Remoting endpoints that used the binary formatter and the HTTP channel were very similar in performance.
Interesting results indeed.
I went into this thinking that I would use .NET remoting over HTTP because it was more lightweight than XML WebServices. Now I'm not so sure. I am going to have to do some performance tests to see what works best for me.
Just another example of why such design choices can't always and shouldn't be prescriptive.