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:
[ServiceContract]
public interface IWcfTree
{
[OperationContract]
string GetData(string nodeId);
[OperationContract]
void SetData(string nodeId, string value);
[OperationContract]
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.
Permalink
Your Baktun Shell uses .Net Remoting. .Net Core will not support .Net Remoting. Instead, they recommend HTTP based protocols. So this post seems very relevant.
Any suggestions on how to make Baktun Shell work in .Net Core?
Thank you.
Permalink
Kareem, thank you for the comment. You’d need to build a layer of communication based on WCF I suppose. But to be honest, I am not sure about the reasons to run Baktun shell on .NET core.
It’s a WPF application, so it will not run on Linux, and on Windows you have regular .NET. The only problem with regular .NET I can think of is that you cannot have multiple versions on the same machine. Do you have a particular scenario in mind when you’d really need Baktun shell on .NET core? I am sincerely curious, my imagination runs blank on that one, but I did not give it a very deep thought. Please advise.
Permalink
Our need for .Net Core is not significant, really. The main value we hoped to achieve with .Net Core was moving to the new project format that .Net Standard and .Net Core support.
Doing so means we give up what .Net Framework offers. For example, .Net Remoting because we hope to use your ideas from Baktun Shell. (We are just now starting to see if it will work.)
The real problem that we want to solve is developing code as “modules” that are independently developable and deployable, meaning a team works on their code using versions of packages as needed. Modules have their own UI. However, the main product will run with all the modules, sort of like a plugin model, and will appear as running in one Window.
If we use one AppDomain, then the CLR will load only one version of a assembly, and thus, likely break one of the modules.
We also like the option of having some modules run in their own process (for various reasons that are not relevant to this discussion).
Baktun Shell seems to be a way to solve both of our real needs.
Permalink
After thinking about this some more, the WCF solution you mentioned does not seem a good way to go based on what you described in the post. .Net Remoting “remotes” the object, which somehow allows graphics rendered by WPF to go across a process. I am not sure how that can be done with WCF.
Permalink
In the company I work now, we have a home-grown equivalent of Baktun shell that uses WCF. I did not write it though, and I did not have time to investigate the details, but it proves it’s possibe. Having said that, you probably can follow the “isolate the ugly stuff’ strategy: have all your UI components in .NET standard assemblies, and then one “dirty” loader DLL that knows about remoting and talks to Baktun shell. If I remember correctly, there is no requirement in Baktun shell that the User Control itself implements any of the remoting stuff, but I may be mistaken, it’s been a while.
Permalink
I agree that it is possible. I just assumed it would be much more work. Baktun shell is a surprisingly small but elegant code base given what it accomplishes. (Not trying to be fawning.)
I did think about the design that you mentioned. The “top” layer would be .Net Framework.
I assumed that WPF won’t be in the .Net Standard.
Permalink
Simple article which addresses complex questions. Many thanks for your time.