I'm frequently asked the question, "How does .NET Remoting compare with Web servicesaren't they the same technology?" .NET Remoting complements Web servicesit doesn't compete with them. It's true that some pieces of the technology stacks naturally overlap with each otherfor instance, in their ability to send SOAP-formatted messages over an HTTP channel, which both technologies do equally well. However, both technologies offer distinct areas of functionality.
First, .NET Remoting supports a TCP channel and a binary formatter. Removing the need for HTTP headers and selecting a raw formatter improves the performance in most cases. Therefore, if you need to pass multiple requests (for example, thousands of requests per second) across a communication channel, using .NET Remoting with a binary formatter in combination with a TCP channel might give you better performance than using a Web service implementation.
Second, as mentioned, .NET Remoting supports passing by value and passing by reference. You can still pass by value and pass by reference using a Web service, but passing by reference is more difficult to implement. Moreover, storing session state with Web services can be troublesome in some applications, which also can make working with events and callbacks more difficult.
On the other hand, you could argue that the Web services space has more momentum. Many providers that haven't adopted an architecture similar to .NET Remoting have instead selected Web services as their primary transport technology. For solutions that need to dynamically interoperate with other systems using Web services, adopting a pure Web services strategy can be an advantage.
Before you select one of these two communications technologies, look at what each can do and how each can provide solutions for your applications. Select a technology based on its merit, and feel free to use both .NET Remoting and Web services when they complement each other.