WCF vs .NET Remoting

Remoting is about distributed objects, while WCF is about services. Remoting is capable of passing object instances between the client and the server, WCF is not. This distinction is much more fundamental than the technicalities like which technology is more efficient, more dead, or whether it can connect .NET to Java, but I have fully realized it only recently, when I was debating what technology to use for communication between two specific .NET apps that we had.

Remoting is conceptually similar to other distributed objects technologies like DCOM, CORBA, and Java RMI. The server holds a stateful object, which the client accesses via a proxy. The client may pass its own objects to the server, and the server may pass more objects to the client. Bidirectional connection is essential, and proxy lifetime issues are a big thing.

WCF is conceptually similar to data-exchanging technologies like HTML, REST, SQL and, to some extent, Win32 API if we ignore callbacks. The client may call the server, but not necessarily vice versa. Only plain data can be exchanged between the client and the server. There are no proxies, and thus lifetime management issues don’t exist. If the server is complex and represents multiple entities, every call must identify the entity it referes to via some kind of moniker: it could be a URL, a table name, or a numeric handle like in Win32 API.

So, Remoting and WCF are not really easily interchangeable except the simplest scenario when the server has only one object and all its methods deal only with plain data.

To illustrate, suppose you have a server that stores some kind of tree. With Remoting you can define the interface as follows:

public interface IRemotingTree
    string Data { get; set; }
    IRemotingTree AddChild(string data);

With WCF you cannot have properties or return callable object, so the interface would look something like this:

public interface IWcfTree
    string GetData(string nodeId);

    void SetData(string nodeId, string value);

    string AddChildNode(string data); // returns node id

This is where similarity with Win32 API comes in: we cannot return multiple objects from the call, so we must specify which tree node is being worked on by sending node ID. If this ID is some opaque token like 0x1234, then this would look like Win32 API. If this ID encodes a path from the root to the node, e.g. “/4/2” (second child of the 4th child of the root), then it would be more like REST.

In any case, unlike Remoting WCF is not object oriented and everything that gets passed around is plain data. What are the implications of that in real life? That’s going to be the topic of a future post.

Leave a Reply

Your email address will not be published. Required fields are marked *