Remoting and Callbacks

For those of you who don't know what .NET remoting is, it is basically like DCOM with a lot more flexibility built in. Unlike the Win32 world, when a process spins up for managed code there is something called an AppDomain which is sort of like a process within a process. A Win32 process can contain 1 or more AppDomains. Remoting essentially lets two components from different AppDomains talk to each other. This is regardless of whether each component is on the same physical machine or across the network. The following example code will show you how to create a remote object using a binary format over TCP. This is the fastest. For demo purposes, I'm hosting each application in a console. Typically you need some kind of host (or "daemon") like a Windows Service or IIS to host a remoting object. To use IIS, however, you have to run over HTTP instead of TCP (SOAP over HTTP). The nice thing is that IIS gives you the easy of hosting along with its security features, whereas if you implement binary over TCP, you are probably going to host the remoting server object in a Windows Service memory space and have to manually secure it by rolling your own security even sinks or using something like IPSec.

There are actually two examples going on here...one is remoting,  the other is the fact that the remoting call is done asynchronously to avoid blocking the client. Hopefully this doesn't overcomplicate the example, but you should be able to distinguish the two concepts fairly easily. In order for a remoted server object to perform a callback to the client, they have to reside on the same network. So, I went for kind of a "wow factor" but keep in mind that if your clients are behind a firewall, this callback example is essentially worthless. Although I would question why you are using remoting over a firewall instead of using ASMX, but that's another topic.

So, the approach I usually take with remoting is to create a common assembly that contains the "contracts" for the functionality that the server performs. I hate Soapsuds.exe, and I hate when people directly reference the server to get the metadata because quite frankly you never know if you are remoting or loading the server directly into your own AppDomain! So, shared interfaces and/or base classes is the best IMHO, so that's the route I'm going.

The Shared Assembly: TaskManagement.dll

The shared assembly defines an interface for the operation that the remote server object will adhere to. This assembly is simply a class library. You basically see an event being defined and a method that takes no parameters. Additionally you see a "shim" for the callback. This shim is necessary to avoid the requirement of the server needing to have the metadata for each client in order to make the callback. That is, our client needs to know where the server resides to make the call, but...if we create a shim to manage the remoting of delegates, the server only needs to know about the shim, not the client. The shim knows about the client and forwards the communications to the client. Notice that you will be seing MarshalByRefObject...all remoted objects must inherit from this class.